HDMI Intel FPGA IP User Guide
Version Information
Updated for: |
---|
Intel® Quartus® Prime Design Suite 19.3 |
IP Version 19.1.0 |
1. HDMI Intel FPGA IP Quick Reference
Information | Description | |
---|---|---|
IP Core Information | Core Features |
|
Typical Application |
|
|
Device Family | Supports Intel® Stratix® 10 (H-tile and L-tile), Intel® Arria® 10, Intel® Cyclone® 10 GX, Arria® V, and Stratix® V FPGA devices | |
Design Tools |
|
2. HDMI Overview
- Internal connections—interface within a PC and monitor
- External display connections—interface between a PC and monitor or projector, between a PC and TV, or between a device such a DVD player and TV display.
The HDMI system architecture consists of sinks and sources. A device may have one or more HDMI inputs and outputs.
The HDMI cable and connectors carry four differential pairs that make up the Transition Minimized Differential Signaling (TMDS) data and clock channels. You can use these channels to carry video, audio, and auxiliary data.
The HDMI also carries a Video Electronics Standards Association (VESA) Display Data Channel (DDC) and Status and Control Data Channel (SCDC). The DDC configures and exchanges status between a single source and a single sink. The source uses the DDC to read the sink's Enhanced Extended Display Identification Data (E-EDID) to discover the sink's configuration and capabilities.
The optional Consumer Electronics Control (CEC) protocol provides high-level control functions between various audio visual products in your environment.
The optional HDMI Ethernet and Audio Return Channel (HEAC) provides Ethernet compatible data networking between connected devices and an audio return channel in the opposite direction of TMDS. The HEAC also uses Hot-Plug Detect (HPD) line for link detection.
Based on TMDS encoding, the HDMI protocol allows the transmission of both audio and video data between source and sink devices.
An HDMI interface consists of three color channels accompanied by a single clock channel. You can use each color line to transfer both individual RGB colors and auxiliary data.
The receiver uses the TMDS clock as a frequency reference for data recovery on the three TMDS data channels. This clock typically runs at the video pixel rate.
TMDS encoding is based on an 8-bit to 10-bit algorithm. This protocol attempts to minimize data channel transition, and yet maintain sufficient transition so that a sink device can lock reliably to the data stream.
- Data stream in green—transports color data
- Data stream in dark blue—transports auxiliary data
Data | Description |
---|---|
Video data |
|
Auxiliary data |
|
Each data stream section is preceded with guard bands and pre-ambles. The guard bands and pre-ambles allow for accurate synchronization with received data streams.
The following figures show the arrangement of the video data, video data enable, video H-SYNC, and video V-SYNC in 1, 2, and 4 symbols per clock.
2.1. Release Information
IP versions are the same as the Intel® Quartus® Prime Design Suite software versions up to v19.1. From Intel® Quartus® Prime Design Suite software version 19.2 or later, IP cores have a new IP versioning scheme.
The IP versioning scheme (X.Y.Z) number changes from one software version to another. A change in:
- X indicates a major revision of the IP. If you update your Intel Quartus Prime software, you must regenerate the IP.
- Y indicates the IP includes new features. Regenerate your IP to include these new features.
- Z indicates the IP includes minor changes. Regenerate your IP to include these changes.
Item |
Description |
---|---|
IP Version |
19.1.0 |
Intel® Quartus® Prime Version |
19.3 |
Release Date |
September 2019 |
Ordering Code |
IP-HDMI |
2.2. Device Family Support
Device Family | Support Level |
---|---|
Intel® Stratix® 10 (H-tile and L-tile) | Final |
Intel® Arria® 10 | Final |
Intel® Cyclone® 10 GX | Final |
Arria V | Final |
Stratix V | Final |
The following terms define device support levels for Intel FPGA IP cores:
- Advance support—the IP core is available for simulation and compilation for this device family. Timing models include initial engineering estimates of delays based on early post-layout information. The timing models are subject to change as silicon testing improves the correlation between the actual silicon and the timing models. You can use this IP core for system architecture and resource utilization studies, simulation, pinout, system latency assessments, basic timing assessments (pipeline budgeting), and I/O transfer strategy (data-path width, burst depth, I/O standards tradeoffs).
- Preliminary support—the IP core is verified with preliminary timing models for this device family. The IP core meets all functional requirements, but might still be undergoing timing analysis for the device family. It can be used in production designs with caution.
- Final support—the IP core is verified with final timing models for this device family. The IP core meets all functional and timing requirements for the device family and can be used in production designs.
2.3. Resource Utilization
Devices | Maximum Data Rate (Mbps) | ||
---|---|---|---|
1 Symbol per Clock | 2 Symbols per Clock | 4 Symbols per Clock | |
Intel® Stratix® 10 | Not Supported | 5,940 (Example: 4Kp60 8 bpc) |
Not Supported |
Intel® Arria® 10 | Not Supported | 5,940 (Example: 4Kp60 8 bpc) |
Not Supported |
Intel® Cyclone® 10 GX | Not Supported | 5,940 (Example: 4Kp60 8 bpc) |
Not Supported |
Arria V GX | 1,875 (Example: 1080p60 10 bpc) |
3,276.8 (Example: 4Kp30 8 bpc) |
5,940 (Example: 4Kp60 8 bpc) |
Stratix V | 2,970 (Example: 4Kp30 8 bpc) |
5,940 (Example: 4Kp60 8 bpc) |
Not Supported |
Pixel Encoding | Color Depth | |||
---|---|---|---|---|
8 | 10 | 12 | 16 | |
RGB | Yes | Yes | Yes | Yes |
YCbCr 4:4:4 | Yes | Yes | Yes | Yes |
YCbCr 4:2:21 | Yes | Yes | Yes | Not applicable |
YCbCr 4:2:0 | Yes | Yes | Yes | Yes |
Device | Symbols per Clock | Direction | ALMs | Logic Registers | Memory | ||
---|---|---|---|---|---|---|---|
Primary | Secondary | Bits | M10K or M20K | ||||
Intel® Stratix® 10 H-tile | 2 | RX | 5.041 | 6,633 | 902 | 38,400 | 14 |
2 | TX | 4,975 | 7,559 | 1,368 | 37,568 | 13 | |
Intel® Stratix® 10 L-tile | 2 | RX | 5,025 | 6,584 | 967 | 38,400 | 14 |
2 | TX | 4,966 | 7,539 | 1,425 | 37,568 | 13 | |
Intel® Arria® 10 | 2 | RX | 3,952 | 5,716 | 1,049 | 38,400 | 14 |
2 | TX | 4,422 | 7,016 | 1,701 | 36,968 | 13 | |
Intel® Cyclone® 10 GX | 2 | RX | 4,000 | 5,768 | 965 | 38,400 | 14 |
2 | TX | 4,484 | 7,167 | 1,629 | 36,968 | 13 | |
Arria V GX | 1 | RX | 2,630 | 4,039 | 402 | 35,712 | 13 |
1 | TX | 2,700 | 4,462 | 417 | 11,108 | 11 | |
2 | RX | 3,446 | 4,656 | 531 | 38,400 | 14 | |
2 | TX | 3,759 | 6,091 | 450 | 12,680 | 13 | |
4 | RX | 4,895 | 5,937 | 614 | 43,776 | 20 | |
4 | TX | 6,135 | 9,156 | 445 | 15,824 | 18 | |
Stratix V | 1 | RX | 2,592 | 3,946 | 398 | 35,712 | 13 |
1 | TX | 2,634 | 4,415 | 461 | 11,108 | 11 | |
2 | RX | 3,337 | 4,619 | 440 | 38,400 | 14 | |
2 | TX | 3,644 | 5,919 | 680 | 12,680 | 13 |
Device | Lane Rate (Mbps) | Interface Width (bits) | Speed Grades |
---|---|---|---|
Intel® Stratix® 10 | 6,000 | 20 | -1, -2 |
Intel® Arria® 10 | 6,000 | 20 | -1, -2 |
Intel® Cyclone® 10 GX | 6,000 | 20 | -5 |
HDCP IP | ALMs | Combinatorial ALUTs | Registers | M20K | DSP |
---|---|---|---|---|---|
HDCP 2.3 TX | 6,336 | 10,568 | 12,004 | 10 | 3 |
HDCP 2.3 RX | 6,950 | 11,768 | 12,648 | 11 | 3 |
HDCP 1.4 TX | 1,815 | 3,019 | 3,886 | 2 | 0 |
HDCP 1.4 RX | 1,368 | 2,315 | 3,108 | 3 | 0 |
3. HDMI Intel FPGA IP Getting Started
3.1. Installing and Licensing Intel FPGA IP Cores
The Intel® Quartus® Prime software installs IP cores in the following locations by default:
Location | Software | Platform |
---|---|---|
<drive>:\intelFPGA_pro\quartus\ip\altera | Intel® Quartus® Prime Pro Edition | Windows* |
<drive>:\intelFPGA\quartus\ip\altera | Intel® Quartus® Prime Standard Edition | Windows |
<home directory>:/intelFPGA_pro/quartus/ip/altera | Intel® Quartus® Prime Pro Edition | Linux* |
<home directory>:/intelFPGA/quartus/ip/altera | Intel® Quartus® Prime Standard Edition | Linux |
3.1.1. Intel FPGA IP Evaluation Mode
- Simulate the behavior of a licensed Intel® FPGA IP core in your system.
- Verify the functionality, size, and speed of the IP core quickly and easily.
- Generate time-limited device programming files for designs that include IP cores.
- Program a device with your IP core and verify your design in hardware.
Intel® FPGA IP Evaluation Mode supports the following operation modes:
- Tethered—Allows running the design containing the licensed Intel® FPGA IP indefinitely with a connection between your board and the host computer. Tethered mode requires a serial joint test action group (JTAG) cable connected between the JTAG port on your board and the host computer, which is running the Intel® Quartus® Prime Programmer for the duration of the hardware evaluation period. The Programmer only requires a minimum installation of the Intel® Quartus® Prime software, and requires no Intel® Quartus® Prime license. The host computer controls the evaluation time by sending a periodic signal to the device via the JTAG port. If all licensed IP cores in the design support tethered mode, the evaluation time runs until any IP core evaluation expires. If all of the IP cores support unlimited evaluation time, the device does not time-out.
- Untethered—Allows running the design containing the licensed IP for a limited time. The IP core reverts to untethered mode if the device disconnects from the host computer running the Intel® Quartus® Prime software. The IP core also reverts to untethered mode if any other licensed IP core in the design does not support tethered mode.
When the evaluation time expires for any licensed Intel® FPGA IP in the design, the design stops functioning. All IP cores that use the Intel® FPGA IP Evaluation Mode time out simultaneously when any IP core in the design times out. When the evaluation time expires, you must reprogram the FPGA device before continuing hardware verification. To extend use of the IP core for production, purchase a full production license for the IP core.
You must purchase the license and generate a full production license key before you can generate an unrestricted device programming file. During Intel® FPGA IP Evaluation Mode, the Compiler only generates a time-limited device programming file (<project name> _time_limited.sof) that expires at the time limit.
Intel® licenses IP cores on a per-seat, perpetual basis. The license fee includes first-year maintenance and support. You must renew the maintenance contract to receive updates, bug fixes, and technical support beyond the first year. You must purchase a full production license for Intel® FPGA IP cores that require a production license, before generating programming files that you may use for an unlimited time. During Intel® FPGA IP Evaluation Mode, the Compiler only generates a time-limited device programming file (<project name> _time_limited.sof) that expires at the time limit. To obtain your production license keys, visit the Self-Service Licensing Center.
The Intel® FPGA Software License Agreements govern the installation and use of licensed IP cores, the Intel® Quartus® Prime design software, and all unlicensed IP cores.
3.2. Specifying IP Core Parameters and Options
- Create a Intel® Quartus® Prime project using the New Project Wizard available from the File menu.
- On the Tools menu, click IP Catalog.
-
Under Installed IP,
double-click Library > Interface > Protocols > Audio&Video >
HDMI Intel® FPGA
.
The parameter editor appears.
- Specify a top-level name for your custom IP variation. This name identifies the IP core variation files in your project. If prompted, also specify the targeted FPGA device family and output file HDL preference. Click OK.
-
Specify parameters and options in the HDMI parameter editor:
- Optionally select preset parameter values. Presets specify all initial parameter values for specific applications (where provided).
- Specify parameters defining the IP core functionality, port configurations, and device-specific features.
- Specify options for generation of a timing netlist, simulation model, testbench, or example design (where applicable).
- Specify options for processing the IP core files in other EDA tools.
- Click Generate to generate the IP core and supporting files, including simulation models.
- Click Close when file generation completes.
- Click Finish.
- If you generate the HDMI Intel® FPGA IP core instance in a Intel® Quartus® Prime project, you are prompted to add Intel® Quartus® Prime IP File (.qip) and Intel® Quartus® Prime Simulation IP File (.sip) to the current Intel® Quartus® Prime project.
4. HDMI Hardware Design Examples
The implementation of the HDMI Intel® FPGA IP on hardware requires additional components specific to the targeted device.
4.1. HDMI Hardware Design Examples for Intel Arria 10, Intel Cyclone 10 GX, and Intel Stratix 10 Devices
4.2. HDCP Over HDMI Design Example for Intel Arria 10 Devices
The HDCP over HDMI hardware design example helps you to evaluate the functionality of the HDCP feature and enables you to use the feature in your Intel® Arria® 10 designs.
4.2.1. High-bandwidth Digital Content Protection (HDCP)
Intel created the original technology, which is licensed by the Digital Content Protection LLC group. HDCP is a copy protection method where the audio/video stream is encrypted between the transmitter and the receiver, protecting it against illegal copying.
The HDCP features adheres to HDCP Specification version 1.4 and HDCP Specification version 2.3.
The HDCP 1.4 and HDCP 2.3 IPs perform all computation within the hardware core logic with no confidential values (such as private key and session key) being accessible from outside the encrypted IP.
HDCP IP | Functions |
---|---|
HDCP 1.4 IP |
|
HDCP 2.3 IP |
|
4.2.2. HDCP Over HDMI Design Example Architecture
- Sources (TX)
- Sinks (RX)
- Repeaters
This design example demonstrates the HDCP system in a repeater device where it accepts data, decrypts, then re-encrypts the data, and finally retransmits data. Repeaters have both HDMI inputs and outputs. It instantiates the FIFO buffers to perform a direct HDMI video stream pass-through between the HDMI sink and source. It may perform some signal processing, such as converting videos into a higher resolution format by replacing the FIFO buffers with the Video and Image Processing (VIP) Suite IP cores.
The following descriptions about the architecture of the design example correspond to the HDCP over HDMI design example block diagram.
- The HDCP1x and HDCP2x are IPs that are available through the HDMI Intel® FPGA IP parameter editor. When you configure the
HDMI IP in the parameter editor, you can enable and include either HDCP1x or HDCP2x or both
IPs as part of the subsystem. With both HDCP IPs enabled, the HDMI IP configures itself in
the cascade topology where the HDCP2x and HDCP1x IPs are connected back-to-back.
- The HDCP egress interface of the HDMI TX sends unencrypted audio video data.
- The unencrypted data gets encrypted by the active HDCP block and sent back into the HDMI TX over the HDCP Ingress interface for transmission over the link.
- The CPU subsystem as the authentication master controller ensures that only one of the HDCP TX IPs is active at any given time and the other one is passive.
- Similarly, the HDCP RX also decrypts data received over the link from an external HDCP TX.
- You need to program the HDCP IPs with Digital Content Protection (DCP)
issued production keys. Load the following keys:
Table 11. DCP-issued Production Keys HDCP TX/RX Keys HDCP2x TX 16 bytes: Global Constant (lc128) RX - 16 bytes (same as TX): Global Constant (lc128)
- 320 bytes: RSA Private Key (kprivrx)
- 522 bytes: RSA Public Key Certificate (certrx)
HDCP1x TX - 5 bytes: TX Key Selection Vector (Aksv)
- 280 bytes: TX Private Device Keys (Akeys)
RX - 5 bytes: RX Key Selection Vector (Bksv)
- 280 bytes: RX Private Device Keys (Bkeys)
The design example implements the key memories as simple dual-port, dual-clock synchronous RAM. For small key size like HDCP2x TX, the IP implements the key memory using registers in regular logic.
Note: Intel does not provide the HDCP production keys with the design example or Intel® FPGA IPs under any circumstances. To use the HDCP IPs or the design example, you must become an HDCP adopter and acquire the production keys directly from the Digital Content Protection LLC (DCP).To run the design example, you either edit the key memory files at compile time to include the production keys or implement logic blocks to securely read the production keys from an external storage device and write them into the key memories at run time.
- You can clock the cryptographic functions implemented in the HDCP2x IP with any frequency up to 200 MHz. The frequency of this clock determines how quickly the HDCP2x authentication operates. You can opt to share the 100 MHz clock used for Nios II processor but the authentication latency would be doubled compared to using a 200 MHz clock.
- The values that must be exchanged between the HDCP TX and the HDCP RX are communicated over the HDMI DDC interface (I2C serial interface) of the HDCP-protected interface. The HDCP RX must present a logical device on the I2C bus for each link that it supports. The I2C slave is duplicated for HDCP port with device address of 0x74. It drives the HDCP register port (Avalon-MM) of both the HDCP2x and HDCP1x RX IPs.
- The HDMI TX uses the I2C master to read the EDID from RX and transfer the SCDC data that is required for HDMI 2.0 operation to RX. The same I2C master that is driven by the Nios II processor is also used to transfer the HDCP messages between TX and RX. The I2C master is embedded in the CPU subsystem.
- The Nios II processor acts as the master in the authentication protocol and drives the control and status registers (Avalon-MM) of both the HDCP2x and HDCP1x TX IPs. The software drivers implements the authentication protocol state machine including certificate signature verification, master key exchange, locality check, session key exchange, pairing, link integrity check (HDCP1x), and authentication with repeaters, such as topology information propagation and stream management information propagation. The software drivers do not implement any of the cryptographic functions required by the authentication protocol. Instead, the HDCP IP hardware implements all the cryptographic functions ensuring no confidential values can be accessed.
- In a true repeater demonstration where propagating topology information upstream is required, the Nios II processor drives the Repeater Message Port (Avalon-MM) of both HDCP2x and HDCP1x RX IPs. The Nios II processor clears the RX REPEATER bit to 0 when it detects the connected downstream is not HDCP-capable or when no downstream is connected. Without downstream connection, the RX system is now an end-point receiver, rather than a repeater. Conversely, the Nios II processor sets the RX REPEATER bit to 1 upon detecting the downstream is HDCP-capable.
4.2.3. Nios II Processor Software Flow
The Nios II software flowchart includes the HDCP authentication controls over HDMI application.
- The Nios II software initializes and resets the HDMI TX PLL, TX transceiver PHY, I2C master and the external TI retimer.
- The Nios II software polls periodic rate detection valid signal from RX rate detection circuit to determine whether video resolution has changed and if TX reconfiguration is required. The software also polls the TX hot-plug detect signal to determine whether a TX hot-plug event has occurred.
- When a valid signal received from RX rate detection circuit, the Nios II software reads the SCDC and clock depth values from the HDMI RX and retrieves the clock frequency band based on the detected rate to determine whether HDMI TX PLL and transceiver PHY reconfiguration are required. If TX reconfiguration is required, the Nios II software commands the I2C master to send the SCDC value over to external RX. It then commands to reconfigure the HDMI TX PLL and TX transceiver PHY, followed by device recalibration, and reset sequence. If the rate does not change, neither TX reconfiguration nor HDCP re-authentication is required.
- When a TX hot-plug event has occurred, the Nios II software commands the I2C master to send the SCDC value over to external RX, and then read EDID from RX and update the internal EDID RAM. The software then propagates the EDID information to the upstream.
- The Nios II software starts the HDCP activity by commanding the I2C master to
read offset 0x50 from external RX to detect if the downstream is HDCP-capable, or otherwise:
- If the returned HDCP2Version value is 1, the downstream is HDCP2x-capable.
- If the returned value of the entire 0x50 reads are 0’s, the downstream is HDCP1x-capable.
- If the returned value of the entire 0x50 reads are 1’s, the downstream is either not HDCP-capable or inactive.
- If the downstream 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 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 commands the I2C master to poll the RxStatus register from external RX, and if the software detects the REAUTH_REQ bit is set, it initiates re-authentication and disables TX encryption.
- When the downstream is a repeater and the READY bit of the RxStatus register is set to 1, this usually indicates the downstream topology has changed. So, the Nios II software commands the I2C master to read the ReceiverID_List from downstream 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-MM 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.
- The Nios II software 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 is a repeater and the READY bit of the Bcaps register is set to 1, this usually indicates that the downstream topology has changed. So, the Nios II software commands the I2C master to read the KSV list value from downstream 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.
4.2.4. Design Walkthrough
- Set up the hardware.
- Edit the HDCP key memory files to include your HDCP production keys.
- Build and compile the design.
- View the results.
4.2.4.1. Set Up the Hardware
To set up the hardware for the demonstration:
- Connect the Bitec HDMI 2.0 FMC daughter card (revision 11) to the Arria 10 development kit at FMC port B.
- Connect the Arria 10 development kid to your PC using a USB cable.
- Connect an HDMI cable from the HDMI RX connector on the Bitec HDMI 2.0 FMC daughter card to an HDCP-enabled HDMI device, such as a graphic card with HDMI output.
- Connect another HDMI cable from the HDMI TX connector on the Bitec HDMI 2.0 FMC daughter card to an HDCP-enabled HDMI device, such as a television with HDMI input.
4.2.4.2. Include HDCP Production Keys
To include the production keys, follow these steps.
-
Locate the following
key
memory
files in the hdcp2x/hw_demo/arria10/rtl/hdcp/ directory:
- hdcp2x_tx_kmem.v
- hdcp2x_rx_kmem.v
- hdcp1x_tx_kmem.v
- hdcp1x_rx_kmem.v
-
Open the hdcp2x_rx_kmem.v
file and locate the predefined facsimile key R1 for Receiver Public Certificate
and RX Private Key and Global Constant as shown in the examples below.
Figure 10. Wire Array of Facsimile Key R1 for Receiver Public CertificateFigure 11. Wire Array of Facsimile Key R1 for RX Private Key and Global Constant
-
Locate the placeholder for the production keys and replace with your own
production keys in their respective wire array in big endian format.
Figure 12. Wire Array of HDCP Production Keys (Placeholder)
- Repeat Step 3 for all other key memory files. When you have finished including your production keys in all the key memory files, ensure that the USE_FACSIMILE parameter is set to 0 at the design example top level file (a10_hdmi2_demo.v)
4.2.4.3. Build and Compile the Design
You can use the provided Tcl script to build and compile the design.
- Install Intel® Quartus® Prime Pro Edition version 19.3.
- Open a Nios II Command Shell.
- Change the directory to your working directory, specifically the hdcp2x/hw_demo/arria10/script/ directory.
-
Run ./runall.tcl.
This script executes the following commands:
- Generate IP catalog files
- Generate the Platform Designer system
- Create an Intel® Quartus® Prime project
- Create a software work space and build the software
- Compile the Intel® Quartus® Prime project
- Perform a full compilation
4.2.4.4. View the Results
To view the results of the demonstration, follow these steps:
- Power up the Intel FPGA board.
- Change the directory to hdcp2x/hw_demo/arria10/quartus/ directory.
-
Type the following command on the Nios II Command Shell to
download the Software Object File (.sof) to
the FPGA.
nios2-configure-sof output_files/<Quartus project name>.sof
- Power up the HDCP-enabled HDMI external source and sink (if you haven't done so). The HDMI external sink displays the output of your HDMI external source.
4.2.4.4.1. LED Functions
LED | Functions |
---|---|
user_led[0] | RX HDMI PLL lock status.
|
user_led[1] | RX HDMI core lock status
|
user_led[2] | RX HDCP1x IP decryption status.
|
user_led[3] | RX HDCP2x IP decryption status.
|
user_led[4] | TX HDMI PLL lock status.
|
user_led[5] |
TX transceiver PLL lock status.
|
user_led[6] | TX HDCP1x IP encryption status.
|
user_led[7] | TX HDCP2x IP encryption status.
|
4.2.5. Security Considerations
- When designing a repeater system, you must block the received video from
entering the TX IP in the following conditions:
- If the received video is HDCP-encrypted (i.e. encryption status hdcp1_enabled or hdcp2_enabled from the RX IP is asserted) and the transmitted video is not HDCP-encrypted (i.e. encryption status hdcp1_enabled or hdcp2_enabled from the TX IP is not asserted).
- If the received video is HDCP TYPE 1 (i.e. streamid_type from the RX IP is asserted) and the transmitted video is HDCP 1.4 encrypted (i.e. encryption status hdcp1_enabled from the TX IP is asserted)
- You should maintain the confidentiality and integrity of your HDCP production keys, and any user encryption keys.
- Intel strongly advices you to develop any Intel® Quartus® Prime projects and design source files that contain encryption keys in a secure compute environment to protect the keys.
- Intel strongly advices you to design security features in FPGAs to protect the design, including any embedded encryption keys, from unauthorized copying, reverse engineering, and tampering.
4.3. HDMI Hardware Design Examples for Arria V and Stratix V Devices
The design example runs on the following device kits:
- Arria V GX starter kit
- Stratix V GX development kit
- Bitec HDMI HSMC 2.0 Daughter Card Revision 8
4.3.1. HDMI Hardware Design Components
The hardware demonstration design comprises the following components:
- HDMI sink
- Transceiver Native PHY (RX)
- Transceiver PHY Reset Controller (RX)
- PLL
- PLL Reconfiguration
- Multirate Reconfiguration Controller (RX)
- Oversampler (RX)
- DCFIFO
- Sink Display Data Channel (DDC) and Status and Control Data Channel (SCDC)
- Transceiver Reconfiguration Controller
- VIP bypass and Audio, Auxiliary and InfoFrame buffers
-
Platform Designer system
- VIP passthrough for HDMI video stream
- Source SCDC controller
- HDMI source reconfiguration controller
- HDMI source
- Transceiver Native PHY (TX)
- Transceiver fPLL
- Transceiver PHY Reset Controller (TX)
- PLL
- PLL Reconfiguration
- Oversampler (TX)
- DCFIFO
- Clock Enable Generator
The following details of the design example architecture correspond to the numbers in the block diagram.
- The sink TMDS data has three channels: data channel 0 (blue), data channel 1 (green), and data channel 2 (red).
- The Oversampler (RX) and dual-clock FIFO (DCFIFO) instances are duplicated for each TMDS data channel (0,1,2).
- The video data input width for each color channel of the HDMI RX core is equivalent to RX transceiver PCS-PLD parallel data width per channel.
- Each color channel is fixed at 16 bpc. The video data output width of the HDMI RX core is equivalent to the value of symbols per clock*16*3.
- The video data input width of the Clocked Video Input (CVI) and Clocked Video Output (CVO) IP cores are equivalent to the value of NUMBER_OF_PIXELS_IN_PARALLEL * BITS_PER_PIXEL_PER_COLOR_PLANE * NUMBER_OF_COLOR_PLANES. To interface with the HDMI core, the values of NUMBER_OF_PIXELS_IN_PARALLEL, BITS_PER_PIXEL_PER_COLOR_PLANE, and NUMBER_OF_COLOR_PLANES must match the symbols per clock, 16 and 3 respectively.
- The video data input width of the HDMI TX core is equivalent to the value of symbols per clock*16*3. You can use the user switch to select the video data from the CVO IP core (VIP passthrough) or DCFIFO (VIP bypass).
- The video data output width for each color channel of the HDMI TX core is equivalent to TX transceiver PCS-PLD parallel data width per channel.
- The DCFIFO and the Oversampler (TX) instances are duplicated for each TMDS data channel (0,1,2) and clock channel.
- The Oversampler (TX) uses the clock enable signal to read data from the DCFIFO.
- The source TMDS data has four channels: data channel 0 (blue), data channel 1 (green), data channel 2 (red), and clock channel.
- The RX Multirate Reconfiguration Controller requires the status of TMDS_Bit_clock_Ratio port to perform appropriate RX reconfiguration between the TMDS character rates below 340 Mcsc (HDMI 1.4b) and above 340 Mcsc (HDMI 2.0b). The status of the port is also required by the Nios II processor and the HDMI TX core to perform appropriate TX reconfiguration and scrambling.
- The reset control and lock status signals from HDMI PLL, RX Transceiver Reset Controller and HDMI RX core.
- The reset and oversampling control signals for HDMI PLL, TX Transceiver Reset Controller, and HDMI TX core. The lock status and rate detection measure valid signals from the HDMI sink initiate the TX reconfiguration process.
- The I2C SCL and SDA lines with tristate buffer for bidirectional configuration. Use the ALTIOBUF IP core for Arria V and Stratix V devices.
- The SCDC is mainly designed for the source to update the TMDS_Bit_Clock_Ratio and Scrambler_Enable bits of the sink TMDS Configuration register. .
4.3.1.1. Transceiver Native PHY (RX)
- Transceiver Native PHY in Arria V devices
- To operate the TMDS bit rate up to 3,400 Mbps, configure the Transceiver Native PHY at 20 bits at PCS – PLD interface with the HDMI RX core at 2 symbols per clock. When the PCS – PLD interface width is 20 bits, the minimum link rate is 611 Mbps.
- To operate the TMDS bit rate up to 6,000 Mbps, configure the Transceiver Native PHY at 40 bits with the HDMI RX core at 4 symbols per clock. When the PCS – PLD interface width is 40 bits, the minimum link rate is 1,000 Mbps.
- Oversampling is required for TMDS bit rate which is below the minimum link rate.
- Transceiver Native PHY in Stratix V devices
- To operate the TMDS bit rate up to 6,000 Mbps, configure the Transceiver Native PHY at 20 bits at PCS – PLD interface with the HDMI RX core at 2 symbols per clock. When the PCS – PLD interface width is 20 bits, the minimum link rate is 611 Mbps.
Parameters | Settings |
---|---|
Datapath Options | |
Enable TX datapath | Off |
Enable RX datapath | On |
Enable Standard PCS | On |
Initial PCS datapath selection | Standard |
Number of data channels | 3 |
Enable simplified data interface | On |
RX PMA | |
Data rate | 6,000 Mbps |
Enable CDR dynamic reconfiguration | On |
Number of CDR reference clocks | 2 2 |
Selected CDR reference clock | 0 2 |
Selected CDR reference clock frequency | 600 MHz |
PPM detector threshold | 1,000 PPM |
Enable rx_pma_clkout port | On |
Enable rx_is_lockedtodata port | On |
Enable rx_is_lockedtoref port | On |
Enable rx_set_locktodata and rx_set_locktoref ports | On |
Standard PCS | |
Standard PCS protocol | Basic |
Standard PCS/PMA interface width |
|
Enable RX byte deserializer |
|
Signals | Direction | Description |
---|---|---|
Clocks | ||
rx_cdr_refclk[1:0] | Input |
Input reference clock for the RX CDR circuitry.
|
rx_std_clkout[2:0] | Output |
RX parallel clock output.
|
rx_std_coreclkin[2:0] | Input |
RX parallel clock that drives the read side of the RX phase compensation FIFO. Connect to rx_std_clkout ports. |
rx_pma_clkout[2:0] | Output |
RX parallel clock (recovered clock) output from PMA. Leave unconnected. |
Resets | ||
rx_analogreset[2:0] | Input |
Active-high, edge-sensitive, asynchronous reset signal. When asserted, resets the RX CDR circuit, deserializer. Connect to Transceiver PHY Reset Controller IP core. |
rx_digitalreset[2:0] | Input |
Active-high, edge-sensitive, asynchronous reset signal. When asserted, resets the digital component of the RX data path. Connect to the Transceiver PHY Reset Controller IP core. |
PMA Ports | ||
rx_set_locktoref[2:0] | Input |
When asserted, programs the RX CDR to lock to reference mode manually. The lock to reference mode enables you to control the reset sequence using rx_set_locktoref and rx_set_locktodata. The Multirate Reconfiguration Controller (RX) sets this port to 1 if oversampling mode is required. Otherwise, this port is set to 0. Refer "Transceiver Reset Sequence" in Transceiver Reset Control in Arria V/Stratix V Devices for more information about manual control of the reset sequence. |
rx_set_locktodata[2:0] | Input | Always driven to 0. When rx_set_locktoref is driven to 1, the CDR is configured to lock-to-reference mode. Otherwise, the CDR is configured to lock-to-data mode. |
rx_is_lockedtoref[2:0] | Output | When asserted, the CDR is locked to the incoming reference clock. Connect this port to rx_is_lockedtodata port of the Transceiver PHY Reset Controller IP core when rx_set_locktoref is 1. |
rx_is_lockedtodata[2:0] | Output | When asserted, the CDR is locked to the incoming data. Connect this port to rx_is_lockedtodata port of Transceiver PHY Reset Controller IP core when rx_set_locktoref is 0. |
rx_serial_data[2:0] | Input | RX differential serial input data. |
PCS Ports | ||
unused_rx_parallel_data | Output | Leave unconnected. |
rx_parallel_data[S*3*10-1:0] | Output | PCS RX parallel data. Note: S=Symbols per clock.
|
Calibration Status Port | ||
rx_cal_busy[2:0] | Output | When asserted, indicates that the initial RX calibration is in progress. This port is also asserted if the reconfiguration controller is reset. Connect to the Transceiver PHY Reset Controller IP core. |
Reconfiguration Ports | ||
reconfig_to_xcvr[209:0] | Input | Reconfiguration signals from the Transceiver Reconfiguration Controller. |
reconfig_from_xcvr[137:0] | Output | Reconfiguration signals to the Transceiver Reconfiguration Controller. |
4.3.1.2. PLL Intel FPGA IP Cores
The HDMI PLL is referenced by the arbitrary TMDS clock. For HDMI source, you can reference the HDMI PLL by a separate clock source in the VIP passthrough design, which contains frame buffer. The HDMI PLL for TX has the same desired output frequencies as RX across symbols per clock and color depth.
- For TMDS bit rates ranging from 3,400 Mbps to 6,000 Mbps (HDMI 2.0), the TMDS clock rate is 1/40 of the TMDS bit rate. The HDMI PLL generates reference clock for RX/TX transceiver at 4 times the TMDS clock.
- For TMDS bit rates below 3,400 Mbps (HDMI 1.4b), the TMDS clock rate is 1/10 of the TMDS bit rate. The HDMI PLL generates reference clock for RX/TX transceiver at identical rate as the TMDS clock.
Device Family | Symbols Per Clock | Minimum Link Rate (Mbps) | TMDS Bit Rate (Mbps) | Oversampling (5x) Required | TMDS Clock Rate (MHz) | RX/TX Transceiver Refclk (MHz) | RX/TX Link Speed Clock (MHz) | RX/TX Video Clock (MHz) |
---|---|---|---|---|---|---|---|---|
Arria V | 2 | 611 | 270 | Yes | 27 | 135 | 13.5 | 13.5 |
742.5 | No | 74.25 | 74.25 | 37.125 | 37.125 | |||
1,485 | No | 148.5 | 148.5 | 74.25 | 74.25 | |||
2,970 | No | 297 | 297 | 148.5 | 148.5 | |||
4 | 1,000 | 270 | Yes | 27 | 135 | 6.75 | 6.75 | |
742.5 | Yes | 74.25 | 371.25 | 18.5625 | 18.5625 | |||
1,485 | No | 148.5 | 148.5 | 37.125 | 37.125 | |||
5,940 | No | 148.5 | 594 | 148.5 | 148.5 | |||
Stratix V | 2 | 611 | 540 | Yes | 54 | 270 | 27 | 27 |
1,620 | No | 162 | 162 | 81 | 81 | |||
5,934 | No | 296.7 | 593.4 | 296.7 | 296.7 |
The color depths greater than 8 bpc or 24 bpp are defined to be deep color. For a color depth of 8 bpc, the core carries the pixels at a rate of one pixel per TMDS clock. At deeper color depths, the TMDS clock runs faster than the source pixel clock to provide the extra bandwidth for the additional bits.
The TMDS clock rate is increased by the ratio of the pixel size to 8 bits:
- 8 bits mode—TMDS clock = 1.0 × pixel or video clock (1:1)
- 10 bits mode—TMDS clock = 1.25 × pixel or video clock (5:4)
- 12 bits mode—TMDS clock = 1.5 × pixel or video clock (3:2)
- 16 bits mode—TMDS clock = 2 × pixel or video clock (2:1)
Symbols Per Clock | Oversampling (5x) Required | Bits Per Component | TMDS Bit Rate (Mbps) | TMDS Clock Rate (MHz) | RX/TX Transceiver Refclk (MHz) | RX/TX Link Speed Clock (MHz) | RX/TX Video Clock (MHz) |
---|---|---|---|---|---|---|---|
2 | Yes | 8 | 270 | 27 | 135 | 13.5 | 13.5 |
10 3 | 337.5 | 33.75 | 168.75 | 16.875 | 13.5 | ||
12 3 | 405 | 40.5 | 202.5 | 20.25 | 13.5 | ||
16 3 | 540 | 54 | 270 | 27 | 13.5 | ||
4 | No | 8 | 1,485 | 148.5 | 148.5 | 37.125 | 37.125 |
10 3 | 1,856.25 | 185.625 | 185.625 | 46.40625 | 37.125 | ||
12 3 | 2,227.5 | 222.75 | 222.75 | 55.6875 | 37.125 | ||
16 3 | 2,970 | 297 | 297 | 74.25 | 37.125 |
4.3.1.3. PLL Reconfig Intel FPGA IP Core
Use the IP core to update the output clock frequency, PLL bandwidth in real-time, without reconfiguring the entire FPGA.
You can run this IP core at 100 MHz in Stratix V devices. In Arria V devices, you need to run at 75 MHz for timing closure. To simplify clocking in Arria V devices, the entire management clock domain is capped at 75 MHz.
4.3.1.4. Multirate Reconfig Controller (RX)
The Multirate Reconfig Controller performs rate detection on the HDMI PLL arbitrary reference clock, which is also the TMDS clock, to determine the clock frequency band. Based on the detected clock frequency band, the circuitry dynamically reconfigures the HDMI PLL and transceiver settings to accommodate for the link rate change.
4.3.1.5. Oversampler (RX)
The oversampling factor is fixed at 5 and you can program the data width to support different number of symbols. The supported data width is 20 bit for 2 symbols per clock and 40 bits for 4 symbols per clock. The extracted bit will be accompanied by data valid pulse which asserts every 5 clock cycles.
4.3.1.6. DCFIFO
- Sink
- When the Multirate Reconfig Controller (RX) detects an incoming input stream that is below the transceiver minimum link rate, the DCFIFO accepts the data from the Oversampler with data valid pulse as write request asserted every 5 clock cycles.
- Otherwise, it accepts data directly from the transceiver with write request asserted at all times.
- Source
- When Nios II processor determines the outgoing data stream is below the TX transceiver minimum link rate, the TX transceiver accepts the data from the Oversampler (TX).
- Otherwise, the TX transceiver reads data directly from the DCFIFO with read request asserted at all times.
4.3.1.7. Sink Display Data Channel (DDC) & Status and Control Data Channel (SCDC)
The E-EDID memory is stored using the RAM 1-Port IP core. A standard two-wire (clock and data) serial data bus protocol (I2C slave-only controller) is used to transfer CEA-861-D compliant E-EDID data structure.
The 8-bit I2C slave addresses for the E-EDID are 0xA0/0xA1. The LSB indicates the access type: 1 for read and 0 for write. When an HPD event occurs, the I2C slave responds to E-EDID data by reading from the RAM.
The I2C slave-only controller is also used to support SCDC for HDMI 2.0b operation. The 8-bit I2C slave addresses for the SCDC are 0xA8/0xA9. When an HPD event occurs, the I2C slave performs write/read transaction to/from SCDC interface of HDMI RX core. This I2C slave-only controller for SCDC is not required if HDMI 2.0b is not intended.
4.3.1.8. Transceiver Reconfiguration Controller
You can selectively reconfigure any portion of the transceiver. The reconfiguration of each portion requires a read-modify-write operation (read first, then write). The read-modify-write operation modifies only the appropriate bits in a register and does not affect the other bits.
The Transceiver Reconfiguration Controller is only available and required in Arria V and Stratix V devices. Because the RX and TX transceivers share a single controller, the controller requires Platform Designer interconnects, such as Avalon-MM Master Translator and Avalon-MM Slave Translator, in the Platform Designer system.
- The Avalon-MM Master Translator provides an interface between this controller and the RX Multirate Reconfig Controller.
- The Avalon-MM Slave Translator arbitrates the RX and TX reconfiguration event for this controller.
4.3.1.9. VIP Bypass and Audio, Auxiliary and InfoFrame Buffers
The auxiliary data port of the HDMI TX core controls the auxiliary data that flow through DCFIFO through backpressure. The backpressure ensures there is no incomplete auxiliary packet on the auxiliary data port. This block also performs external filtering on the audio data and audio clock regeneration packet from the auxiliary data stream before sending to the HDMI TX core auxiliary data port.
4.3.1.10. Transceiver Native PHY (TX)
The Arria V and Stratix V Transceiver Native PHY (TX) configuration settings are typically the same as RX.
Parameters | Settings |
---|---|
Datapath Options | |
Enable TX datapath | On |
Enable RX datapath | Off |
Enable Standard PCS | On |
Initial PCS datapath selection | Standard |
Number of data channels | 4 |
Bonding mode | xN |
Enable simplified data interface | On |
TX PMA | |
Data rate | 6,000 Mbps |
TX local clock division factor | 1 |
Enable TX PLL dynamic reconfiguration | On |
Use external TX PLL | Off |
Number of TX PLLs | 1 |
Main TX PLL logical index | 0 |
Number of TX PLL reference clocks | 1 |
PLL type | CMU |
Reference clock frequency | 600 MHz |
Selected reference clock source | 0 |
Selected clock network | xN |
Standard PCS | |
Standard PCS protocol | Basic |
Standard PCS/PMA interface width |
|
Enable TX byte serializer |
|
Signals | Direction | Description |
---|---|---|
Clocks | ||
tx_pll_refclk | Input |
The reference clock input to the TX PLL. |
tx_std_clkout[3:0] | Output |
TX parallel clock output. |
tx_std_coreclkin[3:0] | Input |
TX parallel clock that drives the write side of the TX phase compensation FIFO. Connect to tx_std_clkout[0] ports. |
Resets | ||
tx_analogreset[3:0] | Input |
When asserted, resets all the blocks in TX PMA. Connect to Transceiver PHY Reset Controller (TX) IP core. |
tx_digitalreset[3:0] | Input |
When asserted, resets all the blocks in TX PCS. Connect to the Transceiver PHY Reset Controller (TX) IP core. |
TX PLL | ||
pll_powerdown | Input |
When asserted, resets the TX PLL. Connect to the Transceiver PHY Reset Controller (TX) IP core. |
pll_locked | Output |
When asserted, indicates that the TX PLL is locked. Connect to the Transceiver PHY Reset Controller (TX) IP core. |
PCS Ports | ||
unused_tx_parallel_data | Input | Leave unconnected. |
tx_parallel_data[S*4*10-1:0] | Input | PCS TX parallel data. Note: S=Symbols per clock.
|
PMA Port | ||
tx_serial_data[3:0] | Output | TX differential serial output data. |
Calibration Status Port | ||
tx_cal_busy[3:0] | Output | When asserted, indicates that the initial TX calibration is in progress. This port is also asserted if the reconfiguration controller is reset. Connect to the Transceiver PHY Reset Controller (TX) IP core. |
Reconfiguration Ports | ||
reconfig_to_xcvr[349:0] | Input | Reconfiguration signals from the Transceiver Reconfiguration Controller. |
reconfig_from_xcvr[229:0] | Output | Reconfiguration signals to the Transceiver Reconfiguration Controller. |
4.3.1.11. Transceiver PHY Reset Controller
The reset controller has separate reset controls per channel to handle synchronization of reset inputs, lagging of PLL locked status, and automatic or manual reset recovery mode.
4.3.1.12. Oversampler (TX)
The oversampling factor is fixed at 5. The Oversampler (TX) assumes that the input word is only valid every 5 clock cycles. This block enables when the outgoing data stream is determined to be below the TX transceiver minimum link rate by reading once from the DCFIFO every 5 clock cycles.
4.3.1.13. Clock Enable Generator
This clock enable pulse asserts every 5 clock cycles and serves as a read request signal to clock the data out from DCFIFO.
4.3.1.14. Platform Designer System
4.3.1.14.1. VIP Passthrough for HDMI Video Stream
The Clocked Video Input II (CVI II) Intel® FPGA IP core converts clocked video formats to Avalon-ST video by stripping incoming clocked video of horizontal and vertical blanking, leaving only active picture data.
- The IP core provides clock crossing capabilities to allow video formats running at different frequencies to enter the system.
- The IP core also detects the format of the incoming clocked video and provides this information in a set of registers.
- The Nios II processor uses this information to reconfigure the video frame mode registers of the CVO IP core in the VIP passthrough design.
The Video Frame Buffer II Intel® FPGA IP core buffers video frames into external RAM.
- The IP core supports double and triple buffering with a range of options for frame dropping and repeating.
- You can use the buffering options to solve throughput issues in the data path and perform simple frame rate conversion.
In a VIP passthrough design, you can reference the HDMI source PLL and sink PLL using separate clock sources. However, in a VIP bypass design, you must reference the HDMI source PLL and sink PLL using the same clock source.
The Clocked Video Output II (CVO II) Intel® FPGA IP core converts data from the flow-controlled Avalon-ST video protocol to clocked video.
- The IP core provides clock crossing capabilities to allow video formats running at different frequencies to be created from the system.
- It formats the Avalon-ST video into clocked video by inserting horizontal and vertical blanking and generating horizontal and vertical synchronization information using the Avalon-ST video control and active picture packets.
- The video frame is described using the mode registers that are accessed through the Avalon-MM control port.
VIP Passthrough Design | VIP Bypass Design |
---|---|
|
|
Device Family | Symbols Per Clock | HDMI Specification Support | Bitec HDMI HSMC 2.0 Daughter Card | Directory | VIP Passthrough | VIP Bypass |
---|---|---|---|---|---|---|
Arria V | 2 | 1.4b | HSMC (Rev8) | av_sk | Supported | Supported |
4 | 2.0b | HSMC (Rev8) | av_sk_hdmi2 | Not supported | Supported | |
Stratix V | 2 | 2.0b | HSMC (Rev8) | sv_hdmi2 | Not supported | Supported |
4.3.1.14.2. Source SCDC Controller
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 can also transfer the DDC data structure (E-EDID) between the HDMI source and external sink.
4.3.1.14.3. Source Reconfiguration Controller
The CPU relies on the periodic rate detection from the Multirate Reconfig Controller (RX) to determine if TX requires reconfiguration. The Avalon-MM slave translator provides the interface between the Nios II processor Avalon-MM master interface and the Avalon-MM slave interfaces of the externally instantiated HDMI source's PLL Reconfig Intel FPGA IP and Transceiver Native PHY (TX).
4.3.2. HDMI Hardware Design Requirements
- Intel FPGA board
- Bitec HDMI HSMC 2.0 daughter card
- Standard HDMI source—for example, PC with a graphic card and HDMI output
- Standard HDMI sink—for example, monitor with HDMI input
- 2 HDMI cables
- A cable to connect the graphics card to the Bitec daughter card RX connector.
- A cable to connect the Bitec daughter card TX connector to the monitor.
Design Example | Intel FPGA Board | Bitec HDMI HSMC 2.0 Daughter Card |
---|---|---|
Arria V (av_sk) | Arria V GX FPGA Starter Kit | HSMC (Rev8) |
Arria V (av_sk_hdmi2) | Arria V GX FPGA Starter Kit | HSMC (Rev8) |
Stratix V (sv_hdmi2) | Stratix V GX FPGA Development Kit | HSMC (Rev8) |
4.3.3. Design Walkthrough
- Set up the hardware.
- Copy the design files to your working directory.
- Build and compile the design.
- View the results.
4.3.3.1. Set Up the Hardware
To set up the hardware for the demonstration:
- Connect the Bitec HDMI HSMC 2.0 daughter card to the FPGA development board.
-
Connect the FPGA board to your PC using a USB cable.
Note: The Arria V GX FPGA Starter Kit and Stratix V GX FPGA Development Kit have an On-Board Intel® FPGA Download Cable II connector. If your version of the board does not have this connector, you can use an external Intel® FPGA Download Cable cable.
- Connect an HDMI cable from the HDMI RX connector on the Bitec HDMI HSMC 2.0 daughter card to a standard HDMI source, in this case a PC with a graphic card and HDMI output.
- Connect another HDMI cable from the HDMI TX connector on the Bitec HDMI HSMC 2.0 daughter card to a standard HDMI sink, in this case a monitor with HDMI input.
4.3.3.2. Copy the Design Files
- Arria V
- 2 symbols per clock (HDMI 1.4b) demonstration: <IP root directory>/altera_hdmi/hw_demo/av_sk
- 4 symbols per clock (HDMI 2.0b) demonstration: <IP root directory>/altera_hdmi/hw_demo/av_sk_hdmi2
- Stratix V
- 2 symbols per clock (HDMI 2.0b) demonstration: <IP root directory>/altera_hdmi/hw_demo/sv_hdmi2
4.3.3.3. Build and Compile the Design
You can use the provided Tcl script to build and compile the FPGA design.
- Open a Nios II Command Shell.
- Change the directory to your working directory.
-
Type the command and enter source
runall.tcl.
This script executes the following commands:
- Generate IP catalog files
- Generate the Platform Designer system
- Create an Intel® Quartus® Prime project
- Create a software work space and build the software
- Compile the Intel® Quartus® Prime project
- Run Analysis & Synthesis to generate a post-map netlist for DDR assignments—for VIP passthrough design only
- Perform a full compilation
Note: If you are a Linux user, you will get a message cygpath: command not found. You can safely ignore this message; the script will proceed to generate the next commands.
4.3.3.4. View the Results
To view the results of the demonstration, follow these steps:
- Power up the Intel FPGA board.
-
Type the following command on the Nios II Command Shell to
download the Software Object File (.sof) to
the FPGA.
nios2-configure-sof output_files/<Quartus project name>.sof
-
Power up the standard HDMI source and sink (if you haven't done
so).
The design displays the output of your video source (PC).Note: If the output does not appear, press cpu_resetn to reinitialize the system or perform HPD by unplugging the cable from the standard source and plug it back again.
-
Open the graphic card control utility (if you are using a PC as
source). Using the control panel, you can switch between various video
resolutions.
The av_hdmi2 and sv_hdmi2 demonstration designs allow any video resolutions up to 4Kp60. The av_sk design allows 640×480p60, 720×480p60, 1280×720p60, 1920×1080p60, and 3840×2160p24 when you select the VIP passthrough mode (user_dipsw[0] = 0). If you select the VIP bypass mode (user_dipsw[0] = 1, the design allows any video resolutions up to 4Kp60.
4.3.3.4.1. Push Buttons, DIP Switches and LED Functions
Push Button/ DIP Switch/LED | Pins | Functions | |
---|---|---|---|
av_sk/av_sk_hdmi2 | sv_hdmi2 | ||
cpu_resetn | D5 | AM34 | Press once to perform system reset. |
user_pb[0] | A14 | A7 | Press once to turn on and turn off HPD signal to the standard HDMI source. |
user_pb[1] | B15 | B7 | Press and hold to instruct the TX to send DVI encoded signal and release to send HDMI encoded signal. |
user_pb[2] | B14 | C7 | Press and hold to instruct the TX to stop sending InfoFrames and release to resume sending. |
user_dipsw[0] | D15 | Unused | Only used in av_sk design which demonstrates the VIP passthrough feature.
|
user_led[0] | F17 | J11 | RX HDMI PLL lock status.
|
user_led[1] | G15 | U10 | RX transceiver ready status.
|
user_led[2] | G16 | U9 | RX HDMI core lock status
|
user_led[3] | G17 | AU24 | RX oversampling status.
|
user_led[4] | D16 | AF28 | TX HDMI PLL lock status.
|
user_led[5] | C13 | AE29 | TX transceiver ready status.
|
user_led[6] | C14 | AR7 |
TX transceiver PLL lock status.
|
user_led[7] | C16 | AV10 | TX oversampling status.
|
5. HDMI Source
5.1. Source Functional Description
The source core provides four 10-bit, 20-bit or 40-bit parallel data paths corresponding to the 3 color channels and the clock channel.
Central to the core is the Scrambler, TMDS/TERC4 Encoder. The encoder processes either video or auxiliary data.
5.1.1. Source Scrambler, TMDS/TERC4 Encoder
The encoder processes symbol data at 1, 2, or 4 symbols per clock. When the encoder operates in 2 or 4 symbols per clock, it also produces the output in the form of two or four encoded symbols per clock.
The TMDS/TERC4 encoder also produces digital visual interface (DVI) signaling when you deassert the mode input signal. DVI signaling is identical to HDMI signaling, except for the absence of data and video islands and TERC4 auxiliary data.
5.1.2. Source Video Resampler
The gearbox converts data of 8, 10, 12, or 16 bits per component to 8-bit per component data based on the current color depth. The General Control Packet (GCP) conveys the color depth information.
- The phase counter must register the last pixel packing-phase (pp) of the last pixel of the last active line.
- The core then transmits the pp value to the attached sink device in the GCP for packing synchronization.
The HDMI cable may send across four different pixel encodings: RGB 4:4:4, YCbCr 4:4:4, and YCbCr 4:2:2 (as described in HDMI 1.4b Specification Section 6.5), and YCbCr 4:2:0 (as described in HDMI 2.0b Specification Section 7.1).
The higher order 8 bits of the Y samples are mapped to the 8 bits of Channel 1 and the lower order 4 bits are mapped to the lower order 4 bits of Channel 0.
The first pixel transmitted within a Video Data Period contains three components, Y0, Cb0 and Cr0. The Y0 and Cb0 components are transmitted during the first pixel period while Cr0 is transmitted during the second pixel period. This second pixel period also contains the only component for the second pixel, Y1. In this way, the link carries one Cb sample for every two pixels and one Cr sample for every two pixels. These two components (Cb and Cr) are multiplexed onto the same signal paths on the link.
The two horizontally successive 8-bit Y components are transmitted in TMDS Channels 1 and 2, in that order. The 8-bit Cb or Cr components are transmitted alternately in TMDS Channel 0, line by line.
For even lines starting with line 0:
- vid_data[47:32] always transfer the Yn+1 component
- vid_data[31:16] always transfer the Yn component
- vid_data[15:0] always transfer the Cbn component
For odd lines:
- vid_data[47:32] always transfer the Yn+1 component
- vid_data[31:16] always transfer the Yn component
- vid_data[15:0] always transfer the Crn component
The frequency of vid_clk must be halved when YCbCr 4:2:0 is used, because two pixels are fed into a single clock cycle.
5.1.3. Source Window of Opportunity Generator
During horizontal blanking region, the WOP generator creates a leading region to hold at least 12 period symbols that include eight preamble symbols. The generator also creates a trailing region to hold two data island trailing guard band symbols, at least 12 control period symbols that include eight preamble symbols and two video leading guard band symbols.
During vertical blanking region, the source cannot send more than 18 auxiliary packets consecutively. The WOP generator deasserts the data island output enable (aux_wop) line after every 18th auxiliary packet for 32-symbol clocks.
The WOP generator also has an integral number of auxiliary packet cycles: 24 clocks when processing in 1-symbol mode, 16 clocks when processing in 2-symbol mode, and 8 clocks when processing in 4-symbol mode.
5.1.4. Source Auxiliary Packet Encoder
The auxiliary packets originate from several sources, which are multiplexed into the auxiliary packet encoder in a round-robin schedule. The auxiliary packet encoder converts a standard stream into the channel data format required by the TERC4 encoder.
The encoder assumes the data valid input will remain asserted for the duration of a packet to complete. A packet is always 24 clocks (in 1-symbol mode), 12 clocks (in 2-symbol mode), or 6 clocks (in 4-symbol mode).
5.1.5. Source Auxiliary Packet Generators
The packet generator propagates backpressure from the output ready signal to the input ready signal. The generator asserts the input valid signal when a packet is ready to be transmitted. The input valid signal remains asserted until the end of the packet and the generator receives a ready acknowledgment.
5.1.6. Source Auxiliary Data Path Multiplexers
The various auxiliary packet generators traverse a multiplexed routing path to the auxiliary packet encoder. The multiplexers obey a round-robin schedule and propagate backpressure.
5.1.7. Source Auxiliary Control Port
These packets are: General Control Packet, Auxiliary Video Information (AVI) InfoFrame, and HDMI Vendor Specific InfoFrame (VSI).
The core sends the default values in the auxiliary packets. The default values allow the core to send video data compatible with the HDMI 1.4b Specification with minimum description.
You can also override the generators using the customized input values. The override values replace the default values when the input checksum is non-zero.
Auxiliary Packets | Insertion/Filtration | Frequency of Insertion | |
---|---|---|---|
General Control Packet (GCP) | – |
The core always inserts GCP packets from the GCP sideband upon the rising edge of vsync. The core always removes the GCP in the Auxiliary Data Port. You must provide the pixel packing and color depth information through the gcp port. |
Once per frame. |
Auxiliary Video Information (AVI) InfoFrame | info_avi[112]=1'b0 |
The core inserts info_avi[111:0] when there is a non-zero bit upon the rising edge of vsync. The core send default values when all bits are zero. The core filters the AVI InfoFrame packet on the Auxiliary Data Port. |
Once per frame. |
info_avi[112]=1'b1 |
The core does not insert info_avi[111:0]. The AVI InfoFrame packet on the Auxiliary Data Port passes through. |
||
Vendor Specific InfoFrame (VSI) | info_vsi[61]=1'b0 |
The core inserts info_vsi[60:0] when there is a non-zero bit upon the rising edge of vsync. The core sends default values when all bits are zero. The core filters the VSI InfoFrame packet on the Auxiliary Data Port. |
Once per frame. |
info_vsi[61]=1'b1 |
The core does not insert info_vsi[60:0]. The VSI InfoFrame packet on the Auxiliary Data Port passes through. |
||
Audio Metadata (AM) | audio_metadata[165]=1'b0 |
The core inserts audio_metadata[164:0] when audio_format[3:0] is 3D audio or MST audio upon the rising edge of vsync. The core filters the AM packet on the Auxiliary Data Port. |
Once per frame. |
audio_metadata[165]=1'b1 |
The core does not insert audio_metadata[164:0]. The AM packet on the Auxiliary Data Port passes through. |
||
Audio InfoFrame (AI) | audio_info_ai[48]=1'b0 |
The core inserts audio_info_ai[47:0] when there is a non-zero bit upon the rising edge of vsync. The core sends default values when all bits are zero. The core filters the AI packet on the Auxiliary Data Port. |
Once per frame. |
audio_info_ai[48]=1'b1 |
The core does not insert audio_info_ai[47:0]. The AI packet on the Auxiliary Data Port passes through. |
||
Audio Control Regeneration (ACR) | – |
The core always inserts the audio_N and audio_CTS. The core does not filter the ACR packet in the auxiliary. If there is ACR packet in the Auxiliary Data Port, you must remove it before passing into the Auxiliary Data Port. |
Every 1 ms. |
Audio Sample | – |
The core always inserts audio_data. The core does not filter the audio sample packet in the Auxiliary Data Port. If there is audio sample packet in the Auxiliary Data Port, you must remove it before passing into the Auxiliary Data Port. |
Based on audio sample rate. |
5.1.7.1. Source General Control Packet (GCP)
Bit Field | Name | Value | Comment | |||
---|---|---|---|---|---|---|
gcp[3:0] | Color Depth (CD) | CD3 | CD2 | CD1 | CD0 | Color depth |
0 | 0 | 0 | 0 | Color depth not indicated | ||
0 | 1 | 0 | 0 | 8 bpc or 24 bits per pixel (bpp) | ||
0 | 1 | 0 | 1 | 10 bpc or 30 bpp | ||
0 | 1 | 1 | 0 | 12 bpc or 36 bpp | ||
0 | 1 | 1 | 1 | 16 bpc or 48 bpp | ||
Others | Reserved | |||||
gcp[4] | Set_AVMUTE | Refer to HDMI 1.4b Specification Section 5.3.6. | ||||
gcp[5] | Clear_AVMUTE | Refer to HDMI 1.4b Specification Section 5.3.6. |
5.1.7.2. Source Auxiliary Video Information (AVI) InfoFrame Bit-Fields
Bit-field | Name | Description | Default Value |
---|---|---|---|
7:0 | Checksum | Checksum |
8’h67 |
9:8 | S | Scan information | 2’h0 |
11:10 | B | Bar info data valid | 2’h0 |
12 | A0 | Active information present | 1’h0 |
14:13 | Y | RGB or YCbCr indicator | 2’h0 |
15 | Reserved | Returns 0 | 1’h0 |
19:16 | R | Active format aspect ratio | 4’h8 |
21:20 | M | Picture aspect ratio | 2’h0 |
23:22 | C | Colorimetry (for example: ITU BT.601, BT.709) | 2’h0 |
25:24 | SC | Non-uniform picture scaling | 2’h0 |
27:26 | Q | Quantization range | 2’h0 |
30:28 | EC | Extended colorimetry | 3’h0 |
31 | ITC | IT content | 1’h0 |
38:32 | VIC | Video format identification code | 7’h00 |
39 | Reserved | Returns 0 | 1’h0 |
43:40 | PR | Picture repetition factor | 4’h0 |
45:44 | CN | Content type | 2’h0 |
47:46 | YQ | YCC quantization range | 2’h0 |
63:48 | ETB | Line number of end of top bar | 16’h0000 |
79:64 | SBB | Line number of start of bottom bar | 16’h0000 |
95:80 | ELB | Pixel number of end of left bar | 16’h0000 |
111:96 | SRB | Pixel number of start of right bar | 16’h0000 |
112 | Control | Disables the core from inserting the
InfoFrame packet.
|
– |
5.1.7.3. Source HDMI Vendor Specific InfoFrame (VSI)
Bit-field | Name | Description | Default Value |
---|---|---|---|
4:0 | Length | Length of HDMI VSI payload | 5’h06 |
12:5 | Checksum | Checksum | 8’h69 |
36:13 | IEEE | 24-bit IEEE registration identifier (0×000C03) | 24’h000C03 |
41:37 | Reserved | Reserved (0) | 5’h00 |
44:42 | HDMI_Video_Format | Structure of extended video formats exclusively defined in HDMI 1.4b Specification | 3’h0 |
52:45 | HDMI_VIC or 3D_Structure |
|
8’h00 |
57:53 | Reserved | Reserved (0) | 5’h00 |
60:58 | 3D_Ext_Data | 3D extended data | 3’h0 |
61 | Control | Disables the core from inserting the
InfoFrame packet.
|
– |
5.1.8. Source Audio Encoder
- Audio Clock Regeneration
- Audio InfoFrame
- Audio Metadata
- Audio Sample
The Audio Clock Regeneration packet contains the CTS and N values. You need to provide these values as recommended in HDMI 1.4b Specification Section 7.2.1 through 7.2.3 and HDMI 2.0b Specification Section 9.2.1. The core schedules this packet to be sent every ms. The timestamp scheduler uses the audio_clk and N value to determine a 1-ms interval.
The audio data queues on a DCFIFO. The core also uses the DCFIFO to synchronize its clock to ls_clk. The Audio Packetizer packs the audio data into the Audio Sample packets according to the specified audio format (as described in HDMI 1.4b Specification Section 5.3.4). An Audio Sample packet can contain up to 4 audio samples, based on the required audio sample clock. The core sends the Audio Sample packets whenever there is an available slot in the auxiliary packet stream.
The core determines the payload data packet type from the audio_format[3:0] signal.
Value | Name | Description |
---|---|---|
0 |
Linear Pulse-Code Modulation (LPCM) |
Use packet type 0x02 to transport payload data |
4 |
3D Audio (LPCM) |
Use packet type 0x0B to transport payload data |
6 |
Multi-Stream(MST) Audio for LPCM |
Use packet type 0x0E to transport payload data |
Others | – | Reserved |
The 32-bit audio data is packed in IEC-60958 standard. The least significant word is the left channel sample.
The audio_data port is always at a fixed value of 256 bits. In the LPCM format, the core can send up to 8 channels of audio data.
- Channel 1 audio data should be present at audio_data[31:0].
- Channel 2 audio data should be present at audio_data[63:32] and so on.
The Sample Present (SP) bit determines whether to use 2-channel or 8-channel layout. If the SP bit from Channel 3 is high, then the core uses the 8-channel layout. If otherwise, the core uses the 2-channel layout. The core ignores all other fields if the SP bit is 0.
The core requires an audio_de port for designs in which the audio_clk port frequency is higher than the actual audio sample clock. The audio_de port qualifies the audio data. If audio_clk is the actual audio sample clock, you can tie the audio_de signal to 1. For audio channels fewer than 8, insert 0 to the respective audio data of the unused audio channels.
The Audio Clock Regeneration and Audio Sample packets on the Auxiliary Data Port are not filtered by the core. You must filter these packets externally if you want to loop back the auxiliary data stream from the sink.
3D Audio Format
In 3D format, the core sends up to 32 channels audio data by consuming up to 4 writes of 8 channels. Assert audio_format[4] to indicate the first 8 channels of each sample. For audio channels greater than 8, do not drive audio_clk at actual audio sample clock; instead drive audio_clk with ls_clk and qualify audio_data with audio_de.
MST Audio Format
In MST format, the core sends 2, 3, or 4 streams of audio. For audio streams fewer than 4, you must set the respective audio data to zero for the unused streams as shown in the figure below.
5.1.8.1. Audio InfoFrame (AI) Bundle Bit-Fields
The default values are overridden by the customized input values (audio_info_ai[47:0]) when the input checksum is non-zero. The core sends the AI packet on the active edge of the V-SYNC signal to ensure that the packet is sent once per field.
Bit-field | Name | Description | Default Value |
---|---|---|---|
7:0 | Checksum | Checksum | 8’h71 |
10:8 | CC | Channel count | 3’h0 |
11 | Reserved | Returns 0 | 1’h0 |
15:12 | CT | Audio format type | 4’h0 |
17:16 | SS | Bits per audio sample | 2’h0 |
20:18 | SF | Sampling frequency | 3’h0 |
23:21 | Reserved | Returns 0 | 3’h0 |
31:24 | CXT | Audio format type of the audio stream | 8’h00 |
39:32 | CA | Speaker location allocation FL, FR | 8’h00 |
41:40 | LFEPBL | LFE playback level information, dB | 2’h0 |
42 | Reserved | Returns 0 | 1’h0 |
46:43 | LSV | Level shift information, dB | 4’h0 |
47 | DM_INH | Down-mix inhibit flag | 1’h0 |
48 | Control | Disables the core from
inserting
the AI packet.
|
– |
5.1.8.2. Audio Metadata Bundle Bit-Fields
The core sends the AM packet on the active edge of the V-SYNC signal to ensure that the packet is sent once per field. The signal bundle of audio_metadata[165:0] is clocked by ls_clk.
Bit-field | Name | Description |
---|---|---|
0 | 3D_AUDIO |
|
2:1 | NUM_VIEWS | Number of views for an MST stream |
4:3 | NUM_AUDIO_STR | Number of audio streams - 1 |
165 | Control | Disables the core from inserting the
AM packet.
|
Bit-field | Name | Description |
---|---|---|
9:5 | 3D_CC | Channel count of the transmitted 3D audio |
12:10 | Reserved | Reserved (0) |
16:13 | ACAT | Audio channel allocation standard |
20:17 | Reserved | Reserved (0) |
28:21 | 3D_ACAT | Channel/Speaker allocation for 3D audio |
164:29 | Reserved | Reserved (0) |
Bit-field | Name | Description |
---|---|---|
5 | Multiview_Left_0 | Left stereoscopic picture (Subpacket 0 in MST Audio Sample Packet) |
6 | Multiview_Right_0 | Right stereoscopic picture (Subpacket 0 in MST Audio Sample Packet) |
12:7 | Reserved | Reserved (0) |
15:13 | Suppl_A_Type_0 | Supplementary audio type (Subpacket 0 in MST Audio Sample Packet) |
16 | Suppl_A_Mixed_0 | Mix of main audio components and a supplementary audio track (Subpacket 0 in MST Audio Sample Packet) |
17 | Suppl_A_Valid_0 | Audio stream contains a supplementary audio track (Subpacket 0 in MST Audio Sample Packet) |
19:18 | Reserved | Reserved (0) |
20 | LC_Valid_0 | Validity of Language_Code (Subpacket 0 in MST Audio Sample Packet) |
44:21 | Language_Code_0 | Audio stream language (Subpacket 0 in MST Audio Sample Packet) |
45 | Multiview_Left_1 | Left stereoscopic picture (Subpacket 1 in MST Audio Sample Packet) |
46 | Multiview_Right_1 | Right stereoscopic picture (Subpacket 1 in MST Audio Sample Packet) |
52:47 | Reserved | Reserved (0) |
55:53 | Suppl_A_Type_1 | Supplementary audio type (Subpacket 1 in MST Audio Sample Packet) |
56 | Suppl_A_Mixed_1 | Mix of main audio components and a supplementary audio track (Subpacket 1 in MST Audio Sample Packet) |
57 | Suppl_A_Valid_1 | Audio stream contains a supplementary audio track (Subpacket 1 in MST Audio Sample Packet) |
59:58 | Reserved | Reserved (0) |
60 | LC_Valid_1 | Validity of Language_Code (Subpacket 1 in MST Audio Sample Packet) |
84:61 | Language_Code_1 | Audio stream language (Subpacket 1 in MST Audio Sample Packet) |
85 | Multiview_Left_2 | Left stereoscopic picture (Subpacket 2 in MST Audio Sample Packet) |
86 | Multiview_Right_2 | Right stereoscopic picture (Subpacket 2 in MST Audio Sample Packet) |
92:87 | Reserved | Reserved (0) |
95:93 | Suppl_A_Type_2 | Supplementary audio type (Subpacket 2 in MST Audio Sample Packet) |
96 | Suppl_A_Mixed_2 | Mix of main audio components and a supplementary audio track (Subpacket 2 in MST Audio Sample Packet) |
97 | Suppl_A_Valid_2 | Audio stream contains a supplementary audio track (Subpacket 2 in MST Audio Sample Packet) |
99:98 | Reserved | Reserved (0) |
100 | LC_Valid_2 | Validity of Language_Code (Subpacket 2 in MST Audio Sample Packet) |
124:101 | Language_Code_2 | Audio stream language (Subpacket 2 in MST Audio Sample Packet) |
125 | Multiview_Left_3 | Left stereoscopic picture (Subpacket 3 in MST Audio Sample Packet) |
126 | Multiview_Right_3 | Right stereoscopic picture (Subpacket 3 in MST Audio Sample Packet) |
132:127 | Reserved | Reserved (0) |
135:133 | Suppl_A_Type_3 | Supplementary audio type (Subpacket 3 in MST Audio Sample Packet) |
136 | Suppl_A_Mixed_3 | Mix of main audio components and a supplementary audio track (Subpacket 3 in MST Audio Sample Packet) |
137 | Suppl_A_Valid_3 | Audio stream contains a supplementary audio track (Subpacket 3 in MST Audio Sample Packet) |
139:138 | Reserved | Reserved (0) |
140 | LC_Valid_3 | Validity of Language_Code (Subpacket 3 in MST Audio Sample Packet) |
164:141 | Language_Code_3 | Audio stream language (Subpacket 3 in MST Audio Sample Packet) |
5.1.9. HDCP 1.4 TX Architecture
- Control and Status Registers Layer
- Authentication Layer
- Video Stream and Auxiliary Layer
The Nios II processor typically drives the HDCP 1.4 TX core. The processor implements the authentication protocol. The processor accesses the IP through the Control and Status Port using Avalon Memory Mapped (Avalon-MM) interface.
The HDCP specifications requires the HDCP 1.4 TX core to be programmed with the DCP-issued production keys – Device Private Keys (Akeys) and Key Selection Vector (Aksv). The IP retrieves the key from the on-chip memory externally to the core through the HDCP Key Port. The on-chip memory must store the key data in the arrangement in the table below.
Address | Content |
---|---|
6'h29 | {16’d0, Aksv[39:0]} |
6'h28 | Akeys39[55:0] |
6'h27 | Akeys38[55:0] |
... | ... |
6'h01 | Akeys01[55:0] |
6'h00 | Akeys00[55:0] |
When authenticating with the HDCP 1.4 repeater device, the HDCP 1.4 TX core must perform the second part of the authentication protocol. This second part corresponds to the computation of the SHA-1 hash digest for all downstream device KSVs which are written to the registers in Control and Status Register Layer using the Control and Status Port (Avalon-MM).
The Video Stream and Auxiliary layer receives audio and video content over its Video and Aux Data Input Port, and performs the encryption operation. The Video Stream and Auxiliary Layer detects the Encryption Status Signaling (ESS) provided by the HDMI TX core to determine when to encrypt frames.
You can use the HDCP 1.4 registers to customize your design configurations. The HDCP 1.4 TX core supports full handshaking mechanism for authentication. Every issued command should be followed by polling of the assertion of its corresponding status bit before proceeding to issuing the next command. The value of AUTH_CMD must be in one-hot format that only one bit can be set at a time.
Address | Register | R/W | Reset | Bit | Bit Name | Description |
---|---|---|---|---|---|---|
0x00 | AUTH_CMD (one-hot) | WO | 0x0 | 31:6 | Reserved | Reserved. |
5 | GO_V | Set to 1 to compute V and compare against V’ during authentication with repeater. Self-cleared. | ||||
4 | Reserved | Reserved. | ||||
3 | GEN_RI | Set to 1 to generate and receive R0 during authentication exchange or Ri during link integrity verification. Ri-Ri’ comparison should be performed by Nios II processor. Self-cleared. | ||||
2 | GO_KM | Set to 1 to compute master key (km). Self-cleared. | ||||
1 | GEN_AKSV | Set to 1 to request and receive Aksv. Self-cleared. | ||||
0 | GEN_AN | Set to 1 to generate and receive new true random An. Self-cleared. | ||||
0x01 | AUTH_MSGDATAIN | WO | 0x0 | 31:8 | Reserved | Reserved. |
7:0 | MSGDATAIN |
Write messages (in byte) from receiver in burst mode.
|
||||
0x02 | AUTH_STATUS | RO | 0x0 | 31 | KM_OK | Asserted by the core to indicate the received Bksv is valid. Poll KM_DONE until it is set before reading KM_OK. |
30 | V_OK | Asserted by the core to indicate V-V’ comparison is passed. Poll V_DONE until it is set before reading V_OK. | ||||
29:6 | Reserved | Reserved. | ||||
5 | V_DONE | Asserted by the core when V is generated. Self-cleared upon next GO_V is set. | ||||
4 | Reserved | Reserved | ||||
3 | RI_DONE | Asserted by the core when Ri is generated. Self-cleared upon next GEN_RI is set. | ||||
2 | KM_DONE | Asserted by the core when Km is generated. Self-cleared upon next GO_KM is set. | ||||
1 | AKSV_DONE | Asserted by the core when Aksv is ready to be read from MSGDATAOUT. Self-cleared upon next GEN_AKSV is set. | ||||
0 | AN_DONE | Asserted by the core when new random An is generated and ready to be read from MSGDATAOUT. Self-cleared upon next GEN_AN is set. | ||||
0x03 | AUTH_MSGDATAOUT | RO | 0x0 | 31:8 | Reserved | Reserved. |
7:0 | MSGDATAOUT |
Read messages (in byte) from the IP in burst mode.
|
||||
0x04 | VID_CTL | RW | 0x0 | 31:1 | Reserved | Reserved. |
0 | HDCP_ENABLE | Set to 1 to enable HDCP 1.4 encryption. Set to 0 if HDCP 1.4 encryption is not required especially when it is in unauthenticated state. | ||||
0x05 | BCAPS | RW | 0x0 | 31:2 | Reserved | Reserved.. |
1 | REPEATER | Downstream repeater capability. Write bit 6 (REPEATER) of Bcaps received from downstream to this offset. | ||||
0 | Reserved | Reserved. |
5.1.10. HDCP 2.3 TX Architecture
- Control and Status Registers Layer
- Authentication and Cryptographic Layer
- Video Stream and Auxiliary Layer
The Nios II processor typically drives the HDCP 2.3 TX core. The processor implements the authentication protocol. The processor accesses the IP through the Control and Status Port using Avalon Memory Mapped (Avalon-MM) interface.
The HDCP specifications requires the HDCP 2.3 TX core to be programmed with the DCP-issued production key – Global Constant (lc128). The IP retrieves the key from the on-chip memory externally to the core through the HDCP Key Port. The on-chip memory must store the key data in the arrangement in the table below.
Address | Content |
---|---|
2'h3 | lc128[127:96] |
2'h2 | lc128[95:64] |
2'h1 | lc128[63:32] |
2'h0 | lc128[31:0] |
The Video Stream and Auxiliary Layer receives audio and video content over its Video and Aux Data Input port, and performs the encryption operation. The Video Stream and Auxiliary Layer detects the Encryption Status Signaling (ESS) provided by the HDMI TX core to determine when to encrypt frames.
You can use the HDCP 2.3 registers to perform authentication. The HDCP 2.3 TX core supports full handshaking mechanism for authentication. Every issued command should be followed by polling of the assertion of its corresponding status bit before proceeding to issuing the next command. The value of CRYPTO_CMD must be in one-hot encoding format that only one bit can be set at a time.
Address | Register | R/W | Reset | Bit | Bit Name | Description |
---|---|---|---|---|---|---|
0x00 | CRPYTO_CMD (one-hot) | WO | 0x0 | 31:11 | Reserved | Reserved |
10 | GO_HMAC_M | Set to 1 to compute M and verify against M’. Self-cleared upon operation is busy. | ||||
9 | GO_HMAC_V | Set to 1 to compute V and verify against V’. Self-cleared upon operation is busy. | ||||
8 | GEN_RIV | Set to 1 to generate and receive new random riv. Self-cleared upon operation is busy. | ||||
7 | GEN_EDKEYKS | Set to 1 to generate and receive new random Edkey(ks). Self-cleared upon operation is busy. | ||||
6 | GO_HMAC_L | Set to 1 to compute L and verify against L’. Self-cleared upon operation is busy. | ||||
5 | GEN_RN | Set to 1 to generate and receive new random rn. Self-cleared upon operation is busy. | ||||
4 | GO_HMAC_H | Set to 1 to compute H and verify against H’. Self-cleared upon operation is busy. | ||||
3 | GO_KD | Set to 1 to compute kd (dkey0, dkey1). Self-cleared upon operation is busy. | ||||
2 | GEN_EKPUBKM | Set to 1 to generate and receive new random Ekpub(km). Self-cleared upon operation is busy. | ||||
1 | GO_SIG | Set to 1 to verify signature (certrx or SRM). Self-cleared upon operation is busy. | ||||
0 | GEN_RTX | Set to 1 to generate and receive new random rtx. Self-cleared upon operation is busy. | ||||
0x01 | CRYPTO_MSGDATAIN | WO | 0x0 | 31:8 | Reserved | Reserved |
7:0 | MSGDATAIN |
Write messages (in byte) from receiver in burst mode.
|
||||
0x02 | CRYPTO_STATUS | RO | 0x0 | 31 | SIG_OK | Asserted by the core to indicate signature verification is passed. Poll SIG_DONE until it is set before reading SIG_OK. |
30 | H_OK | Asserted by the core to indicate H-H’ comparison is passed. Poll H_DONE until it is set before reading H_OK. | ||||
29 | L_OK | Asserted by the core to indicate L-L’ comparison is passed. Poll L_DONE until it is set before reading L_OK. | ||||
28 | V_OK | Asserted by the core to indicate V-V’ comparison is passed. Poll V_DONE until it is set before reading V_OK. | ||||
27 | M_OK | Asserted by the core to indicate M-M’ comparison is passed. Poll M_DONE until it is set before reading M_OK. | ||||
26:11 | Reserved | Reserved | ||||
10 | M_DONE | Asserted by the core when M-M’ comparison is done. Self-cleared upon next GO_HMAC_M is set. | ||||
9 | V_DONE | Asserted by the core when V-V’ comparison is done. Self-cleared upon next GO_HMAC_V is set. | ||||
8 | RIV_DONE | Asserted by the core when riv is generated and ready to be read from MSGDATAOUT. Self-cleared upon next GEN_RIV is set. | ||||
7 | EDKEYKS_DONE | Asserted by the core when Edkey(ks) is generated and ready to be read from MSGDATAOUT. Self-cleared upon next GEN_EDKEYKS is set. | ||||
6 | L_DONE | Asserted by the core when L-L’ comparison is done. Self-cleared upon next GO_HMAC_L is set. | ||||
5 | RN_DONE | Asserted by the core when rn is generated and ready to be read from MSGDATAOUT. Self-cleared upon next GEN_RN is set. | ||||
4 | H_DONE | Asserted by the core when H-H’ comparison is done. Self-cleared upon next GO_HMAC_H is set. | ||||
3 | KD_DONE | Asserted by the core when kd is generated. Self-cleared upon next GO_KD is set. | ||||
2 | EKPUBKM_DONE | Asserted by the core when Ekpub(km) is generated and ready to be read from MSGDATAOUT. Self-cleared upon next GEN_EKPUBKM is set. | ||||
1 | SIG_DONE | Asserted by the core when signature verification is done. Self-cleared upon next GO_SIG is set. | ||||
0 | RTX_DONE | Asserted by the core when rtx is generated and ready to be read from MSGDATAOUT. Self-cleared upon next GEN_RTX is set. | ||||
0x03 | CRYPTO_MSGDATAOUT | RO | 0x0 | 31:8 | Reserved | Reserved. |
7:0 | MSGDATAOUT |
Read messages (in byte) from IP core in burst mode.
|
||||
0x04 | VID_CTL | RW | 0x0 | 31:1 | Reserved | Reserved. |
0 | HDCP_ENABLE | Set to 1 to enable HDCP 2.3 encryption. Set to 0 if HDCP 2.3 encryption is not required especially when it is in unauthenticated state. |
5.2. Source Interfaces
Interface |
Port Type |
Clock Domain |
Port |
Direction |
Description |
|
---|---|---|---|---|---|---|
Reset | Reset | – | reset | Input | Main asynchronous reset input. | |
Clock | Clock | – | ls_clk | Input | Link speed clock
input. Relationship to vid_clk as a function of color depth:
This signal connects to the transceiver output clock only if an application does not require low TMDS Bit Rate (below the minimum transceiver data rate), which means no oversampling is required. This signal should connect to a PLL output clock that meets the vid_clk relationship if an application requires low TMDS Bit Rate (below the minimum transceiver data rate), which means oversampling is required. Refer to Source Clock Tree for more information. |
|
Clock | – | vid_clk | Input |
Video data clock input. For RGB and YCbCr 4:4:4/4:2:2 transport:
For YCbCr 4:2:0 transport:
|
||
Clock | – | audio_clk | Input |
Audio clock input. Connect this signal to ls_clk by qualifying the slower frequency of audio_data with audio_de. If you connect this signal to a clock at actual audio sample frequency, you must tie audio_de to 1. For audio channels greater than 8, do not drive audio_clk at actual audio sample clock; instead drive audio_clk with ls_clk and qualify audio_data with audio_de. Note: Applicable only when you turn on the Support auxiliary and Support audio parameters.
|
||
Video Data Port | Conduit | vid_clk | vid_data[N*48-1:0] | Input |
Video 48-bit pixel data input port.
|
|
Conduit | vid_clk | vid_de[N-1:0] | Input | Video data enable input that indicates active picture region. | ||
Conduit | vid_clk | vid_hsync[N-1:0] | Input | Video horizontal sync input. | ||
Conduit | vid_clk | vid_vsync[N-1:0] | Input | Video vertical sync input. | ||
TMDS Data Port 4 | Conduit | ls_clk | out_b[N*10-1:0] | Output | TMDS encoded blue channel (0) output. | |
Conduit | ls_clk | out_g[N*10-1:0] | Output | TMDS encoded green channel (1) output. | ||
Conduit | ls_clk | out_r[N*10-1:0] | Output | TMDS encoded red channel (2) output. | ||
Conduit | ls_clk | out_c[N*10-1:0] | Output | Clock channel output. | ||
Encoder Control Port | Conduit | ls_clk | mode | Input | Encoding mode input.
|
|
Conduit | ls_clk | TMDS_Bit_clock_Ratio | Input |
Indicates if TMDS Bit Rate is greater than 3.4Gbps.
|
||
Conduit | ls_clk | Scrambler_Enable | Input |
Enables scrambling.
|
||
Conduit | ls_clk | ctrl[N*6-1:0] | Input | DVI control side-band inputs to override the necessary control and synchronization data in the green and red channels. | ||
Bit-Field | Name | |||||
N*6+5 |
CTL3 |
|||||
N*6+4 |
CTL2 |
|||||
N*6+3 |
CTL1 |
|||||
N*6+2 |
CTL0 |
|||||
N*6+1 |
Reserved (0) |
|||||
N*6 |
Reserved (0) |
|||||
Refer to the HDMI 1.4b Specification for more information. |
||||||
Auxiliary Data Port (Applicable only when you enable Support auxiliary parameter) | Conduit | ls_clk | aux_ready | Output | Auxiliary data channel ready output. Asserted high to indicate that the core is ready to accept data. | |
Conduit | ls_clk | aux_valid | Input | Auxiliary data channel valid input to qualify the data. | ||
Conduit | ls_clk | aux_data[71:0] | Input | Auxiliary data channel
data input. For information about the bit-fields, refer to Figure 23. |
||
Conduit | ls_clk | aux_sop | Input | Auxiliary data channel start-of-packet input to mark the beginning of a packet. | ||
Conduit | ls_clk | aux_eop | Input | Auxiliary data channel end-of-packet input to mark the end of a packet. | ||
Auxiliary Control Port (Applicable only when you enable Support auxiliary parameter) | Conduit | ls_clk | gcp[5:0] | Input | General Control Packet
user input. For information about the bit-fields, refer to Table 24. |
|
Conduit | ls_clk | info_avi[112:0] | Input | Auxiliary Video
Information InfoFrame user input. For information about the bit-fields, refer to Table 25. |
||
Conduit | ls_clk | info_vsi[61:0] | Input | Vendor Specific
Information InfoFrame user input. For information about the bit-fields, refer to Table 26. |
||
Audio Port (Applicable only when you enable Support auxiliary and Support audio parameters) | Conduit | audio_clk | audio_CTS[19:0] | Input | Audio CTS value input. | |
Conduit | audio_clk | audio_N[19:0] | Input | Audio N value input. | ||
Conduit | audio_clk | audio_data[255:0] | Input | Audio data input. For audio channel values, refer to Table 39. |
||
Conduit | audio_clk | audio_de | Input | Audio data valid input. | ||
Conduit | audio_clk | audio_mute | Input | Audio mute input. No audio will be transmitted when this signal is asserted high. | ||
Conduit | ls_clk | audio_info_ai[48:0] | Input | Audio InfoFrame user input. Note: If you provide
audio_info_ai
[48:0]
using audio_clk with actual audio sample frequency, you must
synchronize the clock domain to ls_clk externally.
For information about the bit-fields, refer to Table 28. |
||
Conduit | ls_clk | audio_metadata[165:0] | Input | Carries additional
information related to 3D audio and MST audio. Note: If you provide
audio_metadata
[165:0]
using audio_clk with actual audio sample frequency, you must
synchronize the clock domain to ls_clk externally.
For information about the bit-fields, refer to Table 29, Table 30, and Table 31. |
||
Conduit | audio_clk | audio_format[4:0] | Input | Controls the transmission of the 3D audio and indicates the audio format to be transmitted. | ||
Bit-Field | Description | |||||
4 | Assert to indicate the first 8 channels of each 3D audio sample. | |||||
3:0 |
For information about the bit-fields, refer to Table 27. |
|||||
HDCP Port (Applicable only when you enable Support HDCP 2.3 or Support HDCP 1.4 parameters) | Reset | – | hdcp_reset | Input | Main asynchronous reset. | |
Clock | – | csr_clk | Input |
HDCP clock for Control and Status Registers Layer. Typically, shares the Nios II processor clock (100 MHz). |
||
– | crypto_clk | Input |
HDCP 2.3 clock for Authentication and Cryptographic Layer. You can use any clock with a frequency of up to 200 MHz. Note: The clock frequency determines the authentication
latency.
|
|||
Avalon-MM | csr_clk | csr_addr[7:0] | Input |
The Avalon-MM slave port that provides access to internal control and status register, mainly for authentication messages transfer. This interface is expected to operate at Nios II processor clock domain. Because of the extremely large bit portion of message, the IP transfers the message in burst mode with full handshaking mechanism. Write transfers always have a wait time of 0 cycle while read transfers have a wait time of 1 cycle. The addressing should be accessed as word addressing in the Platform Designer flow. For example, addressing of 4 in the Nios II software selects the address of 1 in the slave. |
||
csr_wr | Input | |||||
csr_rd | Input | |||||
csr_wrdata[31:0] | Input | |||||
csr_rddata[31:0] | Output | |||||
Conduit (Key) |
crypto_clk (HDCP 2.3) csr_clk (HDCP 1.4) |
kmem_wait[0] (HDCP 2.3) kmem_wait[1] (HDCP 1.4) |
Input |
Always keep this signal asserted until the key is ready to be read. |
||
kmem_rdaddr[3:0] (HDCP 2.3) kmem_rdaddr[9:4] (HDCP 1.4) |
Output |
Key read address bus. [3:2] = Reserved. |
||||
kmem_q[31:0] (HDCP 2.3) kmem_q[87:32] (HDCP 1.4) |
Input |
Key read data transfer. Read transfer always have a wait time of 1 cycle. |
||||
Conduit | ls_clk | hdcp1_enabled | Output | This signal is asserted by the IP if the outgoing video and auxiliary data are HDCP 1.4 encrypted. | ||
hdcp2_enabled | Output | This signal is asserted by the IP if the outgoing video and auxiliary data are HDCP 2.3 encrypted. |
N | out_c Value |
---|---|
1 | 10'b1111100000 |
2 | 20'b1111100000_1111100000 |
4 | 40'b1111100000_1111100000 1111100000_1111100000 |
N | out_c Value | |||
---|---|---|---|---|
t | t+1 | t+2 | t+3 | |
1 | 10’h000 | 10’h000 | 10’h3ff | 10’h3ff |
2 | 20’h00000 | 20’hfffff | 20'h00000 | 20’hfffff |
4 | 40’hfffff 00000 | 40’hfffff 00000 | 40’hfffff 00000 | 40’hfffff 00000 |
Bit-Field | Audio Channel | |
---|---|---|
LPCM and 3D Audio (LPCM) | MST Audio (LPCM) | |
255:224 | 8 or 16 or 24 or 32 |
Stream 4 right channel |
223:192 | 7 or 15 or 23 or 31 |
Stream 4 left channel |
191:160 | 6 or 14 or 22 or 30 |
Stream 3 right channel |
159:128 | 5 or 13 or 21 or 29 |
Stream 3 left channel |
127:96 | 4 or 12 or 20 or 28 |
Stream 2 right channel |
95:64 | 3 or 11 or 19 or 27 |
Stream 2 left channel |
63:32 | 2 or 10 or 18 or 26 |
Stream 1 right channel |
31:0 | 1 or 9 or 17 or 25 |
Stream 1 left channel |
5.3. Source Clock Tree
For HDMI source, you must instantiate 4 transceiver channels: 3 channels to transmit data and 1 channel to transmit clock information.
The core uses a general purpose phase-locked loop (GPLL), that is referenced by an arbitrary TMDS clock frequency, to generate the link speed clock (ls_clk) and video clock (vid_clk).
- The video data clocks into the core at vid_clk.
- The TMDS data clocks out from the core at ls_clk.
The same arbitrary TMDS clock frequency is also used to drive the transceiver PLL. ls_clk and tx_clkout[0] are derived from vid_clk based on the color depth, TMDS_Bit_clock_Ratio, and user oversampling control bit information.
If an application requires low TMDS Bit Rate (below the transceiver minimum data rate requirement), then the application needs a user logic consisting of a DCFIFO and oversampling logic.
- The DCFIFO synchronizes the TMDS data from ls_clk to a faster transceiver output clock (tx_clkout[0]).
- The oversampling logic repeats each bit of the TMDS data a given number of times.
- When you enable the oversampling control bit, the transceiver transmits the TMDS data between the HDMI source core and the oversampling logic.
- You can use tx_clkout[0] across 4 channels if the transceiver is in bonding mode.
If an application does not require low TMDS Bit Rate, you can connect the core output directly to the transceiver with tx_clkout[0] driving the core ls_clk. You do not require the GPLL to generate CLK1 (ls_clk).
6. HDMI Sink
6.1. Sink Functional Description
- Blue channel: 0
- Green channel: 1
- Red channel: 2
6.1.1. Sink Word Alignment and Channel Deskew
Stage | Description |
---|---|
Word Alignment |
Note: If you
are using
Intel®
Arria® 10 or
Intel®
Cyclone® 10 GX devices, soft
word alignment logic in the HDMI RX core is disabled for HDMI 2.0 resolution (data
rate >3.4 Gbps). Hard transceiver PCS word alignment is used with some control logic
to achieve faster word alignment with more optimized resource utilization. Refer to
the design example user guides for more
information.
Note: If
you are using
Intel®
Stratix® 10 devices, the HDMI RX core uses a new word
alignment algorithm logic to achieve fast word alignment time for HDMI 2.0
resolution (data rate >3.4Gbps).
|
Channel Deskew |
|
The FIFO read signal of the channels is normally asserted. The sink core deasserts a particular FIFO read signal if a marker appears at its output and not in the other two FIFO outputs. By deasserting, the sink core stalls the data stream for sufficient cycles to remove the channel skew. If any of the FIFO channels overflow, the sink core asserts a reset signal which propagates backwards to the word alignment logic.
6.1.2. Sink Descrambler, TMDS/TERC4 Decoder
The sink core feeds the aligned channels into the TMDS/TERC4 decoder. You can parameterize the decoder to operate in 1, 2, or 4 TMDS symbols per clock. If you choose 2 or 4 TMDS symbols per clock, the decoder will produce 2 or 4 decoded symbols per clock. The decoded symbols per clock output supports high pixel clock resolutions on low-end FPGA devices.
6.1.3. Sink Video Resampler
- To keep the source and sink resamples synchronized, the source must send the packing-phase (pp) value to the sink during the vertical blanking phase, using the general control packet.
- The pp corresponds to the phase of the last pixel in the last active video line.
- The phase-counter logic compares its own pp value to the pp value received in the general control packet and slips the phase count if the two pp values do not agree.
The output from the resampler is fixed at 16 bpc. When the resampler operates in lower color depths, the low order bits are zero. The pixel data output format across color space are are described in Figure 10-12.
6.1.4. Sink Auxiliary Decoder
Memory Start Address | Packet Name |
---|---|
0 | NULL PACKET |
4 | Audio Clock Regeneration (N/CTS) |
8 | Audio Sample |
12 | General Control |
16 | ACP Packet |
20 | ISRC1 Packet |
24 | ISRC2 Packet |
28 | One Bit Audio Sample Packet 5.3.9 |
32 | DST Audio Packet |
36 | High Bit rate (HBR) Audio Stream Packet |
40 | Gamut Metadata Packet |
44 | 3D Audio Sample Packet |
48 | One Bit 3D Audio Sample Packet |
52 | Audio Metadata Packet |
56 | Multi-Stream Audio Sample Packet |
60 | One Bit Multi-Stream Audio Sample Packet |
64 | Vendor-Specific InfoFrame |
68 | AVI InfoFrame |
72 | Source Product Descriptor InfoFrame |
76 | Audio InfoFrame |
80 | MPEG Source InfoFrame |
84 | TSC VBI InfoFrame |
88 | Dynamic Range and Mastering InfoFrame |
Word Offset | Byte Offset | ||||||||
---|---|---|---|---|---|---|---|---|---|
8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | |
0 | PB22 | PB21 | PB15 | PB14 | PB8 | PB7 | PB1 | PB0 | HB0 |
1 | PB24 | PB23 | PB17 | PB16 | PB10 | PB9 | PB3 | PB2 | HB1 |
2 | PB26 | PB25 | PB19 | PB18 | PB12 | PB11 | PB5 | PB4 | HB2 |
3 | BCH3 | PB27 | BCH2 | PB20 | BCH1 | PB13 | BCH0 | PB6 | HBCH0 |
The data output at EOP contains the received BCH error correcting code. The sink core does not perform any error correction within the core. The auxiliary data is available outside the core.
6.1.5. Sink Auxiliary Packet Capture
These packets are: General Control Packet (GCP), Auxiliary Video Information (AVI) InfoFrame, and HDMI Vendor Specific InfoFrame (VSI).
The GCP, AVI and VSI bit-fields (excluding control bit) are defined in Table 24. Table 25. and Table 26 respectively with reserved bits return 0.
6.1.6. Sink Auxiliary Data Port
The core calculates the address for the data port using the header byte of the received packet. The core writes packet types 0–15 into a contiguous memory region.
Memory Start Address | Packet Name |
---|---|
0 | NULL PACKET |
4 | Audio Clock Regeneration (N/CTS) |
8 | Audio Sample |
12 | General Control |
16 | ACP Packet |
20 | ISRC1 Packet |
24 | ISRC2 Packet |
28 | One Bit Audio Sample Packet 5.3.9 |
32 | DST Audio Packet |
36 | High Bitrate (HBR) Audio Stream Packet |
40 | Gamut Metadata Packet |
44 | 3D Audio Sample Packet |
48 | One Bit 3D Audio Sample Packet |
52 | Audio Metadata Packet |
56 | Multi-Stream Audio Sample Packet |
60 | One Bit Multi-Stream Audio Sample Packet |
64 | Vendor-Specific InfoFrame |
68 | AVI InfoFrame |
72 | Source Product Descriptor InfoFrame |
76 | Audio InfoFrame |
80 | MPEG Source InfoFrame |
84 | TSC VBI InfoFrame |
88 | Dynamic Range and Mastering InfoFrame |
Word Offset | Byte Offset | ||||||||
---|---|---|---|---|---|---|---|---|---|
8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | |
0 | PB22 | PB21 | PB15 | PB14 | PB8 | PB7 | PB1 | PB0 | HB0 |
1 | PB24 | PB23 | PB17 | PB16 | PB10 | PB9 | PB3 | PB2 | HB1 |
2 | PB26 | PB25 | PB19 | PB18 | PB12 | PB11 | PB5 | PB4 | HB2 |
3 | BCH3 | PB27 | BCH2 | PB20 | BCH1 | PB13 | BCH0 | PB6 | HBCH0 |
6.1.7. Sink Audio Decoder
An audio clock synthesizer uses a phase-counter to recover the audio sample rate. The output from the audio clock synthesizer generates a valid pulse at the same rate as the audio sample clock from the attached source device. This valid pulse is available outside the core as an audio sample valid signal. This signal reads from a FIFO, which governs the rate of audio samples. The audio depacketizer drives the input to the FIFO.
The audio depacketizer extracts the 32-bit audio sample data from the incoming Audio Sample packets. The Audio Sample packets can hold from one to four sample data values. The audio format indicates the format of the received audio data as defined in Table 27.
The Audio InfoFrame and Audio Metadata packets are not used within the core. The packets are captured and presented outside the core. The bit fields (excluding control bit) are defined in Table 28, Table 29, Table 30, and Table 31 with reserved bits return 0.
6.1.8. Status and Control Data Channel (SCDC) Interface
This memory slave port connects to an I2C slave component. The TMDS_Bit_clock_Ratio output from the SCDC interface indicates when the core requires the TMDS Bit Rate/TMDS Clock Rate ratio of 40. This bit is also stored in its corresponding field in the SCDC registers.
The HDMI 2.0b Specification requires the core to respond to the presence of the 5V input from the connector and the state of the HPD signal. The 5V input and HPD signal are used in the register mechanism updates. The signals are synchronous to the scdc_i2c_clk clock domain. You must create a 100-ms delay on the HPD signal externally to the core.
For more information about the Status and Control Data Channel, you may refer to HDMI 2.0b Specification Chapter 10.4. You can obtain the address map for the registers in the HDMI 2.0b Specification.
6.1.9. HDCP 1.4 RX Architecture
The HDCP 1.4 RX core is fully autonomous. For HDMI application, the transmitter drives the HDCP 1.4 RX core using the standard DDC interface supporting I2C protocol. You need an I2C slave externally to drive the IP through the HDCP Register Port (Avalon-MM).
The HDCP specifications requires the HDCP 2.3 RX core to be programmed with the DCP-issued production key – Device Private Keys (Bkeys) and Key Selection Vector (Bksv). The IP retrieves the key from the on-chip memory externally to the core through the HDCP Key Port. The on-chip memory must store the key data in the arrangement shown in the table below.
Address | Content |
---|---|
6'h29 | {16’d0, Bksv[39:0]} |
6'h28 | Bkeys39[55:0] |
6'h27 | Bkeys38[55:0] |
... | ... |
6'h01 | Bkeys01[55:0] |
6'h00 | Bkeys00[55:0] |
The Video Stream and Auxiliary Layer receives audio and video content over its Video and Aux Data Input Port, and performs the decryption operation. The Video Stream and Auxiliary Layer detects the Encryption Status Signaling (ESS) provided by the HDMI IP to determine when to decrypt frames.
To implement the HDCP 1.4 RX core as a repeater upstream interface, the IP must propagate certain information such as KSV list and Bstatus to the upstream transmitter and to be used for SHA-1 hash digest. The repeater downstream interface (TX) must provide this information using the Repeater Message Port (Avalon-MM). You can use the same clock source to drive the clocking for the HDCP Register Port and Repeater Message Port.
The RX registers mapping defined in the following table is equivalent to the address space for HDCP 1.4 receiver defined in the HDCP specification.
Address | Register | R/W | Reset | Bit | Bit Name | Description |
---|---|---|---|---|---|---|
0x00 | BKSV0 | RO | - | 7:0 | - | Bit [7:0] of HDCP Receiver KSV. |
0x01 | BKSV1 | - | 7:0 | Bit [15:8] of HDCP Receiver KSV. | ||
0x02 | BKSV2 | - | 7:0 | Bit [23:16] of HDCP Receiver KSV. | ||
0x03 | BKSV3 | - | 7:0 | Bit [31:24] of HDCP Receiver KSV. | ||
0x04 | BKSV4 | - | 7:0 | Bit [39:32] of HDCP Receiver KSV. | ||
0x05-0x07 | Rsvd | RO | 0x00 | 7:0 | - | Reserved. All bytes read as 0x00. |
0x08 | RI_PRIME0 | RO | 0x00 | 7:0 | - | Link verification response. Bit [7:0] of Ri’. |
0x09 | RI_PRIME1 | 0x00 | 7:0 | - | Link verification response. Bit [15:8] of Ri’. | |
0x0A | PJ_PRIME | RO | 0x00 | 7:0 | - | Reserved. All bytes read as 0x00. |
0x0B – 0x0F | Rsvd | RO | 0x00 | 7:0 | - | Reserved. All bytes read as 0x00. |
0x10 | AKSV0 | WO | 0x00 | 7:0 | - | Bit [7:0] of HDCP Transmitter KSV. |
0x11 | AKSV1 | 0x00 | 7:0 | Bit [15:8] of HDCP Transmitter KSV. | ||
0x12 | AKSV2 | 0x00 | 7:0 | Bit [23:16] of HDCP Transmitter KSV. | ||
0x13 | AKSV3 | 0x00 | 7:0 | Bit [31:24] of HDCP Transmitter KSV. | ||
0x14 | AKSV4 | 0x00 | 7:0 | Bit [39:32] of HDCP Transmitter KSV. | ||
0x15 | AINFO | WO | 0x00 | 7:0 | - | Reserved. |
0x16 – 0x17 | Rsvd | RO | 0x00 | 7:0 | - | Reserved. All bytes read as 0x00. |
0x20 | V_PRIME_H0_0 | RO | 0x00 | 7:0 | - | H0 part of SHA-1 hash value used in the authentication protocol HDCP repeaters. Bit [7:0] of H0 value. |
0x21 | V_PRIME_H0_1 | 0x00 | 7:0 | Bit [15:8] of H0 value. | ||
0x22 | V_PRIME_H0_2 | 0x00 | 7:0 | Bit [23:16] of H0 value. | ||
0x23 | V_PRIME_H0_3 | 0x00 | 7:0 | Bit [31:24] of H0 value. | ||
0x24 | V_PRIME_H1_0 | RO | 0x00 | 7:0 | - | H1 part of SHA-1 hash value used in the authentication protocol HDCP repeaters. Bit [7:0] of H1 value. |
0x25 | V_PRIME_H1_1 | 0x00 | 7:0 | Bit [15:8] of H1 value. | ||
0x26 | V_PRIME_H1_2 | 0x00 | 7:0 | Bit [23:16] of H1 value. | ||
0x27 | V_PRIME_H1_3 | 0x00 | 7:0 | Bit [31:24] of H1 value. | ||
0x28 | V_PRIME_H2_0 | RO | 0x00 | 7:0 | - | H2 part of SHA-1 hash value used in the authentication protocol HDCP repeaters. Bit [7:0] of H2 value. |
0x29 | V_PRIME_H2_1 | 0x00 | 7:0 | Bit [15:8] of H2 value. | ||
0x2A | V_PRIME_H2_2 | 0x00 | 7:0 | Bit [23:16] of H2 value. | ||
0x2B | V_PRIME_H2_3 | 0x00 | 7:0 | Bit [31:24] of H2 value. | ||
0x2C | V_PRIME_H3_0 | RO | 0x00 | 7:0 | - | H3 part of SHA-1 hash value used in the authentication protocol HDCP repeaters. Bit [7:0] of H3 value. |
0x2D | V_PRIME_H3_1 | 0x00 | 7:0 | Bit [15:8] of H3 value. | ||
0x2E | V_PRIME_H3_2 | 0x00 | 7:0 | Bit [23:16] of H3 value. | ||
0x2F | V_PRIME_H3_3 | 0x00 | 7:0 | Bit [31:24] of H3 value. | ||
0x30 | V_PRIME_H4_0 | RO | 0x00 | 7:0 | - | H4 part of SHA-1 hash value used in the authentication protocol HDCP repeaters. Bit [7:0] of H4 value. |
0x31 | V_PRIME_H4_1 | 0x00 | 7:0 | Bit [15:8] of H4 value. | ||
0x32 | V_PRIME_H4_2 | 0x00 | 7:0 | Bit [23:16] of H4 value. | ||
0x33 | V_PRIME_H4_3 | 0x00 | 7:0 | Bit [31:24] of H4 value. | ||
0x34 – 0x3F | Rsvd | RO | 0x00 | 7:0 | - | Reserved. All bytes read as 00. |
0x40 | BCAPS | RO | 0x00 | 7 | HDMI_RESERVED |
0 = Receiver not capable of supporting HDMI 1 = Receiver capable of supporting HDMI |
6 | REPEATER |
HDCP repeater capability. 0 = Receiver is not a repeater. 1 = Receiver is a repeater. |
||||
5 | READY | KSV FIFO ready. When set to 1, the receiver has built the list of attached KSVs and computed the verification value V’. This value is always 0 during the computation of V’. | ||||
4 | FAST | This bit reads as 0. | ||||
3:2 | Reserved | These bits read as 0. | ||||
1 | FEATURES_1_1 | Reserved. This bit reads as 0. | ||||
0 |
FAST_ REAUTHENTICATION |
This bit reads as 1. | ||||
0x41 | BSTATUS0 | RO | 0x00 | 7 |
MAX_DEVS_ EXCEEDED |
Topology error indicator. When set to 1, more than 127 downstream devices, or the capacity of the KSV FIFO, are attached. |
6:0 | DEVICE_COUNT | Total number of attached downstream devices. Always 0 for HDCP Receivers. This count does not include the HDCP Repeater itself, but only downstream devices downstream from the HDCP Repeater. | ||||
0x42 | BSTATUS1 | 0x00 | 7:6 | Rsvd | These bits read as 0. | |
5 | HDMI_RESERVED_2 | Reserved for future possible HDMI use. | ||||
4 | HDMI_MODE | HDMI mode. When set to 1, the HDCP Receiver has transitioned from DVI mode to HDMI mode. | ||||
3 |
MAX_CASCADE_EXCEEDED |
Topology error indicator. When set to 1, more than 7 levels of video repeater have been cascaded together. | ||||
2:0 | DEPTH | 3-bit repeater cascade depth. This value gives the number of attached levels through the connection topology. | ||||
0x43 | KSV_FIFO | RO | 0x00 | 7:0 | - | Key selection vector FIFO. Used to pull downstream KSVs from HDCP Repeaters. |
0x44 – 0xBF | Rsvd | RO | 0x00 | 7:0 | - | Reserved. All bytes read as 0x00. |
0xC0 – 0x100 | DBG | RW | 0x00 | 7:0 | - | Implementation-specific debug registers. |
Address | Register | R/W | Reset | Bit | Bit Name | Description |
---|---|---|---|---|---|---|
0x00 | RPT_KSV_LIST | WO | 0x0 | 31:8 | Reserved | Reserved |
7:0 | KSV_LIST | Byte write KSV List in big endian order. | ||||
0x01 | RPT_BSTATUS | RW | 0x0 | 31:19 | Reserved | Reserved |
18 | REQUEST | Read-only. Asserted by the core to request for KSV_LIST and BSTATUS. This usually happens when re-authentication is triggered by the connected upstream. Note that when REQUEST is asserted, the READY should also be asserted. | ||||
17 | READY | Read-only. Asserted by the core to indicate KSV_LIST and BSTATUS are processed. Write KSV_LIST and BSTATUS after this bit is asserted. | ||||
16 | VALID | Set to 1 after KSV_LIST and BSTATUS are written. Self-cleared by the core after KSV_LIST and BSTATUS are read. | ||||
15:0 | BSTATUS |
[15:12]: Reserved. [11]: MAX_CASCADE_EXCEEDED [10:8]: DEPTH [7]: MAX_DEVS_EXCEEDED [6:0]: DEVICE_COUNT |
||||
0x02 | RPT_MISC | RW | - | 31:1 | Reserved | Reserved. |
0 | REPEATER |
Set to 0 if no downstream is connected or if the connected downstream is not HDCP 1.4-capable. This means the receiver IP core is an end-point receiver rather than a repeater. Set to 1 if the connected downstream is HDCP-capable. |
6.1.10. HDCP 2.3 RX Architecture
The HDCP 2.3 RX core is fully autonomous. For HDMI application, the transmitter drives the HDCP 2.3 RX core using the standard DDC interface supporting I2C protocol.
The HDCP specifications requires the HDCP 2.3 RX core to be programmed with the DCP-issued production key – Global Constant (lc128), RSA private key (kprivrx) and RSA Public Key Certificate (certrx). The IP retrieves the key from the on-chip memory externally to the core through the HDCP Key Port. The on-chip memory must store the key data in the arrangement shown in the table below.
Address | Content |
---|---|
8'hE3 | lc128[127:96] |
8'hE2 | lc128[95:64] |
8'hE1 | lc128[63:32] |
8'hE0 | lc128[31:0] |
8'hDF | kprivrx_p[511:480] |
... | ... |
8'hD0 | kprivrx_p[31:0] |
8'hCF | kprivrx_q[511:480] |
... | ... |
8'hC0 | kprivrx_q[31:0] |
8'hBF | kprivrx_dp[511:480] |
... | ... |
8'hB0 | kprivrx_dp[31:0] |
8'hAF | kprivrx_dq[511:480] |
... | ... |
8'hA0 | kprivrx_dq[31:0] |
8'h9F | kprivrx_qinv[511:480] |
... | ... |
8'h90 | kprivrx_qinv[31:0] |
8'h83–8'h8F | Reserved |
8'h82 | {16’d0, certrx[4175:4160]} |
8'h81 | certrx[4159:4128] |
... | ... |
8'h01 | certrx[63:32] |
8'h00 | certrx[31:0] |
The Video Stream and Auxiliary Layer receives audio and video content over its Video and Aux Data Input Port, and performs the decryption operation. The Video Stream and Auxiliary Layer detects the Encryption Status Signaling (ESS) provided by the HDMI IP to determine when to decrypt frames.
To implement the HDCP 2.3 RX core as a repeater upstream interface, the IP must propagate certain information such as ReceiverID List and RxInfo to the upstream transmitter and to be used for HMAC computation. The repeater downstream interface (TX) must provide this information using the Repeater Message Port (Avalon-MM). You can use the same clock source to drive the clocking for the HDCP Register Port and Repeater Message Port.
The RX registers mapping defined in the following table is equivalent to the address space for HDCP 2.3 receiver defined in the HDCP specification.
Address | Register | R/W | Reset | Bit | Bit Name | Description |
---|---|---|---|---|---|---|
0x44 – 0x4F | Rsvd | RO | 0x00 | 7:0 | Reserved | Reserved. |
0x50 | HDCP2VERSION | RO | 0x04 | 7:3 | Reserved | Reserved. |
2 | HDCP22 | When set to 1, the core supports HDCP 2.2 and above. | ||||
1:0 | Reserved | Reserved. | ||||
0x51 – 0x5F | Rsvd | RO | 0x00 | 7:0 | Reserved | Reserved. |
0x60 | WRITE_MESSAGE | WO | 0x00 | 7:0 | WR_MSG | Variable length message written by the transmitter as a single burst write to this address. |
0x61 – 0x6F | Rsvd | RO | 0x00 | 7:0 | Reserved | Reserved. |
0x70 | RXSTATUS0 | RO | 0x00 | 7:0 | MSG_SIZE0 | The lower part of message size in bytes available at the receiver for reading by the transmitter. |
0x71 | RXSTATUS1 | RO | 0x00 | 7:4 | Reserved | Reserved |
3 | REAUTH_REQ | When set to 1, indicates the link integrity check failure at the receiver (including upstream side of the repeater) or the upstream side of the repeater has transitioned into an unauthenticated state. Self-cleared by the core on every new authentication initiated by the AKE_Init message. | ||||
2 | READY | When set to 1, the repeater has built the list of downstream Receiver IDs and computed the verification value V’. Self-cleared by the core as soon as the RepeaterAuth_Send_ReceiverID_List message has been read by the transmitter or on every new authentication request by the transmitter. | ||||
1:0 | MSG_SIZE1 | The upper part of message size in bytes available at the receiver for reading by the transmitter. | ||||
0x72 – 0x7F | Rsvd | RO | 0x00 | 7:0 | Reserved | Reserved. |
0x80 | READ_MESSAGE | RO | 0x00 | 7:0 | RD_MSG | Variable length message read by the transmitter as a single burst read from this address. |
0x81 – 0xBF | Rsvd | RO | 0x00 | 7:0 | Reserved | Reserved. |
0xC0 – 0xFF | DBG | RW | 0x00 | 7:0 | DBG_REGS | Implemented specific debug registers. |
Address | Register | R/W | Reset | Bit | Bit Name | Description |
---|---|---|---|---|---|---|
0x00 | RPT_RCVDID_LIST | WO | 0x0 | 31:8 | Reserved | Reserved |
7:0 | RCVDID_LIST | Byte write ReceiverID_List in big endian order. | ||||
0x01 | RPT_RXINFO | RW | 0x0 | 31:19 | Reserved | Reserved |
18 | REQUEST | Read-only. Asserted by the core to request for RCVDID_LIST and RXINFO. This usually happens when re-authentication is triggered by the connected upstream. Note that when REQUEST is asserted, the READY should also be asserted. | ||||
17 | READY | Read-only. Asserted by the core to indicate RCVDID_LIST and RXINFO are processed. Write RCVDID_LIST and RXINFO after this bit is asserted. | ||||
16 | VALID | Set to 1 after RCVDID_LIST and RXINFO are written. Self-cleared by the core after RCVDID_LIST and RXINFO are read. | ||||
15:0 | RXINFO |
[15:12]: Reserved. [11:9]: DEPTH [8:4]: DEVICE_COUNT [3]: MAX_DEVS_EXCEEDED [2]: MAX_CASCADE_EXCEEDED [1]: HDCP2_REPEATER_DOWNSTREAM [0]: HDCP1_DEVICE_DOWNSTREAM |
||||
0x02 | RPT_TYPE | RO | 0x0 | 31:9 | Reserved | Reserved |
8 | VALID | Asserted by the core to indicate content stream TYPE is valid. Self-cleared by the core after TYPE is read. | ||||
7:0 | TYPE |
0x00: Type 0 Content Stream 0x01: Type 1 Content Stream 0x02-0xFF: Reserved. Treated as Type 1 Content Stream. |
||||
0x03 | RPT_MISC | RW | 0x0 | 31:1 | Reserved | Reserved. |
0 | REPEATER |
Set to 0 if no downstream is connected or if the connected downstream is not HDCP 2.3-capable. This means the receiver IP core is an end-point receiver rather than a repeater. Set to 1 if the connected downstream is HDCP- capable. |
6.2. Sink Interfaces
Interface |
Port Type |
Clock Domain |
Port |
Direction |
Description |
|
---|---|---|---|---|---|---|
Reset | Reset | – | reset | Input | Main asynchronous
reset input. Note: Asserting the reset input resets the SCDC
register.
|
|
Clock | Clock | – | ls_clk[2:0] | Input | Link speed clock
input. These clocks correspond to the in_r (2), in_g (1), and in_b (0) TMDS encoded data inputs. Relationship to vid_clk as a function of color depth:
This signal connects to the transceiver output clock only if TMDS Bit Rate is above the minimum transceiver data rate, which means no oversampling is required. This signal should connect to a PLL output clock that meets the vid_clk relationship if TMDS Bit Rate is below the minimum transceiver data rate, which means oversampling is required. |
|
Clock | – | vid_clk | Input | Video data clock
input. For RGB and YCbCr 4:4:4/4:2:2 transport:
For YCbCr 4:2:0 transport:
|
||
Clock | – | scdc_i2_clk | Input | Avalon-MM SCDC Management Interface clock input. | ||
Video Data Port | Conduit | vid_clk | vid_data[N*48-1:0] | Output |
Video 48-bit pixel data output port. In 2 symbols per clock (N=2) mode, this port produces two 48-bit pixels per clock. In 4 symbols per clock (N=4) mode, this port produces four 48-bit pixels per clock. |
|
Conduit | vid_clk | vid_de[N-1:0] | Output | Video data enable output that indicates active picture region. | ||
Conduit | vid_clk | vid_hsync[N-1:0] | Output | Video horizontal sync output. | ||
Conduit | vid_clk | vid_vsync[N-1:0] | Output | Video vertical sync output. | ||
Conduit | vid_clk | locked[2:0] | Output |
Indicates that the HDMI sink core is locked to the TMDS signals. Each bit represents a TMDS color channel. |
||
Bit-Field | Channel | |||||
0 | Blue (0) | |||||
1 | Green (1) | |||||
2 | Red (2) | |||||
Conduit | vid_clk | vid_lock | Output | Asserted when the vid_de length is consistent for 3 frames. If the the vid_de length is inconsistent for 2 frames, this signal deasserts. | ||
TMDS Data Port 5 | Conduit | ls_clk[0] | in_b[N*transceiver width-1:0] | Input | TMDS encoded blue channel (0) input. | |
Conduit | ls_clk[1] | in_g[N*transceiver width-1:0] | Input | TMDS encoded green channel (1) input. | ||
Conduit | ls_clk[2] | in_r[N*transceiver width-1:0] | Input | TMDS encoded red channel (2) input. | ||
Conduit | ls_clk[2:0] | in_lock[2:0] | Input |
Ready signal from the transceiver reset controller that indicates the transceivers are locked. Indicates the readiness of the up-stream block for the HDMI sink core to start operating. When this port is low, all blocks, except the SCDC registers and the character error detection block are hold in reset. Each bit represents a color channel. |
||
Decoder Status Port | Conduit | ls_clk[0] | ctrl[N*6-1:0] | Output | DVI (mode = 0) status signals that overwrite the control and synchronization character in the green and red channels. | |
Bit-Field | Name | |||||
N*6+5 |
CTL3 |
|||||
N*6+4 |
CTL2 |
|||||
N*6+3 |
CTL1 |
|||||
N*6+2 |
CTL0 |
|||||
N*6+1 |
Reserved (0) |
|||||
N*6 |
Reserved (0) |
|||||
Refer to the HDMI 1.4b Specification for more information. |
||||||
Conduit | ls_clk[0] | mode | Output |
Indicates the encoding mode of the incoming TMDS signals.
|
||
SCDC Control Port | Conduit | scdc_i2c_clk | in_5v_power | Input | Detects the presence of 5V input voltage. | |
Conduit | scdc_i2c_clk | in_hpd | Input | Detects the Hot Plug Detect (HPD) status. This signal should be driven with the same signal to the HPD pin on the HDMI connector. | ||
Conduit | scdc_i2c_clk | TMDS_Bit_clock_Ratio | Output |
Indicates if the TMDS Bit Rate is greater than 3.4 Gbps
|
||
Avalon-MM SCDC Management Interface 6 |
Avalon-MM | scdc_i2c_clk | scdc_i2c_addr[7:0] | Input |
Address. |
|
Avalon-MM | scdc_i2c_clk | scdc_i2c_r | Input | Assert to indicate a read transfer. | ||
Avalon-MM | scdc_i2c_clk | scdc_i2c_rdata[7:0] | Output | Data driven from the core in response to a read transfer. | ||
Avalon-MM | scdc_i2c_clk | scdc_i2c_w | Input | Assert to indicate a write transfer. | ||
Avalon-MM | scdc_i2c_clk | scdc_i2c_wdata[7:0] | Input | Data for write transfers. | ||
Auxiliary Data Port (Applicable only when you enable Support auxiliary parameter) | Conduit | ls_clk[0] | aux_valid | Output | Auxiliary data channel valid output to qualify the data. | |
Conduit | ls_clk[0] | aux_data[71:0] | Output | Auxiliary data channel
data output. For information about the bit-fields, refer to Figure 34. |
||
Conduit | ls_clk[0] | aux_sop | Output | Auxiliary data channel start-of-packet output to mark the beginning of a packet. | ||
Conduit | ls_clk[0] | aux_eop | Output | Auxiliary data channel end-of-packet output to mark the end of a packet. | ||
Conduit | ls_clk[0] | aux_error | Output | Asserted when there is auxiliary data channel CRC error. | ||
Auxiliary Status Port (Applicable only when you enable Support auxiliary parameter) | Conduit | ls_clk[0] | gcp[5:0] | Output | General Control Packet
output. For information about the bit-fields, refer to Table 24. |
|
Conduit | ls_clk[0] | info_avi[111:0] | Output | Auxiliary Video
Information InfoFrame output. For information about the bit-fields, refer to Table 25. |
||
Conduit | ls_clk[0] | info_vsi[60:0] | Output | Vendor Specific
Information InfoFrame output. For information about the bit-fields, refer to Table 26. |
||
Auxiliary Memory Interface (Applicable only when you enable Support auxiliary parameter) | Conduit | ls_clk[0] | aux_pkt_addr[6:0] | Output | Auxiliary packet memory buffer address output. | |
Conduit | ls_clk[0] | aux_pkt_data[71:0] | Output | Auxiliary packet memory buffer data output. | ||
Conduit | ls_clk[0] | aux_pkt_wr | Output | Auxiliary packet memory buffer write strobe output. | ||
Audio Port (Applicable only when you enable Support auxiliary and Support audio parameters) | Conduit | ls_clk[0] | audio_CTS[19:0] | Output | Audio CTS value output. | |
Conduit | ls_clk[0] | audio_N[19:0] | Output | Audio N value output. | ||
Conduit | ls_clk[0] | audio_data[255:0] | Output | Audio data output. For audio channel values, refer to Table 39. |
||
Conduit | ls_clk[0] | audio_de | Output | Audio data valid output. | ||
Conduit | ls_clk[0] | audio_metadata[164:0] | Output | Additional information
related to 3D audio and MST audio. For information about the bit-fields, refer to Table 29, Table 30, and Table 31. |
||
Conduit | ls_clk[0] | audio_format[4:0] | Output | Indicates 3D audio status and the audio format detected. | ||
Bit-Field | Description | |||||
4 | The core asserts to indicate the first 8 channels of each 3D audio sample. | |||||
3:0 |
For information about the bit-fields, refer to Table 27. |
|||||
Conduit | ls_clk[0] | audio_info_ai[47:0] | Output | Audio InfoFrame output
bundle. For information about the bit-fields, refer to Table 28. |
||
HDCP Port (Applicable only when you enable Support HDCP 2.3 or Support HDCP 1.4 parameters) | Reset | – | hdcp_reset | Input | Main asynchronous reset. | |
Clock | – | hdcp_i2c_clk | Input |
HDCP clock for Control and Status Registers (HDCP Registers). Typically, shares the I2C slave clock (100 MHz). |
||
– | crypto_clk | Input |
HDCP 2.3 clock for Authentication and Cryptographic Layer. You can use any clock with a frequency up to 200 MHz. Note: The clock frequency determines the authentication
latency.
|
|||
– | rpt_msg_clk | Input |
HDCP clock for the Repeater registers in the Control and Status Registers Layer. Typically, shares the clock (100 MHz) that drives the repeater downstream Nios II processor. |
|||
Avalon-MM | hdcp_i2c_clk | hdcp_i2c_addr[7:0] | Input |
The Avalon-MM slave port that provides access to HDCP registers. The I2C slave must drive this port. |
||
hdcp_i2c_wr | Input | |||||
hdcp_i2c_rd | Input | |||||
hdcp_i2c_wrdata[7:0] | Input | |||||
hdcp_i2c_rddata[7:0] | Output | |||||
Conduit | hdcp_i2c_clk | i2c_stop_det | Input | Assert this signal to indicate the stop condition for each I2C command. | ||
Avalon-MM | rpt_msg_clk | rpt_msg_addr[7:0] | Input |
The Avalon-MM slave port that provides access to the Repeater registers, mainly for ReceiverID List and RxInfo. This interface is expected to operate at repeater downstream Nios II processor clock domain. Because of the extremely large bit portion of message, the IP transfers the message in burst mode with full handshaking mechanism. Write transfers always have a wait time of 0 cycle while read transfers have a wait time of 1 cycle. The addressing should be accessed as word addressing in the Platform Designer flow. For example, addressing of 4 in the Nios II software selects the address of 1 in the slave. |
||
rpt_msg_wr | Input | |||||
rpt_msg_rd | Input | |||||
rpt_msg_wrdata[31:0] | Input | |||||
rpt_msg_rddata[31:0] | Output | |||||
Conduit (Key) |
crypto_clk (HDCP 2.3) hdcp_i2c_clk (HDCP 1.4) |
kmem_wait[0] (HDCP 2.3) kmem_wait[1] (HDCP 1.4) |
Input |
Always keep this signal asserted until the key is ready to be read. |
||
kmem_rdaddr[7:0] (HDCP 2.3) kmem_rdaddr[13:8] (HDCP 1.4) |
Output | Key read address bus. | ||||
kmem_q[31:0] (HDCP 2.3) kmem_q[87:32] (HDCP 1.4) |
Input | Key
read address
bus. Read transfer always have 1 cycle of wait time. |
||||
Conduit | ls_clk | hdcp1_enabled | Output | This signal is asserted by the IP if the incoming video and auxiliary data are HDCP 1.4 encrypted. | ||
hdcp2_enabled | Output | This signal is asserted by the IP if the incoming video and auxiliary data are HDCP 2.3 encrypted. | ||||
streamid_type | Output |
|
6.3. Sink Clock Tree
The logic clocks the transceiver data into the core using the three CDR clocks: (rx_clk[2:0]).
The TMDS and TERC4 decoding is done at the link-speed clock (ls_clk). The sink then resamples the pixel data and presents the data at the output of the core at the video pixel clock (vid_clk).
The pixel data clock depends on the video format used (within HDMI specification).
For HDMI sink, you must instantiate 3 receiver channels to receive TMS data.
The core uses a general purpose phase-locked loop (GPLL), that is referenced by the source Clock Channel, to generate the transceiver CDR reference clock (rx_refclk), link speed clock (ls_clk), and video clock (vid_clk) for the core.
- The TMDS data clocks into the core at ls_clk[2:0] with all channels driven by the same clock source (GPLL CLK1).
- The video data clocks out from the core at vid_clk.
rx_refclk, ls_clk, and vid_clk are derived based on the color depth, TMDS_Bit_clock_Ratio, user oversampling control bit information, and the detected Clock Channel frequency band.
If an application requires low TMDS Bit Rate (below the transceiver minimum data rate requirement), then the application needs a user logic consisting of a DCFIFO and oversampling logic.
- The oversampling logic extracts the data from the oversampled incoming data stream.
- When you enable the oversampling control bit, the DCFIFO gets the TMDS data between the transceiver and the oversampling logic.
- The DCFIFO synchronizes the TMDS data from the fastest transceiver output clock (rx_clkout[2:0]) to the ls_clk domain.
If an application does not require low TMDS Bit Rate, the Clock Channel drives the transceiver rx_refclk directly. You can also connect the transceiver output to the core with ls_clk[2:0] driven by rx_clkout[2:0].
7. HDMI Parameters
7.1. HDMI Source Parameters
Parameter | Value | Description |
---|---|---|
Device family |
Intel® Stratix® 10 Intel® Arria® 10 Intel® Cyclone® 10 GX Arria V Stratix V |
Targeted device family; matches the project device family. |
Direction |
Transmitter Receiver |
Select HDMI transmitter. |
Symbols per clock | 1, 2, or 4 symbols per clock | Determines how many TMDS symbols and
pixels are processed per clock.
|
Support auxiliary | On, Off | Determines if auxiliary channel encoding is included. This parameter is turned on by default. |
Support deep color | On, Off |
Determines if the core can encode deep color formats. This parameter is turned on by default. |
Support audio | On, Off |
Determines if the core can encode audio data. To enable this parameter, you must also enable the Support auxiliary parameter. This parameter is turned on by default. |
Support HDCP 1.4 | On, Off |
Turn on to enable HDCP 1.4 TX support. This parameter can only be used when you enable 2 symbols per clock with Intel® Arria® 10 devices. Note: The HDCP-related parameters are not
included
in the 19.3 version of the
Intel®
Quartus® Prime Pro Edition software. To
access
the HDCP feature, contact Intel at https://www.intel.com/content/www/us/en/broadcast/products/programmable/applications/connectivity-solutions.html.
|
Support HDCP 2.3 | On, Off |
Turn on to enable HDCP 2.3 TX support. This parameter can only be used when you enable 2 symbols per clock with Intel® Arria® 10 devices. Note: The HDCP-related parameters are not
included
in the 19.3 version of the
Intel®
Quartus® Prime Pro Edition software. To
access
the HDCP feature, contact Intel at https://www.intel.com/content/www/us/en/broadcast/products/programmable/applications/connectivity-solutions.html.
|
7.2. HDMI Sink Parameters
Parameter | Value | Description |
---|---|---|
Device family |
Intel® Stratix® 10 Intel® Arria® 10 Intel® Cyclone® 10 GX Arria V Stratix V |
Targeted device family; matches the project device family. |
Direction |
Transmitter Receiver |
Select HDMI receiver. |
Symbols per clock | 1, 2, or 4 symbols per clock | Determines how many TMDS symbols and
pixels are processed per clock.
|
Support auxiliary | On. Off | Determines if auxiliary channel encoding is included. This parameter is turned on by default. |
Support deep color | On. Off |
Determines if the core can encode deep color formats. This parameter is turned on by default. |
Support audio | On, Off |
Determines if the core can encode audio data. To enable this parameter, you must also enable the Support auxiliary parameter. This parameter is turned on by default. |
Support HDCP 1.4 | On, Off |
Turn on to enable HDCP 1.4 RX support. This parameter can only be used when you enable 2 symbols per clock with Intel® Arria® 10 devices. Note: The HDCP-related parameters are not
included
in the 19.3 version of the
Intel®
Quartus® Prime Pro Edition software. To
access
the HDCP feature, contact Intel at https://www.intel.com/content/www/us/en/broadcast/products/programmable/applications/connectivity-solutions.html.
|
Support HDCP 2.3 | On, Off |
Turn on to enable HDCP 2.3 RX support. This parameter can only be used when you enable 2 symbols per clock with Intel® Arria® 10 devices. Note: The HDCP-related parameters are not
included
in the 19.3 version of the
Intel®
Quartus® Prime Pro Edition software. To
access
the HDCP feature, contact Intel at https://www.intel.com/content/www/us/en/broadcast/products/programmable/applications/connectivity-solutions.html.
|
Manufacturer OUI | — |
The Manufacturer Organizationally Unique Identifier (OUI) assigned to the manufactured device to be written into the SCDC registers of address 0xD0, 0xD1, and 0xD2. Key in 3 byte hexadecimal data. |
Device ID String | — |
The Device Identification (ID) string to be written into the SCDC registers from addresses 0xD3 to 0xDa. Use this parameter to identify the sink device. You can key in up to eight ASCII characters. If you use less than eight characters, the unused bytes are set to 0x00. |
Hardware Revision | — |
Indicates the major and minor revisions of the hardware. Key in one byte of integer data.
The hardware major revision increments on a major silicon or board revision. The hardware minor revision increments on a minor silicon revision or minor board revision and resets to 0 when the major revision increments. |
8. HDMI Simulation Example
- IEC-60958 audio format
- Standard H/V/DE/RGB input video format
- Support for 4 symbols per clock
- Support for HDMI 2.0b scrambled operation
The Test Pattern Generator (TPG) provides the video stimulus. The IP core stimulates the HDMI TX core using an audio packet generator and aux packet generator. The output from the HDMI TX core drives the HDMI RX core.
The IP core requires a memory-mapped master stimulus to operate the testbench for HDMI 2.0b scrambling. This stimulus implements the activity normally seen across the I2C DDC channel. At this point, the IP core asserts the scramble enable bit in the SCDC registers.
The testbench implements CRC checking on the input and output video. The testbench checks the CRC value of the transmitted data against the CRC calculated in the received video data. The testbench performs the checking after detecting 4 stable V-SYNC signals from the receiver.
The aux sample generator generates a fixed data to be transmitted from the transmitter. On the receiver side, the generator compares whether the expected aux data is received and decoded correctly.
The audio sample generator generates an incrementing test data pattern to be transmitted through the audio channel. On the receiver side, the audio data checker checks and compares whether the incrementing test data pattern is received and decoded correctly.
8.1. Simulation Walkthrough
- Copy the simulation files from <IP root directory>/altera/altera_hdmi/sim_example to your working directory.
-
Generate the IP simulation files and scripts, compile, and
simulate.
- Start the Nios II Command Shell.
-
Type the command below and enter.
sh runall.shThis script executes the following commands:
Command Generate the simulation files for the HDMI cores. - ip-generate --project-directory=./ --component-file=./hdmi_rx_single.qsys --output-directory=./hdmi_rx_single/sim/ --file-set=SIM_VERILOG --report-file=sopcinfo:./hdmi_rx_single.sopcinfo --report-file=html:./hdmi_rx_single.html --report-file=spd:./hdmi_rx_single/sim/hdmi_rx_single.spd --report-file=qip:./hdmi_rx_single/sim/hdmi_rx_single.qip
- ip-generate --project-directory=./ --component-file=./hdmi_rx_double.qsys --output-directory=./hdmi_rx_double/sim/ --file-set=SIM_VERILOG --report-file=sopcinfo:./hdmi_rx_double.sopcinfo --report-file=html:./hdmi_rx_double.html --report-file=spd:./hdmi_rx_double/sim/hdmi_rx_double.spd --report-file=qip:./hdmi_rx_double/sim/hdmi_rx_double.qip
- ip-generate --project-directory=./ --component-file=./hdmi_tx_single.qsys --output-directory=./hdmi_tx_single/sim/ --file-set=SIM_VERILOG --report-file=sopcinfo:./hdmi_tx_single.sopcinfo --report-file=html:./hdmi_tx_single.html --report-file=spd:./hdmi_tx_single/sim/hdmi_tx_single.spd --report-file=qip:./hdmi_tx_single/sim/hdmi_tx_single.qip
- ip-generate --project-directory=./ --component-file=./hdmi_tx_double.qsys --output-directory=./hdmi_tx_double/sim/ --file-set=SIM_VERILOG --report-file=sopcinfo:./hdmi_tx_double.sopcinfo --report-file=html:./hdmi_tx_double.html --report-file=spd:./hdmi_tx_double/sim/hdmi_tx_double.spd --report-file=qip:./hdmi_tx_double/sim/hdmi_tx_double.qip
Merge the four resulting msim_setup.tcl scripts to create a single mentor/msim_setup.tcl script. ip-make-simscript --spd=./hdmi_tx_single/sim/hdmi_tx_single.spd --spd=./hdmi_tx_double/sim/hdmi_tx_double.spd --spd=./hdmi_rx_single/sim/hdmi_rx_single.spd --spd=./hdmi_rx_double/sim/hdmi_rx_double.spd Compile and simulate the design in the ModelSim software. vsim -c -do msim_hdmi.tcl Generate the simulation files for the HDMI cores. Merge the resulting msim_setup.tcl scripts to create a single mentor/msim_setup.tcl script. Compile and simulate the design in the ModelSim software.
Example successful result:# SYMBOLS_PER_CLOCK = 4 # VIC = 0 # AUDIO_CLK_DIVIDE = 800 # TEST_HDMI_6G = 1 # Simulation pass # ** Note: $finish : bitec_hdmi_tb.v (647) Time: 15702552 ns Iteration: 3 Instance: /bitec_hdmi_tb # End time: 14:39:02 on Feb 04,2016, Elapsed time: 0:03:17 # Errors: 0, Warnings: 134
9. HDMI Intel FPGA IP User Guide Archives
IP versions are the same as the Intel® Quartus® Prime Design Suite software versions up to 19.1. From Intel® Quartus® Prime Design Suite software version 19.2 or later, IP cores have a new IP versioning scheme.
IP Core Version | User Guide |
---|---|
19.1 | HDMI Intel FPGA IP User Guide |
18.1 | HDMI Intel FPGA IP User Guide |
18.0 | HDMI Intel FPGA IP User Guide |
17.1 | HDMI IP Core User Guide |
17.0 | HDMI IP Core User Guide |
16.1 | HDMI IP Core User Guide |
16.0 | HDMI IP Core User Guide |
15.1 | HDMI IP Core User Guide |
15.0 | HDMI IP Core User Guide |
14.1 | HDMI IP Core User Guide |
10. Document Revision History for the HDMI Intel FPGA IP User Guide
Document Version | Intel® Quartus® Prime Version | IP Version | Changes |
---|---|---|---|
2019.10.10 | 19.3 | 19.1.0 |
|
2019.04.29 | 19.1 | – |
|
2019.01.21 | 18.1 | – |
|
2018.05.07 | 18.0 | – |
|
Date | Version | Changes |
---|---|---|
November 2017 | 2017.11.06 |
|
May 2017 | 2017.05.08 |
|
December 2016 | 2016.12.20 |
|
May 2016 | 2016.05.02 |
|
November 2015 | 2015.11.02 |
|
May 2015 | 2015.05.04 |
|
December 2014 | 2014.12.15 |
Initial release. |