HDMI Intel® Arria 10 FPGA IP Design Example User Guide

ID 683156
Date 7/29/2022
Public
Document Table of Contents

4.1.1. HDCP Over HDMI Design Example Architecture

The HDCP feature protects data as the data is transmitted between devices connected through an HDMI or other HDCP-protected digital interfaces.
The HDCP-protected systems include three types of devices:
  • Sources (TX)
  • Sinks (RX)
  • Repeaters

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 HDMI inputs and outputs. It instantiates the FIFO buffers to perform a direct HDMI video stream pass-through between the HDMI 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.

Figure 29. HDCP Over HDMI Design Example Block Diagram

The following descriptions about the architecture of the design example correspond to the HDCP over HDMI design example block diagram. When SUPPORT FRL = 1 or SUPPORT HDCP KEY MANAGEMENT = 1, the design example hierarchy is slightly different from Figure 29 but the underlying HDCP functions remain the same.

  1. The HDCP1x and HDCP2x are IPs that are available through the HDMI Intel® FPGA IP parameter editor. When you configure the HDMI 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 HDMI IP configures itself in the cascade topology where the HDCP2x and HDCP1x IPs are connected back-to-back.
    • The HDCP egress interface of the HDMI TX sends unencrypted audio video data.
    • The unencrypted data gets encrypted by the active HDCP block and sent back into the HDMI 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.
  2. You need to program the HDCP IPs with Digital Content Protection (DCP) issued production keys. Load the following keys:
    Table 52.  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)
    HDCP1x TX
    • 5 bytes: TX Key Selection Vector (Aksv)
    • 280 bytes: TX Private Device Keys (Akeys)
    RX
    • 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.

  3. 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.
  4. The values that must be exchanged between the HDCP TX and the HDCP RX are communicated over the HDMI DDC interface (I2C serial interface) of the HDCP-protected interface. The HDCP RX must present a logical device on the I2C bus for each link that it supports. The I2C slave is duplicated for HDCP port with device address of 0x74. It drives the HDCP register port (Avalon-MM) of both the HDCP2x and HDCP1x RX IPs.
  5. The HDMI TX uses the I2C master to read the EDID from RX and transfer the SCDC data that is required for HDMI 2.0 operation to RX. The same I2C master that is driven by the Nios II processor is also used to transfer the HDCP messages between TX and RX. The I2C master is embedded in the CPU subsystem.
  6. The Nios II processor acts as the master in the authentication protocol and drives the control and status registers (Avalon-MM) 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.
  7. In a true repeater demonstration where propagating topology information upstream is required, the Nios II processor drives the Repeater Message Port (Avalon-MM) of both HDCP2x and HDCP1x RX IPs. The Nios II processor clears the RX REPEATER bit to 0 when it detects the connected downstream is not HDCP-capable or when no downstream 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 is HDCP-capable.

Did you find the information on this page useful?

Characters remaining:

Feedback Message