The HDMI system architecture consists of sinks and sources. A device may have one or more HDMI inputs and outputs.

The HDMI cable and connectors carry four differential pairs that make up the Transition Minimized Differential Signaling (TMDS) data and clock channels for HDMI 1.4 and HDMI 2.0. For HDMI 2.1, HDMI cable and connectors carry four fixed rate link (FRL) lanes of data. You can use these channels to carry video, audio, and auxiliary data.

The HDMI also carries a Video Electronics Standards Association (VESA) Display Data Channel (DDC) and Status and Control Data Channel (SCDC). The DDC configures and exchanges status between a single source and a single sink. The source uses the DDC to read the sink's Enhanced Extended Display Identification Data (E-EDID) to discover the sink's configuration and capabilities.

The optional Consumer Electronics Control (CEC) protocol provides high-level control functions between various audio visual products in your environment.

The optional HDMI Ethernet and Audio Return Channel (HEAC) provides Ethernet compatible data networking between connected devices and an audio return channel in the opposite direction of TMDS. The HEAC also uses Hot-Plug Detect (HPD) line for link detection.

Based on TMDS encoding, the HDMI protocol allows the transmission of both audio and video data between source and sink devices.

An HDMI interface consists of three color channels accompanied by a single clock channel. You can use each color line to transfer both individual RGB colors and auxiliary data.

The receiver uses the TMDS clock as a frequency reference for data recovery on the three TMDS data channels. This clock typically runs at the video pixel rate.

TMDS encoding is based on an 8-bit to 10-bit algorithm. This protocol attempts to minimize data channel transition, and yet maintain sufficient transition so that a sink device can lock reliably to the data stream.

In HDMI 1.4 and HDMI 2.0, 3 lanes carry data and 1 lane carries TMDS clock. When operating in FRL mode, the clock channel carries data as well. As the HDMI 2.1 specification requires backward compatibility with HDMI 1.4 and HDMI 2.0, you need to configure the 4th lane to carry data or clock during run time.

You can configure the FRL mode to 3 lanes and 4 lanes. In 3-lane FRL mode, each lane can operate at 3 Gbps or 6 Gbps. In 4-lane FRL mode, each lane can operate at 6 Gbps, 8 Gbps, 10 Gbps, or 12 Gbps.

Use category 3 (Cat 3) cable for FRL mode to ensure good signal integrity.

Each data stream section is preceded with guard bands and pre-ambles. The guard bands and pre-ambles allow for accurate synchronization with received data streams.

The following figures show the arrangement of the video data, video data enable, video H-SYNC, and video V-SYNC in 1, 2, 4, and 8 symbols per clock.

The following terms define device support levels for Intel FPGA IP cores:

• Advance support—the IP core is available for simulation and compilation for this device family. Timing models include initial engineering estimates of delays based on early post-layout information. The timing models are subject to change as silicon testing improves the correlation between the actual silicon and the timing models. You can use this IP core for system architecture and resource utilization studies, simulation, pinout, system latency assessments, basic timing assessments (pipeline budgeting), and I/O transfer strategy (data-path width, burst depth, I/O standards tradeoffs).
• Preliminary support—the IP core is verified with preliminary timing models for this device family. The IP core meets all functional requirements, but might still be undergoing timing analysis for the device family. It can be used in production designs with caution.
• Final support—the IP core is verified with final timing models for this device family. The IP core meets all functional and timing requirements for the device family and can be used in production designs.

The following terms define IP feature support levels for HDMI Intel^® FPGA IP:

• Preliminary support—The IP meets the functional requirement for the feature set as listed in this user guide. Additional features, characterization, and system level design guidelines shall be covered in future releases. The IP can be used in production designs for the supported device family with caution.
• Final support—The IP is compliant to the protocol CTS requirement for the supported device family and can be used in production design. Characterization report and system level design guidelines are available to facilitate meeting PHY CTS requirements.

The Intel^® Quartus^® Prime software installs IP cores in the following locations by default:

The implementation of the HDMI Intel^® FPGA IP on hardware requires additional components specific to the targeted device.

The High-bandwidth Digital Content Protection (HDCP) over HDMI hardware design example helps you to evaluate the functionality of the HDCP feature and enables you to use the feature in your Intel^® Arria^® 10 and Intel^® Stratix^® 10 designs.

For detailed information about the HDCP over HDMI design examples, refer to the Intel^® Arria^® 10 and Intel^® Stratix^® 10 design example user guides.

The design example runs on the following device kits:

• Arria V GX starter kit
• Stratix V GX development kit
• Bitec HDMI HSMC 2.0 Daughter Card Revision 8

The hardware demonstration design comprises the following components:

• HDMI sink
  • Transceiver Native PHY (RX)
  • Transceiver PHY Reset Controller (RX)
  • PLL
  • PLL Reconfiguration
  • Multirate Reconfiguration Controller (RX)
  • Oversampler (RX)
  • DCFIFO
• Sink Display Data Channel (DDC) and Status and Control Data Channel (SCDC)
• Transceiver Reconfiguration Controller
• VIP bypass and Audio, Auxiliary and InfoFrame buffers
• Platform Designer system
  • VIP passthrough for HDMI video stream
  • Source SCDC controller
  • HDMI source reconfiguration controller
• HDMI source
  • Transceiver Native PHY (TX)
  • Transceiver fPLL
  • Transceiver PHY Reset Controller (TX)
  • PLL
  • PLL Reconfiguration
  • Oversampler (TX)
  • DCFIFO
  • Clock Enable Generator

The following details of the design example architecture correspond to the numbers in the block diagram.

1. The sink TMDS data has three channels: data channel 0 (blue), data channel 1 (green), and data channel 2 (red).
2. The Oversampler (RX) and dual-clock FIFO (DCFIFO) instances are duplicated for each TMDS data channel (0,1,2).
3. The video data input width for each color channel of the HDMI RX core is equivalent to RX transceiver PCS-PLD parallel data width per channel.
4. Each color channel is fixed at 16 bpc. The video data output width of the HDMI RX core is equivalent to the value of symbols per clock*16*3.
5. The video data input width of the Clocked Video Input (CVI) and Clocked Video Output (CVO) IP cores are equivalent to the value of NUMBER_OF_PIXELS_IN_PARALLEL * BITS_PER_PIXEL_PER_COLOR_PLANE * NUMBER_OF_COLOR_PLANES. To interface with the HDMI core, the values of NUMBER_OF_PIXELS_IN_PARALLEL, BITS_PER_PIXEL_PER_COLOR_PLANE, and NUMBER_OF_COLOR_PLANES must match the symbols per clock, 16 and 3 respectively.
6. The video data input width of the HDMI TX core is equivalent to the value of symbols per clock*16*3. You can use the user switch to select the video data from the CVO IP core (VIP passthrough) or DCFIFO (VIP bypass).
7. The video data output width for each color channel of the HDMI TX core is equivalent to TX transceiver PCS-PLD parallel data width per channel.
8. The DCFIFO and the Oversampler (TX) instances are duplicated for each TMDS data channel (0,1,2) and clock channel.
9. The Oversampler (TX) uses the clock enable signal to read data from the DCFIFO.
10. The source TMDS data has four channels: data channel 0 (blue), data channel 1 (green), data channel 2 (red), and clock channel.
11. The RX Multirate Reconfiguration Controller requires the status of TMDS_Bit_clock_Ratio port to perform appropriate RX reconfiguration between the TMDS character rates below 340 Mcsc (HDMI 1.4b) and above 340 Mcsc (HDMI 2.0b). The status of the port is also required by the Nios II processor and the HDMI TX core to perform appropriate TX reconfiguration and scrambling.
12. The reset control and lock status signals from HDMI PLL, RX Transceiver Reset Controller and HDMI RX core.
13. The reset and oversampling control signals for HDMI PLL, TX Transceiver Reset Controller, and HDMI TX core. The lock status and rate detection measure valid signals from the HDMI sink initiate the TX reconfiguration process.
14. The I²C SCL and SDA lines with tristate buffer for bidirectional configuration. Use the ALTIOBUF IP core for Arria V and Stratix V devices.
15. The SCDC is mainly designed for the source to update the TMDS_Bit_Clock_Ratio and Scrambler_Enable bits of the sink TMDS Configuration register. .

• Transceiver Native PHY in Arria V devices
  • To operate the TMDS bit rate up to 3,400 Mbps, configure the Transceiver Native PHY at 20 bits at PCS – PLD interface with the HDMI RX core at 2 symbols per clock. When the PCS – PLD interface width is 20 bits, the minimum link rate is 611 Mbps.
  • To operate the TMDS bit rate up to 6,000 Mbps, configure the Transceiver Native PHY at 40 bits with the HDMI RX core at 4 symbols per clock. When the PCS – PLD interface width is 40 bits, the minimum link rate is 1,000 Mbps.
  • Oversampling is required for TMDS bit rate which is below the minimum link rate.
• Transceiver Native PHY in Stratix V devices
  • To operate the TMDS bit rate up to 6,000 Mbps, configure the Transceiver Native PHY at 20 bits at PCS – PLD interface with the HDMI RX core at 2 symbols per clock. When the PCS – PLD interface width is 20 bits, the minimum link rate is 611 Mbps.

The HDMI PLL is referenced by the arbitrary TMDS clock. For HDMI source, you can reference the HDMI PLL by a separate clock source in the VIP passthrough design, which contains frame buffer. The HDMI PLL for TX has the same desired output frequencies as RX across symbols per clock and color depth.

• For TMDS bit rates ranging from 3,400 Mbps to 6,000 Mbps (HDMI 2.0), the TMDS clock rate is 1/40 of the TMDS bit rate. The HDMI PLL generates reference clock for RX/TX transceiver at 4 times the TMDS clock.
• For TMDS bit rates below 3,400 Mbps (HDMI 1.4b), the TMDS clock rate is 1/10 of the TMDS bit rate. The HDMI PLL generates reference clock for RX/TX transceiver at identical rate as the TMDS clock.

The color depths greater than 8 bpc or 24 bpp are defined to be deep color. For a color depth of 8 bpc, the core carries the pixels at a rate of one pixel per TMDS clock. At deeper color depths, the TMDS clock runs faster than the source pixel clock to provide the extra bandwidth for the additional bits.

The TMDS clock rate is increased by the ratio of the pixel size to 8 bits:

• 8 bits mode—TMDS clock = 1.0 × pixel or video clock (1:1)
• 10 bits mode—TMDS clock = 1.25 × pixel or video clock (5:4)
• 12 bits mode—TMDS clock = 1.5 × pixel or video clock (3:2)
• 16 bits mode—TMDS clock = 2 × pixel or video clock (2:1)

Use the IP core to update the output clock frequency, PLL bandwidth in real-time, without reconfiguring the entire FPGA.

You can run this IP core at 100 MHz in Stratix V devices. In Arria V devices, you need to run at 75 MHz for timing closure. To simplify clocking in Arria V devices, the entire management clock domain is capped at 75 MHz.

The Multirate Reconfig Controller performs rate detection on the HDMI PLL arbitrary reference clock, which is also the TMDS clock, to determine the clock frequency band. Based on the detected clock frequency band, the circuitry dynamically reconfigures the HDMI PLL and transceiver settings to accommodate for the link rate change.

The oversampling factor is fixed at 5 and you can program the data width to support different number of symbols. The supported data width is 20 bit for 2 symbols per clock and 40 bits for 4 symbols per clock. The extracted bit will be accompanied by data valid pulse which asserts every 5 clock cycles.

• Sink
  • When the Multirate Reconfig Controller (RX) detects an incoming input stream that is below the transceiver minimum link rate, the DCFIFO accepts the data from the Oversampler with data valid pulse as write request asserted every 5 clock cycles.
  • Otherwise, it accepts data directly from the transceiver with write request asserted at all times.
• Source
  • When Nios II processor determines the outgoing data stream is below the TX transceiver minimum link rate, the TX transceiver accepts the data from the Oversampler (TX).
  • Otherwise, the TX transceiver reads data directly from the DCFIFO with read request asserted at all times.

The E-EDID memory is stored using the RAM 1-Port IP core. A standard two-wire (clock and data) serial data bus protocol (I2C slave-only controller) is used to transfer CEA-861-D compliant E-EDID data structure.

The 8-bit I²C slave addresses for the E-EDID are 0xA0/0xA1. The LSB indicates the access type: 1 for read and 0 for write. When an HPD event occurs, the I²C slave responds to E-EDID data by reading from the RAM.

The I²C slave-only controller is also used to support SCDC for HDMI 2.0b operation. The 8-bit I²C slave addresses for the SCDC are 0xA8/0xA9. When an HPD event occurs, the I²C slave performs write/read transaction to/from SCDC interface of HDMI RX core. This I²C slave-only controller for SCDC is not required if HDMI 2.0b is not intended.

You can selectively reconfigure any portion of the transceiver. The reconfiguration of each portion requires a read-modify-write operation (read first, then write). The read-modify-write operation modifies only the appropriate bits in a register and does not affect the other bits.

The Transceiver Reconfiguration Controller is only available and required in Arria V and Stratix V devices. Because the RX and TX transceivers share a single controller, the controller requires Platform Designer interconnects, such as Avalon-MM Master Translator and Avalon-MM Slave Translator, in the Platform Designer system.

• The Avalon-MM Master Translator provides an interface between this controller and the RX Multirate Reconfig Controller.
• The Avalon-MM Slave Translator arbitrates the RX and TX reconfiguration event for this controller.

The auxiliary data port of the HDMI TX core controls the auxiliary data that flow through DCFIFO through backpressure. The backpressure ensures there is no incomplete auxiliary packet on the auxiliary data port. This block also performs external filtering on the audio data and audio clock regeneration packet from the auxiliary data stream before sending to the HDMI TX core auxiliary data port.

The Arria V and Stratix V Transceiver Native PHY (TX) configuration settings are typically the same as RX.

The reset controller has separate reset controls per channel to handle synchronization of reset inputs, lagging of PLL locked status, and automatic or manual reset recovery mode.

The oversampling factor is fixed at 5. The Oversampler (TX) assumes that the input word is only valid every 5 clock cycles. This block enables when the outgoing data stream is determined to be below the TX transceiver minimum link rate by reading once from the DCFIFO every 5 clock cycles.

This clock enable pulse asserts every 5 clock cycles and serves as a read request signal to clock the data out from DCFIFO.

The Clocked Video Input II (CVI II) Intel^® FPGA IP core converts clocked video formats to Avalon-ST video by stripping incoming clocked video of horizontal and vertical blanking, leaving only active picture data.

• The IP core provides clock crossing capabilities to allow video formats running at different frequencies to enter the system.
• The IP core also detects the format of the incoming clocked video and provides this information in a set of registers.
• The Nios II processor uses this information to reconfigure the video frame mode registers of the CVO IP core in the VIP passthrough design.

The Video Frame Buffer II Intel^® FPGA IP core buffers video frames into external RAM.

• The IP core supports double and triple buffering with a range of options for frame dropping and repeating.
• You can use the buffering options to solve throughput issues in the data path and perform simple frame rate conversion.

In a VIP passthrough design, you can reference the HDMI source PLL and sink PLL using separate clock sources. However, in a VIP bypass design, you must reference the HDMI source PLL and sink PLL using the same clock source.

The Clocked Video Output II (CVO II) Intel^® FPGA IP core converts data from the flow-controlled Avalon-ST video protocol to clocked video.

• The IP core provides clock crossing capabilities to allow video formats running at different frequencies to be created from the system.
• It formats the Avalon-ST video into clocked video by inserting horizontal and vertical blanking and generating horizontal and vertical synchronization information using the Avalon-ST video control and active picture packets.
• The video frame is described using the mode registers that are accessed through the Avalon-MM control port.

For example, if the outgoing data stream is 6,000 Mbps, the Nios II processor commands the I²C master controller to update the TMDS_Bit_Clock_Ratio and Scrambler_Enable bits of the sink TMDS configuration register to 1. The same I²C master can also transfer the DDC data structure (E-EDID) between the HDMI source and external sink.

The CPU relies on the periodic rate detection from the Multirate Reconfig Controller (RX) to determine if TX requires reconfiguration. The Avalon-MM slave translator provides the interface between the Nios II processor Avalon-MM master interface and the Avalon-MM slave interfaces of the externally instantiated HDMI source's PLL Reconfig Intel FPGA IP and Transceiver Native PHY (TX).

The source core provides four 20-bit parallel data paths corresponding to the 3 color channels and the clock channel.

Central to the core is the Scrambler, TMDS/TERC4 Encoder. The encoder processes either video or auxiliary data.

For FRL path design, the video resampler and WOP generator operating at video clock domain accept video data running in the video clock (vid_clk) domain. The auxiliary data port, audio data port, and the auxiliary sideband signals also run in the video clock domain.

• A DCFIFO clocks the HDMI data stream from the WOP generator in the video clock domain to the scrambler, TMDS/TERC4 encoder in the transceiver recovered clock (tx_clk) domain to create a TMDS data stream.
• The HDMI data stream is also fed into the FRL path in FRL clock (frl_clk) domain to create an FRL data stream.

The multiplexer selects either TMDS data stream or FRL data stream as output data for lanes 0–3 based on the FRL rate.

• If FRL rate is 0, the multiplexer selects TMDS data streams as output.
• If FRL rate is non-zero, the multiplexer selects FRL data streams as output.

The encoder processes symbol data at 1, 2, or 4 symbols per clock. When the encoder operates in 2 or 4 symbols per clock, it also produces the output in the form of two or four encoded symbols per clock.

The TMDS/TERC4 encoder also produces digital visual interface (DVI) signaling when you deassert the mode input signal. DVI signaling is identical to HDMI signaling, except for the absence of data and video islands and TERC4 auxiliary data.

The gearbox converts data of 8, 10, 12, or 16 bits per component to 8-bit per component data based on the current color depth. The General Control Packet (GCP) conveys the color depth information.

The HDMI cable may send across four different pixel encodings: RGB 4:4:4, YCbCr 4:4:4, and YCbCr 4:2:2 (as described in HDMI 1.4b Specification Section 6.5), and YCbCr 4:2:0 (as described in HDMI 2.0b Specification Section 7.1).

The higher order 8 bits of the Y samples are mapped to the 8 bits of Channel 1 and the lower order 4 bits are mapped to the lower order 4 bits of Channel 0.

The first pixel transmitted within a Video Data Period contains three components, Y0, Cb0 and Cr0. The Y0 and Cb0 components are transmitted during the first pixel period while Cr0 is transmitted during the second pixel period. This second pixel period also contains the only component for the second pixel, Y1. In this way, the link carries one Cb sample for every two pixels and one Cr sample for every two pixels. These two components (Cb and Cr) are multiplexed onto the same signal paths on the link.

The two horizontally successive 8-bit Y components are transmitted in TMDS Channels 1 and 2, in that order. The 8-bit Cb or Cr components are transmitted alternately in TMDS Channel 0, line by line.

For even lines starting with line 0:

• vid_data[47:32] always transfer the Yn+1 component
• vid_data[31:16] always transfer the Yn component
• vid_data[15:0] always transfer the Cbn component

For odd lines:

• vid_data[47:32] always transfer the Yn+1 component
• vid_data[31:16] always transfer the Yn component
• vid_data[15:0] always transfer the Crn component

The frequency of vid_clk must be halved when YCbCr 4:2:0 is used, because two pixels are fed into a single clock cycle.

During horizontal blanking region, the WOP generator creates a leading region to hold at least 12 period symbols that include eight preamble symbols. The generator also creates a trailing region to hold two data island trailing guard band symbols, at least 12 control period symbols that include eight preamble symbols and two video leading guard band symbols.

During vertical blanking region, the source cannot send more than 18 auxiliary packets consecutively. The WOP generator deasserts the data island output enable (aux_wop) line after every 18th auxiliary packet for 32-symbol clocks.

The WOP generator also has an integral number of auxiliary packet cycles: 24 clocks when processing in 1-symbol mode, 16 clocks when processing in 2-symbol mode, and 8 clocks when processing in 4-symbol mode.

The auxiliary packets originate from several sources, which are multiplexed into the auxiliary packet encoder in a round-robin schedule. The auxiliary packet encoder converts a standard stream into the channel data format required by the TERC4 encoder.

The encoder assumes the data valid input will remain asserted for the duration of a packet to complete. A packet is always 24 clocks (in 1-symbol mode), 12 clocks (in 2-symbol mode), or 6 clocks (in 4-symbol mode).

The packet generator propagates backpressure from the output ready signal to the input ready signal. The generator asserts the input valid signal when a packet is ready to be transmitted. The input valid signal remains asserted until the end of the packet and the generator receives a ready acknowledgment.

The various auxiliary packet generators traverse a multiplexed routing path to the auxiliary packet encoder. The multiplexers obey a round-robin schedule and propagate backpressure.

These packets are: General Control Packet, Auxiliary Video Information (AVI) InfoFrame, and HDMI Vendor Specific InfoFrame (VSI).

The core sends the default values in the auxiliary packets. The default values allow the core to send video data compatible with the HDMI 1.4b Specification with minimum description.

You can also override the generators using the customized input values. The override values replace the default values when the input checksum is non-zero.

The core schedules this packet to be sent every ms. The timestamp scheduler uses the audio_clk and N value to determine a 1-ms interval. The audio data queues on a DCFIFO. The core also uses the DCFIFO to synchronize its clock to ls_clk when you turn off Support FRL and synchronized to vid_clk when you turn on Support FRL. The Audio Packetizer packs the audio data into the Audio Sample packets according to the specified audio format (as described in HDMI 1.4b Specification Section 5.3.4). An Audio Sample packet can contain up to 4 audio samples, based on the required audio sample clock. The core sends the Audio Sample packets whenever there is an available slot in the auxiliary packet stream.

The core determines the payload data packet type from the audio_format[3:0] signal.

The 32-bit audio data is packed in IEC-60958 standard. The least significant word is the left channel sample.

The audio_data port is always at a fixed value of 256 bits. In the LPCM format, the core can send up to 8 channels of audio data.

• Channel 1 audio data should be present at audio_data[31:0].
• Channel 2 audio data should be present at audio_data[63:32] and so on.

The Sample Present (SP) bit determines whether to use 2-channel or 8-channel layout. If the SP bit from Channel 3 is high, then the core uses the 8-channel layout. If otherwise, the core uses the 2-channel layout. The core ignores all other fields if the SP bit is 0.

The core requires an audio_de port for designs in which the audio_clk port frequency is higher than the actual audio sample clock. The audio_de port qualifies the audio data. If audio_clk is the actual audio sample clock, you can tie the audio_de signal to 1. For audio channels fewer than 8, insert 0 to the respective audio data of the unused audio channels.

The Audio Clock Regeneration and Audio Sample packets on the Auxiliary Data Port are not filtered by the core. You must filter these packets externally if you want to loop back the auxiliary data stream from the sink.

The Nios II processor typically drives the HDCP 1.4 TX core. The processor implements the authentication protocol. The processor accesses the IP through the Control and Status Port using Avalon Memory Mapped (Avalon-MM) interface.

The HDCP specifications requires the HDCP 1.4 TX core to be programmed with the DCP-issued production keys – Device Private Keys (Akeys) and Key Selection Vector (Aksv). The IP retrieves the key from the on-chip memory externally to the core through the HDCP Key Port. The on-chip memory must store the key data in the arrangement in the table below.

When authenticating with the HDCP 1.4 repeater device, the HDCP 1.4 TX core must perform the second part of the authentication protocol. This second part corresponds to the computation of the SHA-1 hash digest for all downstream device KSVs which are written to the registers in Control and Status Register Layer using the Control and Status Port (Avalon-MM).

The Video Stream and Auxiliary layer receives audio and video content over its Video and Aux Data Input Port, and performs the encryption operation. The Video Stream and Auxiliary Layer detects the Encryption Status Signaling (ESS) provided by the HDMI TX core to determine when to encrypt frames.

You can use the HDCP 1.4 registers to customize your design configurations. The HDCP 1.4 TX core supports full handshaking mechanism for authentication. Every issued command should be followed by polling of the assertion of its corresponding status bit before proceeding to issuing the next command. The value of AUTH_CMD must be in one-hot format that only one bit can be set at a time.

The Nios II processor typically drives the HDCP 2.3 TX core. The processor implements the authentication protocol. The processor accesses the IP through the Control and Status Port using Avalon Memory Mapped (Avalon-MM) interface.

The HDCP specifications requires the HDCP 2.3 TX core to be programmed with the DCP-issued production key – Global Constant (lc128). The IP retrieves the key from the on-chip memory externally to the core through the HDCP Key Port. The on-chip memory must store the key data in the arrangement in the table below.

The Video Stream and Auxiliary Layer receives audio and video content over its Video and Aux Data Input port, and performs the encryption operation. The Video Stream and Auxiliary Layer detects the Encryption Status Signaling (ESS) provided by the HDMI TX core to determine when to encrypt frames.

You can use the HDCP 2.3 registers to perform authentication. The HDCP 2.3 TX core supports full handshaking mechanism for authentication. Every issued command should be followed by polling of the assertion of its corresponding status bit before proceeding to issuing the next command. The value of CRYPTO_CMD must be in one-hot encoding format that only one bit can be set at a time.

Each FRL packet comprises a single map character of 0 to 1022 data characters.

Each Character Block contains up to 502 FRL characters transporting FRL packets and eight FRL characters carrying Reed-Solomon parity data.

Each FRL Super Block is preceded by a group of three or four Start Super Blocks (SSB) or a group of three or four Scrambler Reset (SR) characters. SSB and SR characters are comma characters used by a receiver for character alignment.

The IP demultiplexes the data on the link into four RS blocks to create the RS parity words. The parity data are interleaved onto the data lanes.

The primitive polynomial used to form the GF (256) field is:

p(x)= X⁸ + x⁴ + x³ + x² + 1

The corresponding RS code generator polynomial used by the encoder is:

g(x) = x⁴ + 15x³ + 54x² + 120x + 64

The IP then encodes the scrambled data into FRL characters using 16B/18B encoding.

In FRL path, the IP processes video data in FRL characters per clock*18 bits. FRL characters per clock are always 16. The mixed-width FIFO converts the data width into (Number of lanes*Effective transceiver width) bits width. For each link rate, the frl_clk and tx_clk frequency is reconfigured to the specific ratio to keep the throughput of the data the same from frl_clk domain to tx_clk domain.

There are three possible oversampling factors: 3, 4, and 5. The oversampler assumes that the input word is only valid for the number of clock cycles defined by the oversampling factor. The oversampler is enabled when the outgoing data stream is determined to be below the TX transceiver minimum data rate. The oversampler then reads the DCFIFO once every number of clock cycles determined by the oversampling factor.

This clock enable pulse asserts every number of clock cycles defined by the oversampling factor and serves as a read request signal to clock the data out from the DCFIFO.

The HDMI source uses the I²C core to communicate with the SCDC and EDID from the HDMI sink through the DDC signals.

For HDMI source, you must instantiate 4 transceiver channels: 3 channels to transmit data and 1 channel to transmit clock information.

The core uses a general purpose phase-locked loop (GPLL), that is referenced by a transceiver output clock, to generate the link speed clock (ls_clk), FRL clock (frl_clk), and video clock (vid_clk). The transceiver PLL has two reference clocks:

• Reference clock 0 which supplied with arbitrary TMDS clock frequency
• Reference clock 1 supplied with free running 100 MHz clock

The link speed clock (ls_clk) is not required when you turn on the Support FRL parameter, and the FRL clock (frl_clk) is not required when you turn off the Support FRL parameter. When you turn on the Support FRL parameter, you can fix the video clock (vid_clk) at a static frequency of 225 MHz.

The transceiver PLL switches between reference clock 0 and reference clock 1 in TMDS and FRL modes.

The video data clocks into the core at vid_clk, the TMDS or FRL data clocks out from the core at tx_clk/ls_clk, and the FRL data clocks with frl_clk.

If an application requires low TMDS Bit Rate (below the transceiver minimum data rate requirement), then the application needs a user logic consisting of a DCFIFO and oversampling logic.

• The DCFIFO synchronizes the TMDS data from ls_clk to a faster transceiver output clock (tx_clk[0]).
• The oversampling logic repeats each bit of the TMDS data a given number of times.
• When you enable the oversampling control bit, the transceiver transmits the TMDS data between the HDMI source core and the oversampling logic.
• You can use tx_clk[0] across four channels if the transceiver is in bonding mode.

If an application does not require low TMDS Bit Rate, you can connect the core output directly to the transceiver with tx_clk[0] driving the core ls_clk. You do not require the GPLL to generate CLK1 (ls_clk).

Instead, the Nios^® II software manages the link training process, which is demonstrated in the Intel^® Arria^® 10 FRL design example.

Implement the link training external to the HDMI TX core according to the TX link training flow diagram shown below. The HDMI TX core generates different link training patterns on each lane based on your input through the scdc_frl_pattern port when scdc_frl_start is deasserted. When scdc_frl_start is asserted, the source core generates normal video.

The vid_valid signal at the HDMI TX core qualifies the validity of the data for every clock cycle. Due to the timing consideration on maximum FRL data rate, the transceiver width is set to 40 bits.

In the FRL clock domain, the TX core always processes the data in multiple of 18 bits because of the 16B/18B encoder in the FRL path. The FRL modules can process N (FRL char per clock) FRL characters in parallel. However, the FRL modules always process 16 FRL characters in parallel due to timing considerations.

Hence, frl_clk frequency = (data rate per lane * number of lanes) / (FRL char per clock*18)

Similarly, in the vid_clk domain, the TX core processes data in multiples of pixels (24 bits) in parallel. You can configure the number of pixels to be processed in parallel through the pixels per clock GUI parameter. However, due to timing consideration and backward compatibility, the IP sets the pixels per clock to 2 when you turn off Support FRL, and to 8 when you turn on Support FRL. Because the actual pixel clock may differ based on different resolutions, you can configure vid_clk to the maximum frequency per the specified link rate according to the following calculation:

vid_clk frequency = (data rate per lane * number of lanes) / (pixels per clock * 24)

To generate video data, you need to use the actual pixel clock but vid_clk runs at a faster frequency. You can use a FIFO buffer to clock the data between the actual pixel clock and vid_clk while generating the valid video data (vid_valid) based on the inverted empty FIFO buffer.

For example, when operating at 8 Gbps link rate while transmitting 7680 x 4320p30 RGB resolution, a test pattern generator configured at 8 pixels in parallel runs at 148.5 MHz with the vid_clk domain of the HDMI TX core operating at 166.67 MHz. Like this case, not every vid_clk has valid video data. You can handle similar cases using the inverted empty signal of the DCFIFO.

When vid_clk runs at a faster frequency than the actual pixel clock frequency/pixels per clock, toggle vid_valid to qualify the video data.

When vid_clk runs at the actual pixel clock frequency/pixels per clock, vid_valid should always remain asserted.

ls_clk frequency = data rate per lane / effective transceiver width = data rate per lane / 20

vid_clk frequency = (data rate per lane / effective transceiver width) / color depth ratio

• In TMDS mode:

  vid_clk frequency = (data rate per lane / effective transceiver width) / 4

• In FRL mode:

  vid_clk frequency = 225 MHz

The vid_ready signal toggles to indicate if the HDMI TX core is ready to take in new video data. In this case, you can use a DCFIFO IP to store the video data when the HDMI TX core is not ready (vid_ready is low). You need to configure the DCFIFO IP to show-ahead mode, with the vid_ready signal connected to the rden signal of the DCFIFO IP.

When vid_ready is low, the DCFIFO IP holds the video data immediately. When vid_ready goes high, the HDMI TX core processes the stored data without losing any valid video data.

The inverted empty signal from the DCFIFO IP sets the vid_valid signal to the HDMI TX core.

The sink core provides three (TMDS mode) or four (FRL mode) 20-bit or 40-bit data input paths corresponding to the color channels. The sink core clocks the three 20-bit or 40-bit channels from the transceiver outputs using the respective transceiver clock outputs.

• Blue channel: 0
• Green channel: 1
• Red channel: 2
• Clock channel: 3

For Support FRL = 1 design, in TMDS mode, a DCFIFO clocks the HDMI data stream from the scrambler, TMDS/TERC4 decoder in the transceiver recovered clock domain to vid_clk domain. All the blocks in the FRL path and video data operate in vid_clk domain.

When operating TMDS mode, the sink core accepts three 20-bit data input paths corresponding to each color channel. The sink core clocks the three 20-bit channels from the transceiver outputs using respective transceiver clock outputs.

• Blue channel: Data channel 0
• Green channel: Data channel 1
• Red channel: Data channel 2

When operating in FRL mode, the sink core accepts four 40-bit data input paths corresponding to each FRL channel. The sink core clocks the four 40-bit channels from the transceiver outputs using respective transceiver clock outputs.

• FRL channel 0: Data channel 0
• FRL channel 1: Data channel 1
• FRL channel 2: Data channel 2
• FRL channel 3: Data channel 3

The sink core provides N*48 bit video data per channel for each color channel, where N is number of pixels per clock.

The FIFO read signal of the channels is normally asserted. The sink core deasserts a particular FIFO read signal if a marker appears at its output and not in the other two FIFO outputs. By deasserting, the sink core stalls the data stream for sufficient cycles to remove the channel skew. If any of the FIFO channels overflow, the sink core asserts a reset signal which propagates backwards to the word alignment logic.

The sink core feeds the aligned channels into the TMDS/TERC4 decoder. You can parameterize the decoder to operate in 1, 2, or 4 TMDS symbols per clock. If you choose 2 or 4 TMDS symbols per clock, the decoder will produce 2 or 4 decoded symbols per clock. The decoded symbols per clock output supports high pixel clock resolutions on low-end FPGA devices.

The output from the resampler is fixed at 16 bpc. When the resampler operates in lower color depths, the low order bits are zero. The pixel data output format across color space are are described in Figure 10-12.

The data output at EOP contains the received BCH error correcting code. The sink core does not perform any error correction within the core. The auxiliary data is available outside the core.

These packets are: General Control Packet (GCP), Auxiliary Video Information (AVI) InfoFrame, and HDMI Vendor Specific InfoFrame (VSI).

The core calculates the address for the data port using the header byte of the received packet. The core writes packet types 0–15 into a contiguous memory region.

An audio clock synthesizer uses a phase-counter to recover the audio sample rate. The output from the audio clock synthesizer generates a valid pulse at the same rate as the audio sample clock from the attached source device. This valid pulse is available outside the core as an audio sample valid signal. This signal reads from a FIFO, which governs the rate of audio samples. The audio depacketizer drives the input to the FIFO.

The audio depacketizer extracts the 32-bit audio sample data from the incoming Audio Sample packets. The Audio Sample packets can hold from one to four sample data values. The audio format indicates the format of the received audio data as defined in Table 26.

The Audio InfoFrame and Audio Metadata packets are not used within the core. The packets are captured and presented outside the core. The bit fields (excluding control bit) are defined in Table 27, Table 28, Table 29, and Table 30 with reserved bits return 0.

This memory slave port connects to an I²C slave component. The TMDS_Bit_clock_Ratio output from the SCDC interface indicates when the core requires the TMDS Bit Rate/TMDS Clock Rate ratio of 40. This bit is also stored in its corresponding field in the SCDC registers.

The HDMI 2.0b Specification requires the core to respond to the presence of the 5V input from the connector and the state of the HPD signal. The 5V input and HPD signal are used in the register mechanism updates. The signals are synchronous to the i2c_clk clock domain. You must create a 100-ms delay on the HPD signal externally to the core.

For more information about the Status and Control Data Channel, you may refer to HDMI 2.0b Specification Chapter 10.4. You can obtain the address map for the registers in the HDMI 2.0b Specification.

The HDCP 1.4 RX core is fully autonomous. For HDMI application, the transmitter drives the HDCP 1.4 RX core using the standard DDC interface supporting I²C protocol. You need an I²C slave externally to drive the IP through the HDCP Register Port (Avalon-MM).

The HDCP specifications requires the HDCP 2.3 RX core to be programmed with the DCP-issued production key – Device Private Keys (Bkeys) and Key Selection Vector (Bksv). The IP retrieves the key from the on-chip memory externally to the core through the HDCP Key Port. The on-chip memory must store the key data in the arrangement shown in the table below.

The Video Stream and Auxiliary Layer receives audio and video content over its Video and Aux Data Input Port, and performs the decryption operation. The Video Stream and Auxiliary Layer detects the Encryption Status Signaling (ESS) provided by the HDMI IP to determine when to decrypt frames.

To implement the HDCP 1.4 RX core as a repeater upstream interface, the IP must propagate certain information such as KSV list and Bstatus to the upstream transmitter and to be used for SHA-1 hash digest. The repeater downstream interface (TX) must provide this information using the Repeater Message Port (Avalon-MM). You can use the same clock source to drive the clocking for the HDCP Register Port and Repeater Message Port.

The RX registers mapping defined in the following table is equivalent to the address space for HDCP 1.4 receiver defined in the HDCP specification.

The HDCP 2.3 RX core is fully autonomous. For HDMI application, the transmitter drives the HDCP 2.3 RX core using the standard DDC interface supporting I²C protocol.

The HDCP specifications requires the HDCP 2.3 RX core to be programmed with the DCP-issued production key – Global Constant (lc128), RSA private key (kprivrx) and RSA Public Key Certificate (certrx). The IP retrieves the key from the on-chip memory externally to the core through the HDCP Key Port. The on-chip memory must store the key data in the arrangement shown in the table below.

The Video Stream and Auxiliary Layer receives audio and video content over its Video and Aux Data Input Port, and performs the decryption operation. The Video Stream and Auxiliary Layer detects the Encryption Status Signaling (ESS) provided by the HDMI IP to determine when to decrypt frames.

To implement the HDCP 2.3 RX core as a repeater upstream interface, the IP must propagate certain information such as ReceiverID List and RxInfo to the upstream transmitter and to be used for HMAC computation. The repeater downstream interface (TX) must provide this information using the Repeater Message Port (Avalon-MM). You can use the same clock source to drive the clocking for the HDCP Register Port and Repeater Message Port.

The RX registers mapping defined in the following table is equivalent to the address space for HDCP 2.3 receiver defined in the HDCP specification.

FRL depacketizer contains a mixed-width DCFIFO to clock the data from the frl_clk domain to the vid_clk domain. This block also demaps the HDMI data from number of FRL characters per clock * 16 bits to pixels per clock * 24 bits, where number of FRL characters per clock is always 16 and pixels per clock is always 8 in FRL mode.

The HDMI RX core achieves FRL character alignment based on the Start Super Block (SSB) or Scrambler Reset (SR) character proceeded FRL super block.

The mixed-width FIFO buffer demaps the FRL data in effective transceiver width bits to FRL characters in parallel*18 bits. For FRL mode, the transceiver width is always 40 bits and number of FRL characters in parallel is 16.

The oversampling factor on the RX is set to 5. For example, a video resolution with TMDS Bit Rates of 742.5 Mb/s should configure the transceiver to operate at 5 times its data rate, which is 3.7125 Gb/s.

• One slave is for the EDID address (0x50).

  You need to instantiate a separate memory (ROM/RAM) to interface with this slave. The HDMI IP also has an optional feature to include a RAM for EDID.

• The other slave is for the SCDC address (0x54).

  The I2C slave for the SCDC will be directly interfaced with the HDMI core for the SCDC registers operation.

You need to specify your EDID content in a .mif or .hex file before you start generating the IP. You can also modify your EDID contents at run time.

The edid_ram_access signal acts as a trigger to the EDID RAM. When this signal is asserted, the IP holds the hpd signal low. During this period, you are free to modify the RAM content by accessing its Avalon memory-mapped interface through an Avalon memory-mapped master, such as NIOS.

After you are done modifying the RAM contents, deassert the edid_ram_access signal to reassert the hpd signal. The source device rereads the new EDID content.