DisplayPort Intel® Arria 10 FPGA IP Design Example User Guide

Download PDF
ID 683050
Date 11/12/2021
Public

A newer version of this document is available. Customers should click here to go to the newest version.

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 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
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. 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. Creating RX-Only or TX-Only Designs 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
3. HDCP Over DisplayPort Design Example for Intel® Arria® 10 Devices x
3.1. High-bandwidth Digital Content Protection (HDCP) 3.2. HDCP Over DisplayPort Design Example Architecture 3.3. Nios II 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. Set Up the Hardware 3.4.2. Generate the Design 3.4.3. Include HDCP Production Keys 3.4.4. Compile the Design 3.4.5. View the Results
3.4.3. Include HDCP Production Keys x
3.4.3.1. Store plain HDCP production keys in the FPGA (Support HDCP Key Management = 0) 3.4.3.2. Store encrypted HDCP production keys in the external flash memory or EEPROM (Support HDCP Key Management = 1)
3.4.3.1. Store 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. Store 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.4.5. View the Results x
3.4.5.1. LED Functions
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 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

3.3. Nios II Processor Software Flow

The Nios II software flowchart includes the HDCP authentication controls over DisplayPort application.

Figure 14. Nios II Processor Software Flowchart
  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. The Nios® II software prepares the ReceiverID_List and RxInfo values and then writes to the Avalon-MM Repeater Message port of the repeater upstream (RX). The RX then propagates the list to external TX (upstream).
  8. Authentication is complete at this point. The software enables TX encryption.
  9. The software initiates the HDCP1x authentication protocol that includes key exchange and authentication with repeaters.
  10. 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.
  11. 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-MM 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.
Level Two Title