A newer version of this document is available. Customers should click here to go to the newest version.
3.2. HDCP Over DisplayPort Design Example Architecture
- Sources (TX)
- Sinks (RX)
This design example demonstrates the HDCP system in a repeater device where it accepts data, decrypts, then re-encrypts the data, and finally retransmits data. Repeaters have both DisplayPort inputs and outputs. It instantiates the FIFO buffers to perform a direct DisplayPort video stream pass-through between the DisplayPort sink and source. It may perform some signal processing, such as converting videos into a higher resolution format by replacing the FIFO buffers with the Video and Image Processing (VIP) Suite IP cores.
The following descriptions about the architecture of the design example correspond to the HDCP over DisplayPort design example block diagram. When SUPPORT HDCP KEY MANAGEMENT = 1, the design example hierarchy is slightly different from Figure 11 but the underlying HDCP functions remain the same.
- The HDCP1x and HDCP2x are IPs that are available through the DisplayPort Intel® FPGA IP parameter editor. When you configure the DisplayPort IP in the parameter editor, you can enable and include either HDCP1x or HDCP2x or both IPs as part of the subsystem. With both HDCP IPs enabled, the DisplayPort IP configures itself in the cascade topology where the HDCP2x and HDCP1x IPs are connected back-to-back.
- The HDCP egress interface of the DisplayPort TX sends unencrypted audio video data.
- The unencrypted data gets encrypted by the active HDCP block and sent back into the DisplayPort TX over the HDCP Ingress interface for transmission over the link.
- The CPU subsystem as the authentication master controller ensures that only one of the HDCP TX IPs is active at any given time and the other one is passive.
- Similarly, the HDCP RX also decrypts data received over the link from an external HDCP TX.
- You need to program the HDCP IPs with Digital Content Protection (DCP) issued production keys. Load the following keys:
Table 31. DCP-issued Production Keys HDCP TX/RX Keys HDCP2x TX 16 bytes: Global Constant (lc128) RX
- 16 bytes (same as TX): Global Constant (lc128)
- 320 bytes: RSA Private Key (kprivrx)
- 522 bytes: RSA Public Key Certificate (certrx)
- 5 bytes: TX Key Selection Vector (Aksv)
- 280 bytes: TX Private Device Keys (Akeys)
- 5 bytes: RX Key Selection Vector (Bksv)
- 280 bytes: RX Private Device Keys (Bkeys)
The design example implements the key memories as simple dual-port, dual-clock synchronous RAM. For small key size like HDCP2x TX, the IP implements the key memory using registers in regular logic.Note: Intel does not provide the HDCP production keys with the design example or Intel FPGA IPs under any circumstances. To use the HDCP IPs or the design example, you must become an HDCP adopter and acquire the production keys directly from the Digital Content Protection LLC (DCP).
To run the design example, you either edit the key memory files at compile time to include the production keys or implement logic blocks to securely read the production keys from an external storage device and write them into the key memories at run time.
- You can clock the cryptographic functions implemented in the HDCP2x IP with any frequency up to 200 MHz. The frequency of this clock determines how quickly the HDCP2x authentication operates. You can opt to share the 100 MHz clock used for Nios® II processor but the authentication latency would be doubled compared to using a 200 MHz clock.
- The values that must be exchanged between the HDCP TX and the HDCP RX are communicated over the DisplayPort AUX channel. The AUX controller is embedded within the DisplayPort IP.
- The Nios® II processor acts as the master in the authentication protocol and drives the control and status registers ( Avalon® memory-mapped) of both the HDCP2x and HDCP1x TX IPs. The software drivers implements the authentication protocol state machine including certificate signature verification, master key exchange, locality check, session key exchange, pairing, link integrity check (HDCP1x), and authentication with repeaters, such as topology information propagation and stream management information propagation. The software drivers do not implement any of the cryptographic functions required by the authentication protocol. Instead, the HDCP IP hardware implements all the cryptographic functions ensuring no confidential values can be accessed.
- In a DisplayPort application, the HDCP TX and HDCP RX IPs communicate the HDCP register values over the AUX channel. For a repeater application, the DisplayPort IP is configured in GPU mode where the HDCP registers in DPCD are defined in the embedded Nios® II processor. The Nios® II processor acts as an authentication master for the HDCP RX. The Nios® II processor processes all HDCP register values received from the AUX controller in the DisplayPort sink before sending the values to the HDCP RX IP and vice versa.
- In a true repeater demonstration where propagating topology information upstream is required, the Nios® II processor drives the Repeater Message Port ( Avalon® memory-mapped) of both HDCP2x and HDCP1x RX IPs. The Nios® II processor clears the RX REPEATER bit to 0 when it detects the connected downstream device is not HDCP-capable or when no downstream device is connected. Without downstream connection, the RX system is now an end-point receiver, rather than a repeater. Conversely, the Nios® II processor sets the RX REPEATER bit to 1 upon detecting the downstream device is HDCP-capable.
Did you find the information on this page useful?