HDMI Stratix® 10 FPGA IP Design Example User Guide

ID 683701
Date 4/09/2024
Public
Document Table of Contents

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.