product guide subsystem v1

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.

https://www.xilinx.com

https://www.xilinx.com/content/dam/xilinx/publications/about/Inclusive-terminology.pdf

Table of ContentsChapter 1: Introduction.............................................................................................. 4

Features........................................................................................................................................4IP Facts..........................................................................................................................................6

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

PG351 (v1.2) October 22, 2021 www.xilinx.comHDMI 2.1 RX Subsystem 2Send Feedback


https://www.xilinx.com/about/feedback/document-feedback.html?docType=Product_Guide&docId=PG351&Title=HDMI%202.1%20Receiver%20Subsystem%20v1.2&releaseVersion=1.2&docPage=2

Appendix A: Verification, Compliance, and Interoperability...............71Interoperability..........................................................................................................................71Hardware Testing...................................................................................................................... 71Video Resolutions......................................................................................................................72

Appendix B: Upgrading............................................................................................. 88Port Changes for 2021.2........................................................................................................... 88Port Changes for 2021.1........................................................................................................... 88Port Changes for 2020.2........................................................................................................... 88

Appendix C: Debugging.............................................................................................89Finding Help on Xilinx.com...................................................................................................... 89Debug Tools............................................................................................................................... 90Hardware Debug....................................................................................................................... 91Interface Debug........................................................................................................................ 92

Appendix D: Application Software Development....................................... 94Device Drivers............................................................................................................................ 94

Appendix E: Additional Resources and Legal Notices............................118Xilinx Resources.......................................................................................................................118Documentation Navigator and Design Hubs...................................................................... 118References................................................................................................................................118Revision History.......................................................................................................................119Please Read: Important Legal Notices................................................................................. 120




Chapter 1

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

• Supports L-PCM Audio up to 32 channels

• High bit rate (HBR) Audio

• 3D audio support

• Optional HDCP 2.3/1.4 decryption support

• Info frames

• Data Display Channel (DDC)

Chapter 1: Introduction




• Cable Detect at active-High or Low polarity

• Supports hot-plug detection at active-High or Low polarity

• Supports HDR video transport (Dynamic Range and Mastering info frames)

○ Traditional Gamma - SDR

○ Traditional Gamma - HDR

○ HDR 10 - SMPTE ST 2084

○ Hybrid Log Gamma (HLG)

• Supports enhanced gaming and media features

○ Variable Refresh Rate (VRR)

○ Quick Frame Transport (QFT)

○ Auto Low Latency Mode (ALLM)

○ Quick Media Switching (QMS)

• Supports AMD FreeSync VRR

• Supports Dynamic HDR

○ CTA 861-H HDR dynamic metadata extended info frame

• Supports HDR10+ Forum VSIF





IP FactsSubsystem Facts Table

Subsystem Specifics

Supported Device Family1 UltraScale+™ Families (GTHE4, GTYE4)2

Supported User Interfaces AXI4-Lite, AXI4-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.



https://www.xilinx.com/cgi-bin/docs/ndoc?t=ip+ru;d=v-hdmi-rxss1.html

https://www.xilinx.com/support/answers/72276.html


https://www.xilinx.com/support

https://www.xilinx.com/cgi-bin/docs/rdoc?v=2021.2;t=vivado+release+notes



Chapter 2

Overview

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.

Chapter 2: Overview


https://www.xilinx.com/support/documentation-navigation/design-hubs.html

https://www.xilinx.com/support/documentation-navigation/design-hubs.html



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

Chapter 2: Overview




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.

Chapter 2: Overview


https://www.xilinx.com/cgi-bin/docs/ipdoc?t=core+license

https://www.xilinx.com/getlicense

https://www.xilinx.com/about/contact.html


https://www.xilinx.com/products/intellectual-property/hdmi.html

https://www.xilinx.com/products/intellectual-property.html


https://www.digital-cp.com/licensee-list



Chapter 3

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.

Chapter 3: Product Specification


https://www.xilinx.com/cgi-bin/docs/ipdoc?c=v_hdmi_phy1;v=latest;d=pg333-hdmi-phy-controller.pdf



Table 1: Supported Video Timing

Video Interface Color SpacePixels Per Clock (PPC)

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.



http://www.hdmi.org/manufacturer/specification.aspx



Figure 1: HDMI 2.1 RX Subsystem AXI4-Stream Video Interface Block Diagram

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 interfaceAXI4-stream

CPU interfaceAXI4-lite

Audio Clock

Video in to AXI4-S

Bridge

AXI Remapper Rx

4-8 PPC Conversion

YUV 420 Conversion

4/8 PPC

Dynamic HDR Clock

Dynamic HDR InterfaceAXI4-MM

X24939-051221





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.

Related Information

Port Descriptions



https://www.xilinx.com/cgi-bin/docs/ipdoc?c=v_vid_in_axi4s;v=latest;d=pg043_v_vid_in_axi4s.pdf

https://www.xilinx.com/cgi-bin/docs/ipdoc?c=axi_ref_guide;v=latest;d=ug1037-vivado-axi-reference-guide.pdf

https://www.xilinx.com/cgi-bin/docs/ipdoc?c=axi_videoip;v=latest;d=ug934_axi_videoIP.pdf



HDMI 2.1 ReceiverFigure 3: HDMI 2.1 RX Subsystem Core Block Diagram

HDMI 2.0

Logic

Vid_in to

AXI4-S

FRL Scrambler

16b/18bDecoder

FRL Mapper

FRL Depacketi

zer

AXI4-Stream

HDCP(optional)

TMDS Scramb

ler

TMDS Decoder

PHY

RS FECDecoder

DisparityChecker

HDMI 2.1 ReceiverX23112-081419

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.



https://www.xilinx.com/cgi-bin/docs/ipdoc?c=hdcp;v=latest;d=pg224-hdcp.pdf

https://www.xilinx.com/cgi-bin/docs/ipdoc?c=hdcp22;v=latest;d=pg249-hdcp22.pdf



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.







Figure 7: Packet Body

Note:

• 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)

0x031 General Control

0x04 ACP Packet

0x05 ISRC1 Packet

0x06 ISRC2 Packet

0x07 One Bit Audio Sample Packet







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.

XHdmiC_Aux *XV_HdmiRxSs1_GetAuxiliary(XV_HdmiRxSs1 *InstancePtr);

where,

• InstancePtr is a pointer to the HDMI 2.1 RX Subsystem instance.

• It returns a pointer to a data structure contains the complete AUX packet.

The AUX packet data structure defined in the driver is:

typedef union { u32 Data; u8 Byte[4]; } XHdmiC_AuxHeader;typedef union { u32 Data[8]; u8 Byte[32];





} XHdmiC_AuxData;typedef struct { XHdmiC_AuxHeader Header; XHdmiC_AuxData Data;} XHdmiC_Aux;

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 list of available parser APIs are:

void XV_HdmiC_ParseAVIInfoFrame(XHdmiC_Aux *AuxPtr, XHdmiC_AVI_InfoFrame *infoFramePtr);void XV_HdmiC_ParseAudioInfoFrame(XHdmiC_Aux *AuxPtr, XHdmiC_AudioInfoFrame *AudIFPtr);int XV_HdmiC_VSIF_ParsePacket(XHdmiC_Aux *AuxPtr, XHdmiC_VSIF *VSIFPtr);void XV_HdmiC_ParseGCP(XHdmiC_Aux *AuxPtr, XHdmiC_GeneralControlPacket *GcpPtr);void XV_HdmiC_ParseDRMIF(XHdmiC_Aux *AuxPtr, XHdmiC_DRMInfoFrame *DRMInfoFrame);

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:

typedef struct XHDMIC_AVI_InfoFrame { unsigned char Version; XHdmiC_Colorspace ColorSpace; u8 ActiveFormatDataPresent; XHdmiC_BarInfo BarInfo; XHdmiC_ScanInfo ScanInfo; XHdmiC_Colorimetry Colorimetry; XHdmiC_PicAspectRatio PicAspectRatio; XHdmiC_ActiveAspectRatio ActiveAspectRatio;



https://cta.tech/



unsigned char Itc; XHdmiC_ExtendedColorimetry ExtendedColorimetry; XHdmiC_RGBQuantizationRange QuantizationRange; XHdmiC_NonUniformPictureScaling NonUniformPictureScaling; unsigned char VIC; XHdmiC_YccQuantizationRange YccQuantizationRange; XHdmiC_ContentType ContentType; XHdmiC_PixelRepetitionFactor PixelRepetition; u16 TopBar; u16 BottomBar; u16 LeftBar; u16 RightBar;} XHdmiC_AVI_InfoFrame;

Audio InfoFrame

Use the following code example for Audio InfoFrames:

typedef struct XHdmiC_Audio_InfoFrame { unsigned char Version; XHdmiC_AudioChannelCount ChannelCount; XHdmiC_AudioCodingType CodingType; XHdmiC_SampleSize SampleSize; XHdmiC_SamplingFrequency SampleFrequency; u8 CodingTypeExt; u8 ChannelAllocation; XHdmiC_LFEPlaybackLevel LFE_Playback_Level; XHdmiC_LevelShiftValue LevelShiftVal; unsigned char Downmix_Inhibit;} XHdmiC_AudioInfoFrame;

Vendor Specific InfoFrame (VSIF)

Use the following code example for VSIF:

typedef struct { u8 Version; u32 IEEE_ID; XHdmiC_VSIF_Video_Format Format; union { u8 HDMI_VIC; XHdmiC_3D_Info Info_3D; };} XHdmiC_VSIF;

Dynamic Range and Mastering InfoFrame

Use the following code example for Dynamic Range and Mastering (HDR) InfoFrames:

typedef struct XHdmiC_DRM_InfoFrame { XHdmiC_DRM_EOTF EOTF; XHdmiC_DRM_Static_Metadata_Descp_Id Static_Metadata_Descriptor_ID; struct { u16 x,y; } disp_primaries[3]; struct { u16 x,y; } white_point;





u16 Max_Disp_Mastering_Luminance; u16 Min_Disp_Mastering_Luminance; u16 Max_Content_Light_Level; u16 Max_Frame_Average_Light_Level;} XHdmiC_DRMInfoFrame;

General Control Packet

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.

typedef struct XHdmiC_GCP_Packet { unsigned char Set_AVMUTE; unsigned char Clear_AVMUTE; XHdmiC_ColorDepth ColorDepth; XHdmiC_PixelPackingPhase PixelPackingPhase; unsigned char Default_Phase;} XHdmiC_GeneralControlPacket;

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.

XVidC_VideoStream *XV_HdmiRxSs1_GetVideoStream(XV_HdmiRxSs1 *InstancePtr)

You must enable the interrupt handler by calling the following API.

void XV_HdmiRxSs1_VfpControl(XV_HdmiRxSs1 *InstancePtr, u8 Enable) // 0 – Disable , 1- Enable





XV_HDMIRXSS1_HANDLER_VRR_RDY

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.

XV_HdmiC_VrrInfoFrame *XV_HdmiRxSs1_GetVrrIf(XV_HdmiRxSs1 *InstancePtr)

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.



https://cta.tech/

https://hdr10plus.org/

https://www.etsi.org/deliver/etsi_ts/103400_103499/10343301/01.02.01_60/ts_10343301v010201p.pdf


https://www.itu.int/rec/T-REC-H.265



Dynamic HDR Info Structure

The Dynamic HDR info structure is as follows.

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.



https://ieeexplore.ieee.org/document/7513370









http://www.digital-cp.com/hdcp-specifications






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:

• AXI4-Lite CPU control interface (S_AXI_CPU_IN)

• AXI4-Stream Video interface (VIDEO_OUT)

• AXI4-Stream Audio interface (AUDIO_OUT)





https://www.xilinx.com/cgi-bin/docs/ndoc?t=data_sheets;d=ds922-kintex-ultrascale-plus.pdf

https://www.xilinx.com/cgi-bin/docs/ndoc?t=data_sheets;d=ds923-virtex-ultrascale-plus.pdf

https://www.xilinx.com/cgi-bin/docs/ndoc?t=data_sheets;d=ds925-zynq-ultrascale-plus.pdf

https://www.xilinx.com/cgi-bin/docs/ndoc?t=data_sheets;d=ds926-zynq-ultrascale-plus-rfsoc.pdf

https://www.xilinx.com/cgi-bin/docs/ndoc?t=data_sheets;d=ds931-artix-ultrascale-plus.pdf



Figure 8: HDMI 2.1 RX Subsystem Pinout – AXI4-Stream Video Interface

S_AXI_CPU_IN

SB_STATUS_IN

s_axi_cpu_aclks_axi_cpu_aresetns_axi_audio_aclks_axi_audio_aresetns_axi_video_aclks_axi_video_aresetn

video_clk

fidhpd

DDC_OUT

irq

LINK_DATA1_INLINK_DATA2_IN

LINK_DATA0_IN

link_clk acr_cts[19:0]acr_n[19:0]

acr_valid

AUDIO_OUTVIDEO_OUT

cable_detect

LINK_DATA3_IN

video_cke_out

frl_clk HDCP14_KEY_IN

hdcp14_irq

hdcp14_key_aresetnhdcp14_key_aclk

hdcp14_start_key_transmithdcp14_reg_key_sel[2:0]

hdcp14_timer_irq

hdcp22_irqhdcp22_timer_irq

M_HD_AXIm_hdr_axi_aresetn

m_hdr_axi_aclk

X23114-051121

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.





Figure 9: HDMI 2.1 RX Subsystem Pinout – Native Video Interface

S_AXI_CPU_IN

SB_STATUS_IN

s_axi_cpu_aclks_axi_cpu_aresetn

s_axi_audio_aclks_axi_audio_aresetn

video_clk

hpd

DDC_OUT

irq

LINK_DATA1_INLINK_DATA2_IN

LINK_DATA0_IN

link_clk acr_cts[19:0]acr_n[19:0]

acr_valid

AUDIO_OUT

VIDEO_OUT

cable_detect

LINK_DATA3_IN

video_cke_out

frl_clk HDCP14_KEY_IN

hdcp14_irq

hdcp14_key_aresetnhdcp14_key_aclk

hdcp14_start_key_transmithdcp14_reg_key_sel[2:0]

hdcp14_timer_irq

hdcp22_irqhdcp22_timer_irq

video_rst

NATIVE_VID_OUT

M_HDR_AXIm_hdr_axi_aresetnm_hdr_axi_aclk

X24941-051121

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.





Figure 10: HDMI 2.1 RX Subsystem Pinout – Native Video (Vectored DE) Interface

LINK_DATA0_IN

LINK_DATA1_IN

LINK_DATA2_IN

LINK_DATA3_IN

link_clk

S_AXI_CPU_IN

s_axi_cpu_aclk

s_axi_cpu_aresetn

s_axi_audio_aclk

s_axi_audio_aresetn

M-hdr_axi_aresetn

M_HDR_AXI

m_hdr_axi_aclk

video_clk

frl_clk

SB_STATUS_IN

cable_detect

DDC_OUT

acr_cts[19:0]

acr_n[19:0]

acr_valid

hpd

irq

video_hs_arb[PPC-1:0]

video_vs_arb[PPC-1:0]

video_field_arb

video_cke_out

video_rst

hdcp14_key_arsetn

hdcp14_reg_key_sel[2:0]

hdcp14_timer_irq

hdcp14_start_key_transmit

hdcp14_irq

HDCP14_KEY_IN

hdcp22_timer_irq

AUDIO_OUT

hdcp22_irq

video_data_arb[video_data_width-1:0]

video_de_arb[PPC-1:0]

hdcp14_key_aclk

X25741-091621

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

S_AXI_CPU_IN_awaddr I 17 or 19 Write address





Table 4: CPU Interface Ports (cont'd)

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

s_axis_video_aresetn I 1 Reset (Active-Low)

VIDEO_OUT_tdata O (int((3*BPC*PPC+7)/8))*8 Data

VIDEO_OUT_tlast O 1 End of line

VIDEO_OUT_tready I 1 Ready

VIDEO_OUT_tuser O 1 Start of frame





Table 5: AXI4-Stream Video Interface (cont'd)

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_OUT_tid O 5 Channel ID

AUDIO_OUT_tready I 1 Ready

AUDIO_OUT_tvalid O 1 Valid





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).

Table 10: Dynamic HDR Memory Mapped AXI4 Interface

Name I/O Width Descriptionm_hdr_axi_aresetn I 1 Reset (Active-Low)

m_hdr_axi_aclk I 1 Clock for M_HDR_AXIinterface.

M_HDR_AXI_* AXI4-M Address and data width are64

See the Vivado Design Suite:AXI Reference Guide (UG1037)for the description of theAXI4 signals.

HDMI Link Input InterfaceThe following table shows the HDMI Link interface signals. This interface runs at the link_clkclock rate.








Table 11: HDMI Link Interface

Name I/O Width Descriptionlink_clk I 1 Link clock

LINK_DATA0_IN_tdata Input 40 Link data 0

LINK_DATA0_IN_tvalid Input 1 Link Data 0 Valid







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

HDCP_KEY_IN_tlast I 1 End of key data

HDCP_KEY_IN_tready O 1 Ready

HDCP_KEY_IN_tuser I 8 Start of key data

HDCP_KEY_IN_tvalid I 1 Valid

hdcp14_key_aclk O 1 AXI4-Stream clock





Table 13: HDCP 1.4 Key Input Interface (cont'd)

Name I/O Width Descriptionhdcp14_key_aresetn O 1 Reset (Active-Low)

hdcp14_start_key_transmit O 1 Start key transmit

hdcp14_reg_key_sel O 3 Key select

HDCP 2.3 Interrupt OutputsThe following table shows the signals for HDCP 2.3 interrupt output ports.

Table 14: HDCP 2.3 Interrupt Output Interface

Name I/O Width Descriptionhdcp22_irq O 1 HDCP 2.3 interrupt

hdcp22_timer_irq O 1 HDCP 2.3 timer interrupt

HDCP 1.4 Interrupt OutputsThe following table shows the signals for HDCP 1.4 interrupt output ports.

Table 15: HDCP 1.4 Interrupt Output Interface

Name Direction Width DescriptionHdcp14_irq Output 1 HDCP 1.4 interrupt

Hdcp14_timer_irq Output 1 HDCP 1.4 timer interrupt

Miscellaneous SignalsThe following table shows the miscellaneous signals.

Table 16: Miscellaneous Signals

Name I/O Width Descriptionhpd O 1 If XGUI option: Hot Plug Detect active-High (Default)

0 - Hot Plug Detect is released1 - Hot Plug Detect is asserted

If XGUI option: Hot Plug Detect active-Low1

0 - Hot Plug Detect is asserted1 - Hot Plug Detect is released





Table 16: Miscellaneous Signals (cont'd)

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.

Related Information

ClockingResets





Chapter 4

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.

Figure 11: Audio Cycle

Chapter 4: Designing with the Subsystem




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

16

8 [7:0]

10 [9:0]

12 [11:0]

16 [15:0]

12

8 [7:0]

10 [9:0]

12 [11:0]

16 [15:4]





Table 18: Max Bits Per Component Support (cont'd)

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)

Y007 Cb006 Y006 Y005 Cb004 Y004 Y003 Cb002 Y002 Y001 Cb000 Y000

Y107 Cr006 Y106 Y105 Cr004 Y104 Y103 Cr002 Y102 Y101 Cr000 Y100

YUV420 8bits Line 0

YUV420 8bits Line 1

191 176 160 144 128 112 96 80 64 48 32 16 0X25744-091621

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

Zynq UltraScale+Virtex UltraScale+Kintex UltraScale+Artix UltraScale+

-1LV, -2LV CPLL,QPLL

325 MHz 300 MHz 300 MHz 300 MHz

-1, -1L6 CPLL 325 MHz 300 MHz 375 MHz 300 MHz

QPLL 380 MHz 375 MHz 375 MHz 300 MHz

-2, -2L, -3 CPLL,QPLL

450 MHz 400 MHz 375 MHz 300 MHz

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).

= 1/10 data rate(for data rates < 3.4 Gb/s)

Data rate = 2.97 Gb/sTMDS clock = 2.97/10 = 297 MHz

= 1/40 data rate(for data rates > 3.4 Gb/s)

Data rate = 5.94 Gb/sTMDS clock = 5.94/40 = 148.5 MHz






Table 21: HDMI Clocking (TMDS) (cont'd)

Clock Function Freq/Rate Example1

Data

This is the actual data rateclock. This clock is notused in the system. It isonly listed to illustrate theclock relations.

= TMDS clock(for data rates < 3.4 Gb/s)

Data rate = 2.97 Gb/sData clock = TMDS clock * 1 = 297 MHz

= TMDS clock * 4(for data rates > 3.4 Gb/s)

Data rate = 5.94 Gb/sData clock = TMDS clock * 4 = 594 MHzTMDS clock = 148.5 MHz

LinkClock used for datainterface between theHDMI PHY layer moduleand subsystem

clock=data clock/4

TMDS clock = 297 MHzData clock = 297 MHzLink clock = 297 MHz/4 = 74.25 MHzData clock = 594 MHzLink clock = 594 MHz/4 = 148.5 MHz

Pixel

This is the internal pixelclock. This clock is notused in the system. It isonly listed to illustrate theclock relations.

For 8 bpc pixel clock = data clockFor 10 bpc pixel clock = data clock/1.25For 12 bpc pixel clock = data clock/1.5For 16 bpc pixel clock = data clock/2

Data clock = 297 MHzFor 8 bpc pixel clock = 297 MHzFor 10 bpc pixel clock = 297/1.25 = 237.6MHzFor 12 bpc pixel clock = 297/1.5 = 198MHzFor 16 bpc pixel clock = 297/1.5 = 148.5MHz

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

(Hz)8kp30 9000 7680 4400 4320 30







The pixel clock represents the total number of pixels that need to be sent every second.

Therefore, for TMDS mode, the following calculation is used.

Pixel clock = Htotal × Vtotal × Frame Rate = 9000 x 4400 x 30 = 1,188,000,000 = 1188 MHzVideo clock = (Pixel clock)/PPC = 1188/4 = 297 MHzData clock = (Pixel clock) x BPC/8 = 1188 x 8/8 = 1188 MHzLink clock = (Data clock)/PPC = 1188/4 = 297 MHz

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.






ResetsThe subsystem has one reset input for each of the AXI4-Lite and AXI4-Stream interfaces:

• s_axi_cpu_areset: Active-Low AXI4-Lite reset

• s_axis_video_aresetn: Active-Low AXI4-Stream Video interface reset

• s_axis_audio_aresetn: Active-Low AXI4-Stream Audio interface reset

• m_hdr_axi_aresetn: Active-Low Dynamic HDR memory mapped AXI4 interface reset.

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.





Chapter 5

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.

Chapter 5: Design Flow Steps


https://www.xilinx.com/cgi-bin/docs/rdoc?v=latest;d=ug994-vivado-ip-subsystems.pdf

https://www.xilinx.com/cgi-bin/docs/rdoc?v=latest;d=ug896-vivado-ip.pdf

https://www.xilinx.com/cgi-bin/docs/rdoc?v=latest;d=ug910-vivado-getting-started.pdf




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)).





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.






Figure 18: Video Bridge Tab

The parameter on the Video Bridge tab is as follows:

• FIFO Depth: Specifies the number of locations in the input FIFO. The allowable values are 32,1024, 2048, 4096, and 8192.

Example Design Tab (AXI4-Stream Interface Only)The Example Design tab is shown in the following figure.

Figure 19: Example Design Tab





• 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)

C_INCLUDE_HDCPfalsetrue

Exclude

Number of pixels per clock on Video Interface48

C_INPUT_PIXELS_PER_CLOCK48

8

Max bits per component8101216

C_MAX_BITS_PER_COMPONENT8101216

8

Hot Plug Detect ActiveHighLow

C_HPD_INVERTHighLow

High

Cable Detect ActiveHighLow

C_CD_INVERTHighLow

High






Table 24: Vivado IDE Parameter to User Parameter Relationship (cont'd)

Vivado IDE Parameter/Value User Parameter/Value Default ValueEDID RAM Size

25651210244096

C_EDID_RAM_SIZE25651210244096

256

Enable Dynamic HDR Support10

C_DYNAMIC_HDR10

0

Video Bridge

FIFO Depth321024204840968192

C_ADDR_WIDTH321024204840968192

1024

Example Design

TX PLL TypeCPLLQPLL01(GTHE4/GTYE4)

C_EXDES_TX_PLL_SELECTION06

6 (GTHE4/GTYE4)

RX PLL TypeCPLLQPLL01(GTHE4/GTYE4)

C_EXDES_RX_PLL_SELECTION06

0 (GTHE4/GTYE4)

Output GenerationFor details, see the Vivado Design Suite User Guide: Designing with IP (UG896).

Constraining the SubsystemThis section contains information about constraining the subsystem in the Vivado Design Suite.






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.

create_clock -name s_axi_cpu_aclk -period 10.0 [get_ports s_axi_cpu_aclk]create_clock -name s_axis_audio_aclk -period 10.0 [get_ports s_axis_audio_aclk]create_clock -name video_clk -period 2.5 [get_ports video_clk]create_clock -name s_axis_video_aclk -period 2.5 [get_ports s_axis_video_aclk]create_clock -name link_clk -period 3.333 [get_ports link_clk]create_clock -name frl_clk -period 2.222 [get_ports frl_clk]create_clock -name m_hdr_axi_clk-period 3.333 [get_ports m_hdr_axi_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

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

Zynq®

UltraScale+™-1LV, -2LV CPLL,

QPLLNot Supported Supported

-1, -1L4 CPLL Not Supported Supported

QPLL NotSupported

Supported


Supported







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,



QPLL NotSupported

Supported


Supported

Virtex®

UltraScale+™-2LV CPLL,


-14 CPLL Not Supported Supported

QPLL NotSupported

Supported


Supported

Artix UltraScale+ -1LV CPLL,QPLL

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).








Chapter 6

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

ZCU102/ZCU106 HDMI 2.1 FMC + Mezzanines A53 Pass-through Passthrough_A53

VCU118 HDMI 2.1 FMC + Mezzanines MicroBlaze™ Pass-through Passthrough_Microblaze

ZCU106 HDMI 2.1 FMC + Mezzanines A53 Pass-Through withAdvance Features Passthrough_A53

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.

Chapter 6: Example Design


https://us.teldevice.com/product/tb-fmch-vfmc-hdmi/

https://us.teldevice.com/product/tb-fmch-vfmc-hdmi/



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



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.





3. Set the desired Project Name and select Next.

4. Select Create from hardware specification (XSA) and select Next.





5. Select the generated XSA from the HDMI 2.1 Example Design, and select Finish.

6. Build/Generate the platform - Right-click Platform and select Build Project.





7. At the platform.spr page, select Board Support Package under the standalone, and expandthe Peripheral Drivers.

8. Locate v_hdmi_rx_ss1 or v_hdmi_tx_ss1, and select Import Examples.





9. An Import Examples window opens with a list of applications. Select the respectiveapplication and click OK.





10. Build the application.

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.





Formatting HDCP Keys for HDCP 1.x

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:

Vivado% cd ./<IP instance name>_ex

3. Invoke Xilinx System Debugger (xsdb).

Vivado% xsdb

4. Establish connections to debug targets.

xsdb% connect

5. Download the bitstream to the FPGA.

xsdb% fpga -file ./<IP instance name>_ex.runs/impl_1/exdes_wrapper.bit

6. Set the target processor.

xsdb% target 1* xcvu9p 2 MicroBlaze Debug Module at USER2 3 MicroBlaze #0 (Running)xsdb% target -set 3





7. Download the software .elf to the FPGA.

xsdb% dow ./<vitis_workspace>/<application_name>_1/Debug/<application_name>_1.elf

8. Run the software.

xsdb% stopxsdb% rstxsdb% con

9. Exit the XSDB command prompt.

xsdb% exit

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:

Vivado% cd ./<IP instance name>_ex

3. Invoke Xilinx System Debugger (xsdb).

Vivado% xsdb

4. Establish connections to debug targets.

xsdb% connect

5. List all available JTAG targets.

xsdb% targets 1 PS TAP 2 PMU 3 PL 4 PSU 5 RPU (Reset) 6 Cortex-R5 #0 (RPU Reset) 7 Cortex-R5 #1 (RPU Reset) 8 APU 9* Cortex-A53 #0 (Running) 10 Cortex-A53 #1 (Power On Reset) 11 Cortex-A53 #2 (Power On Reset) 12 Cortex-A53 #3 (Power On Reset)

6. Download the bitstream to the PL.

xsdb% target -set 3 (PL)xsdb% fpga -file ./<IP instance name>_ex.runs/impl_1/exdes_wrapper.bitxsdd% after 2000





7. Set the target processor.

xsdb% target -set 9 (Cortex-A53 #0)xsdb% rst -processorxsdb% dow ./<vitis_workspace>/<platform_name>/export/<platform_name>/sw/<platform_name>/boot/fsbl.elfxsdb% after 1000xsdb% conxsdb% after 1000xsdb% stopxsdb% after 1000

8. Download the software .elf to the PS.

xsdb% dow ./<vitis_workspace>/<application_name>_1/Debug/<application_name>_1.elf

9. Run the software.

xsdb% con

10. Exit the XSDB command prompt.

xsdb% exit





Appendix A

Verification, Compliance, andInteroperability

InteroperabilityInteroperability tests for the HDMI 2.1 RX Subsystem have been conducted with the followinghardware setup.

Hardware TestingThe HDMI 2.1 RX Subsystem has been validated using

• Virtex® UltraScale+™ FPGA Evaluation Kit (VCU118) and HDMI 2.1 FMC + Mezzanine cards

• Zynq UltraScale+ MPSoC ZCU106 Evaluation Kit and HDMI 2.1 FMC + Mezzanine cards

• Zynq UltraScale+ MPSoC ZCU102 Evaluation Kit and HDMI 2.1 FMC + Mezzanine cards

This release is tested for FRL with the following source devices:

• QD980B

• Nvidia GEFORCE RTX 3080 graphics card (https://www.nvidia.com/en-in/geforce/graphics-cards/30-series/rtx-3080/)

• AMD Radeon RX 6700 XT (https://www.amd.com/en/products/graphics/amd-radeon-rx-6700-xt)

• Club-3D DisplayPort™ 1.4 to HDMI™ 4K120 Hz HDR Active adapter M/F (https://www.club-3d.com/en/detail/2496/displayport_1.4_to_hdmi_4k120hz_hdr_active_adapter_m-f/)

• Sony PlayStation 5

• Xbox One Series X

Note: HDMI 2.1 FRL Mode is tested with Belkin 48 Gb/s HDMI 2.1 Ultra High Speed HDMI (Category 3)cable.

Appendix A: Verification, Compliance, and Interoperability


https://www.nvidia.com/en-in/geforce/graphics-cards/30-series/rtx-3080

https://www.nvidia.com/en-in/geforce/graphics-cards/30-series/rtx-3080

https://www.amd.com/en/products/graphics/amd-radeon-rx-6700-xt

https://www.amd.com/en/products/graphics/amd-radeon-rx-6700-xt

https://www.club-3d.com/en/detail/2496/displayport_1.4_to_hdmi_4k120hz_hdr_active_adapter_m-f/





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.






Tested Video Resolutions for TMDS: RGB 4:4:4 andYCbCr 4:4:4Table 28: Tested Video Resolutions for TMDS: RGB 4:4:4 and YCbCr 4:4:4

Resolution VICColor Depth

8 10 12 165120x2160p30 123 TESTED TESTED TESTED NOT SUPPORTED

5120x2160p25 122 TESTED TESTED TESTED NOT SUPPORTED


4096x2160p60 102 TESTED NOT SUPPORTED NOT SUPPORTED NOT SUPPORTED



4096x2160p30 100 TESTED TESTED TESTED TESTED
































Table 28: Tested Video Resolutions for TMDS: RGB 4:4:4 and YCbCr 4:4:4 (cont'd)


8 10 12 161280x720p50 19 TESTED TESTED TESTED TESTED














720x576p @ 100Hz

42,43 TESTED TESTED TESTED TESTED

720x576p @ 200Hz



720x480p @119.88/120 Hz


720x480p @239.76/240 Hz



1440x576p @ 50Hz


1440x480p @59.94/60 Hz


720(1440)x288p @50 Hz


720(1440)x240p @59.94/60 Hz


2880x576p @ 50Hz


2880x480p @59.94/60 Hz


2880x288p @ 50Hz


2880x240p @59.94/60 Hz


1920x1080i120 46 TESTED TESTED TESTED TESTED






Table 28: Tested Video Resolutions for TMDS: RGB 4:4:4 and YCbCr 4:4:4 (cont'd)


8 10 12 161920x1080i60 5 TESTED TESTED TESTED TESTED


1920x1080i50(1250)

39 TESTED TESTED TESTED TESTED

720(1440)x480i @59.94/60 Hz


720(1440)x576i @50 Hz


720(1440)x576i @100 Hz


720(1440)x480i @119.88/120 Hz


2880x480i @59.94/60 Hz


2880x576i @ 50 Hz 25,26 TESTED TESTED TESTED TESTED

vgap60 NA TESTED TESTED TESTED TESTED

svgap60 NA TESTED TESTED TESTED TESTED

xgap60 NA TESTED TESTED TESTED TESTED

sxgap60 NA TESTED TESTED TESTED TESTED

wxgap60 NA TESTED TESTED TESTED TESTED

wxga+p60 NA TESTED TESTED TESTED TESTED

uxgap60 NA TESTED TESTED TESTED TESTED

wuxgap60 NA TESTED TESTED TESTED TESTED

wsxgap60 NA TESTED TESTED TESTED TESTED

Notes:1. Not all resolutions can be supported due to HDMI PHY limitation. For details, refer to the HDMI PHY Controller

LogiCORE IP Product Guide (PG333).

Tested Video Resolutions for TMDS: YCbCr 4:2:2Table 29: Tested Video Resolutions for TMDS: YCbCr 4:2:2


125120x2160p30 123 TESTED

5120x2160p25 122 TESTED

5120x2160p24 121 TESTED

4096x2160p60 102 TESTED

4096x2160p50 101 TESTED

4096x2160p48 115 TESTED






Table 29: Tested Video Resolutions for TMDS: YCbCr 4:2:2 (cont'd)


124096x2160p30 100 TESTED

4096x2160p25 99 TESTED

4096x2160p24 98 TESTED

3840x2160p60 97 TESTED

3840x2160p50 96 TESTED

3840x2160p48 114 TESTED

3840x2160p30 95 TESTED

3840x2160p25 94 TESTED

3840x2160p24 93 TESTED

1920x1080p120 63 TESTED

1920x1080p100 64 TESTED

1920x1080p60 16 TESTED

1920x1080p50 31 TESTED

1920x1080p48 111 TESTED

1920x1080p30 34 TESTED

1920x1080p25 33 TESTED

1920x1080p24 32 TESTED

2560x1080p120 92 TESTED

2560x1080p100 91 TESTED

2560x1080p60 90 TESTED

2560x1080p50 89 TESTED

2560x1080p48 113 TESTED

2560x1080p30 88 TESTED

2560x1080p25 87 TESTED

2560x1080p24 86 TESTED

1280x720p120 47 TESTED

1280x720p100 41 TESTED

1280x720p60 4 TESTED

1280x720p50 19 TESTED

1280x720p48 108 TESTED

1280x720p30 62 TESTED

1280x720p25 66 TESTED

1280x720p24 65 TESTED

1680x720p120 85 TESTED

1680x720p100 84 TESTED

1680x720p60 83 TESTED

1680x720p50 82 TESTED

1680x720p48 110 TESTED







121680x720p30 81 TESTED

1680x720p25 80 TESTED

1680x720p24 79 TESTED


720x576p @ 100 Hz 42,43 TESTED

720x576p @ 200 Hz 52,53 TESTED

720x480p60 2 TESTED

720x480p @ 119.88/120 Hz 48,49 TESTED

720x480p @ 239.76/240 Hz 56,57 TESTED

640x480p60 1 TESTED

1440x576p @ 50 Hz 29,30 TESTED

1440x480p @ 59.94/60 Hz 14,15 TESTED

720(1440)x288p @ 50 Hz 23,24 TESTED

720(1440)x240p @ 59.94/60 Hz 8,9 TESTED

2880x576p @ 50 Hz 37,38 TESTED

2880x480p @ 59.94/60 Hz 35,36 TESTED

2880x288p @ 50 Hz 27,28 TESTED

2880x240p @ 59.94/60 Hz 12,13 TESTED

1920x1080i120 46 TESTED

1920x1080i100 40 TESTED

1920x1080i60 5 TESTED

1920x1080i50 20 TESTED

1920x1080i50 (1250) 39 TESTED

720(1440)x480i @ 59.94/60 Hz 6,7 TESTED

720(1440)x576i @ 50 Hz 21,22 TESTED

720(1440)x576i @ 100 Hz 44,45 TESTED

720(1440)x480i @ 119.88/120 Hz 50,51 TESTED

2880x480i @ 59.94/60 Hz 10,11 TESTED

2880x576i @ 50 Hz 25,26 TESTED

Tested Video Resolutions for TMDS: YCbCr 4:2:0Table 30: Tested Video Resolutions for TMDS: YCbCr 4:2:0


8 10 12 167680x4320p30 196 TESTED NOT SUPPORTED NOT SUPPORTED NOT SUPPORTED

























1440x576p @ 50Hz


1440x480p @59.94/60 Hz


Tested Video Resolutions for FRL Mode - YCbCr422

Table 31: FRL Mode - YCbCr422


1210240x4320p30 212 TESTED

10240x4320p25 211 TESTED

10240x4320p24 210 TESTED

7680x4320p30 196 TESTED

7680x4320p25 195 TESTED

7680x4320p24 194 TESTED

5120x2160p120 193 TESTED

5120x2160p100 127 TESTED

5120x2160p60 126 TESTED





Table 31: FRL Mode - YCbCr422 (cont'd)


125120x2160p50 125 TESTED

5120x2160p48 124 TESTED

5120x2160p30 123 TESTED

5120x2160p25 122 TESTED

5120x2160p24 121 TESTED

4096x2160p120 219 TESTED

4096x2160p100 218 TESTED

4096x2160p60 102 TESTED

4096x2160p50 101 TESTED

4096x2160p48 115 TESTED

4096x2160p30 100 TESTED

4096x2160p25 99 TESTED

4096x2160p24 98 TESTED

3840x2160p120 118 TESTED

3840x2160p100 117 TESTED

3840x2160p60 97 TESTED

3840x2160p50 96 TESTED

3840x2160p48 114 TESTED

3840x2160p30 95 TESTED

3840x2160p25 94 TESTED

3840x2160p24 93 TESTED

1920x1080p120 63 TESTED

1920x1080p100 64 TESTED

1920x1080p60 16 TESTED

1920x1080p50 31 TESTED

1920x1080p48 111 TESTED

1920x1080p30 34 TESTED

1920x1080p25 33 TESTED

1920x1080p24 32 TESTED

2560x1080p120 92 TESTED

2560x1080p100 91 TESTED

2560x1080p60 90 TESTED

2560x1080p50 89 TESTED

2560x1080p48 113 TESTED

2560x1080p30 88 TESTED

2560x1080p25 87 TESTED

2560x1080p24 86 TESTED

1280x720p120 47 TESTED







121280x720p100 41 TESTED


1280x720p50 19 TESTED

1280x720p48 108 TESTED

1280x720p30 62 TESTED

1280x720p25 66 TESTED

1280x720p24 65 TESTED

1680x720p120 85 TESTED

1680x720p100 84 TESTED

1680x720p60 83 TESTED

1680x720p50 82 TESTED

1680x720p48 110 TESTED

1680x720p30 81 TESTED

1680x720p25 80 TESTED

1680x720p24 79 TESTED


720x576p @ 100 Hz 42, 43 TESTED

720x576p @ 200 Hz 52, 53 TESTED

720x480p60 2 TESTED

720x480p @ 119.88/120 Hz 48, 49 TESTED

720x480p @ 239.76/240 Hz 56, 57 TESTED

640x480p60 1 TESTED

1440x576p @ 50 Hz 29, 30 TESTED

1440x480p @ 59.94/60 Hz 14, 15 TESTED

720(1440)x288p @ 50 Hz 23, 24 TESTED

720(1440)x240p @ 59.94/60 Hz 8,9 TESTED

2880x576p @ 50 Hz 37, 38 TESTED

2880x480p @ 59.94/60 Hz 35, 36 TESTED

2880x288p @ 50 Hz 27, 28 TESTED

2880x240p @ 59.94/60 Hz 12, 13 TESTED

1920x1080i120 46 TESTED

1920x1080i100 40 TESTED

1920x1080i60 5 TESTED

1920x1080i50 20 TESTED

1920x1080i50 (1250) 39 TESTED

720(1440)x480i @ 59.94/60 Hz 6, 7 TESTED

720(1440)x576i @ 50 Hz 21, 22 TESTED

720(1440)x576i @ 100 Hz 44, 45 TESTED







12720(1440)x480i @ 119.88/120 Hz 50, 51 TESTED

2880x480i @ 59.94/60 Hz 10, 11 TESTED

880x576i @ 50 Hz 25, 26 TESTED

Tested Video Resolutions for FRL Mode - RGB,YCbCr444Table 32: FRL Mode - RGB, YCbCr444
































Table 32: FRL Mode - RGB, YCbCr444 (cont'd)











































Table 32: FRL Mode - RGB, YCbCr444 (cont'd)


8 10 12 16720x576p @ 100

Hz42,43 TESTED TESTED TESTED TESTED

720x576p @ 200Hz



720x480p @119.88/120 Hz


720x480p @239.76/240 Hz



1440x576p @ 50Hz


1440x480p @59.94/60 Hz


720(1440)x288p @50 Hz


720(1440)x240p @59.94/60 Hz


2880x576p @ 50Hz


2880x480p @59.94/60 Hz


2880x288p @ 50Hz


2880x240p @59.94/60 Hz






1920x1080i50(1250)

39 TESTED TESTED TESTED TESTED

720(1440)x480i @59.94/60 Hz


720(1440)x576i @50 Hz


720(1440)x576i @100 Hz


720(1440)x480i @119.88/120 Hz


2880x480i @59.94/60 Hz


2880x576i @ 50 Hz 25,26 TESTED TESTED TESTED TESTED





Tested Video Resolutions for FRL Mode - YCbCr420Table 33: FRL Mode - YCbCr420

Resolution VIC Color SpaceColor Depth

8 10 12 1610240x4320p60

1215 YUV420 TESTED NOT

SUPPORTEDNOT

SUPPORTEDNOT

SUPPORTED

10240x4320p501

214 YUV420 TESTED NOTSUPPORTED

NOTSUPPORTED

NOTSUPPORTED

10240x4320p481

213 YUV420 TESTED NOTSUPPORTED

NOTSUPPORTED

NOTSUPPORTED

10240x4320p30 212 YUV420 TESTED TESTED TESTED TESTED



7680x4320p601 199 YUV420 TESTED TESTED TESTED NOTSUPPORTED































Resolution VIC Color SpaceColor Depth

8 10 12 163840x2160p48 114 YUV420 TESTED TESTED TESTED TESTED




































Notes:1. Only available on an 8 PPC enabled system in AXI4-Stream Video Interface.





IMPORTANT! The following VIC ID Video Timings are not supported in the Native Video interfacebecause the Htotal is not divisible by four.

• For RGB/YCbCr444/YCbCr422: 2, 3, 4, 32, 47, 48, 49, 56, 57, 69, 71, 72, 86, 91, 110, 111, 112,113, 124

• For YCbCr420: 2, 3, 4, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 19, 32, 41, 47, 48, 49, 50, 51, 56, 57, 58,59, 60, 62, 65, 67, 68, 69, 70, 71, 72,79, 86, 89, 91, 93, 98, 103, 108, 109, 110, 111, 112, 113,114, 115, 116, 121, 124, 126, 193, 210, 211, 213, 214





Appendix B

UpgradingThis appendix contains information about upgrading to a more recent version of the IP core.

Port Changes for 2021.2The Native Video (Vectored DE) interface has been added. See Native Video (Vectored DE)Interface for details.

Port Changes for 2021.1The Native Video interface bus is renamed to NATIVE_VID_OUT.

M_HDR_AXI interface added.

Related Information

Dynamic HDR Interface (Memory Mapped AXI4 Interface)Native Video Interface

Port Changes for 2020.2AUDIO_OUT_tid port increased to 5 bits to support 3D Audio (up to 32 channels). See AudioOutput Stream Interface for details.

The Native Video interface has been added. See Native Video Interface for details.

Appendix B: Upgrading




Appendix C

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.

Appendix C: Debugging


https://www.xilinx.com/support.html

https://forums.xilinx.com/




https://www.xilinx.com/support/download.html



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.



https://www.xilinx.com/cgi-bin/docs/rdoc?v=latest;d=ug908-vivado-programming-debugging.pdf



• If your outputs go to 0, check your licensing.

○ 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.

• Check subsystem configuration.






AXI4-Stream Audio Interface

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.





Appendix D

Application Software Development

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.

Appendix D: Application Software Development




Figure 23: Subsystem Driver Architecture

Application Layer

Subsystem Driver

Sub-Core IP1 Driver Sub-Core IP2 Driver Sub-Core IPn Driver

X16747-040716

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.





Figure 25: Application Example Code





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.

void XV_HdmiRxSs1_SetEdidParam(XV_HdmiRxSs1 *InstancePtr, u8 *EdidDataPtr, u16 Length);

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.

int XIntc_Connect(XIntc *InstancePtr, u8 Id, XInterruptHandler Handler, void *CallBackRef);void XIntc_Enable(XIntc *InstancePtr, u8 Id);

where ID can be found in xparameters.h.

7. Set the default Link Training Patterns, Threshold, and FFE Support. These values will be usedby the RX Driver during FRL training.

void XV_HdmiRxSs1_FrlModeEnable(XV_HdmiRxSs1 *InstancePtr, u8 LtpThreshold, XV_HdmiRx1_FrltpDefaultLtp, u8 FfeSuppFlag);

Note:





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.

• XV_HdmiRxSs1_HdcpSetKey

○ XV_HDMIRXSS1_KEY_HDCP14

○ XV_HDMIRXSS1_KEY_HDCP22_LC128 (128-bit DCP Licensed Constant)

○ XV_HDMIRXSS1_KEY_HDCP22_PRIVATE (902-byte DCP Receiver Device Key Set)

Table 34: HDCP Production Keys Mapping

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.

• XV_HdmiRxSs1_SetCallback

○ XV_HDMIRXSS1_HANDLER_HDCP_AUTHENTICATED

○ XV_HDMIRXSS1_HANDLER_HDCP_UNAUTHENTICATED

○ XV_HDMIRXSS1_HANDLER_HDCP_AUTHENTICATION_REQUEST

○ XV_HDMIRXSS1_HANDLER_HDCP_STREAM_MANAGE_REQUEST

○ XV_HDMIRXSS1_HANDLER_HDCP_TOPOLOGY_UPDATE

○ XV_HDMIRXSS1_HANDLER_HDCP_ENCRYPTION_UPDATE

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.

• XV_HdmiRxSs1_HdcpIsEncrypted





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.





Figure 26: Application Example Code

To integrate and use the HDMI PHY Controller for the HDMI 2.1 RX Subsystem in theapplication code, the following steps must be followed:

1. Include the subsystem header file xhdmiphy1.h that defines the subsystem object.

2. Declare and allocate space for a HDMI PHY Controller instance in your application code.





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:

XHdmiphy1_Config *XHdmiphy1_LookupConfig(u16 DeviceId);u32 XHdmiphy1_Hdmi_CfgInitialize(XHdmiphy1 *InstancePtr, u8 QuadId, XHdmiphy1_Config *CfgPtr);

The Device ID can be found in xparameters.h:

XPAR_[HDMI PHY Controller Instance Name in IPI]_DEVICE_ID

Note:

• Xilinx recommends initializing the PHY controller after the HDMI 2.1 RX Subsystem initialization iscompleted.

• Registering the PHY Controller interrupts are part of system application integration. Steps are shown inthe previous section and not repeated here.

Interrupts

• HDMI 2.1 Receiver

• HDCP 1.4 IP

• HDCP 1.4 Timer

• HDCP 2.3 IP

The HDMI 2.1 RX Subsystem IP has multiple interrupts sources:

• Hardware I/O inputs (for example, HPD, SB_STATUS, bridge FIFO overflow/underflow)

• Auxiliary packets, interrupts

• Internal timer (for example, VTD timer FRL timer)

All interrupts generated by the HDMI 2.1 RX Subsystem are listed here:

1. HPD – Peripheral I/O to assert HDMI cable 5.0V signal

a. Rising edge – Cable connected

b. Falling edge – Cable disconnected





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.





Callback functions defined in the application code must be registered with provided handlers,using the following defined API:

int XV_HdmiRxSs1_SetCallback(XV_HdmiRxSs1 *InstancePtr, u32 HandlerType, void *CallbackFuncPtr, void *CallbackRef);

Available handlers are defined in xv_hdmirxss1.h:

• XV_HDMIRXSS1_HANDLER_CONNECT

• XV_HDMIRXSS1_HANDLER_AUX

• XV_HDMIRXSS1_HANDLER_AUD

• XV_HDMIRXSS1_HANDLER_LNKSTA

• XV_HDMIRXSS1_HANDLER_STREAM_UP

• XV_HDMIRXSS1_HANDLER_STREAM_DOWN

• XV_HDMIRXSS1_HANDLER_STREAM_INIT

• XV_HDMIRXSS1_HANDLER_FRL_CONFIG

• XV_HDMIRXSS1_HANDLER_FRL_START

• XV_HDMIRXSS1_HANDLER_TMDS_CONFIG

• XV_HDMIRXSS1_HANDLER_HDCP_AUTHENTICATE

• XV_HDMIRXSS1_HANDLER_VFP_CH

• XV_HDMIRXSS1_HANDLER_VRR_RDY

• XV_HDMIRXSS1_HANDLER_DYN_HDR

Note: The following HDMI 2.1 RX Subsystem interrupt callbacks are defined in the driver, but they are notdirectly programmable in this release.

• XV_HDMIRXSS1_HANDLER_BRDGOVERFLOW

• XV_HDMIRXSS1_HANDLER_DDC

• XV_HDMIRXSS1_HANDLER_TMDS_CLK_RATIO

HDCP related callbacks are not covered in this document.

• XV_HDMIRXSS1_HANDLER_HDCP

• XV_HDMIRXSS1_HANDLER_HDCP_AUTHENTICATION_REQUEST

• XV_HDMIRXSS1_HANDLER_HDCP_AUTHENTICATED

• XV_HDMIRXSS1_HANDLER_HDCP_UNAUTHENTICATED

• XV_HDMIRXSS1_HANDLER_HDCP_STREAM_MANAGE_REQUEST





• XV_HDMIRXSS1_HANDLER_HDCP_TOPOLOGY_UPDATE

• XV_HDMIRXSS1_HANDLER_HDCP_ENCRYPTION_UPDATE

XV_HDMIRXSS1_HANDLER_CONNECT

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.

void XHdmiphy1_IBufDsEnable (XVphy *InstancePtr, u8 QuadId, XVphy_DirectionType Dir, u8 Enable);

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.





XV_HDMIRXSS1_HANDLER_STREAM_UP

This interrupt is triggered every time an HDMI video stream becomes locked.

The callback function must ensure that when the Video mode is not FRL, the PHY CLKOUT1OBUFTDS peripheral is enabled.

void XHdmiphy1_Clkout1OBufTdsEnable (XHdmiphy1 *InstancePtr, XHdmiphy1_DirectionType Dir, u8 Enable);

The callback function can update stream up information to the application software.

XV_HDMIRXSS1_HANDLER_STREAM_DOWN

This interrupt is triggered when an HDMI video stream becomes unlocked.

The callback function must perform the following steps:

1. Check if the video mode is not XHDMIC_VIDMODE_HDMI_FRL.

2. Power down the PHY MMCM.

void XHdmiphy1_MmcmPowerDown(XHdmiphy1 *InstancePtr, u8 QuadId, XHdmiphy1_DirectionType Dir, u8 Hold)

3. Disable the PHY CLKOUT1 OBUFTDS peripheral.

void XHdmiphy1_Clkout1OBufTdsEnable(XHdmiphy1 *InstancePtr, XHdmiphy1_DirectionType Dir, u8 Enable)

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.


1. Retrieve the video stream information.

XVidC_VideoStream *XV_HdmiRxSs1_GetVideoStream(XV_HdmiRxSs1 *InstancePtr);





2. Calculate the HDMI MMCM parameter based on the video stream information received.

u32 XHdmiphy1_HdmiCfgCalcMmcmParam(XHdmiphy1 *InstancePtr, u8 QuadId, XHdmiphy1_ChannelId ChId, XHdmiphy1_DirectionType Dir, XVidC_PixelsPerClock Ppc, XVidC_ColorDepth Bpc);

3. Enable the HDMI PHY Controller to start the MMCM.

void XHdmiphy1_MmcmStart(XHdmiphy1*InstancePtr, u8 QuadId, XVphy_DirectionType Dir);

where,

InstancePtr is a pointer to the XVphy core instance.

QuadId is the GT quad ID to operate on.

Dir is an indicator for TX or RX.

Note: QuadId is not used and should be set to 0.

For example:

XHdmiphy1_MmcmStart(&Hdmiphy1, 0, XHDMIPHY1_DIR_RX);

XV_HDMIRXSS1_HANDLER_FRL_CONFIG

This interrupt is triggered every time FRL Training state for rate change is successfully executed.


1. Update the application to configure the clock for the RX source.

2. Enable the differential input clock buffer.

void XHdmiphy1_IBufDsEnable(XHdmiphy1 *InstancePtr, u8 QuadId, XHdmiphy1_DirectionType Dir, u8 Enable)

3. Configure the PHY GT for HDMI 2.1 operation.

u32 XHdmiphy1_Hdmi21Config(XHdmiphy1 *InstancePtr, u8 QuadId,XHdmiphy1_DirectionType Dir,u64 LineRate,u8 NChannels)

where,

• InstancePtr is a pointer to the XVphy core instance.

• QuadId is the GT quad ID to operate on.

• Dir is an indicator for TX or RX.






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.


1. Update the application to configure the clock for the RX source.

2. Configure the PHY GT for HDMI 2.0 operation.

u32 XHdmiphy1_Hdmi20Config(XHdmiphy1 *InstancePtr, u8 QuadId, XHdmiphy1_DirectionType Dir)

where,

• InstancePtr is a pointer to the XVphy core instance.

• QuadId is the GT quad ID to operate on.

• Dir is an indicator for TX or RX.


3. Set the video clock for the RX Core's FRL peripheral to 0.

XV_HdmiRx1_SetFrlVidClock(InstancePtr, Value)

XV_HDMIRXSS1_HANDLER_HDCP_AUTHENTICATE

If HDCP 1.4 or HDCP 2.3 is enabled in the HDMI 2.1 RX Subsystem hardware, this interrupt istriggered when HDCP passes its authentication state.

The callback function can update HDCP authentication status to the application software.





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. Use the following API to register callback functions and read theupdated video timing information.

XVidC_VideoStream *XV_HdmiRxSs1_GetVideoStream(XV_HdmiRxSs1 *InstancePtr)

You must enable the interrupt handler by calling following API.

void XV_HdmiRxSs1_VfpControl(XV_HdmiRxSs1 *InstancePtr, u8 Enable) // 0 – Disable , 1- Enable

XV_HDMIRXSS1_HANDLER_VRR_RDY

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.

XV_HdmiC_VrrInfoFrame *XV_HdmiRxSs1_GetVrrIf(XV_HdmiRxSs1 *InstancePtr);

XV_HDMIRXSS1_HANDLER_DYN_HDR

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.

void XV_HdmiRxSs1_DynHDR_SetAddr(XV_HdmiRxSs1 *InstancePtr, u64 Addr);

void XV_HdmiRxSs1_DynHDR_GetInfo(XV_HdmiRxSs1 *InstancePtr, XV_HdmiRxSs1_DynHDR_Info *RxDynHdrInfo);

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:

• XHDMIPHY1_HDMI_HANDLER_RXINIT

• XHDMIPHY1_HDMI_HANDLER_RXREADY





Callback functions need to be defined in the application code and hooked up with these interrupthandlers.

void XHdmiphy1_SetHdmiCallback(XHdmiphy1 *InstancePtr, XHdmiphy1_HdmiHandlerType HandlerType, void *CallbackFunc, void *CallbackRef);

XHDMIPHY1_HDMI_HANDLER_RXINIT

This interrupt is triggered every time the HDMI PHY Controller detects an HDMI RX referenceclock change.

The callback function must perform the following:

1. Initialize a reference clock change process for the HDMI 2.1 RX Subsystem.

void XV_HdmiRxSs1_RefClockChangeInit(XV_HdmiRxSs1 *InstancePtr);

2. Set the HDMI PHY Controller HDMI RX reference TMDS clock ratio.

Hdmiphy1Ptr->HdmiRxTmdsClockRatio = HdmiRxSs1Ptr->TMDSClockRatio;

XHDMIPHY1_HDMI_HANDLER_RXREADY

This interrupt is triggered every time the HDMI PHY Controller RX reset lock is done.

The callback function must perform the following:

1. Check the HDMI PHY Controller PLL type.

XHdmiphy1_PllType XHdmiphy1_GetPllType(XHdmiphy1 *InstancePtr, u8 QuadId, XHdmiphy1_DirectionType Dir, XHdmiphy1_ChannelId ChId);

2. Set the HDMI 2.1 RX Subsystem video stream according to the PLL type.

XV_HdmiRxSs1_SetStream(XV_HdmiRxSs1 *InstancePtr, u32 Clock, u32 LineRate);

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

HDMI 2.1 RXInterrupts HDMI 2.1 RX SS Callback HDMI 2.1 RX Interrupt Controlling

layer event LABEL

HPD XV_HDMIRXSS1_HANDLER_CONNECT XV_RX_HDMI_EVENT_DISCONNECTEDXV_RX_HDMI_EVENT_CONNECTED

AB

Video ReadyNote: It is edgetriggered

XV_HDMIRXSS1_HANDLER_STREAM_UPXV_HDMIRXSS1_HANDLER_STREAM_DOWNVideo Ready rising edge: Stream UpVideo Ready falling edge: Stream Down.

XV_RX_HDMI_EVENT_STREAMUPXV_RX_HDMI_EVENT_STREAMDOWN

CD

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_RX_HDMI_EVENT_STREAMINIT E

FRL XV_HDMIRXSS1_HANDLER_FRL_CONFIGXV_HDMIRXSS1_HANDLER_FRL_STARTXV_HDMIRXSS1_HANDLER_TMDS_CONFIG

XV_RX_HDMI_EVENT_FRLCONFIGXV_RX_HDMI_EVENT_FRLSTARTXV_RX_HDMI_EVENT_TMDSCONFIG

FGH

HDMI ReceiverAuxiliary InfoframeInterrupt

XV_HDMIRXSS1_HANDLER_AUX XV_RX_TRIG_HANDLER_AUXEVENT

HDMI ReceiverAudio Interrupt

XV_HDMIRXSS1_HANDLER_AUD XV_RX_TRIG_HANDLER_AUDIOCONFIG

HDCP 1.4 Interrupt

HDCP 1.4 TimerInterrupt

HDCP 2.3 TimerInterrupt

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.





Figure 28: HDMI 2.1 Subsystem Interrupt Control

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,

u32 XV_Rx_Hdmi_Initialize(XV_Rx *InstancePtr, u32 HdmiRxSsDevId, u32 VPhyDevId, XV_Rx_IntrVecId IntrVecIds);

• Setting the callbacks from the interrupt controlling layer,

u32 XV_Rx_SetTriggerCallbacks(XV_Rx *InstancePtr, XV_Rx_Trigger_CallbackHandler Handler, void *Callback, void *CallbackRef);

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.

Table 36: HDMI 2.1 RX Interrupt Controller Layer Callback Handlers

HDMI 2.1 Interrupt Controller Layer CallbackHandlers Description

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.





Table 36: HDMI 2.1 RX Interrupt Controller Layer Callback Handlers (cont'd)

HDMI 2.1 Interrupt Controller Layer CallbackHandlers Description

XV_RX_TRIG_HANDLER_HDCP_FORCE_BLANKING Request to disable sending HDCP decrypted content.

XV_RX_TRIG_HANDLER_HDCP_SET_CONTENTSTREAMTYPE Set the encrypted content stream type for the HDMIreceiver.





Appendix E

Additional Resources and LegalNotices

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




https://www.xilinx.com/cgi-bin/docs/ndoc?t=design+hubs

https://www.xilinx.com/cgi-bin/docs/rdoc?t=docnav



1. Vivado Design Suite: AXI Reference Guide (UG1037)

2. Kintex UltraScale+ FPGAs Data Sheet: DC and AC Switching Characteristics (DS922)

3. Virtex UltraScale+ FPGA Data Sheet: DC and AC Switching Characteristics (DS923)

4. Zynq UltraScale+ MPSoC Data Sheet: DC and AC Switching Characteristics (DS925)

5. Zynq UltraScale+ RFSoC Data Sheet: DC and AC Switching Characteristics (DS926)

6. Artix UltraScale+ FPGA Data Sheet: DC and AC Switching Characteristics (DS931)

7. HDMI Specifications (https://www.hdmi.org/manufacturer/specification.aspx)

8. HDCP Specifications (https://www.digital-cp.com/hdcp-specifications)

9. CTA-861 Specifications (https://cta.tech)

10. AXI4-Stream Video IP and System Design Guide (UG934)

11. Vivado Design Suite User Guide: Designing IP Subsystems using IP Integrator (UG994)

12. Vivado Design Suite User Guide: Designing with IP (UG896)

13. Vivado Design Suite User Guide: Getting Started (UG910)

14. Vivado Design Suite User Guide: Programming and Debugging (UG908)

15. Vivado Design Suite User Guide: Implementation (UG904)

16. AXI Interconnect LogiCORE IP Product Guide (PG059)

17. SmartConnect LogiCORE IP Product Guide (PG247)

18. HDMI PHY Controller LogiCORE IP Product Guide (PG333)

19. HDCP 2.2 LogiCORE IP Product Guide (PG249)

20. HDCP 1.x Product Guide (PG224)

21. Video In to AXI4-Stream LogiCORE IP Product Guide (PG043)

22. ST 2094-10 (https://ieeexplore.ieee.org/document/7513370)

23. ST 2094-40 (https://ieeexplore.ieee.org/document/9095450)

24. ETSI 103-433-1 (https://www.etsi.org/deliver/etsi_ts/103400_103499/10343301/01.02.01_60/ts_10343301v010201p.pdf)

25. ITU-T H.265 (https://www.itu.int/rec/T-REC-H.265)

Revision HistoryThe following table shows the revision history for this document.




https://www.xilinx.com/cgi-bin/docs/ndoc?t=data_sheets;d=ds922-kintex-ultrascale-plus.pdf

https://www.xilinx.com/cgi-bin/docs/ndoc?t=data_sheets;d=ds923-virtex-ultrascale-plus.pdf

https://www.xilinx.com/cgi-bin/docs/ndoc?t=data_sheets;d=ds925-zynq-ultrascale-plus.pdf

https://www.xilinx.com/cgi-bin/docs/ndoc?t=data_sheets;d=ds926-zynq-ultrascale-plus-rfsoc.pdf

https://www.xilinx.com/cgi-bin/docs/ndoc?t=data_sheets;d=ds931-artix-ultrascale-plus.pdf

https://www.hdmi.org/manufacturer/specification.aspx

https://www.digital-cp.com/hdcp-specifications

https://cta.tech





https://www.xilinx.com/cgi-bin/docs/rdoc?v=latest;d=ug908-vivado-programming-debugging.pdf

https://www.xilinx.com/cgi-bin/docs/rdoc?v=latest;d=ug904-vivado-implementation.pdf

https://www.xilinx.com/cgi-bin/docs/ipdoc?c=axi_interconnect;v=latest;d=pg059-axi-interconnect.pdf

https://www.xilinx.com/cgi-bin/docs/ipdoc?c=smartconnect;v=latest;d=pg247-smartconnect.pdf




https://www.xilinx.com/cgi-bin/docs/ipdoc?c=v_vid_in_axi4s;v=latest;d=pg043_v_vid_in_axi4s.pdf








Section Revision Summary10/22/2021 Version 1.2

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://



https://www.xilinx.com/legal.htm#tos



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.

Copyright

© Copyright 2021 Xilinx, Inc. Xilinx, the Xilinx logo, Alveo, Artix, Kintex, Spartan, Versal, Virtex,Vivado, Zynq, and other designated brands included herein are trademarks of Xilinx in the UnitedStates and other countries. AMBA, AMBA Designer, Arm, ARM1176JZ-S, CoreSight, Cortex,PrimeCell, Mali, and MPCore are trademarks of Arm Limited in the EU and other countries. TheDisplayPort Icon is a trademark of the Video Electronics Standards Association, registered in theU.S. and other countries. HDMI, HDMI logo, and High-Definition Multimedia Interface aretrademarks of HDMI Licensing LLC. All other trademarks are the property of their respectiveowners.







product guide subsystem v1

Documents