HDMI Intel® Stratix® 10 FPGA IP Design Example User Guide

Download PDF
ID 683701
Date 1/26/2024
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. HDMI Intel® FPGA IP Design Example Quick Start Guide for Intel® Stratix® 10 Devices 2. HDMI 2.1 Design Example (Support FRL = 1) 3. HDMI 2.0 Design Example 4. HDCP Over HDMI 2.0/2.1 Design Example 5. HDMI Intel® Stratix® 10 FPGA IP Design Example User Guide Archives 6. Document Revision History for the HDMI Intel® Stratix® 10 FPGA IP Design Example User Guide
1. HDMI Intel® FPGA IP Design Example Quick Start Guide for Intel® Stratix® 10 Devices x
1.1. Directory Structure 1.2. Generating the Design 1.3. Hardware and Software Requirements 1.4. Simulating the Design 1.5. Compiling and Testing the Design 1.6. Design Limitation 1.7. HDMI Intel® FPGA IP Design Example Parameters
2. HDMI 2.1 Design Example (Support FRL = 1) x
2.1. HDMI 2.1 RX-TX Retransmit Design Block Diagram 2.2. Creating RX-Only or TX-Only Designs 2.3. Hardware and Software Requirements 2.4. Directory Structure 2.5. Design Components 2.6. Dynamic Range and Mastering (HDR) InfoFrame Insertion and Filtering 2.7. Design Software Flow 2.8. Running the Design in Different FRL Rates 2.9. Clocking Scheme 2.10. Interface Signals 2.11. Design RTL Parameters 2.12. Hardware Setup 2.13. Simulation Testbench 2.14. Design Limitations 2.15. Debugging Features
2.5. Design Components x
2.5.1. HDMI TX Components 2.5.2. HDMI RX Components 2.5.3. Top-Level Common Blocks
2.15. Debugging Features x
2.15.1. Software Debugging Message 2.15.2. SCDC Information from the Sink Connected to TX 2.15.3. Clock Frequency Measurement
3. HDMI 2.0 Design Example x
3.1. HDMI RX-TX Retransmit Design Block Diagram 3.2. Creating TX or RX Only Designs 3.3. Design Components 3.4. Dynamic Range and Mastering (HDR) InfoFrame Insertion and Filtering 3.5. Clocking Scheme 3.6. Interface Signals 3.7. Design RTL Parameters 3.8. Hardware Setup 3.9. Simulation Testbench 3.10. Upgrading Your Design
4. HDCP Over HDMI 2.0/2.1 Design Example x
4.1. High-bandwidth Digital Content Protection (HDCP) 4.2. Nios II Processor Software Flow 4.3. Design Walkthrough 4.4. Protection of Encryption Key Embedded in FPGA Design 4.5. Security Considerations 4.6. Debug Guidelines
4.1. High-bandwidth Digital Content Protection (HDCP) x
4.1.1. HDCP Over HDMI Design Example Architecture
4.3. Design Walkthrough x
4.3.1. Set Up the Hardware 4.3.2. Generate the Design 4.3.3. Include HDCP Production Keys 4.3.4. Compile the Design 4.3.5. View the Results
4.3.3. Include HDCP Production Keys x
4.3.3.1. Store plain HDCP production keys in the FPGA (Support HDCP Key Management = 0) 4.3.3.2. Store encrypted HDCP production keys in the external flash memory or EEPROM (Support HDCP Key Management = 1)
4.3.3.1. Store plain HDCP production keys in the FPGA (Support HDCP Key Management = 0) x
4.3.3.1.1. HDCP Key Mapping from DCP Key Files 4.3.3.1.2. hdcp1x_tx_kmem.v and hdcp1x_rx_kmem.v files 4.3.3.1.3. hdcp2x_rx_kmem.v file 4.3.3.1.4. hdcp2x_tx_kmem.v file
4.3.3.2. Store encrypted HDCP production keys in the external flash memory or EEPROM (Support HDCP Key Management = 1) x
4.3.3.2.1. Intel KEYENC 4.3.3.2.2. Key Programmer
4.3.5. View the Results x
4.3.5.1. Push Buttons and LED Functions
4.6. Debug Guidelines x
4.6.1. HDCP Status Signals 4.6.2. Modifying HDCP Software Parameters 4.6.3. Frequently Asked Questions (FAQ)
1. HDMI Intel® FPGA IP Design Example Quick Start Guide for Intel® Stratix® 10 Devices
2. HDMI 2.1 Design Example (Support FRL = 1)
3. HDMI 2.0 Design Example
4. HDCP Over HDMI 2.0/2.1 Design Example
5. HDMI Intel® Stratix® 10 FPGA IP Design Example User Guide Archives
6. Document Revision History for the HDMI Intel® Stratix® 10 FPGA IP Design Example User Guide

2.5.3. Top-Level Common Blocks

The top-level common blocks include the transceiver arbiter, the RX-TX link components, and the CPU subsystem.
Table 14.  Top-Level Common Blocks
Module Description
Transceiver Arbiter

This generic functional block prevents transceivers from recalibrating simultaneously when either RX or TX transceivers within the same physical channel require reconfiguration. The simultaneous recalibration impacts applications where RX and TX transceivers within the same channel are assigned to independent IP implementations.

This transceiver arbiter is an extension to the resolution recommended for merging simplex TX and simplex RX into the same physical channel. This transceiver arbiter also assists in merging and arbitrating the Avalon® memory-mapped RX and TX reconfiguration requests targeting simplex RX and TX transceivers within a channel as the reconfiguration interface port of the transceivers can only be accessed sequentially.

The interface connection between the transceiver arbiter and TX/RX Native PHY/PHY Reset Controller blocks in this design example demonstrates a generic mode that applies for any IP combination using the transceiver arbiter. The transceiver arbiter is not required when only either RX or TX transceiver is used in a channel.

The transceiver arbiter identifies the requester of a reconfiguration through its Avalon® memory-mapped reconfiguration interfaces and ensures that the corresponding tx_reconfig_cal_busy or rx_reconfig_cal_busy is gated accordingly.

For HDMI applications, only RX initiates reconfiguration. By channeling the Avalon® memory-mapped reconfiguration request through the arbiter, the arbiter identifies that the reconfiguration request originates from the RX, which then gates tx_reconfig_cal_busy from asserting and allows rx_reconfig_cal_busy to assert. The gating prevents the TX transceiver from being moved to calibration mode unintentionally.
Note: Because HDMI only requires RX reconfiguration, the tx_reconfig_mgmt_* signals are tied off. Also, the Avalon® memory-mapped interface is not required between the arbiter and the TX Native PHY block. The blocks are assigned to the interface in the design example to demonstrate generic transceiver arbiter connection to TX/RX Native PHY/PHY Reset Controller.
RX-TX Link
  • The video data output and synchronization signals from HDMI RX core loop through a DCFIFO across the RX and TX video clock domains.
  • The auxiliary data port of the HDMI TX core controls the auxiliary data that flow through the DCFIFO through backpressure. The backpressure ensures there is no incomplete auxiliary packet on the auxiliary data port.
  • This block also performs external filtering:
    • Filters the audio data and audio clock regeneration packet from the auxiliary data stream before transmitting to the HDMI TX core auxiliary data port.
    • Filters the High Dynamic Range (HDR) InfoFrame from the HDMI RX auxiliary data and inserts an example HDR InfoFrame to the auxiliary data of the HDMI TX through the Avalon® streaming multiplexer.
CPU Subsystem

The CPU subsystem functions as SCDC and DDC controllers, and source reconfiguration controller.

  • The source SCDC controller contains the I2C master controller. The I2C master controller transfers the SCDC data structure from the FPGA source to the external sink for HDMI 2.0 operation. For example, if the outgoing data stream is 6,000 Mbps, the Nios® II processor commands the I2C master controller to update the TMDS_BIT_CLOCK_RATIO and SCRAMBLER_ENABLE bits of the sink TMDS configuration register to 1.
  • The same I2C master also transfers the DDC data structure (E-EDID) between the HDMI source and external sink.
  • The Nios® II CPU acts as the reconfiguration controller for the HDMI source. The CPU relies on the periodic rate detection from the RX Reconfiguration Management module to determine if the TX requires reconfiguration. The Avalon® memory-mapped slave translator provides the interface between the Nios® II processor Avalon® memory-mapped master interface and the Avalon® memory-mapped slave interfaces of the externally instantiated HDMI source’s IOPLL and TX Native PHY.
  • Perform link training through I2C master interface with external sink
Level Two Title