1. DisplayPort Intel® FPGA IP Design Example Quick Start Guide 2. DisplayPort Design Examples 3. HDCP Over DisplayPort Design Example for Intel® Arria® 10 Devices 4. DisplayPort Intel® Arria® 10 FPGA IP Design Example User Guide Archives 5. Revision History for DisplayPort Intel® Arria® 10 FPGA IP Design Example User Guide
2.1. Intel® Arria® 10 DisplayPort SST Parallel Loopback Design Features 2.2. Intel® Arria® 10 DisplayPort MST Parallel Loopback Design Features 2.3. Enabling Adaptive Sync Support 2.4. Intel® Arria® 10 DisplayPort SST TX-only or RX-only Design Features 2.5. Design Components 2.6. Clocking Scheme 2.7. Interface Signals and Parameters 2.8. Hardware Setup 2.9. Simulation Testbench 2.10. DisplayPort Transceiver Reconfiguration Flow 2.11. Transceiver Lane Configurations
220.127.116.11. Store encrypted HDCP production keys in the external flash memory or EEPROM (Support HDCP Key Management = 1)
3.3. Nios II Processor Software Flow
The Nios II software flowchart includes the HDCP authentication controls over DisplayPort application.
Figure 15. Nios II Processor Software Flowchart
- The VESA DisplayPort Standard v1.4 supports four link rates (1.62 Gbps, 2.7 Gbps, 5.4 Gbps and 8.1 Gbps). You can dynamically switch from one data rate to another. Transceiver reconfiguration is required to support dynamic link rate switching. The DisplayPort IP design example implements pre-calibration method to reduce the transceiver reconfiguration duration. Upon power-up or push button reset, the DisplayPort reconfiguration block initiates the transceiver reconfiguration to sweep across all supported link rates and all lane counts. After each data rate completes reconfiguration, each data rate recalibrates. After calibration for each data rate completes, the pre-defined calibrated registers will be stored according to the respective date rate.
- When the precalibration step completes, the reconfiguration block is ready to start DisplayPort link training. Whenever the DisplayPort IP sends a new link rate request or hot-plug event, the reconfiguration block initiates reconfiguration to the transceiver. The reconfiguration flow includes retrieving the calibrated register offset value that corresponds to the link rate and reconfiguring the value to the transceiver. No recalibration is required. When reconfiguration completes, the transceiver is ready to receive the link rate and HDCP authentication can be initiated.
- The Nios® II software starts the HDCP activity by commanding the DisplayPort AUX controller to read RxCaps followed by Bcaps from external RX to detect if the downstream device is HDCP-capable, or otherwise:
- If the returned HDCP_CAPABLE bit of RxCaps is 1, the downstream device is HDCP2x-capable.
- If the returned HDCP_CAPABLE bit of Bcaps is 1, the downstream device is HDCP1x-capable.
- If the returned HDCP_CAPABLE bits of both RxCaps and Bcaps are 0, the downstream device is either not HDCP-capable or inactive.
- If the downstream device is previously not HDCP-capable or inactive but is currently HDCP-capable, the software sets the REPEATER bit of the repeater upstream (RX) to 1 to indicate the RX is now a repeater.
- If the downstream device is previously HDCP-capable but is currently not HDCP-capable or inactive, the software sets the REPEATER bit of to 0 to indicate the RX is now an endpoint receiver.
- The software initiates the HDCP2x authentication protocol that includes RX certificate signature verification, master key exchange, locality check, session key exchange, pairing, authentication with repeaters such as topology information propagation.
- When in authenticated state, the Nios® II software processes the CP_IRQ interrupts if there is any, and reads the RxStatus register from external RX. If the software detects the REAUTH_REQ bit is set, it initiates re-authentication and disables TX encryption.
- When the downstream device is a repeater and the READY bit of the RxStatus register is set to 1, this usually indicates the downstream device topology has changed. So, the Nios II software commands the AUX controller to read the ReceiverID_List from downstream device and verify the list. If the list is valid and no topology error is detected, the software proceeds to the Content Stream Management module. Otherwise, it initiates re-authentication and disables TX encryption.
- The Nios® II software prepares the ReceiverID_List and RxInfo values and then writes to the Avalon® Memory-mapped Repeater Message port of the repeater upstream (RX). The RX then propagates the list to external TX (upstream).
- Authentication is complete at this point. The software enables TX encryption.
- The software initiates the HDCP1x authentication protocol that includes key exchange and authentication with repeaters.
- When the Nios® II software encounters CP_IRQ interrupts, it performs link integrity check by reading and comparing Ri’ and Ri from external RX (downstream) and HDCP1x TX respectively. If the values do not match, this indicates loss of synchronization and the software initiates re-authentication and disables TX encryption.
- If the downstream device is a repeater and the READY bit of the Bcaps register is set to 1, this usually indicates that the downstream device topology has changed. So, the Nios® II software commands the AUX controller to read the KSV list value from the downstream device and verify the list. If the list is valid and no topology error is detected, the software prepares the KSV list and Bstatus value and writes to the Avalon® Memory-mapped Repeater Message port of the repeater upstream (RX). The RX then propagates the list to external TX (upstream). Otherwise, it initiates re-authentication and disables TX encryption.
Did you find the information on this page useful?