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

The HDMI cable and connectors carry four differential pairs that make up the Transition Minimized Differential Signaling (TMDS) data and clock channels. You can use these channels to carry video, audio, and auxiliary data.

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

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

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

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.

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

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

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 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 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 10-bit, 20-bit or 40-bit parallel data paths corresponding to the 3 color channels and the clock channel.

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

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 Audio Clock Regeneration packet contains the CTS and N values. You need to provide these values as recommended in HDMI 1.4b Specification Section 7.2.1 through 7.2.3 and HDMI 2.0b Specification Section 9.2.1. The core schedules this packet to be sent every ms. The timestamp scheduler uses the audio_clk and N value to determine a 1-ms interval.

The audio data queues on a DCFIFO. The core also uses the DCFIFO to synchronize its clock to ls_clk. The Audio Packetizer packs the audio data into the Audio Sample packets according to the specified audio format (as described in HDMI 1.4b Specification Section 5.3.4). An Audio Sample packet can contain up to 4 audio samples, based on the required audio sample clock. The core sends the Audio Sample packets whenever there is an available slot in the auxiliary packet stream.

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

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.

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

The core uses a general purpose phase-locked loop (GPLL), that is referenced by an arbitrary TMDS clock frequency, to generate the link speed clock (ls_clk) and video clock (vid_clk).

• The video data clocks into the core at vid_clk.
• The TMDS data clocks out from the core at ls_clk.

The same arbitrary TMDS clock frequency is also used to drive the transceiver PLL. ls_clk and tx_clkout[0] are derived from vid_clk based on the color depth, TMDS_Bit_clock_Ratio, and user oversampling control bit information.

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

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

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

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 sink core decodes the auxiliary data path into a 72-bit wide standard packet stream. The stream contains a valid, start-of-packet (SOP) and end-of-packet (EOP) marker.

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 GCP, AVI and VSI bit-fields (excluding control bit) are defined in Table 19. Table 20. and Table 21 respectively with reserved bits return 0.

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

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 23, Table 24, Table 25, and Table 26 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 scdc_i2c_clk clock domain. You must create a 100-ms delay on the HPD signal externally to the core.

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

The logic clocks the transceiver data into the core using the three CDR clocks: (rx_clk[2:0]).

The TMDS and TERC4 decoding is done at the link-speed clock (ls_clk). The sink then resamples the pixel data and presents the data at the output of the core at the video pixel clock (vid_clk).

The pixel data clock depends on the video format used (within HDMI specification).

For HDMI sink, you must instantiate 3 receiver channels to receive TMS data.

The core uses a general purpose phase-locked loop (GPLL), that is referenced by the source Clock Channel, to generate the transceiver CDR reference clock (rx_refclk), link speed clock (ls_clk), and video clock (vid_clk) for the core.

• The TMDS data clocks into the core at ls_clk[2:0] with all channels driven by the same clock source (GPLL CLK1).
• The video data clocks out from the core at vid_clk.

rx_refclk, ls_clk, and vid_clk are derived based on the color depth, TMDS_Bit_clock_Ratio, user oversampling control bit information, and the detected Clock Channel frequency band.

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

• The oversampling logic extracts the data from the oversampled incoming data stream.
• When you enable the oversampling control bit, the DCFIFO gets the TMDS data between the transceiver and the oversampling logic.
• The DCFIFO synchronizes the TMDS data from the fastest transceiver output clock (rx_clkout[2:0]) to the ls_clk domain.

If an application does not require low TMDS Bit Rate, the Clock Channel drives the transceiver rx_refclk directly. You can also connect the transceiver output to the core with ls_clk[2:0] driven by rx_clkout[2:0].