HDMI Arria® 10 FPGA IP Design Example User Guide

Download PDF
ID 683156
Date 4/29/2024
Public
Document Table of Contents
Document Table of Contents x
1. HDMI Intel® FPGA IP Design Example Quick Start Guide for Arria® 10 Devices 2. HDMI 2.1 Design Example (Support FRL = 1) 3. HDMI 2.0 Design Example (Support FRL = 0) 4. HDCP Over HDMI 2.0/2.1 Design Example 5. HDMI Arria® 10 FPGA IP Design Example User Guide Archives 6. Revision History for HDMI Arria® 10 FPGA IP Design Example User Guide
1. HDMI Intel® FPGA IP Design Example Quick Start Guide for Arria® 10 Devices x
1.1. Generating the Design 1.2. Simulating the Design 1.3. Compiling and Testing the Design 1.4. 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.16. Upgrading Your Design
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 (Support FRL = 0) x
3.1. HDMI 2.0 RX-TX Retransmit Design Block Diagram 3.2. Hardware and Software Requirements 3.3. Directory Structure 3.4. Design Components 3.5. Dynamic Range and Mastering (HDR) InfoFrame Insertion and Filtering 3.6. Clocking Scheme 3.7. Interface Signals 3.8. Design RTL Parameters 3.9. Hardware Setup 3.10. Simulation Testbench 3.11. 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 Arria® 10 Devices
2. HDMI 2.1 Design Example (Support FRL = 1)
3. HDMI 2.0 Design Example (Support FRL = 0)
4. HDCP Over HDMI 2.0/2.1 Design Example
5. HDMI Arria® 10 FPGA IP Design Example User Guide Archives
6. Revision History for HDMI Arria® 10 FPGA IP Design Example User Guide

4.6.3. Frequently Asked Questions (FAQ)

Table 57.  Failure Symptoms and Guidelines
Number Failure Symptom Guideline
1. The RX is receiving encrypted video, but the TX is sending a static video in blue or black color. This is due to the unsuccessful TX authentication with external sink. A HDCP-capable repeater must not transmit the video in unencrypted format if the incoming video from the upstream is encrypted. To achieve this, a static video in blue or black colour replaces the outgoing video when the TX HDCP encryption status signal is inactive while the RX HDCP decryption status signal is active.

For the exact guidelines, refer to Security Considerations. However, this behavior may deter the debugging process when enabling the HDCP design. Below is the method to disable the video blocking in the design example:

  1. Locate the following port connection at the top level of the design example. This port belongs to the hdmi_tx_top module.
  2. Modify the port connection into the following line:
2. TX HDCP encryption status signal is active but snow picture is displayed at the downstream sink. This is due to the downstream sink does not decrypt the outgoing encrypted video correctly. Make sure you provide the global constant (LC128) to the TX HDCP IP. The value must be the production value and correct.
3. TX HDCP encryption status signal is unstable or always inactive. This is due to the unsuccessful TX authentication with downstream sink. To facilitate the debugging process, you can enable the DEBUG_MODE_HDCP parameter in hdcp.c.

Refer to Modifying HDCP Software Parameters on the guidelines. The following 3a-3c could be the possible causes of unsuccessful TX authentication.

3a. The software debug log keeps printing this message “HDCP 1.4 is not supported by the downstream (Rx)”. The message indicates the downstream sink does not support both HDCP 2.3 and HDCP 1.4. Make sure the downstream sink supports HDCP 2.3 or HDCP 1.4.
3b. TX authentication fails halfway. This is due to any part of the TX authentication such as signature verification, locality check etc can fail. Make sure the downstream sink is using production key but not facsimile key.
3c. The software debug log keeps printing “Re-authentication is required” after the HDCP authentication is completed. This message indicates the downstream sink has requested re-authentication because the received video was not decrypted correctly. Make sure you provide the global constant (LC128) to the TX HDCP IP. The value must be the production value and the value is correct.
4. RX HDCP decryption status signal is inactive although the upstream source has enabled HDCP. This indicates that the RX HDCP IP has not achieved the authenticated state. By default, the REPEATER_MODE parameter is enabled in the design example. If the REPEATER_MODE is enabled, make sure the TX HDCP IP is authenticated.

When the REPEATER_MODE parameter is enabled, the RX HDCP IP attempts authentication as a repeater if the TX is connected to a HDCP-capable sink. The authentication stops halfway while waiting for the TX HDCP IP to complete the authentication with downstream sink and pass the RECEIVERID_LIST to the RX HDCP IP. Timeout as defined in the HDCP Specification is 2 seconds. If the TX HDCP IP is unable to complete the authentication in this period, the upstream source treats the authentication as fail and initiates re-authentication as specified in the HDCP Specification.

Note:
  • Refer to Modifying HDCP Software Parameters for the method to disable the REPEATER_MODE parameter for debugging purpose. After disabling the REPEATER_MODE parameter, the RX HDCP IP always attempt authentication as an endpoint receiver. The TX HDCP IP does not gate the authentication process.
  • If the REPEATER_MODE parameter is not enabled, make sure the HDCP key provided to the HDCP IP is the production value and the value is correct.
5. RX HDCP decryption status signal is unstable. This means the RX HDCP IP has requested re-authentication right after the authenticated state is achieved. This is probably due to the incoming encrypted video is not decrypted correctly by the RX HDCP IP. Make sure the global constant (LC128) provided to the RX HDCP IP core is production value and the value is correct.
Level Two Title