DisplayPort Arria® 10 FPGA IP Design Example User Guide

ID 683050
Date 4/29/2024
Public
Document Table of Contents

3.6.3. Frequently Asked Questions (FAQ)

Table 31.  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.