HDMI 2.1 Receiver Subsystem v1.2 Product Guide Vivado Design Suite PG351 (v1.2) October 22, 2021 Xilinx is creating an environment where employees, customers, and partners feel welcome and included. To that end, we’re removing non- inclusive language from our products and related collateral. We’ve launched an internal initiative to remove language that could exclude people or reinforce historical biases, including terms embedded in our software and IPs. You may still find examples of non-inclusive language in our older products as we work to make these changes and align with evolving industry standards. Follow this link for more information.
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
HDMI 2.1 ReceiverSubsystem v1.2
Product GuideVivado Design Suite
PG351 (v1.2) October 22, 2021
Xilinx is creating an environment where employees, customers, andpartners feel welcome and included. To that end, we’re removing non-inclusive language from our products and related collateral. We’velaunched an internal initiative to remove language that could excludepeople or reinforce historical biases, including terms embedded in oursoftware and IPs. You may still find examples of non-inclusivelanguage in our older products as we work to make these changes andalign with evolving industry standards. Follow this link for moreinformation.
Chapter 2: Overview......................................................................................................7Navigating Content by Design Process.................................................................................... 7Subsystem Overview...................................................................................................................7Applications..................................................................................................................................8Unsupported Features................................................................................................................8Licensing and Ordering Information........................................................................................ 9
Chapter 3: Product Specification......................................................................... 10Introduction............................................................................................................................... 10Standards................................................................................................................................... 23Performance and Resource Utilization...................................................................................24Port Descriptions.......................................................................................................................24Clocks and Resets......................................................................................................................35
Chapter 4: Designing with the Subsystem..................................................... 36General Design Guidelines.......................................................................................................36Clocking...................................................................................................................................... 41Resets..........................................................................................................................................46
Chapter 5: Design Flow Steps.................................................................................47Customizing and Generating the Subsystem........................................................................ 47Constraining the Subsystem....................................................................................................52Simulation.................................................................................................................................. 55Synthesis and Implementation................................................................................................55
Chapter 6: Example Design..................................................................................... 56Summary.................................................................................................................................... 56Running the Example Design.................................................................................................. 56
IntroductionThe HDMI 2.1 Receiver Subsystem is a hierarchical IP that bundles a collection of HDMI™ IPsub-cores and outputs them as a single IP. It is an out-of-the-box ready-to-use HDMI 2.1Receiver Subsystem and avoids the need to manually assemble sub-cores to create a workingHDMI system.
Features• HDMI 2.1 compatible
• Dynamic support of FRL and TMDS
• Dynamic support of FRL data rate (12 Gb/s @ 4 lanes, 10 Gb/s @ 4 lanes, 8 Gb/s @ 4 lanes, 6Gb/s @ 4 lanes, 6 Gb/s @ 3 lanes, and 3 Gb/s @ 3 lanes)
• Dynamic support of TMDS up to 6 Gb/s @ 3 lanes
• Supports both integer and non-integer frame rates
• Supports FRL training patterns LTP5, LTP6, LTP7, LTP8, No LTP, and special symbols (0xFFEand 0xFFF).
• Support of resolution up to 10,240 x 4,320 @ 30 fps (in FRL mode)
• Support of 8k/10kp60 YUV420 (in FRL mode)
• Support of 8, 10, 12, and 16 bits per component (BPC)
• Support for RGB, YUV 4:4:4, YUV 4:2:2, YUV 4:2:0 color formats
• Support 4 and 8 pixels per clock (PPC) AXI4-Stream Video input
• Supports 4 pixels per clock (PPC) Native Video and Native Video (Vectored DE) output stream
Resources Performance and Resource Utilization web page
Provided with Subsystem
Design Files RTL
Example Design Vivado® IP integrator and associated software application example
Test Bench Not Provided
Constraints File XDC
Simulation Model Not Provided
Supported S/W Driver3 Standalone
Tested Design Flows4
Design Entry Vivado® Design Suite
Simulation Not Provided
Synthesis Vivado Synthesis
Support
Release Notes and Known Issues Master Answer Record: 72276
All Vivado IP Change Logs Master Vivado IP Change Logs: 72775
Xilinx Support web page
Notes:1. For a complete list of supported devices, see the Vivado IP catalog.2. For GTHE4, -1,-1M, -1L, -1LV, -2LV, and -2LVI parts, and for GTYE4, -1,-1M,-1L, and -1LV parts, the maximum supported
FRL line rate is 8.0Gb/s due to the limitation on CPLL and USRCLKs.3. Standalone driver details can be found in <Install Directory>/Vitis/<Release>/data/embeddedsw/doc/
xilinx_drivers_api_toc.htm.4. For the supported versions of third-party tools, see the Xilinx Design Tools: Release Notes Guide.
Navigating Content by Design ProcessXilinx® documentation is organized around a set of standard design processes to help you findrelevant content for your current development task. All Versal™ ACAP design process DesignHubs can be found on the Xilinx.com website. This document covers the following designprocesses:
• Hardware, IP, and Platform Development: Creating the PL IP blocks for the hardwareplatform, creating PL kernels, functional simulation, and evaluating the Vivado® timing,resource use, and power closure. Also involves developing the hardware platform for systemintegration. Topics in this document that apply to this design process include:
• Port Descriptions
• Clocks and Resets
• Customizing and Generating the Subsystem
• Chapter 6: Example Design
Subsystem OverviewThe HDMI 2.1 Receiver Subsystem is a feature-rich soft IP incorporating all the necessary logicto properly interface with PHY layers and provide HDMI™ decoding functionality. The subsystemis a hierarchical IP that bundles a collection of HDMI 2.1 RX-related IP sub-cores and outputsthem as a single IP. The subsystem receives the captured TMDS data from the PHY layer. It thenextracts the video and audio streams from the HDMI stream and converts it to video and audiostreams.
The subsystem can be configured at design time through a single interface in the Vivado®
Integrated Design Environment (IDE) for performance and quality.
ApplicationsHigh-Definition Multimedia Interface (HDMI) is a common interface used to transport video andaudio and is seen in almost all consumer video equipment such as DVD and media players, digitaltelevisions, camcorders, mobile tablets and phones. The omnipresence of the interface has alsospread to most professional equipment such as professional cameras, video switchers,converters, monitors and large displays used in video walls and public display signs.
For tested video resolutions for the subsystem see Verification, Compliance, and Interoperability.
Related Information
Verification, Compliance, and Interoperability
Unsupported FeaturesThe following features are not supported in this subsystem:
• Lip sync
• CEC
• HEAC
• Dual view
• eARC
• Multi-stream audio
• Digital Stream Compression (DSC)
• FRL Training patterns: LTP1, LTP2, LTP3, and LTP4
Licensing and Ordering InformationLicense TypeThis Xilinx® module is provided under the terms of the Xilinx Core License Agreement. Themodule is shipped as part of the Vivado® Design Suite. For full access to all subsystemfunctionalities in simulation and in hardware, you must purchase a license for the subsystem. Togenerate a full license, visit the product licensing web page. Evaluation licenses and hardwaretimeout licenses might be available for this subsystem. Contact your local Xilinx salesrepresentative for information about pricing and availability.
For more information, visit the Xilinx HDMI web page.
Information about other Xilinx® IP modules is available at the Xilinx Intellectual Property page.For information about pricing and availability of other Xilinx® IP modules and tools, contact your local Xilinx sales representative.
IMPORTANT! Xilinx provides the HDCP IP License (including evaluation license) for HDCP adopters only.See the DPC Licensee list for details.
Note: The HDMI 2.1 license is bundled with the Reed-Solomon Decoder.You do not need to request thelicense separately.
License CheckersIf the IP requires a license key, the key must be verified. The Vivado® design tools have severallicense checkpoints for gating licensed IP through the flow. If the license check succeeds, the IPcan continue generation. Otherwise, generation halts with an error. License checkpoints areenforced by the following tools:
• Vivado Synthesis
• Vivado Implementation
• write_bitstream (Tcl command)
Note: IP license level is ignored at checkpoints. The test confirms a valid license exists. It does not check IPlicense level.
If a Hardware Evaluation License is being used, the core stops transmitting HDMI Stream aftertimeout. This timeout is based on system CPU clock. For example, if system is running at 100MHz, the IP times out after approximately 4 hours of normal operation when HardwareEvaluation License is being used.
Product SpecificationThis chapter includes a description of the subsystem and details about the performance andresource utilization.
IntroductionThe HDMI 2.1 Receiver Subsystem takes in HDMI™ 2.1 protocol video and works with the HDMIPHY Controller. For more information on the HDMI PHY Controller, see the HDMI PHY ControllerLogiCORE IP Product Guide (PG333).
The HDMI 2.1 RX Subsystem is hierarchically packaged with the following subcores to supportAXI4-Stream based video and works seamlessly with other Xilinx® video processing IP cores.
• HDMI 2.1 Receiver core
• Video In to AXI4-Stream Bridge
• AXI Remapper RX
The subsystem also includes an optional HDCP 2.3 controller and HDCP 1.4 controller (togetherwith an AXI Timer core as a helper core) for HDCP 2.3 or HDCP 1.4 decryption functionality.
You can configure it by setting the parameters in the Vivado® Integrated Design Environment(IDE) interface and the subsystem creates the required hardware accordingly. The followingfigures show the architecture of the subsystem. The HDMI 2.1 RX subsystem supports thefollowing types of video interface:
• AXI4-Stream Video interface
• Native Video interface
• Native Video (Vectored Data Enable (DE)) interface
The following table summarizes the supported video timing for each interface, depending on thePPC settings.
4 8AXI4-Stream RGB,YCbCr 444, YCbCr 422 HACTIVE should be divisible
by 4.HACTIVE should be divisibleby 8.
YCbCr 420 HACTIVE should be divisibleby 8.
Native Video RGB,YCbCr 444, YCbCr 422 HACTIVE, HSYNC, HTOTALshould be divisible by 4.
Not applicable (Always 4PPC).
YCbCr 420
Native Video (Vectored DE) RGB,YCbCr 444, YCbCr 422 No restrictions. Allcombinations are supported.
YCbCr 420
Notes:1. AXI4-Stream and Native Video (Vectored DE) I/F supports all CTA resolutions.2. In Native Video I/F, due to the divisible by PPC restriction, all CTA resolutions are not supported.
IMPORTANT! The IP supports 8kp48, 8kp50, and 8kp60/10kp60 YUV420 in both Native Video, NativeVideo (Vectored DE), and AXI4-Stream interfaces. To enable 8kp48, 8kp50, and 8kp60/10kp60 YUV420support in AXI4-Stream Mode, select Number of pixels per clock as 8. In Native Video or Native Video(Vectored DE) Interface, 4 PPC supports 8kp48, 8kp50, and 8kp60/10kp60 YUV420.
IMPORTANT! In Native Video or Native Video (Vectored DE) Interface, the IP supports YCbCr 4:2:0.However, you must process YCbCr 4:2:0 Pixel Encoding. See Section 7 in the HDMI 2.0b Specification(http://www.hdmi.org/manufacturer/specification.aspx) or Video Output Stream Interface.
Figure 2: HDMI 2.1 RX Subsystem Native Video or Native Video DE Interface BlockDiagram
HDMI 2.1 Receiver Core
AXICrossbar
HDCP(optional)
Video Clock
Link Data
DDC
HPD
HDMI 2.1 Receiver Subsystem
HDCP Key HDCP Key Management
HDCP Interrupts
Link Clock
FRL Clock
PHY Layer
Interrupt
Audio interfaceAXI4-stream
Video interfaceNative Video or
Native Video (DE)
CPU interfaceAXI4-lite
Audio Clock
Dynamic HDR Clock
Dynamic HDR Interface AXI4-MM
X24940-051121
Video In to AXI4-Stream BridgeThe Video In to AXI4-Stream Bridge maps the native video format from the HDMI 2.1 ReceiverIP core to video over the AXI4-Stream interface. The bridge uses the Xilinx Video In to AXI4-Stream core to convert the format between the HDMI 2.1 Receiver native video and AXI4-Stream.
For details about the Video In Bridge, see the Video In to AXI4-Stream LogiCORE IP Product Guide(PG043). For details about video over AXI4-Stream, see theVivado Design Suite: AXI ReferenceGuide (UG1037) and AXI4-Stream Video IP and System Design Guide (UG934). The output of thebridge is video over AXI4-Stream. For more details, see Port Descriptions.
The HDMI 2.1 RX Subsystem is connected to a Xilinx® HDMI PHY Controller, which takeselectronic signals from an HDMI cable and translates it into HDMI stream. Then, the HDMI RXcore converts the HDMI stream into native video stream and AXI4-Stream audio stream. TheVideo In to AXI4-Stream bridge converts the video stream taken from the HDMI 2.1 Receivercore into AXI4-Stream.
The HDMI 2.1 RX Subsystem supports both Transition Minimized Differential Signaling (TMDS)and Fixed Rate Link (FRL) protocol based on the HDMI source capability connected. You canbuild an HDMI 2.1 sink system using the HDMI 2.1 RX Subsystem, and its capability is declaredin the customized Extended Display Identification Data (EDID).
The HDMI 2.1 Receiver sub-core contains two separate data paths. One is to decode the videostream TMDS signal, the other is to decode the incoming 16-bit/18-bit encoded data, scramblethem, mapping them into FRL packets, removing FEC parity, depacketize them into the videostream, then sending to HDMI 2.0 logic for video format decoding. A data multiplexer is used toselect TMDS or FRL received from the PHY layer. The PHY layer is controlled by the HDMI PHYController, which is capable of supporting both TMDS and FRL (at rate up to 12 Gb/s).
RECOMMENDED: Xilinx recommends an external TMDS EQ chip (such as an ON SemiconductorNB7NQ621M) for the RX subsystem solution. A high speed data multiplexer is also needed to route thefourth signal pair to TMDS clock path or FRL fourth data path.
HDCPAs part of the HDMI 2.1 RX Subsystem, the Xilinx LogiCORE IP High-bandwidth Digital ContentProtection (HDCP) receivers are designed to receive audiovisual content securely between twodevices that are HDCP capable. In this HDMI 2.1 RX Subsystem, both HDCP 1.4 and HDCP 2.3receiver IP cores are included and can be enabled by the HDCP option in the Vivado IDE.
As a guideline, HDCP 2.3 is used to decrypt all protected content in FRL mode. In TMDS mode,HDCP 2.3 is used to decrypt content at Ultra-High Definition (UHD) while HDCP 1.4 is thelegacy content protection scheme used at lower resolutions to be backward compatible withHDCP 1.4 only sinks.
The following figure shows a configuration of the HDMI RX where both HDCP 1.4 and 2.3 areenabled. With both HDCP protocols enabled, the HDMI Subsystem configures itself in thecascade topology where the HDCP 1.4 and HDCP 2.3 are connected back-to-back. The HDCPEgress interface of the HDMI receiver sends encrypted audiovisual data, which is decrypted bythe active HDCP block and sent back into the HDMI receiver over the HDCP Ingress interface tosend to other video processing modules in the system through AXI4-Stream Video interface.
Figure 4: HDCP 1.4 and HDCP 2.3 over HDMI Receiver
For more details on HDCP, see the HDCP 1.x Product Guide (PG224) and the HDCP 2.2 LogiCOREIP Product Guide (PG249).
IMPORTANT! HDMI IP supports HDCP 2.3; however, all logs are shown as 2.2 which will be fixed in afuture release.
HDCP Key ManagementFor the HDCP 1.4 RX, an HDCP Key Management module is needed, which can send keys overthe AXI4-Stream interface to the HDCP 1.4 controller. The following figure shows an example ofhow the HDMI 2.1 RX Subsystem is connected to the HDCP Key Management module through aKey Management Bus (AXI4-Stream). The HDCP Key Management module is not part of theHDMI 2.1 RX Subsystem. For HDCP 1.4 design details, see the HDCP 1.x Product Guide (PG224).
Figure 5: HDCP 1.4 Key Management Bus (AXI4-Stream)
Key Management Bus (AXI4-Stream)
HDCP Key Management
HDMI 2.1 RX SubSystem
HDMI RX HDCP 2.3Controller
X24942-121020
However, the HDCP 2.3 key is handled slightly differently as it is solely controlled by thesoftware application. The user application is responsible for providing the infrastructure tosecurely store and retrieve the keys to be loaded into the HDCP 2.3 drivers. For the detailed listof keys that are required to be loaded by the user application, see the HDCP 2.2 LogiCORE IPProduct Guide (PG249).
AUX PacketsFor HDMI, all data island packets consist of a 4-byte packet header and a 32 bytes of packetcontents. The packet header, represented in the following figure, contains 24 data bits (3 bytes)and 8 bits (1 byte) of BCH ECC parity.
Figure 6: Packet Header
The packet body, represented in the following figure, is made from four subpackets; eachsubpacket includes 56 bits (7 bytes) of data and 8 bits (1 byte) of BCH ECC parity.
• ECC is calculated in the HDMI 2.1 RX Subsystem. Therefore, you must construct HB0...HB2, and PB0,PB1...PB26, PB27 according to HDMI specs in the software.
• When calculating the checksum value (PB0), the ECC values are ignored.
• Refer to section 5.2.3.4 and 5.2.3.5 of the HDMI 1.4 specification (http://www.hdmi.org/manufacturer/specification.aspx) for more information on the Aux packet structure.
In the following table, the packet types are identified as handled by hardware and handled bysoftware.
Table 2: Hardware and Software Packet Types
Packet Type Value Packet Type0x001 Null
0x011 Audio Clock Regeneration (N/CTS)
0x021 Audio Sample (L-PCM and IEC 61937 compressed formats)
Table 2: Hardware and Software Packet Types (cont'd)
Packet Type Value Packet Type0x08 DST Audio Packet
0x091 High Bitrate (HBR) Audio Stream Packet (IEC 61937)
0x0A Gamut Metadata Packet
0x0B1 3D Audio Sample Packet (LPCM Format Only)
0x0C One Bit 3D Audio Sample Packet
0x0D2 Audio MetaData Packet
0x80+InfoFrame Type InfoFrame Packet
0x00 Reserved
0x012 Vendor-Specific
0x022 Auxiliary Video Information (AVI)
0x03 Source Product Descriptor
0x042 Audio
0x05 MPEG Source
0x06 NTSC VBI
0x072 Dynamic Range and Mastering (HDR)
Notes:1. Handled by hardware.2. Handled by software.
Null packets are dropped by the HDMI 2.1 RX Subsystem automatically. ACR, Audio Sample,One-bit Audio, DST Audio, and HBR Audio are routed to the audio interface. The remainingpackets (packet types not highlighted in the previous table) are routed to the software for furtherprocessing by generating AUX packet interrupts.
In the HDMI 2.1 RX Subsystem driver, there is a generic API function to allow you to retrieve auxpackets.
The HDMI Common driver also defines API functions to parse important InfoFrame packets andgeneral control packets so that this information is available to be used in the user applicationsoftware.
The parsed information is stored in data structures with respect to the packet type.
Other packet types are not parsed by the driver. Instead, upon the AUX interrupt, you mustretrieve those packets and process them in the application software. For example, if an HDMIsource sends NTSC VBI Infoframe, upon receiving them by HDMI Subsystem, the NTSC VBIpacket (both header and payload) is stored in the hardware FIFO, an AUX interrupt is generated.Then the application software reads out the AUX from the FIFO. By checking the packet header,the application knows that the packet is NTSC VBI. Then the application software must parse thepayload data and handle it according to their system requirements.
InfoFrames
As shown in the previous table, the software handles the Vendor Specific InfoFrame (VSIF), theAuxiliary Video Information (AVI) InfoFrame, the Audio InfoFrame, and the Dynamic Range andMastering InfoFrame. The four InfoFrame types are added as part of the HDMI 2.1 RX Subsystemdata structure, each having its own well-defined structure. For more details on InfoFrames, referto Section 6 of CTA-861-H (https://cta.tech/).
AVI InfoFrame
Use the following code example for AVI InfoFrames:
The General Control Packet (GCP) is primarily handled by the hardware but is also passed to thesoftware so that the information can be used at the system application level.
Enhanced Gaming and Media FeaturesThe HDMI 2.1 RX Subsystem supports the following HDMI 2.1 enhanced gaming features:
• Variable Refresh Rate (VRR)
○ Supports both VRR and VRR + FVA
• Quick Frame Transport (QFT)
• Auto Low Latency Mode (ALLM)
• Quick Media Switching (QMS)
Note: The HF-VSIF packet is sent as a generic AUX packet to the software. You need to parse the HF-VSIFpacket to detect the ALLM value.
The HDMI 2.1 RX Subsystem supports the following APIs/interrupt handlers to read the VTEMPacket and VRR timing information.
XV_HDMIRXSS1_HANDLER_VFP_CH
This interrupt is triggered every time video timings (vertical front porch) are changed, and VRR isenabled in the VTEM packet. You can register the callback function and read the updated videotiming information by calling the following API.
This interrupt is triggered every time the VTEM packet is present in the stream and its contentsare changed from previous VTEM packet. You can register the callback function and read theupdated VTEM information by calling the following API.
Dynamic HDRThe HDMI 2.1 RX Subsystem supports CTA 861-H (https://cta.tech/) Dynamic HDR metadatainfo frame and HDR10+ VSIF (https://hdr10plus.org/). Dynamic HDR support is user-configurable in the Vivado IDE. To enable or disable Dynamic HDR support, select the DynamicHDR support check box. When Dynamic HDR support is enabled, a separate memory mappedAXI4 interface (M_HDR_AXI) is added to the IP. The memory mapped interface runs onm_hdr_axi_clock.
The HDMI 2.1 RX Subsystem supports the following Dynamic HDR features:
• Dynamic HDR metadata length up to 65535 bytes
• Support for CTA 861-H dynamic HDR info frames
○ HDR dynamic metadata according to the syntax specified in Annex R
○ HDR dynamic metadata carried in supplemental enhancement information (SEI) messagesaccording to ETSI TS 103 433-1 [50]
Note: For more information, see https://www.etsi.org/deliver/etsi_ts/103400_103499/10343301/01.02.01_60/ts_10343301v010201p.pdf.
○ HDR dynamic metadata carried in a color remapping information SEI message according toRec. ITU-T H.265 [52]
Note: For more information, see https://www.itu.int/rec/T-REC-H.265.
○ HDR dynamic metadata carried according to the syntax specified in Annex S
○ Graphics overlay flag (GOF) carried according to the syntax specified in Annex T
• HDR10+ VSIF Support
Note:
1. The GOF info frame is parsed inside the hardware, and the GOF value will be updated in the IPregisters. This value can be read via the software.
2. Only Dynamic HDR info frames are stored in the memory using a memory mapped AXI4 interface. Thestatic HDR info frames are sent to software as a generic AUX packet. See AUX Packets for details.
3. When Dynamic HDR is not enabled in the hardware, Dynamic HDR packets will be sent to software asgeneric AUX packets.
typedef struct { XV_HdmiRxSs1_DynHdrErrType err; /* Error type */ u16 pkt_type; /* Packet Type */ u16 pkt_length; /* Packet length */ u8 gof; /* Graphics Overlay Flag */} XV_HdmiRxSs1_DynHDR_Info;
The following table provides details of the Dynamic HDR info structure variables and theirrelation.
Table 3: Dynamic HDR Info Structure
Info Frame Type PktType PktLength GOFNo Dynamic HDR 0 N/A N/A
ST 2094-10 (Annex R)1 1 Up to 65535 0/1
ETSI TS 103-433-12 2 Up to 65535 0/1
ITU-T H.265 CRI3 3 Up to 65535 0/1
ST 2094-40 (Annex S)4 4 Up to 65535 0/1
HDR10+ VSIF 5 28 N/A
Notes:1. For more information, see https://ieeexplore.ieee.org/document/7513370.2. For more information, see https://www.etsi.org/deliver/etsi_ts/103400_103499/10343301/01.02.01_60/
ts_10343301v010201p.pdf.3. For more information, see https://www.itu.int/rec/T-REC-H.265.4. For more information, see https://ieeexplore.ieee.org/document/9095450.
StandardsThe HDMI 2.1 RX Subsystem is compliant with the AXI4-Stream Video Protocol, AXI4-Liteinterconnect, and memory mapped AXI4 interface standards. See the Vivado Design Suite: AXIReference Guide (UG1037) and the AXI4-Stream Video IP and System Design Guide (UG934) foradditional information. Also, see the HDMI specifications.
The HDMI 2.1 RX Subsystem is designed to be compliant with the HDMI 2.1 specification.
The Xilinx HDCP 1.4 is designed to be compliant with the High-bandwidth Digital ContentProtection system Revision 1.4.
The Xilinx HDCP 2.3 is designed to be compliant with the HDCP 2.3 specification entitled High-bandwidth Digital Content Protection, Mapping HDCP to HDMI, Revision 2.3, issued by DigitalContent Protection (DCP) LLC.
Performance and Resource UtilizationFor full details about performance and resource utilization, visit the Performance and ResourceUtilization web page.
Maximum FrequenciesRefer to the following documents for information on DC and AC switching characteristics. Thefrequency ranges specified in these documents must be adhered to for proper transceiver andcore operation.
• Kintex UltraScale+ FPGAs Data Sheet: DC and AC Switching Characteristics (DS922)
• Virtex UltraScale+ FPGA Data Sheet: DC and AC Switching Characteristics (DS923)
• Zynq UltraScale+ MPSoC Data Sheet: DC and AC Switching Characteristics (DS925)
• Zynq UltraScale+ RFSoC Data Sheet: DC and AC Switching Characteristics (DS926)
• Artix UltraScale+ FPGA Data Sheet: DC and AC Switching Characteristics (DS931)
Port DescriptionsThe HDMI 2.1 RX Subsystem supports three types of video output stream interfaces, whicheventually is mapped to the HDMI 2.1 RX Subsystem VIDEO_OUT/NATIVE_VID_OUT interface.
• AXI4-Stream Video interface
• Native Video interface
• Native Video (Vectored Data Enable (DE)) interface
AXI4-Stream PinoutsThe following figure shows the HDMI 2.1 RX Subsystem ports. The subsystem has the followingdefault interfaces:
Native Video PinoutsThe following figure shows the HDMI 2.1 RX Subsystem ports when native video is selected asthe video interface. The NATIVE_VID_OUT port is expanded in the figure to show the detailednative video bus signals.
Note: In the following diagrams, for all native interfaces video_data_width = 3*BPC*PPC.
Native Video (Vectored DE) PinoutsThe following figure shows the HDMI 2.1 RX Subsystem ports when native video (Vectored DE)is selected as the video interface.
Note: In the following diagrams, for all native interfaces, video_data_width = 3*BPC*PPC.
CPU InterfaceThe following table shows the AXI4-Lite control interface signals. This interface is an AXI4-Liteinterface and runs at the s_axi_cpu_aclk clock rate. Control of the subsystem is onlysupported through the subsystem driver.
IMPORTANT! Direct register level access to any of the sub-modules is not supported. Instead, all accessesare done through the HDMI 2.1 RX Subsystem driver APIs.
Table 4: CPU Interface Ports
Name I/O Width Descriptions_axi_cpu_aresetn I 1 Reset (Active-Low)
s_axi_cpu_aclk I 1 Clock for AXI4-Lite control interface
Name I/O Width DescriptionS_AXI_CPU_IN_awprot I 3 Write address protection
S_AXI_CPU_IN_awvalid I 1 Write address valid
S_AXI_CPU_IN_awready O 1 Write address ready
S_AXI_CPU_IN_wdata I 32 Write data
S_AXI_CPU_IN_wstrb I 4 Write data strobe
S_AXI_CPU_IN_wvalid I 1 Write data valid
S_AXI_CPU_IN_wready O 1 Write data ready
S_AXI_CPU_IN_bresp O 2 Write response
S_AXI_CPU_IN_bvalid O 1 Write response valid
S_AXI_CPU_IN_bready I 1 Write response ready
S_AXI_CPU_IN_araddr I 17 or 19 Read address
S_AXI_CPU_IN_arprot I 3 Read address protection
S_AXI_CPU_IN_arvalid I 1 Read address valid
S_AXI_CPU_IN_aready O 1 Read address ready
S_AXI_CPU_IN_rdata O 32 Read data
S_AXI_CPU_IN_rresp O 2 Read data response
S_AXI_CPU_IN_rvalid O 1 Read data valid
S_AXI_CPU_IN_rready I 1 Read data ready
Notes:1. Data width for port S_AXI_CPU_IN_araddr and S_AXI_CPU_IN_awaddr has two possible values.
17: When HDCP is disabled in hardware through the HDMI 2.1 RX Subsystem GUI.19: When HDCP is enabled in hardware through the HDMI 2.1 RX Subsystem GUI.
AXI4-Stream Video InterfaceThe following table shows the signals for the AXI4-Stream video interface, which supports 4 and8 pixels per clock with 8 bits, 10 bits, 12 bits, and 16 bits per component for RGB, YUV444, andYUV420 color spaces. The color depth in YUV422 color space is always 12-bits per pixel. Thisinterface is an AXI4-Stream master interface and runs at the s_axis_video_aclk clock rate.The data width is user-configurable in the Vivado IDE by setting Max Bits Per Component (BPC).
Table 5: AXI4-Stream Video Interface
Name I/O Width Descriptions_axis_video_aclk I 1 AXI4-Stream clock
Name I/O Width DescriptionVIDEO_OUT_tvalid O 1 Valid
Notes:1. PPC = 4 or 8 as only 4 or 8 pixels per component is supported by the HDMI 2.1 RX Subsystem.
Native Video InterfaceThe following table shows the signals for the native video interface. This interface is a standardvideo interface and runs at the video_clk clock rate. The data width is user-configurable in theVivado IDE by setting Max Bits Per Component (BPC) and Number of Pixels Per Clock on VideoInterface (PPC).
Table 6: Native Video Interface
Name I/O Width Descriptionvideo_clk1 I 1 Video clock
NATIVE_VID_OUT_field O 1 Field ID (only for interlaced video)
NATIVE_VID_OUT_active_video O 1 Active video
NATIVE_VID_OUT_data O video_data_width3 Data
NATIVE_VID_OUT_hsync O 1 Horizontal sync
NATIVE_VID_OUT_vsync O 1 Vertical sync
Notes:1. video_clk is generated by the HDMI PHY Controller.2. When native video/native video (Vectored DE) interface is selected, s_axis_video_aclk and
s_axis_video_aresetn are removed from the HDMI 2.1 Subsystem interface ports.3. video_data_width = 3*BPC*PPC.
Native Video (Vectored DE) InterfaceAXI4-Stream can only support resolutions with video timing (HActive) divisible by PPC (4 or 8)and native video interface can only support resolutions with video timings(HActive,HSync,HTotal) divisible by PPC (4). To extend support to resolutions with video timingnot divisible by PPC, the Native Video (Vectored Date Enable (DE)) interface can be used. Thefollowing table shows the signals. The data width is user-configurable in the Vivado IDE bysetting Max Bits Per Component (BPC) and Number of Pixels Per Clock on Video Interface (PPC).
Table 7: Native Video (Vectored DE) Interface
Name I/O Width Descriptionvideo_clk1 I 1 Video clock
video_field_arb O 1 Field ID (only for interlacedvideo)
Table 7: Native Video (Vectored DE) Interface (cont'd)
Name I/O Width Descriptionvideo_de_arb O PPC Active video
video_data_arb O video_data_width3 Data
video_hs_arb O PPC Horizontal sync
video_vs_arb O PPC Vertical sync
Notes:1. video_clk is generated by the HDMI PHY Controller.2. When native video/native video (Vectored DE) interface is selected, s_axis_video_aclk and
s_axis_video_aresetn are removed from the HDMI 2.1 RX Subsystem interface ports.3. video_data_width = 3*BPC*PPC
IMPORTANT! In Native/Native (Vectored DE) interface, the IP sends the video data on video_clk,when video_cke_out is high.This will create a clock specific to the pixel clock rate of the resolution ofvideo resolution.
Audio Output Stream InterfaceThe following table shows the signals for AXI4-Stream audio streaming interfaces. The audiointerface transports 24-bits L-PCM or 16-bits HBR audio samples in the IEC 60958 format. Amaximum of 32 channels are supported. The audio interface is a 32-bit AXI4-Stream masterinterface and runs at the s_axis_audio_aclk clock rate.
Table 8: Audio Output Stream Interface
Name I/O Width Descriptions_axis_audio_aclk I 1 Clock (The audio streaming clock must be greater than or equal
or greater than 128 times the audio sample frequency)
s_axis_audio_aresetn I 1 Reset (Active-Low)
AUDIO_OUT_tdata O 32 Data[31] P (Parity)[30] C (Channel status)[29] U (User bit)[28] V (Validity bit)[27:4] Audio sample word (L-PCM) (Option 1)[27:12] Audio sample word (HBR), [11:4] are ignored for HBRaudio (Option 2)
[3:0] Preamble code4'b0001 Subframe 1/Left Channel and start of audio block4'b0010 Subframe 1/Left Channel4'b0011 Subframe 2/Right Channel
Audio Clock Regeneration InterfaceThe audio clock regeneration (ACR) interface has a Cycle Time Stamp (CTS) parameter vector andan Audio Clock Regeneration Value (N) parameter vector. Both vectors are 20 bits wide. The validsignal is driven High when the CTS and N parameters are stable. For more information, seeChapter 9 of the HDMI 2.1 specification.
The subsystem should set up the CTS and N parameters before asserting the valid signal.
The following table shows the Audio Clock Regeneration (ACR) interface signals. This interfaceruns at the s_axis_audio_aclk clock rate.
Table 9: Audio Clock Regeneration (ACR) Interface
Name I/O Width Descriptionacr_cts O 20 CTS
acr_n O 20 N
acr_valid O 1 Valid
Dynamic HDR Interface (Memory Mapped AXI4Interface)The following table shows the M_HDR_AXI interface signals. This interface is a memory mappedAXI4 interface and runs at the m_hdr_axi_aclk clock rate. The memory mapped DynamicHDR interface is only present when you select Enable Dynamic HDR Support in the IDE.
For more information on the memory mapped AXI4 interface, refer to the Vivado Design Suite:AXI Reference Guide (UG1037).
Data Display Channel InterfaceThe following table shows the Data Display Channel interface signals.
Table 12: Data Display Channel (DDC) Interface
Name I/O Width Descriptionddc_scl_i I 1 DDC serial clock in
ddc_scl_o O 1 DDC serial clock out
ddc_scl_t O 1 DDC serial clock tri-state
ddc_sda_i I 1 DDC serial data in
ddc_sda_o O 1 DDC serial data out
ddc_sda_t O 1 DDC serial data tri-state
HDCP 1.4 Key Input Interface (AXI4-Stream SlaveInterface)The following table shows the signals for HDCP 1.4 key interface. This interface runs at thehdcp14_key_aclk (which is running at the AXI4-Lite clock).
Table 13: HDCP 1.4 Key Input Interface
Name I/O Width DescriptionHDCP_KEY_IN_tdata I 64 HDCP 1.4 key data
Name I/O Width Descriptioncable_detect I 1 If XGUI option: Cable Detect active-High (Default)
0 - Cable Detect is released1 - Cable Detect is asserted
If XGUI option: Cable Detect active-Low 2
0 - Cable Detect is asserted1 - Cable Detect is released
irq O 1 Interrupt request for CPU. Active-High.
frl_clk I 1 Fixed FRL link clock.
video_clk I 1 Reference Native Video ClockThe HDMI 2.1 RX core uses this video_clk to clock out the VideoData together with the video_cke_out. Then an Video In to AXI4-Stream Bridge module is added to the HDMI 2.1 RX Subsystemto convert Native Video into AXI4-Stream Video.
video_cke_out O 1 Video clock enable signalFRL Mode: video_cke_in is used to synchronize the video datarate of the HDMI TX core with the HDMI RX core in cases wherea frame buffer is not used. This port is not intended to be usedwith systems using a frame buffer or data source other than theHDMI RX Core. HDMI RX Core video_cke_out should beconnected to video_cke_in. Make sure video_cke_out from theHDMI RX core is synchronized to the HDMI TX clock domain; seethe passthrough example design for an example on how this isimplemented.TMDS Mode: Not used
SB_STATUS_IN_tdata I 2 Side Band Status input signalsBit 0: link_rdyBit 1: video_rdy
SB_STATUS_IN_tvalid I 1 Side Band Status input valid
fid3 I 1 Field ID for AXI4-Stream bus. Used only for interlaced video.0 - even field1 - odd field
This bit is sampled coincident with the SOF on the AXI4-Streambus. If the signal is not used, set the input to Low.
video_rst4 O 1 Video reset signal in video_clk domain. Active-High.
Notes:1. The Hot Plug Detect (HPD) signal is driven by an HDMI sink and asserted when the HDMI cable is connected to notify
the HDMI source of the presence of an HDMI sink. When designing an HDMI sink system using the HDMI 2.1 RXSubsystem, in the PCB, if you choose to use a voltage level shifter, the HPD polarity remains as active-High. However,if you choose to add an inverter to the HPD signal, then the HPD polarity must be set to active-Low in the HDMI 2.1 RXSubsystem GUI. There are two common ways of using HPD: Toggle HPD to trigger HDCP authentication process(usually 100 ~ 500 ms). Or a longer HPD toggle (>1s), the HDMI sink is notifying the source its present without cableunplug and plug. The software API used to assert and release HPD is XV_HdmiRxSs1_SetHpd.
2. The Cable Detect signal is connected to a 5V power signal from the HDMI cable connector via some level shifter tonotify the HDMI 2.1 RX Subsystem that an HDMI source is connected.
3. Applicable only for when the AXI4-Stream video interface present.4. Applicable only for when the Native Video or Native Video (Vectored DE) interface present.
Clocks and ResetsThe following table provides an overview of the clocks and resets. See Clocking and Resets formore information.
Table 17: Clocks and Resets
Name I/O Width Descriptions_axi_cpu_aclk I 1 AXI4-Lite CPU control interface clock.
s_axi_cpu_aresetn I 1 Reset, associated with s_axi_cpu_aclk (active-Low). Thes_axi_cpu_aresetn signal resets the entire subsystemincluding the data path and AXI4-Lite registers.
s_axis_video_aclk I 1 AXI4-Stream video output clock.
s_axis_video_aresetn I 1 Reset, associated with s_axis_video_aclk (active-Low).Resets the AXI4-Stream data path for the video output.
s_axis_audio_aclk I 1 AXI4-Stream Audio output clock. (The audio streaming clockmust be greater than or equal to 128 times the audiosample frequency)
s_axis_audio_aresetn I 1 Reset, associated with s_axis_audio_aclk (active-Low).Resets the AXI4-Stream data path for the audio output.
link_clk I 1 HDMI Link data output clock. This connects to the HDMIPHY Controller link clock output.
video_clk I 1 Clock for the native video interface.
frl_clk I 1 Fixed FRL link clock.
m_hdr_axi_aclk I 1 Dynamic HDR memory mapped AXI4 interface clock.
m_hdr_axi_aresetn I 1 Dynamic HDR memory mapped AXI4 interface resetassociated with m_hdr_axi_aclk clock (active-Low). Resetsthe Dynamic HDR data path.
Notes:1. The reset should be asserted until the associated clock becomes stable.
Designing with the SubsystemThis chapter includes guidelines and additional information to facilitate designing with thesubsystem.
General Design GuidelinesThe subsystem connects to other hardware components to construct a complete HDMI 2.1 RXsystem. These hardware components usually are different from device to device. You must fullyunderstand the system and adjust the subsystem parameters accordingly.
Control Interface
The HDMI 2.1 RX Subsystem is controlled over an AXI4-Lite interface using the Xilinx APIdescribed in Appendix D: Application Software Development; the appendix also describes how tointegrate the subsystem API into a software application. The API is the only provided control forthe HDMI RX subsystems and the register interface descriptions are not provided.
Audio Data StreamAn AXI4-Stream audio cycle is illustrated in the following figure. The data is valid when both thevalid (TVLD) and ready (TRDY) signals are asserted. The HDMI 2.1 RX Subsystem sends outadjacent channels in sequential order (CH0, CH1, etc.). Usually, the audio stream receiver alsoexpects the channels in sequential order. If the channel data is not in order, the channel datamight be mapped into other channel sample slots. Audio signals are defined in Audio OutputStream Interface.
In the HDMI 2.1 RX Subsystem the audio information, such as format and number of channels,are extracted from the video stream. This information is available through API calls.
• XV_HdmiRxSs1_GetAudioFormat
• XV_HdmiRxSs1_GetAudioChannels
The actual audio data is extracted and sent to AUDIO_OUT interface. Similarly, the ACR valuesare extracted from the ACR packets and sent to ACR ports.
If an HDMI system does not require audio, tie all audio related input ports Low. The ports are:
• s_axis_audio_aresetn
• s_axis_audio_aclk
• AUDIO_OUT_tready
Audio related output can be left unconnected. The ports are:
• AUDIO_OUT (except tready)
• acr_cts
• acr_n
• acr_valid
In the HDMI 2.1 RX Subsystem, L-PCM (IEC 60958, Packet Type 0x02), HBR (Packet Type 0x09),and 3D Audio (Packet Type 0x0B) are handled by the hardware. For Aux packet with packet type= 0x02, the audio data are routed to the audio interface. Therefore, even IEC 61937 compressedaudio is available at the audio interface. In this case, you must develop your module to retrieveand uncompress the audio.
Video Output Stream InterfaceThe AXI4-Stream video interface supports four or eight pixels per clock with 8 bits, 10 bits, 12bits, and 16 bits per component for RGB, YUV444, and YUV420 color spaces. The color depth inYUV422 color space is always 12-bits per pixel.
When the parameter, Max Bits Per Component, is set to 16, the following figure shows the dataformat for four pixels per clock to be fully compliant with the AXI4-Stream video protocol.
Figure 12: Four Pixels Data Format (Max Bits Per Component = 16)
G1 / Y18-
bits
G1 / Y110-bits
64
V012-bits
G1 / Y112-bits
G1 / Y116-bits
R1 / V1
8-bits
R1 / V110-bits
96
R1 / V112-bits
R1 / V116-bits
B1 / U1
8-bits
B1 / U110-bits
80
B1 / U112-bits
B1 / U116-bits
0
G0 / Y0
8-bits
G0 / Y010-bits
16
Y012-bits
G0 / Y012-bits
G0 / Y016-bits
R0 / V08-
bits
R0 / V010-bits
48
Y112-bits
R0 / V012-bits
R0 / V016-bits
B0 / U08-
bits
B0 / U010-bits
32
U012-bits
B0 / U012-bits
B0 / U016-bits
G3 / Y38-
bits
G3 / Y310-bits
160
G3 / Y312-bits
G3 / Y316-bits
R3 / V3
8-bits
R3 / V310-bits
191
R3 / V312-bits
R3 / V316-bits
B3 / U38-
bits
B3 / U310-bits
176
B3 / U312-bits
B3 / U316-bits
G2 / Y2
8-bits
G2 / Y210-bits
112
G2 / Y212-bits
G2 / Y216-bits
R2 / V28-
bits
R2 / V210-bits
144
R2 / V212-bits
R2 / V216-bits
B2 / U28-
bits
B2 / U210-bits
128
B2 / U212-bits
B2 / U216-bits
V212-bits
Y212-bits
Y312-bits
U212-bits
RGB / YUV444
8-bits
RGB / YUV44410-bits
YUV42212-bits
RGB / YUV44412-bits
RGB / YUV44416-bits
X15244-092321
If the actual bits per component is greater than Max Bits Per Component set in the Vivado IDE,video formats with actual bits per component larger than Max Bits Per Component should betruncated to the Max Bits Per Component. The remaining least significant bits are discarded. Ifthe actual bits per component is smaller than Max Bits Per Component set in the Vivado IDE, allbits are transported with the MSB aligned and the remaining LSB bits are padded with 0. Thisapplies to all Max Bits Per Component settings.
Table 18: Max Bits Per Component Support
Max Bits Per Component Actual Bits Per Component Bits Transported by Hardware
Max Bits Per Component Actual Bits Per Component Bits Transported by Hardware
10
8 [7:0]
10 [9:0]
12 [11:2]
16 [15:6]
8
8 [7:0]
10 [9:2]
12 [11:4]
16 [15:8]
The video interface can also transport four and eight pixels in the YUV420 color space. Thefollowing figure show the data format for four pixels format.
Figure 13: YUV420 Color Space Four Pixels Data Format (Native)
Similarly, for YUV 4:2:0 deep color (10, 12, or 16 bits), the data representation is the same asshown in the previous two figures. The only difference is that each component carries more bits(10, 12, and 16). However, the current data format is not compliant with the AXI4-Stream videoprotocol. Therefore, a remapping feature is added to the HDMI 2.1 RX Subsystem to convertAXI4-Stream into HDMI native video. This feature will be enabled by default from the HDMI 2.1RX Subsystem GUI when the AXI4-Stream video interface is selected. To illustrate how the dataremapping feature works for YUV 4:2:0 video from AXI4-Stream into native video, the previousfigure is extended and represented in the following figure to show native video data associatedwith the clock and control signals.
Figure 14: Native HDMI Video Interface (Four Pixels per Clock)
When transporting using AXI4-Stream, the data representation must be compliant with theprotocol defined in the AXI4-Stream Video IP and System Design Guide (UG934). With theremapping feature, the same native video data is converted into AXI4-Stream formats, shown inthe following figure. As stated in AXI4-Stream Video IP and System Design Guide (UG934), the4:2:0 format adds vertical sub-sampling to the 4:2:2 format, which is implemented in Video overAXI4-Stream by omitting the chroma data on every other line.
However, in the native HDMI video interface, the video data representation must be as shown inthe following figure.
Figure 15: YUV 4:2:0 AXI4-Stream Video Data (Four Pixels per Clock)
Note: For RGB/YUV444/YUV422 formats, video data is directly mapped from AXI4-Stream to the nativevideo interface without any line buffer. Therefore, the four Pixels Data Format graphics shown previously,represent the data interface for both AXI4-Stream and native video. The control signals are omitted in thefigure.
For more information on the video AXI4-Stream interface and video data format, see the AXI4-Stream Video IP and System Design Guide (UG934). The remapping feature, which is to convertbetween native video data format and AXI4-Stream format, is also described in the AXI4-StreamVideo IP and System Design Guide (UG934).
ClockingThe HDMI 2.1 RX Subsystem uses six clock domains. This section describes all the clocksrequired for the HDMI 2.1 RX Subsystem to function in your application.
• s_axi_cpu_aclk: This is the processor domain. It has been tested to run at 100 MHz.
• frl_clk: A free-running clock input running at a fixed rate. The frl_clk is used by the internalprocessing. It can come from the MMCM or the clock pin. See the following table for moreinformation.
• s_axis_video_aclk: A free-running input clock for the AXI4-Stream video is supported. TheVideo In to AXI4-Stream bridge will convert the native video into AXI4-Stream video runningin the video_clk domain. See the following table for more information.
• video_clk: The rx_video_clk from the HDMI PHY Controller is connected to the HDMI 2.1RX Subsystem video_clk, which supports both TMDS mode and FRL mode.
• In TMDS mode, the HDMI PHY Controller is configured to generate the actual RX videoclock with respect to the actual selected video format.
• In FRL mode, the HDMI PHY Controller is configured to output a fixed rate clock. See thefollowing table for more information.
• In FRL mode, the optional video_cke_in can be enabled to control the actual videoclock rate to be running at video_clk and video_cke_in.
• m_hdr_axi_aclk: Free-running input clock running at the fixed rate. Used by the HDR DataEngine to process the HDR AUX packets and to read from the memory. See the followingtable for more information.
Table 19: HDMI Clocks
Device Family SpeedGrade GT PLL frl_clk video_clk s_axis_video_aclk m_hdr_axi_aclk
Notes:1. frl_clk is a fixed-rate, free running clock generated by MMCM or external clock pin. The frequency must be fixed to the
required rate in this table.2. video_clk frequencies in this table are applicable only for FRL Mode. video_clk is automatically generated by the HDMI
PHY Controller depending on incoming data (TMDS or FRL).3. s_axis_video_clk frequencies in this table are the maximum frequencies supported by the IP; however, you can
configure to lower frequencies depending on the maximum resolution supported by the following equation:s_axis_video_clk >= HActive*Vactive*Frame Rate/PPC
4. For details on FRL line rates supported, see Table 25: HDMI 2.1 FRL Line Rates Supported Across Devices.5. m_hdr_axi_clk frequencies in this table are maximum frequencies support by the IP; however, you can configure to
lower frequencies depending on the maximum resolution and Dynamic HDR metadata size.6. For GTHE4, -1,-1M, -1L, -1LV, -2LV, and -2LVI parts, and for GTYE4, -1,-1M,-1L, and -1LV parts, the maximum supported
FRL line rate is 8.0Gb/s due to the limitation on CPLL and USRCLKs.
• link_clk: The rxoutclk from the HDMI PHY Controller is connected to the HDMI 2.1 RXSubsystem link_clk, which supports both TMDS mode and FRL mode.
• In TMDS mode, the HDMI PHY Controller is configured to generate the actual TMDSclocks with respect to the actual selected video format.
• In FRL mode, the HDMI PHY Controller is configured to support 3, 6, 8, 10, and 12 Gb/s ofline rates based on a single MGT reference clock frequency (400 MHz). The link_clk =line rate/40 as the GT data width is set to 40 bits parallel bus.
Table 20: Link Clock for FRL Line Rates
Line Rate (Gb/s) link_clk (MHz)3 75
6 150
8 200
10 250
12 300
Refer to the HDMI PHY Controller LogiCORE IP Product Guide (PG333) for more details.
• s_axis_audio_aclk: This clock is used by the source audio streaming interface. This clockshould be = 512 × audio sample rate.
The HDMI clock structure is illustrated in the following figure and table.
Figure 16: HDMI Clocking Structure (TMDS)
Data rate< 3.4Gbps
*1
Data rate>3.4Gbps
*4
8 bpc/1
16 bpc/2
/4
Quad/4
10 bpc/1.25
12 bpc/1.5
TMDSclock
Dataclock
Pixelclock
Videoclock
Linkclock
X23116-112320
Table 21: HDMI Clocking (TMDS)
Clock Function Freq/Rate Example1
TMDSSource synchronous clockto HDMI interface (This isthe actual clock on theHDMI cable).
Video Clock used for videointerface clock = pixel clock/4 297 MHz/4 = 74.25 MHz for quad pixel
wide interface
Notes:1. The examples in the Example column are only for reference and do not cover all the possible resolutions. Each GT has
its own hardware requirements and limitations. Therefore, to use the HDMI 2.1 RX Subsystem with different GTdevices, calculate the clock frequencies and make sure the targeted device can support it. When using the HDMI 2.1RX Subsystem with the Xilinx HDMI PHY Controller IP core, more information can be found in the HDMI PHY ControllerLogiCORE IP Product Guide (PG333).
Note: The HDMI 2.1 RX Subsystem supports both integer and non-integer frame rates. However, theHDMI 2.1 RX Subsystem reports frame rate information based on the Video Identification Code (VIC) ID.The VIC ID is common for integer and non-integer frame rates and the HDMI 2.1 RX Subsystem alwaysreports the integer frame rate. To determine the non-integer frame rate in TMDS Mode, Xilinxrecommends you read the receiver frequency using the XHdmiphy1_ClkDetGetRefClkFreqHz API. Formore details, refer to the register definitions in the HDMI PHY Controller LogiCORE IP Product Guide(PG333).
However, in FRL mode, the link is running at a fixed rate according to the line rate establishedbetween source and sink. Therefore, instead of calculating the actual clocks, it is more useful tofind out the minimum required link rate to support certain video format.
For example, 8kp30, 8 BPC, 4 PPC are used to show how all the clocks are derived.
Table 22: Example Settings
VideoResolution
HorizontalTotal
HorizontalActive Vertical Total Vertical Active Frame Rate
In this example, the data clock is 1188 MHz, which is equivalent to 11.88 Gb/s. That exceeds theTMDS bandwidth. Therefore, FRL mode is used to carry this video.
The total bandwidth needed = (Pixel clock) x BPC (bits per component) x 3 (3 components forRGB video) x 18/16 (HDMI 2.1 uses 16/18 encoding scheme) = 1188 x 8 x 3 x 18 / 16 = 32.076Gb/s
On the other hand, AXI4-Stream video only carries active video, for example, TPG only generatesactive video. Therefore, when calculating the "active pixel clock", only hactive and vactive areused.
Active Pixel clock = HActive × Vactive × Frame Rate = 7680 x 4320 x 30 = 995,328,000 =995.328 MHzs_axis_video_clk = (Active Pixel clock)/PPC = 995.328/4 = 248.832 MHz
The total bandwidth needed for active video = (Active Pixel clock) x BPC (bits per component) x3 (3 components for RGB video) x 18 / 16 (HDMI 2.1 uses 16/18 encoding scheme) = 995.328 x8 x 3 x 18 / 16 = 26.874 Gb/s
When the HDMI 2.1 RX Subsystem is running in FRL mode, one of the following modes can beselected.
Table 23: FRL Line Rates
Line Rate Max Total Bandwidth (Gb/s)3 Gb/s @ 3 lanes 9
6 Gb/s @ 3 lanes 18
6 Gb/s @ 4 lanes 24
8 Gb/s @ 4 lanes 32
10 Gb/s @ 4 lanes 40
12 Gb/s @ 4 lanes 48
The HDMI 2.1 specification (http://www.hdmi.org/manufacturer/specification.aspx) (section 6.5)also defines the concept of repeat count, which is to compress the blanking period when it doesnot carry any AUX metadata. Therefore, in this example, 8 Gb/s @ 4 lanes is sufficient to support8kp30 video.
Note: There is no dedicated hardware reset for NATIVE_VID_OUT interface when Native Video or NativeVideo (Vectored DE) interface is selected. However, the HDMI 2.1 RX Subsystem outputs a video_rstsignal, which you can use to reset its supporting Native Video or Native Video (Vectored DE) Sourceprocessing modules.
Design Flow StepsThis chapter describes customizing and generating the subsystem, constraining the subsystem,and the simulation, synthesis and implementation steps that are specific to this IP subsystem.More detailed information about the standard Vivado® design flows and the IP integrator can befound in the following Vivado Design Suite user guides:
• Vivado Design Suite User Guide: Designing IP Subsystems using IP Integrator (UG994)
• Vivado Design Suite User Guide: Designing with IP (UG896)
• Vivado Design Suite User Guide: Getting Started (UG910)
Customizing and Generating the SubsystemThis section includes information about using Xilinx® tools to customize and generate thesubsystem in the Vivado® Design Suite.
The HDMI 2.1 RX Subsystem can be added to a Vivado IP integrator block design in the VivadoDesign Suite and can be customized using IP catalog.
If you are customizing and generating the subsystem in the Vivado IP integrator, see the VivadoDesign Suite User Guide: Designing IP Subsystems using IP Integrator (UG994) for detailedinformation. IP integrator might auto-compute certain configuration values when validating orgenerating the design. To check whether the values do change, see the description of theparameter in this chapter. To view the parameter value, run the validate_bd_designcommand in the Tcl console.
You can customize the IP for use in your design by specifying values for the various parametersassociated with the IP subsystem using the following steps:
1. In the Flow Navigator, click on Create Block Diagram or Open Block Design under the IPIntegrator heading.
2. Right-click in the diagram and select Add IP.
A searchable IP catalog opens. You can also add IP by clicking on the Add IP button on theleft side of the IP Integrator Block Design canvas.
3. Click on the IP name and press the Enter key on your keyboard or double click on the IPname.
4. Double-click the selected IP block or select the Customize Block command from the right-click menu.
For details, see the Vivado Design Suite User Guide: Designing with IP (UG896) and the VivadoDesign Suite User Guide: Getting Started (UG910).
Figures in this chapter are illustrations of the Vivado IDE. The layout depicted here might varyfrom the current version.
Top Level TabThe top level tab is shown in the following figure.
Figure 17: Top Level Tab
The parameters on the top level tab are as follows.
• Component Name: The component name is set automatically by IP integrator.
• Video Interface: This option selects the video interface for the HDMI 2.1 RX Subsystem. Theallowable options are AXI4-Stream, Native Video, and Native Video (Vectored DE).
• Include HDCP Encryption: This option enables both HDCP 1.4 and 2.3 encryption.
Note: HDCP Encryption options are only configurable if you have a HDCP license; otherwise it is disabledand grayed out from the GUI.
• Enable Dynamic HDR Support: This option enables Dynamic HDR support (Section 10.10.2.3of the HDMI 2.1 specification (https://www.hdmi.org/spec/hdmi2_1)).
IMPORTANT! External YUV420 Conversion is removed. Optimized AXIS Remapper and YUV 420Conversion is added inside the subsystem. External Video AXI4S Remapper is not required in designs for8kp60/10kp60 support. To enable 8kp48, 8kp50, 8kp60/10kp60 YUV420, select Number of pixels perclock as 8. Otherwise, it is recommended to select Number of pixels per clock as 4, which is sufficient tosupport up to 8k/10kp30.
IMPORTANT! In Native Video or Native Video (Vectored DE) interface, the IP supports YCbCr 4:2:0.However, you must process YCbCr 4:2:0 Pixel Encoding. See Section 7 in the HDMI 2.0b Specification(http://www.hdmi.org/manufacturer/specification.aspx) or Video Output Stream Interface.
• Max bits per component: This option selects the maximum bits per component. The allowableoptions are, 8, 10, 12 or 16 bits. This parameter is to set the maximum "allowed" bits percomponent, and the actual bits per component can be set from the software API to a differentvalue. However, the actual bits per component is bounded by the Max bits per component.For example, if the Max bits per component is set to 16, the user can set the actual bits percomponent from the software API to any of the values, 8, 10, 12 or 16. But if the Max bits percomponent is set to 8, you can only set the actual bits per component to 8 through thesoftware API.
• Number of pixels per clock on Video Interface: This option selects the number of pixels perclock. The allowable options are 4 or 8 pixels per clock in the AXI4-Stream Interface. NativeVideo or Native Video (Vectored DE) Interface supports only 4 pixels per clock.
Note: IP supports only resolutions that are divisible by 4 (HTotal, HActive, and HBlank). For YUV 420,only video timings that are divisible by 8 are supported.
• Number of GT lanes: Fixed to 4 GT lanes.
• Hot Plug Detect Active: This option selects the HPD active polarity. The allowable options areHigh or Low.
• EDID RAM size: The allowable options are, 256, 512, 1024, or 4096.
• Cable Detect Active: This option selects the Cable Detect active polarity. The allowableoptions are High or Low.
Video Bridge Tab (AXI4-Stream Interface Only)The Video Bridge tab is shown in the following figure.
• Design Topology: Fixed to Pass-Through, to showcase the HDMI 2.1 system built with oneHDMI 2.1 TX Subsystem and one HDMI 2.1 RX Subsystem, sharing the same HDMI PHYController.
• Axilite Frequency: AXI4-Lite CPU clock fixed to 100 MHz in this example design.
• HDMI PHY Controller Setting Section: Allows the configuration of the Transmitter PLL typeand Receiver PLL Type to the HDMI PHY Controller prior generating the example design. NI-DRU is always enabled in this example design. See the HDMI PHY Controller LogiCORE IPProduct Guide (PG333) for details about NI-DRU requirements.
• Example Design Overview: A system block diagram to show the overview of the exampledesign to be generated.
User ParametersThe following table shows the relationship between the fields in the Vivado IDE and the UserParameters (which can be viewed in the Tcl Console).
Table 24: Vivado IDE Parameter to User Parameter Relationship
Vivado IDE Parameter/Value User Parameter/Value Default ValueToplevel
Video InterfaceAXI4-StreamNative VideoNative Video (Vectored DE)
C_VID_INTERFACE012
AXI4-Stream
Include HDCP EncryptionExclude (Untick)Include (Tick)
Required ConstraintsClock frequency constraints are required for the s_axi_cpu_aclk, s_axis_video_aclk,s_axis_audio_aclk, m_hdr_axi_clk, link_clk, frl_clk, and video_clk.
Note: For more details on HDMI 2.1 clocks, see Table 19: HDMI Clocks.
When using this subsystem in the Vivado Design Suite flow with HDMI PHY Controller modules,link_clk and video_clk are generated from the HDMI PHY Controller. Therefore, the clockconstraints are set to the HDMI PHY Controller constraints instead of these generated clocks.See Clocking in the HDMI PHY Controller LogiCORE IP Product Guide (PG333) for moreinformation.
The frl_clk, s_axi_cpu_aclk, s_axis_video_aclk, s_axis_audio_aclk, andm_hdr_axi_clk constraints are generated at system level, for example by using a clock wizard.
Device, Package, and Speed Grade SelectionsFor more information on the device constraint/dependency, see the HDMI PHY ControllerLogiCORE IP Product Guide (PG333).
The following table shows the device and speed grade selections for HDMI 2.1 RX Subsystem.
Table 25: HDMI 2.1 FRL Line Rates Supported Across Devices
Table 25: HDMI 2.1 FRL Line Rates Supported Across Devices (cont'd)
MAX FRL Rate 12 Gb/s@ 4
Lanes
10 Gb/s@ 4
Lanes
8 Gb/s@ 4
Lanes
6 Gb/s@ 4
Lanes
6 Gb/s@ 3
Lanes
3 Gb/s@ 3
LanesTMDS
Device Family SpeedGrade GT PLL
Kintex®
UltraScale+™-1LV,-2LV CPLL,
QPLLNot Supported Supported
-1, -1L4 CPLL Not Supported Supported
QPLL NotSupported
Supported
-2, -2L, -3 CPLL,QPLL
Supported
Virtex®
UltraScale+™-2LV CPLL,
QPLLNot Supported Supported
-14 CPLL Not Supported Supported
QPLL NotSupported
Supported
-2, -2L, -3 CPLL,QPLL
Supported
Artix UltraScale+ -1LV CPLL,QPLL
Not Supported Supported
-1, -1L4 CPLL Not Supported Supported
QPLL NotSupported
Supported
-2 CPLL,QPLL
Supported
Notes:1. 5Kp100, 5Kp120 resolutions are supported only in 8ppc mode for -1LV and -2LV devices due to the s_axis_video_clock
fmax restriction.2. Maximum FRL rate supported by IP will be selected automatically based on device family and speed grade. You must
provide the frl_clock frequency mentioned in the HDMI 2.1 Clocks table. However, you can lower the FRL rate bychanging the MAX FRL rate in HF-VSDB block of EDID.
3. xcau10p and xcau15p devices are not supported due to fabric size.4. For GTHE4, -1,-1M, -1L, -1LV, -2LV, and -2LVI parts, and for GTYE4 -1,-1M,-1L, and -1LV parts, the maximum supported
FRL line rate is 8.0 Gb/s due to the limitation on CPLL and USRCLKs.
Clock FrequenciesSee the Clocking section for more information.
Related Information
Clocking
Clock ManagementThis section is not applicable for this IP subsystem.
Clock PlacementThis section is not applicable for this IP subsystem.
BankingFor more information on the specific banking constraints, see the HDMI PHY Controller LogiCOREIP Product Guide (PG333).
Transceiver PlacementSee Clocking in the Designing the Subsystem chapter for more details about clock frequencies.For more information on GT clocking, see the HDMI PHY Controller LogiCORE IP Product Guide(PG333).
I/O Standard and PlacementThis section is not applicable for this IP subsystem.
SimulationSimulation of the subsystem is not supported.
Synthesis and ImplementationFor details about synthesis and implementation, see the Vivado Design Suite User Guide: Designingwith IP (UG896).
Example DesignThis chapter contains step-by-step instructions for generating an HDMI Example Design fromthe HDMI 2.1 RX Subsystem by using the Vivado® Design Suite flow.
SummaryThe HDMI 2.1 RX Subsystem allows users to customize the example design based on theirsystem requirements. The following table shows a summary of the hardware required for eachtargeted board, supported processors, topologies, and the corresponding Vitis™ softwareplatform import example options.
Table 26: Example Design Support Summary
DevelopmentBoards Additional Hardware Processor Topology Vitis Import Example
Notes:1. The Pass-Through with Advance Features example design supports VRR, QFT, QMS, ALLM, and Dynamic HDR.
Supports only 8bpc for 8kp60 YUV 420, 8kp30, and 4kp120 RGB/YUV44 resolutions.
Note: The example designs supports only up to 8 Channel Audio.
IMPORTANT! Xilinx recommends to use only HDMI 2.1 Category 3 (ULTRA HIGH SPEED HDMI) certifiedcables for Fixed Rate Link Video Receive/Transmit. The HDMI 2.1 FRL Mode is tested with the Belkin 48Gb/s HDMI 2.1 Ultra High Speed HDMI (Category 3) cable.
Note: Contact Inervium/Tokyo Electron Device for HDMI 2.1 FMC cards (https://us.teldevice.com/product/tb-fmch-vfmc-hdmi/).
Running the Example Design1. Open the Vivado Design Suite and create a new project.
2. In the pop-up window, press Next until you get to the page to select the Xilinx part or boardfor the project.
3. Select the target board, then click Next → Finish. (The ZCU102, ZCU106, and VCU118boards are supported.)
4. A Vivado Project opens. In Flow Navigator, PROJECT MANAGER, click IP Catalog to open it.Then double-click HDMI 2.1 Receiver Subsystem in Video Connectivity.
5. A Customize IP window opens. Configure the HDMI 2.1 RX Subsystem, then select OK.
a. Refer to the Design Flow Steps chapter for a detailed description on Customizing andGenerating the Subsystem.
b. You can rename the IP component name, which is used as example design project name.
IMPORTANT! To enable 8kp48, 8kp50, 8kp60/10kp60 YUV420, select Number of pixels per clockas 8. Otherwise, it is recommended that you select Number of pixels per clock as 4, which is sufficientto support up to 8k/10kp30.
Note: Due to a board design limitation, there is no available clock source on the VCU118 board for theNI-DRU reference clock. Therefore, if you are targeting the VCU118 board, the NI-DRU is disabled bydefault.
6. The Generate Output Products dialog box opens. Select Generate.
Note: You can optionally select Skip if you only want to create an example design and leave the IPgeneration to a later stage.
7. The IP component with provided name is added to Design Sources. Right-click on it andselect Open IP Example Design.
8. Choose the target Example project directory, then select OK.
9. A new Vivado project launches, in which an HDMI 2.1 Example Design is generated withBlock Design to show the system structure. Select Run Synthesis, Implementation, andGenerate Bitstream to build the design. An overall system IP integrator block diagram of theZCU106-based example design is shown:
Overwrite Constraints: GT Lane SwapDue to a mismatch between the ZCU102/ZCU106 FMC-HPC0 and the GT Bank, the GT channelmust be swapped accordingly during the post optimize design of implementation stage, byoverwriting the constraint for the ZCU102/ZCU106.
Table 27: ZCU102/ZCU106 GT Lane Swap Mapping
GT Channel GT LOC0 GTHE4_CHANNEL_X0Y14
1 GTHE4_CHANNEL_X0Y13
2 GTHE4_CHANNEL_X0Y15
3 GTHE4_CHANNEL_X0Y12
1. Use the following code to replace the constraint for the ZCU102/ZCU106:# Reset the LOC property to remove the previous LOCreset_property LOC [get_cells -hierarchical -filter {NAME =~ *gen_channel_container[3].*gen_gthe4_channel_inst[0].GTHE4_CHANNEL_PRIM_INST}]reset_property LOC [get_cells -hierarchical -filter {NAME =~ *gen_channel_container[3].*gen_gthe4_channel_inst[1].GTHE4_CHANNEL_PRIM_INST}]reset_property LOC [get_cells -hierarchical -filter {NAME =~ *gen_channel_container[3].*gen_gthe4_channel_inst[2].GTHE4_CHANNEL_PRIM_INST}]reset_property LOC [get_cells -hierarchical -filter {NAME =~ *gen_channel_container[3].*gen_gthe4_channel_inst[3].GTHE4_CHANNEL_PRIM_INST}]
# Assign new LOC property according to ZCU106 HPC0 wiringset_property LOC GTHE4_CHANNEL_X0Y14 [get_cells -hierarchical -filter {NAME =~ *gen_channel_container[3].*gen_gthe4_channel_inst[0].GTHE4_CHANNEL_PRIM_INST}]set_property LOC GTHE4_CHANNEL_X0Y13 [get_cells -hierarchical -filter {NAME =~
*gen_channel_container[3].*gen_gthe4_channel_inst[1].GTHE4_CHANNEL_PRIM_INST}]set_property LOC GTHE4_CHANNEL_X0Y15 [get_cells -hierarchical -filter {NAME =~ *gen_channel_container[3].*gen_gthe4_channel_inst[2].GTHE4_CHANNEL_PRIM_INST}]set_property LOC GTHE4_CHANNEL_X0Y12 [get_cells -hierarchical -filter {NAME =~ *gen_channel_container[3].*gen_gthe4_channel_inst[3].GTHE4_CHANNEL_PRIM_INST}]
Export the Generated Example DesignAfter the hardware is created successfully, the next step is to export the generated the HDMIexample design hardware to build the HDMI application software using the Xilinx Vitis IntegratedDesign Environment (IDE).
1. To export the hardware design, in the generated HDMI example design Vivado project, selectFile → Export → Export Hardware.
2. In the Export Hardware window, select OK. The hardware definition file is exported to afolder (usually the Vivado project root directory).
3. Create a directory for the Vitis workspace on the Vivado Tcl Console.
mkdir <vitis_workspace>
4. Go to the <vitis_workspace> directory and execute the Vitis IDE on the Vivado TclConsole.
cd <vitis_workspace>vitis &
Related Information
Summary
Build Software Application Using Vitis IDE1. Open the Vitis IDE.
2. Select File → New → Platform Project to create a new platform project.
11. Click Run in the Vitis IDE to program the FPGA and load elf file to processor.
The Example Application will be built and a .elf file is ready to use.
HDCP Key UtilityAn optional hdcp_key_utility application software is available for using the same hardware toprogram your own HDCP encryption keys into the EEPROM (FMC or on-board).
To hdcp_key_utility application:
1. Import Example from the Vitis software platform and choose hdcp_key_utility.
2. Open hdcp_key_utility.c from the Vitis project.
3. The arrays Hdcp22Lc128, Hdcp22Key, Hdcp14Key1, and Hdcp14Key2 hold the HDCP keysand are empty. Fill these arrays with the acquired HDCP keys. The arrays are defined in bigendian byte order.
4. Save the file and compile the design.
5. Run the design.
The terminal displays the following output:
HDCP Key EEPROM v1.0This tool encrypts and stores the HDCP 2.2 certificate and HDCP 1.4 keys into the EEPROM on the HDMI FMC boardEnter Password ->
The HDCP keys are encrypted using this password. The same password is used in thereference design to decrypt the HDCP keys.
The application is terminated after completing the programming of HDCP keys.
Note: The keys only need to be programmed into the EEPROM once.
The hdcp_key_utility.c has two (empty) HDCP 1.x key arrays.
• The Hdcp14Key1 array.
This array holds the HDCP 1.x RX KSV and Keys.
• The Hdcp14Key2 array.
This array holds the HDCP 1.x RX KSV and Keys.
The arrays have a size of 328 bytes and contain the Key Selection Vector (KSV) (5 bytes paddedwith zeros to 8 bytes) and key set (320 bytes), where each key is 7 bytes padded with zeros to 8bytes.
To format the HDCP 1.x keys for the key_utility, use the following steps:
1. Discard the 20 byte SHA-1.
2. Pad each key on the right with one byte of 0s (KSV is already padded).
You should now have 1 x 8 byte KSV + 40 x 8 byte Keys.
Running the Reference Design (MicroBlaze)Use the following steps to execute the system using generated bitstream and software elf fromthe example design.
1. Launch the Xilinx System Debugger by selecting Start → All Programs → Xilinx Design Tools → Vivado <version> → Vivado <version> Tcl Shell.
2. In the Xilinx command shell window, change to the Example Design Project directory:
Running the Reference Design (A53 on ZynqUltraScale+ Devices)1. Launch the Xilinx System Debugger by selecting Start → All Programs → Xilinx Design Tools
→ Vivado <version> → Vivado <version> Tcl Shell.
2. In the Xilinx command shell window, change to the Example Design Project directory:
Video ResolutionsThe following figure shows the hardware setup for the AXI4-Stream video Interface. An HDMIsource connects to HDMI PHY Controller, which converts the HDMI Video into LINK DATA andsends to the HDMI RX Subsystem. Then, the HDMI RX Subsystem translates the LINK DATAinto AXI4-Stream Video and sends to the Test Pattern Generator. By setting the Test PatternGenerator to pass-through mode, the AXI4-Stream Video from the HDMI RX Subsystem ispassed to the HDMI TX Subsystem where it gets translated to LINK DATA again and sends backto the HDMI PHY Controller. The HDMI PHY Controller then converts it back to HDMI Videoand sends to the HDMI Sink.
Figure 20: Test Setup for AXI4-Stream Video Interface
HDMI RX Subsystem
HDMI TX Subsystem
HDMI PHY Controller
Zynq UltraScale+ / MicroBlaze
UART
I2C
TestPattern
Generator
AXI4-Stream Video
AXI-Lite
HDMI Source HDMI Sink
X23124-061620
For HDMI PHY Controller settings and PLL selections, see the HDMI PHY Controller LogiCORE IPProduct Guide (PG333).
The following tables show the video resolutions that were tested as part of the release fordifferent video formats.
Appendix A: Verification, Compliance, and Interoperability
DebuggingThis appendix includes details about resources available on the Xilinx Support website anddebugging tools.
If the IP requires a license key, the key must be verified. The Vivado® design tools have severallicense checkpoints for gating licensed IP through the flow. If the license check succeeds, the IPcan continue generation. Otherwise, generation halts with an error. License checkpoints areenforced by the following tools:
• Vivado Synthesis
• Vivado Implementation
• write_bitstream (Tcl command)
IMPORTANT! IP license level is ignored at checkpoints. The test confirms a valid license exists. It does notcheck IP license level.
Finding Help on Xilinx.comTo help in the design and debug process when using the subsystem, the Xilinx Support web pagecontains key resources such as product documentation, release notes, answer records,information about known issues, and links for obtaining further product support. The XilinxCommunity Forums are also available where members can learn, participate, share, and askquestions about Xilinx solutions.
DocumentationThis product guide is the main document associated with the subsystem. This guide, along withdocumentation related to all products that aid in the design process, can be found on the XilinxSupport web page or by using the Xilinx® Documentation Navigator. Download the XilinxDocumentation Navigator from the Downloads page. For more information about this tool andthe features available, open the online help after installation.
Answer RecordsAnswer Records include information about commonly encountered problems, helpful informationon how to resolve these problems, and any known issues with a Xilinx product. Answer Recordsare created and maintained daily ensuring that users have access to the most accurateinformation available.
Answer Records for this subsystem can be located by using the Search Support box on the main Xilinx support web page. To maximize your search results, use keywords such as:
• Product name
• Tool message(s)
• Summary of the issue encountered
A filter search is available after results are returned to further target the results.
Master AR for HDMI 2.1 RX Subsystem
AR: 72276
Technical SupportXilinx provides technical support on the Xilinx Community Forums for this LogiCORE™ IP productwhen used as described in the product documentation. Xilinx cannot guarantee timing,functionality, or support if you do any of the following:
• Implement the solution in devices that are not defined in the documentation.
• Customize the solution beyond that allowed in the product documentation.
• Change any section of the design labeled DO NOT MODIFY.
To ask questions, navigate to the Xilinx Community Forums.
Debug ToolsThere are many tools available to address HDMI 2.1 RX Subsystem design issues. It is importantto know which tools are useful for debugging various situations.
Vivado Design Suite Debug FeatureThe Vivado® Design Suite debug feature inserts logic analyzer and virtual I/O cores directly intoyour design. The debug feature also allows you to set trigger conditions to capture applicationand integrated block port signals in hardware. Captured signals can then be analyzed. Thisfeature in the Vivado IDE is used for logic debugging and validation of a design running in Xilinx®
devices.
The Vivado logic analyzer is used to interact with the logic debug LogiCORE IP cores, including:
• ILA 2.0 (and later versions)
• VIO 2.0 (and later versions)
See the Vivado Design Suite User Guide: Programming and Debugging (UG908).
Reference BoardsVarious Xilinx development boards support the HDMI 2.1 RX Subsystem. These boards can beused to prototype designs and establish that the subsystem can communicate with the system.
• UltraScale+ FPGA evaluation board
○ ZCU102
○ ZCU106
○ VCU118
Hardware DebugHardware issues can range from link bring-up to problems seen after hours of testing. Thissection provides debug steps for common issues. The Vivado debug feature is a valuableresource to use in hardware debug. The signal names mentioned in the following individualsections can be probed using the debug feature for debugging the specific problems.
General Checks• Ensure that all the timing constraints and all other constraints were met duringimplementation.
• Ensure that all clock sources are active and clean.
• If using MMCMs in the design, ensure that all MMCMs have obtained lock by monitoring thelocked port.
○ LED0 - HDMI 2.1 RX Subsystem lock (when the HDMI Example Design is used)
○ Use the debug port to check if there are link data driven to the HDMI PHY Controller core.
○ See the Debugging Appendix in the HDMI PHY Controller LogiCORE IP Product Guide(PG333), and ensure there is no problem with clocking issues.
Interface DebugAXI4-Lite InterfacesRead from a register that does not have all 0s as a default to verify that the interface isfunctional. Output s_axi_arready asserts when the read address is valid, and outputs_axi_rvalid asserts when the read data/response is valid. If the interface is unresponsive,ensure that the following conditions are met:
• The s_axi_aclk and aclk inputs are connected and toggling.
• The interface is not being held in reset, and s_axi_areset is an active-Low reset.
• The interface is enabled, and s_axi_aclken is active-High (if used).
• The main subsystem clocks are toggling and that the enables are also asserted.
• Add AXI4-Lite interface to ILA, and analysis data captured when triggering ats_axi_rvalid.
AXI4-Stream InterfacesIf data is not being transmitted or received, check the following conditions:
• If the transmit <interface_name>_tready is stuck Low following the<interface_name>_tvalid input being asserted, the subsystem cannot send data.
• If the receive <interface_name>_tvalid is stuck Low, the subsystem is not receivingdata.
• Check that the aclk inputs are connected and toggling.
• Check that the AXI4-Stream waveforms are being followed.
To ensure that the audio is working in the HDMI 2.1 RX Subsystem, the AXI4-Stream must beconstructed as described below.
The HDMI 2.1 RX Subsystem supports up to 32 audio channels. The audio data is transmittedthrough an AXI4-Stream audio interface, which is a customized AXI4-Stream protocol that isused to send audio samples with sideband signals defined in the AES3 specification.
The sub-frame format for audio sample is shown as follows.
Figure 21: Sub-Frame Format
A frame is uniquely composed of two sub-frames. The first sub-frame normally starts withpreamble X, and the second sub-frame always starts with preamble Y. However, every 192frames forms one Audio Block. And the first sub-frame in each Audio Block starts with apreamble Z. An illustration is shown as follows.
Figure 22: Audio Sub-Frames
In the case of more than 2 channels, every 2 channels are considered as a single AES3 audioblock. For example, using 8 audio channels, one audio block consists of 192*8 audio samples. Forthe first 8 samples of an audio block, the preamble for audio ch0, ch2, ch4, ch6 are Z. Inremaining part of audio block, the preamble for audio ch0, ch2, ch4, ch6 are X. The preambles foraudio ch1, ch3, ch5, ch7 are always Y through out of the whole audio block.
If 8 channel audio is enabled in your design, and only N Channels (where N is less than 8, forexample, 6) out of 8 channels carry valid audio data, for the unused channels, you must pack theaudio data with zeros and the sub-frame data allocation.
Device DriversThe HDMI 2.1 RX Subsystem driver abstracts the included supporting elements and provides youwith an API for control. The API can be easily integrated into your application thereby providingan out-of-the-box solution.
The subsystem driver is a bare-metal driver, which provides an abstracted view of the feature setprovided by each sub-core. It dynamically manages the data and control flow through theprocessing elements, based on the input/output stream configuration set at run time. Internally,it relies on sub-core drivers to configure the sub-core IP blocks.
ArchitectureThe subsystem driver provides an easy-to-use, well-defined API to help integrate the subsystemin an application without having to understand the underlying complexity of configuring eachand every sub-core.
The subsystem driver consists of the following:
• Subsystem layer: Queries exported hardware to determine the subsystem hardwareconfiguration and pull-in sub-core drivers, at build time. It abstracts sub-core drivers, whichinterface with hardware at register level, into a set of functional APIs. The subsystem driveruses these APIs to dynamically manage the data flow through processing elements.
• Sub-core drivers: Every included sub-core has a driver associated with it that provides APIs tointerface with the core hardware.
The following figure shows the HDMI 2.1 RX Subsystem architecture.
The HDMI 2.1 RX Subsystem is a MAC subsystem which works with a HDMI PHY Controller(PHY) to create a video connectivity system. The HDMI 2.1 RX Subsystem is tightly coupled withthe Xilinx HDMI PHY Controller, which itself is independent and offers flexible architecture withmultiple-protocol support. Both MAC and PHY are dynamically programmable through the AXI4-Lite interface.
Figure 24: MAC Interfaces with PHY
MAC(HDMI RX Subsystem)
PHY (HDMI PHY Controller)
Standard GT Interface
AXI4-LiteAXI4-Lite
X23895-042720
UsageThe HDMI 2.1 RX Subsystem provides a set of API functions for application code to use.Additionally, when the HDMI 2.1 RX Subsystem hardware interrupts are generated, thesubsystem driver is invoked to configure the system accordingly. The HDMI 2.1 RX Subsystemprovides a callback structure to hook up your own callback functions.
First, the video stream must be started in the application. Then, valid AUX data and audio datacan be inserted after the video is locked. However, because the application knows what videoformat is being sent and what audio format is embedded, the ACR number can be calculated andset before the audio stream is ready to be sent.
In the following sections, only HDMI related modules are covered. The user application needs totake care of system peripheral, such as timer, UART, external system clock generator, etc.
Note: Because the HDMI Transmit and Receive Subsystems have many common features, the HDMICommon Library is introduced for the purpose of defining common data structures which can be shared byboth subsystems.
HDMI RX Subsystem FlowThe HDMI 2.1 RX Subsystem in general responds to the following two events:
• HDMI Cable Detect (5V) from the source device
• HDMI Video Stream changes in the term of TMDS frequency change from the source device
Application Integration
The following figure shows example code to show how an HDMI 2.1 RX Subsystem can be usedin your application.
To integrate and use the HDMI 2.1 RX Subsystem driver in your application, the following stepsmust be followed:
1. Include the subsystem header file xv_hdmirxss1.h that defines the subsystem object.
2. Provide the storage for a subsystem driver instance in your application code. For example:
XV_HdmiRxSs1 HdmiRxSs1;
3. In the subsystem driver instance, there is a metadata structure to store the subsystemhardware configuration. Declare a pointer variable in the application code to point to theinstance:
XV_HdmiRxSs1_Config *XV_HdmiRxSs1_ConfigPtr;
4. Set the EDID parameter for the HDMI 2.1 RX Subsystem Subsystem.
5. For each subsystem instance, the data structures declared in the previous two steps need tobe initialized based on its hardware configuration, which is passed through metadatastructure from xparameters.h uniquely identified by device ID.
To initialize the subsystem, call the following two API functions:
XV_HdmiRxSs1_Config* XV_HdmiRxSs1_LookupConfig(u32 DeviceId); int XV_HdmiRxSs1_CfgInitialize(XV_HdmiRxSs1 *InstancePtr, XV_HdmiRxSs1_Config *CfgPtr, u32 EffectiveAddr);
The Device ID can be found in xparameters.h:
XPAR_[HDMI RX 2.1 Subsystem Instance Name in IPI]_DEVICE_ID
6. Each interrupt source has an associated ISR defined in the subsystem. Register the ISR withthe system interrupt controller and enable the interrupt.
1. Prepare the 256 bytes of EDID data and store in an array before calling the specified API function.
2. The EDID data is loaded into the HDMI 2.1 RX Subsystem during initialization. This is handled by thesubsystem driver, no user intervention is needed.
HDCP RX Overview
The HDMI 2.1 RX Subsystem driver is responsible for combining the HDCP 1.4 and HDCP 2.3driver APIs into a single common API for use by the user level application. When HDCP isenabled, the common HDCP driver ensures that only one is active at any given time.
HDCP RX Driver Integration
This section describes the steps required to initialize and run the HDCP RX. The applicationshould call the functions roughly in the order specified to ensure that the driver operatesproperly. When only a single HDCP protocol is enabled, either 1.4 or 2.3, a subset of the functioncalls might be needed.
1. Load the HDCP production keys into the HDMI subsystem. This function needs to be calledfor each key that is loaded. If HDCP is enabled all the keys must be loaded. Note that thebyte arrays used to store the key octet strings for HDCP are defined in big endian byte order.
Position in Bytes Size in Bytes Description0–39 40 Reserved
40–561 522 Device Public Certificate
562–901 340 Device Private Key1
Notes:1. The actual Private Key size is 320 bytes. The additional 20 bytes is for a hash code that can be used by the
software application to verify the keys before loading them. These additional bytes are not used by the HDCPdriver.
IMPORTANT! In an HDCP-enabled system, after the key management block is successfully initialized,a bit is set to block reading out the key again. The bit remains set until the device is reprogrammed.Therefore, the keys can only be read once during initialization.
2. Initialize the HDMI 2.1 RX Subsystem driver after the HDCP keys have been loaded.Initializing the subsystem starts the HDCP 1.4/2.3 drivers internally.
3. Connect the HDCP interrupt handlers to the interrupt controller interrupt ID:
• XV_HdmiRxSS1_HdcpIntrHandler
• XV_HdmiRxSS1_HdcpTimerIntrHandler
4. Set the HDCP user callback functions. These callback functions are optional and used tohook into the HDCP state machine and allow the user to take action at various stages of theHDCP protocol. If there is no use for the callback at the application level, then the callbackcan be left undefined.
5. Execute the poll function to run the HDCP state machine. This function checks to see whichHDCP protocol is enabled, and then execute only the active protocol. The call to this functioncan be inserted in the main loop of the user application and should execute continuously.Because the HDCP RX state machine is run using this poll function, it is important to ensurethat this function is given adequate CPU runtime, especially during authentication attempts.
• XV_HdmiRxSs1_HdcpPoll
6. Set the HDCP protocol capability to notify the upstream transmitter which protocols aresupported. Setting the HDCP protocol capability is optional and is used to override thedefault capability of the receiver. The default capability is set to both protocols. There areonly two valid capability options: both and none. Setting the capability to none disables theHDCP DDC slave device. Note that setting the protocol capability does not enable theprotocol. When the capability is changed, HPD should be immediately toggled to get theattention of the upstream transmitter.
• XV_HdmiRxSs1_HdcpSetCapability
○ XV_HDMIRXSS1_HDCP_NONE
○ XV_HDMIRXSS1_HDCP_BOTH
7. Check the status of authentication.
• XV_HdmiRxSs1_HdcpIsAuthenticated
8. Check the status of the cipher encryption. This is the instantaneous encryption status of thecipher and can change between subsequent frames.
9. Check the overall HDCP protocol status and log data. You can also set the level of detail forlog information reported.
• XV_HdmiRxSs1_HdcpInfo
• XV_HdmiRxSs1_SetInfoDetail
Integrate HDMI PHY Controller Driver for HDMI 2.1 RX SubsystemUse
Because the HDMI 2.1 RX Subsystem is closely coupled with the HDMI PHY Controller, thefollowing example code demonstrates how a HDMI PHY Controller can be used in yourapplication.
3. In the HDMI PHY Controller instance, there is a metadata structure to store the subsystemhardware configuration. Declare a pointer variable in the application code to point to theinstance:
XHdmiphy1_Config *XHdmiphy1CfgPtr;
4. For each HDMI PHY Controller instance, the above data structure needs to be initializedbased on its hardware configuration, which is passed through meta-structure fromxparameters.h uniquely identified by the device ID.
To initialize the , call the following two API functions:
2. Link Ready – Every time the PHY Controller is reconfigured, the link_clk is regenerated.An HDMI RX sub-core register bit (link status bit) reflects the change of link_clk status.When stable link_clk is detected, it is set to 1. When link_clk becomes unstable, it isset to 0. The Link Ready is an interrupt to detect the change of the link status bit.
a. Rising edge – Link is up
b. Falling edge – Link is down
3. Video Ready – This interrupt is generated by the HDMI RX sub-core to reflect the status ofthe received video stream.
a. Rising edge – Video Stream is stable (StreamUp)
b. Falling edge – Video Stream is not stable (StreamDown)
4. HDMI Receiver Auxiliary Infoframe Interrupt – This interrupt is generated when an AuxiliaryInfoframe is received.
5. HDMI Receiver Audio Infoframe Interrupt – This interrupt is generated when an AudioInfoframe is received.
6. HDCP1.4 Interrupt (only available when HDCP 1.4 is enabled in hardware)
7. HDCP 1.4 Timer Interrupt (only available when HDCP 1.4 is enabled in hardware)
8. FRL Interrupts
All FRL interrupts are triggered by the internal FRL timer interrupt. Then based on softwarestate machines and status, interrupts are triggered accordingly.
a. FRL Config interrupt
b. FRL Start interrupt
c. TMDS Config interrupt
9. VFP change – This interrupt is generated by the HDMI 2.1 RX Subsystem subcore whenvideo timing data is changed and the VTEM packet is present.
a. Rising edge – Video timing is changed
10. VTEM change – This interrupt is generated by the HDMI 2.1 RX Subsystem sub-core whenthe VTEM packet content is changed.
a. Rising edge – VTEM packet content is changed.
11. MTW Event – This interrupt is triggered at end of MTW window, when the Dynamic HDRinfo frame is present in the stream.
a. Rising edge – Dynamic HDR info frame received.
Application Callback Functions
The subsystem driver provides a mechanism for the application to register a user-definedfunction that gets called within an interrupt context.
This interrupt is triggered every time an HDMI RX cable connection or disconnection (HPD leveltransition) occurs. The callback function must perform the following:
1. Enable or disable the differential input clock buffer depending on whether cable connectionor disconnection occurs, respectively.
2. Clear HDMI PHY RX TMDS Clock ratio when cable is disconnected:
XV_Rx_Hdmiphy1Ptr->HdmiRxTmdsClockRatio = 0;
3. Reset and clear the connection related information in the HDMI 2.1 RX Interrupt handlinglayer data structure when cable is disconnected. Conversely, when the cable is connected,update and set the connection related information.
XV_HDMIRXSS1_HANDLER_AUX
This interrupt is triggered every time when an Auxiliary InfoFrame packet is received.
The callback function must retrieve the InfoFrame packet data to be used by the systemapplication.
XV_HDMIRXSS1_HANDLER_AUD
This interrupt is triggered every time an active audio stream is detected or the number of activeaudio channels changes.
The callback function can update the audio information to the application software.
Note: You can call function XV_HdmiRxSs1_GetAudioFormat in Audio interrupt callback.
• 1 - LPCM
• 2 - HBR
• 3 - 3D Audio
XV_HDMIRXSS1_HANDLER_LINKSTA
This interrupt is triggered every time a link status interrupt is received.
The callback function must reset the frequency of the PHY RX clock detector if a connectionexists and the RX GT in the ready state and link status maximum errors have occurred.
The callback function can update stream down information to the application software. Theapplication software might start a timer and put the system into standby mode if the HDMI 2.1RX Subsystem remains unlocked for a certain time.
XV_HDMIRXSS1_HANDLER_STREAM_INIT
This interrupt is triggered every time a stream is detected and the HDMI PHY Controller isstabilized for the HDMI 2.1 RX Subsystem to start stream locking.
The callback function must perform the following steps:
4. Set the video clock for the RX core FRL peripheral to 0.
XV_HdmiRx1_SetFrlVidClock(InstancePtr, Value)
XV_HDMIRXSS1_HANDLER_FRL_START
This interrupt is triggered every time the FRL training is Training state P and the stream is readyto [go to the idle state and/or] receive the incoming stream.
The callback function can update the application. The callback is used as a placeholder andperforms no operation.
XV_HDMIRXSS1_HANDLER_TMDS_CONFIG
This interrupt is triggered every time a the FRL training times out and the HDMI 2.1 RX goes tothe TMDS or the HDMI 2.1 trains in the legacy state to support incoming TMDS, HDMI 2.0stream.
The callback function must perform the following steps:
1. Update the application to configure the clock for the RX source.
This interrupt is triggered every time video timings (vertical front porch) are changed, and VRR isenabled in the VTEM packet. Use the following API to register callback functions and read theupdated video timing information.
This interrupt is triggered every time a VTEM packet is present in the stream and its contents arechanged from the previous VTEM packet. Use the following API to register the callback functionand read the updated VTEM information.
This interrupt is triggered at end of MTW window, when the Dynamic HDR info frame is presentin the stream. You must register the callback function to update the new buffer address andDynamic HDR information. The following APIs are provided to update the new buffer addressand Dynamic HDR information.
HDMI PHY Controller Interrupt Handlers for HDMI2.1 RX SubsystemThere are several interrupt handlers available in the HDMI PHY Controller driver to hook up withuser-defined callback functions to support the HDMI 2.1 RX Subsystem functionality. Theseinterrupt handlers are defined in xhdmiphy1.h:
where both Clock and LineRate are from the HDMI PHY Controller data structure.
Follow the steps in Chapter 6: Example Design chapter to create an example design, whichcontains all the procedures implemented and can serve as a reference for integrating the HDMI2.1 RX Subsystem into your system.
Example Application OverviewBecause the HDMI PHY Controller and HDMI 2.1 RX Subsystem are tightly coupled, an interruptcontrolling layer is introduced in the HDMI2.1 Example Application to make integration easier.
The following figure shows the HDMI 2.1 Example Application architecture, which is a layeredarchitecture implemented using the HDMI 2.1 subsystem APIs and interrupt callbacks.
Figure 27: HDMI 2.1 Example Application Architecture
HDMI 2.1 EXAMPLE APPLICATION
HDMI 2.1 RX Subsystem Driver
HDMI 2.1 RX Core driver
HDCP (1.4 & 2.3) drivers
HDMI 2.1 RX Subsystem Interrupt controller layer
Example Application (e.g. Pass-through/Colorbar/Independent TX RX)
X23119-081419
The example application is implemented in two layers:
• HDMI 2.1 RX Subsystem interrupt(s) controlling layer: The interrupt callbacks from the HDMI2.1 RX subsystem driver are handled and controlled in a state-machine based layer. Thisinterrupt controlling layer also controls the enabling and disabling of the HDMI PHY andHDCP.
• Example Application: The Example Application is the top layer which is built on top of thestate-machine based HDMI 2.1 Interrupt controlling layer. The Example Application handlesall system level control, such as:
○ Initialize the HDMI 2.1 RX Subsystem and HDMI PHY (use device IDs to do the binding)
○ Load HDCP keys from EEPROM
○ Process "SystemEvent" from the interrupt controlling layer.
HDMI 2.1 RX Subsystem Interrupt Controlling LayerThe following table shows the mapping between the HDMI 2.1 RX, HDMI 2.1 RX SS interruptsand HDMI 2.1 RX interrupt controlling layer events that trigger state transitions.
Table 35: Interrupt Sources and Application Interrupt Controlling State MachineLayer Mapping
XV_HDMIRXSS1_HANDLER_STREAM_INITNote: This callback function is not directlymapped to any interrupt source. Instead itis executed when the stream is detectedand the HDMI PHY Controller is stabilizedfor the HDMI 2.1 RX Subsystem to startstream locking.
XV_HDMIRXSS1_HANDLER_HDCP_AUTHENTICATENote: This callback function is not directlymapped to any interrupt source. Instead itis executed when the HDCP authenticationstate machine has reached theauthenticated state
The following figure shows the control flow of the HDMI 2.1 RX Subsystem interrupts receivedby the application. See the previous table for more details on the mapping of interrupts andevents. The event LABEL from the previous table is marked as the event cause of statetransitions in the following figure.
In the HDMI 2.1 RX Interrupt controlling layer each interrupt received from the HDMI 2.1 RXsubsystem has its corresponding state. This allows the application to track the last receivedinterrupt and control the behavior of HDMI 2.1 RX based on the next interrupt received. Theapplication controls the flow of HDMI 2.1 RX subsystem interrupts from the connection of theRX cable to the disconnection of the RX cable.
The control of flow and transition from one interrupt state to another can be modified toaccommodate a required level of leniency or strictness. The previous figure shows a minimalistand strict transition between the states.
The state transitions in the HDMI 2.1 RX interrupt controlling layer can be changed and updateddepending on the extent of strictness of leniency that is needed in serving the interrupts fromthe HDMI 2.1 RX SS. The application implements a formal and minimal flow control of theinterrupts.
The following is a description of the HDMI 2.1 RX states and transitions that are allowed on thestate.
• STATE CONNECTED – The state machine transitions to this state after receiving the connectinterrupt from the HDMI 2.1 RX sub-system. Ideally, the transition to this state should happenonly from the disconnected state.
• STATE FRL CONFIG - The state machine transitions to this state after receiving the frl configrequest interrupt from the HDMI 2.1 RX sub-system. The state machine transitions to thisstate from all states except disconnect. In case of multiple frl config requests, each interrupt isserviced exclusively.
• STATE TMDS CONFIG - The state machine transitions to this state after receiving the tmdsconfig request interrupt from the HDMI 2.1 RX sub-system. The state machine transitions tothis state from all states except disconnect. In case of multiple tmds config requests, eachinterrupt is serviced exclusively.
• STATE FRL START - The state machine transitions to this state after receiving the frl startinterrupt from the HDMI 2.1 RX sub-system. Ideally, the state machine should transition tothis state from the frl config states. FRL start received on any other states is ignored.
• XV_RX_HDMI_STATE_STREAMINITIALIZED - The state machine transitions to this state afterreceiving the Stream Init interrupt from the HDMI 2.1 RX sub-system. Ideally, you shouldexpect the state machine to transition to this state from the Tmds Config, Frl Config or FrlStart states.
• STATE STREAM ON - The state machine transitions to this state after receiving the stream upinterrupt from the HDMI 2.1 RX sub-system. Ideally, the state machine should transition tothis state from the stream Init state, however, it is possible to receive the stream up interrupton other states as well.
• STATE STREAM OFF - The state machine will transition to this state upon receiving thestream down interrupt from the HDMI 2.1 RX sub-system drivers. Transition to this state canhappen from any state.
• STATE DISCONNECTED – This is the default state to which the state machine is initialized.The state machine will transition to this state upon receiving the disconnect interrupt from theHDMI 2.1 RX sub-system drivers. Transition to this state must happen from every state.
Integration of HDMI 2.1 RX Interrupt ControllingLayerThe user can make use of the functions provided in the HDMI 2.1 RX interrupt controlling layerto register callbacks that can be used by the example application. These callbacks allow theapplication to directly interface with the HDMI 2.1 RX interrupt controlling layer at differentstages of the RX flow.
The following APIs can be used by the user to interface with the HDMI 2.1 RX interruptcontrolling layer.
• Initializing the application interrupt controlling layer,
Callbacks from HDMI 2.1 RX Interrupt ControllingLayerThe following table shows the interaction between the HDMI 2.1 RX Interrupt controlling layerand the pass-through application. The user can use or modify the callbacks as per theirrequirement.
XV_RX_TRIG_HANDLER_CONNECTION_CHANGE RX cable has been plugged in or plugged out; this allows thepass-through application to make a decision of bringingdown the pass-through system or wait for a stream on thereceiver
XV_RX_TRIG_HANDLER_STREAM_OFF The receiver has stopped receiving a stream
XV_RX_TRIG_HANDLER_STREAM_ON The RX stream is up; this allows the application to eithershow the information or pass the new stream values to atransmitter if applicable.
XV_RX_TRIG_HANDLER_AUDIOCONFIG Configure the system to receive audio,
XV_RX_TRIG_HANDLER_AUXEVENT Aux packets are received. Any operations can be doneincluding analyzing the packets, or copying them to abuffer, so they can be passed to a transmitter.
XV_RX_TRIG_HANDLER_CLKSRC_CONFIG Used to select the clock source for the HDMI 2.1 RXSubsystem.
Xilinx ResourcesFor support resources such as Answers, Documentation, Downloads, and Forums, see XilinxSupport.
Documentation Navigator and Design HubsXilinx® Documentation Navigator (DocNav) provides access to Xilinx documents, videos, andsupport resources, which you can filter and search to find information. To open DocNav:
• From the Vivado® IDE, select Help → Documentation and Tutorials.
• On Windows, select Start → All Programs → Xilinx Design Tools → DocNav.
• At the Linux command prompt, enter docnav.
Xilinx Design Hubs provide links to documentation organized by design tasks and other topics,which you can use to learn key concepts and address frequently asked questions. To access theDesign Hubs:
• In DocNav, click the Design Hubs View tab.
• On the Xilinx website, see the Design Hubs page.
Note: For more information on DocNav, see the Documentation Navigator page on the Xilinx website.
ReferencesThese documents provide supplemental material useful with this guide:
Appendix E: Additional Resources and Legal Notices
General updates • Added Native DE I/F support.• Added support of all CTA resolutions in AXI4-Stream I/F
Features Added Native DE support.
Introduction Added Supported Video Timing table.
Native Video (Vectored DE) Pinouts Added Native Video DE support.
Native Video (Vectored DE) Interface Added Native Video DE support.
Video Output Stream Interface Added new images
Device, Package, and Speed Grade Selections Updated table.
Summary Added note for example design 8 Channel Audio support.
Tested Video Resolutions for TMDS: RGB 4:4:4 and YCbCr4:4:4Tested Video Resolutions for TMDS: YCbCr 4:2:2Tested Video Resolutions for TMDS: YCbCr 4:2:0Tested Video Resolutions for FRL Mode - YCbCr422Tested Video Resolutions for FRL Mode - RGB, YCbCr444Tested Video Resolutions for FRL Mode - YCbCr420
Updated tables.
07/07/2021 Version 1.2
Initial Xilinx release. N/A
Please Read: Important Legal NoticesThe information disclosed to you hereunder (the "Materials") is provided solely for the selectionand use of Xilinx products. To the maximum extent permitted by applicable law: (1) Materials aremade available "AS IS" and with all faults, Xilinx hereby DISCLAIMS ALL WARRANTIES ANDCONDITIONS, EXPRESS, IMPLIED, OR STATUTORY, INCLUDING BUT NOT LIMITED TOWARRANTIES OF MERCHANTABILITY, NON-INFRINGEMENT, OR FITNESS FOR ANYPARTICULAR PURPOSE; and (2) Xilinx shall not be liable (whether in contract or tort, includingnegligence, or under any other theory of liability) for any loss or damage of any kind or naturerelated to, arising under, or in connection with, the Materials (including your use of theMaterials), including for any direct, indirect, special, incidental, or consequential loss or damage(including loss of data, profits, goodwill, or any type of loss or damage suffered as a result of anyaction brought by a third party) even if such damage or loss was reasonably foreseeable or Xilinxhad been advised of the possibility of the same. Xilinx assumes no obligation to correct anyerrors contained in the Materials or to notify you of updates to the Materials or to productspecifications. You may not reproduce, modify, distribute, or publicly display the Materialswithout prior written consent. Certain products are subject to the terms and conditions ofXilinx's limited warranty, please refer to Xilinx's Terms of Sale which can be viewed at https://
Appendix E: Additional Resources and Legal Notices
www.xilinx.com/legal.htm#tos; IP cores may be subject to warranty and support terms containedin a license issued to you by Xilinx. Xilinx products are not designed or intended to be fail-safe orfor use in any application requiring fail-safe performance; you assume sole risk and liability foruse of Xilinx products in such critical applications, please refer to Xilinx's Terms of Sale which canbe viewed at https://www.xilinx.com/legal.htm#tos.
AUTOMOTIVE APPLICATIONS DISCLAIMER
AUTOMOTIVE PRODUCTS (IDENTIFIED AS "XA" IN THE PART NUMBER) ARE NOTWARRANTED FOR USE IN THE DEPLOYMENT OF AIRBAGS OR FOR USE IN APPLICATIONSTHAT AFFECT CONTROL OF A VEHICLE ("SAFETY APPLICATION") UNLESS THERE IS ASAFETY CONCEPT OR REDUNDANCY FEATURE CONSISTENT WITH THE ISO 26262AUTOMOTIVE SAFETY STANDARD ("SAFETY DESIGN"). CUSTOMER SHALL, PRIOR TO USINGOR DISTRIBUTING ANY SYSTEMS THAT INCORPORATE PRODUCTS, THOROUGHLY TESTSUCH SYSTEMS FOR SAFETY PURPOSES. USE OF PRODUCTS IN A SAFETY APPLICATIONWITHOUT A SAFETY DESIGN IS FULLY AT THE RISK OF CUSTOMER, SUBJECT ONLY TOAPPLICABLE LAWS AND REGULATIONS GOVERNING LIMITATIONS ON PRODUCTLIABILITY.