HDMI Stratix® 10 FPGA IP Design Example User Guide

Download PDF
ID 683701
Date 4/09/2024
Public
Document Table of Contents
Document Table of Contents x
1. HDMI Intel® FPGA IP Design Example Quick Start Guide for Stratix® 10 Devices 2. HDMI 2.1 Design Example (Support FRL = 1) 3. HDMI 2.0 Design Example 4. HDCP Over HDMI 2.0/2.1 Design Example 5. HDMI Stratix® 10 FPGA IP Design Example User Guide Archives 6. Document Revision History for the HDMI Stratix® 10 FPGA IP Design Example User Guide
1. HDMI Intel® FPGA IP Design Example Quick Start Guide for Stratix® 10 Devices x
1.1. Directory Structure 1.2. Generating the Design 1.3. Hardware and Software Requirements 1.4. Simulating the Design 1.5. Compiling and Testing the Design 1.6. Design Limitation 1.7. HDMI Intel® FPGA IP Design Example Parameters
2. HDMI 2.1 Design Example (Support FRL = 1) x
2.1. HDMI 2.1 RX-TX Retransmit Design Block Diagram 2.2. Creating RX-Only or TX-Only Designs 2.3. Hardware and Software Requirements 2.4. Directory Structure 2.5. Design Components 2.6. Dynamic Range and Mastering (HDR) InfoFrame Insertion and Filtering 2.7. Design Software Flow 2.8. Running the Design in Different FRL Rates 2.9. Clocking Scheme 2.10. Interface Signals 2.11. Design RTL Parameters 2.12. Hardware Setup 2.13. Simulation Testbench 2.14. Design Limitations 2.15. Debugging Features
2.5. Design Components x
2.5.1. HDMI TX Components 2.5.2. HDMI RX Components 2.5.3. Top-Level Common Blocks
2.15. Debugging Features x
2.15.1. Software Debugging Message 2.15.2. SCDC Information from the Sink Connected to TX 2.15.3. Clock Frequency Measurement
3. HDMI 2.0 Design Example x
3.1. HDMI RX-TX Retransmit Design Block Diagram 3.2. Creating TX or RX Only Designs 3.3. Design Components 3.4. Dynamic Range and Mastering (HDR) InfoFrame Insertion and Filtering 3.5. Clocking Scheme 3.6. Interface Signals 3.7. Design RTL Parameters 3.8. Hardware Setup 3.9. Simulation Testbench 3.10. Upgrading Your Design
4. HDCP Over HDMI 2.0/2.1 Design Example x
4.1. High-bandwidth Digital Content Protection (HDCP) 4.2. Nios® V Processor Software Flow 4.3. Design Walkthrough 4.4. Protection of Encryption Key Embedded in FPGA Design 4.5. Security Considerations 4.6. Debug Guidelines
4.1. High-bandwidth Digital Content Protection (HDCP) x
4.1.1. HDCP Over HDMI Design Example Architecture
4.3. Design Walkthrough x
4.3.1. Setting Up the Hardware 4.3.2. Generating the Design 4.3.3. Including HDCP Production Keys 4.3.4. Compiling the Design 4.3.5. Viewing the Results
4.3.3. Including HDCP Production Keys x
4.3.3.1. Storing Plain HDCP Production Keys in the FPGA (Support HDCP Key Management = 0) 4.3.3.2. Storing Encrypted HDCP Production Keys in the External Flash Memory or EEPROM (Support HDCP Key Management = 1)
4.3.3.1. Storing Plain HDCP Production Keys in the FPGA (Support HDCP Key Management = 0) x
4.3.3.1.1. HDCP Key Mapping from DCP Key Files 4.3.3.1.2. hdcp1x_tx_kmem.v and hdcp1x_rx_kmem.v files 4.3.3.1.3. hdcp2x_rx_kmem.v file 4.3.3.1.4. hdcp2x_tx_kmem.v file
4.3.3.2. Storing Encrypted HDCP Production Keys in the External Flash Memory or EEPROM (Support HDCP Key Management = 1) x
4.3.3.2.1. Intel KEYENC 4.3.3.2.2. Key Programmer
4.3.5. Viewing the Results x
4.3.5.1. Push Buttons and LED Functions
4.6. Debug Guidelines x
4.6.1. HDCP Status Signals 4.6.2. Modifying HDCP Software Parameters 4.6.3. Frequently Asked Questions (FAQ)
1. HDMI Intel® FPGA IP Design Example Quick Start Guide for Stratix® 10 Devices
2. HDMI 2.1 Design Example (Support FRL = 1)
3. HDMI 2.0 Design Example
4. HDCP Over HDMI 2.0/2.1 Design Example
5. HDMI Stratix® 10 FPGA IP Design Example User Guide Archives
6. Document Revision History for the HDMI Stratix® 10 FPGA IP Design Example User Guide

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® V 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® V 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® V processor acts as the master in the authentication protocol and drives the control and status registers ( Avalon® memory-mapped interface) 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® V processor drives the Repeater Message Port ( Avalon® memory-mapped interface) of both HDCP2x and HDCP1x RX IPs. The Nios® V 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® V processor sets the RX REPEATER bit to 1 upon detecting the downstream is HDCP-capable.
Level Two Title