DisplayPort Stratix® 10 FPGA IP Design Example User Guide

Download PDF
ID 683887
Date 4/10/2024
Public
Document Table of Contents
Document Table of Contents x
1. DisplayPort Intel® FPGA IP Design Example Quick Start Guide 2. Parallel Loopback Design Examples 3. HDCP Over DisplayPort Design Example 4. DisplayPort Stratix® 10 FPGA IP Design Example User Guide Archives 5. Revision History for the DisplayPort Stratix® 10 FPGA IP Design Example User Guide
1. DisplayPort Intel® FPGA IP Design Example Quick Start Guide x
1.1. Directory Structure 1.2. Hardware and Software Requirements 1.3. Generating the Design 1.4. Simulating the Design 1.5. Compiling and Testing the Design 1.6. DisplayPort Intel® FPGA IP Design Example Parameters
1.5. Compiling and Testing the Design x
1.5.1. Regenerating ELF File
2. Parallel Loopback Design Examples x
2.1. Stratix® 10 DisplayPort SST Parallel Loopback Design Features 2.2. Stratix® 10 DisplayPort SST TX-only or RX-only Design Features 2.3. Design Components 2.4. Clocking Scheme 2.5. Interface Signals and Parameters 2.6. Hardware Setup 2.7. Simulation Testbench 2.8. DisplayPort Transceiver Reconfiguration Flow 2.9. Transceiver Lane Configurations
2.1. Stratix® 10 DisplayPort SST Parallel Loopback Design Features x
2.1.1. DisplayPort 2.0 UHBR10 (10 Gbps) Data Rate Support 2.1.2. DisplayPort 2.0 UHBR20 (20 Gbps) Data Rate Support 2.1.3. Enabling Adaptive Sync Support
2.2. Stratix® 10 DisplayPort SST TX-only or RX-only Design Features x
2.2.1. Stratix® 10 DisplayPort SST TX-only Design Features 2.2.2. Stratix® 10 DisplayPort SST RX-only Design Features
3. HDCP Over DisplayPort Design Example x
3.1. High-bandwidth Digital Content Protection (HDCP) 3.2. HDCP Over DisplayPort Design Example Architecture 3.3. Nios® V Processor Software Flow 3.4. Design Walkthrough 3.5. Protection of Encryption Key Embedded in FPGA Design 3.6. Debug Guidelines
3.4. Design Walkthrough x
3.4.1. Setting Up the Hardware 3.4.2. Generating the Design 3.4.3. Including HDCP Production Keys 3.4.4. Compiling the Design 3.4.5. Viewing the Results
3.4.3. Including HDCP Production Keys x
3.4.3.1. Storing Plain HDCP Production Keys in the FPGA (Support HDCP Key Management = 0) 3.4.3.2. Storing Encrypted HDCP Production Keys in the External Flash Memory or EEPROM (Support HDCP Key Management = 1)
3.4.3.1. Storing Plain HDCP Production Keys in the FPGA (Support HDCP Key Management = 0) x
3.4.3.1.1. HDCP Key Mapping from DCP Key Files 3.4.3.1.2. hdcp1x_tx_kmem.v and hdcp1x_rx_kmem.v files 3.4.3.1.3. hdcp2x_rx_kmem.v file 3.4.3.1.4. hdcp2x_tx_kmem.v file
3.4.3.2. Storing Encrypted HDCP Production Keys in the External Flash Memory or EEPROM (Support HDCP Key Management = 1) x
3.4.3.2.1. Intel KEYENC 3.4.3.2.2. Key Programmer
3.5. Protection of Encryption Key Embedded in FPGA Design x
3.5.1. Security Considerations
3.6. Debug Guidelines x
3.6.1. HDCP Status Signals 3.6.2. Modifying HDCP Software Parameters 3.6.3. Frequently Asked Questions (FAQ)
1. DisplayPort Intel® FPGA IP Design Example Quick Start Guide
2. Parallel Loopback Design Examples
3. HDCP Over DisplayPort Design Example
4. DisplayPort Stratix® 10 FPGA IP Design Example User Guide Archives
5. Revision History for the DisplayPort Stratix® 10 FPGA IP Design Example User Guide

3.6.3. Frequently Asked Questions (FAQ)

Table 33.  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 colour. This is due to an unsuccessful TX authentication with external sink. An 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 behaviour may deter the debugging process when enabling the HDCP design. Use the following 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. Use 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 not decrypting the outgoing encrypted video correctly. Make sure you provide the global constant (LC128) to the TX HDCP IP. The value must be the correct production value.
3. TX HDCP encryption status signal is unstable or always inactive. This is due to an unsuccessful TX authentication with downstream sink. To facilitate the debugging process, enable the DEBUG_MODE_HDCP parameter in hdcp.c.

Refer to Modifying HDCP Software Parameters for the guidelines.

The following cases 3a-3c are the possible causes of an unsuccessful TX authentication.
3a. The software debug log keeps printing “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.3. Make sure the downstream sink supports HDCP 2.3 or HDCP 1.3.
3b. TX authentication fails halfway. This is due to any part of the TX authentication, such as signature verification and locality check 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 completion ofHDCP authentication. 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 correct production value.
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 within this period, the upstream source treats the authentication as a failure 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 attempts 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 correct production value.
5 RX HDCP decryption status signal is unstable. This means that the RX HDCP IP has requested re-authentication right after the authenticated state is achieved. This is probably due to the incoming encrypted video not having been decrypted correctly by the RX HDCP IP. Make sure the global constant (LC128) provided to the RX HDCP IP core is the correct production value.
Level Two Title