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

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

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

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

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

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

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

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

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

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 HDCP over HDMI hardware design example helps you to evaluate the functionality of the HDCP feature and enables you to use the feature in your Intel^® Arria^® 10 designs.

Intel created the original technology, which is licensed by the Digital Content Protection LLC group. HDCP is a copy protection method where the audio/video stream is encrypted between the transmitter and the receiver, protecting it against illegal copying.

The HDCP features adheres to HDCP Specification version 1.4 and HDCP Specification version 2.3.

The HDCP 1.4 and HDCP 2.3 IPs perform all computation within the hardware core logic with no confidential values (such as private key and session key) being accessible from outside the encrypted IP.

This design example demonstrates the HDCP system in a repeater device where it accepts data, decrypts, then re-encrypts the data, and finally retransmits data. Repeaters have both HDMI inputs and outputs. It instantiates the FIFO buffers to perform a direct HDMI video stream pass-through between the HDMI sink and source. It may perform some signal processing, such as converting videos into a higher resolution format by replacing the FIFO buffers with the Video and Image Processing (VIP) Suite IP cores.

The following descriptions about the architecture of the design example correspond to the HDCP over HDMI design example block diagram.

1. The HDCP1x and HDCP2x are IPs that are available through the HDMI Intel^® FPGA IP parameter editor. When you configure the HDMI IP in the parameter editor, you can enable and include either HDCP1x or HDCP2x or both IPs as part of the subsystem. With both HDCP IPs enabled, the HDMI IP configures itself in the cascade topology where the HDCP2x and HDCP1x IPs are connected back-to-back.
   • The HDCP egress interface of the HDMI TX sends unencrypted audio video data.
   • The unencrypted data gets encrypted by the active HDCP block and sent back into the HDMI TX over the HDCP Ingress interface for transmission over the link.
   • The CPU subsystem as the authentication master controller ensures that only one of the HDCP TX IPs is active at any given time and the other one is passive.
   • Similarly, the HDCP RX also decrypts data received over the link from an external HDCP TX.
2. You need to program the HDCP IPs with Digital Content Protection (DCP) issued production keys. Load the following keys:

   Table 11.  DCP-issued Production Keys

   HDCP	TX/RX	Keys
   HDCP2x	TX	16 bytes: Global Constant (lc128)
   	RX	16 bytes (same as TX): Global Constant (lc128) 320 bytes: RSA Private Key (kprivrx) 522 bytes: RSA Public Key Certificate (certrx)
   HDCP1x	TX	5 bytes: TX Key Selection Vector (Aksv) 280 bytes: TX Private Device Keys (Akeys)
   	RX	5 bytes: RX Key Selection Vector (Bksv) 280 bytes: RX Private Device Keys (Bkeys)

   The design example implements the key memories as simple dual-port, dual-clock synchronous RAM. For small key size like HDCP2x TX, the IP implements the key memory using registers in regular logic.

   Note: Intel does not provide the HDCP production keys with the design example or Intel^® FPGA IPs under any circumstances. To use the HDCP IPs or the design example, you must become an HDCP adopter and acquire the production keys directly from the Digital Content Protection LLC (DCP).

   To run the design example, you either edit the key memory files at compile time to include the production keys or implement logic blocks to securely read the production keys from an external storage device and write them into the key memories at run time.

3. You can clock the cryptographic functions implemented in the HDCP2x IP with any frequency up to 200 MHz. The frequency of this clock determines how quickly the HDCP2x authentication operates. You can opt to share the 100 MHz clock used for Nios II processor but the authentication latency would be doubled compared to using a 200 MHz clock.
4. The values that must be exchanged between the HDCP TX and the HDCP RX are communicated over the HDMI DDC interface (I²C serial interface) of the HDCP-protected interface. The HDCP RX must present a logical device on the I²C bus for each link that it supports. The I²C slave is duplicated for HDCP port with device address of 0x74. It drives the HDCP register port (Avalon-MM) of both the HDCP2x and HDCP1x RX IPs.
5. The HDMI TX uses the I²C master to read the EDID from RX and transfer the SCDC data that is required for HDMI 2.0 operation to RX. The same I²C master that is driven by the Nios II processor is also used to transfer the HDCP messages between TX and RX. The I²C master is embedded in the CPU subsystem.
6. The Nios II processor acts as the master in the authentication protocol and drives the control and status registers (Avalon-MM) of both the HDCP2x and HDCP1x TX IPs. The software drivers implements the authentication protocol state machine including certificate signature verification, master key exchange, locality check, session key exchange, pairing, link integrity check (HDCP1x), and authentication with repeaters, such as topology information propagation and stream management information propagation. The software drivers do not implement any of the cryptographic functions required by the authentication protocol. Instead, the HDCP IP hardware implements all the cryptographic functions ensuring no confidential values can be accessed.
7. In a true repeater demonstration where propagating topology information upstream is required, the Nios II processor drives the Repeater Message Port (Avalon-MM) of both HDCP2x and HDCP1x RX IPs. The Nios II processor clears the RX REPEATER bit to 0 when it detects the connected downstream is not HDCP-capable or when no downstream is connected. Without downstream connection, the RX system is now an end-point receiver, rather than a repeater. Conversely, the Nios II processor sets the RX REPEATER bit to 1 upon detecting the downstream is HDCP-capable.

The Nios II software flowchart includes the HDCP authentication controls over HDMI application.

1. The Nios II software initializes and resets the HDMI TX PLL, TX transceiver PHY, I²C master and the external TI retimer.
2. The Nios II software polls periodic rate detection valid signal from RX rate detection circuit to determine whether video resolution has changed and if TX reconfiguration is required. The software also polls the TX hot-plug detect signal to determine whether a TX hot-plug event has occurred.
3. When a valid signal received from RX rate detection circuit, the Nios II software reads the SCDC and clock depth values from the HDMI RX and retrieves the clock frequency band based on the detected rate to determine whether HDMI TX PLL and transceiver PHY reconfiguration are required. If TX reconfiguration is required, the Nios II software commands the I²C master to send the SCDC value over to external RX. It then commands to reconfigure the HDMI TX PLL and TX transceiver PHY, followed by device recalibration, and reset sequence. If the rate does not change, neither TX reconfiguration nor HDCP re-authentication is required.
4. When a TX hot-plug event has occurred, the Nios II software commands the I²C master to send the SCDC value over to external RX, and then read EDID from RX and update the internal EDID RAM. The software then propagates the EDID information to the upstream.
5. The Nios II software starts the HDCP activity by commanding the I²C master to read offset 0x50 from external RX to detect if the downstream is HDCP-capable, or otherwise:
   • If the returned HDCP2Version value is 1, the downstream is HDCP2x-capable.
   • If the returned value of the entire 0x50 reads are 0’s, the downstream is HDCP1x-capable.
   • If the returned value of the entire 0x50 reads are 1’s, the downstream is either not HDCP-capable or inactive.
   • If the downstream is previously not HDCP-capable or inactive but is currently HDCP-capable, the software sets the REPEATER bit of the repeater upstream (RX) to 1 to indicate the RX is now a repeater.
   • If the downstream is previously HDCP-capable but is currently not HDCP-capable or inactive, the software sets the REPEATER bit of to 0 to indicate the RX is now an endpoint receiver.
6. The software initiates the HDCP2x authentication protocol that includes RX certificate signature verification, master key exchange, locality check, session key exchange, pairing, authentication with repeaters such as topology information propagation.
7. When in authenticated state, the Nios II software commands the I²C master to poll the RxStatus register from external RX, and if the software detects the REAUTH_REQ bit is set, it initiates re-authentication and disables TX encryption.
8. When the downstream is a repeater and the READY bit of the RxStatus register is set to 1, this usually indicates the downstream topology has changed. So, the Nios II software commands the I²C master to read the ReceiverID_List from downstream and verify the list. If the list is valid and no topology error is detected, the software proceeds to the Content Stream Management module. Otherwise, it initiates re-authentication and disables TX encryption.
9. The Nios II software prepares the ReceiverID_List and RxInfo values and then writes to the Avalon-MM Repeater Message port of the repeater upstream (RX). The RX then propagates the list to external TX (upstream).
10. Authentication is complete at this point. The software enables TX encryption.
11. The software initiates the HDCP1x authentication protocol that includes key exchange and authentication with repeaters.
12. The Nios II software performs link integrity check by reading and comparing Ri’ and Ri from external RX (downstream) and HDCP1x TX respectively. If the values do not match, this indicates loss of synchronization and the software initiates re-authentication and disables TX encryption.
13. If the downstream is a repeater and the READY bit of the Bcaps register is set to 1, this usually indicates that the downstream topology has changed. So, the Nios II software commands the I²C master to read the KSV list value from downstream and verify the list. If the list is valid and no topology error is detected, the software prepares the KSV list and Bstatus value and writes to the Avalon-MM Repeater Message port of the repeater upstream (RX). The RX then propagates the list to external TX (upstream). Otherwise, it initiates re-authentication and disables TX encryption.

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.

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.

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 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 24. Table 25. and Table 26 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 27.

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

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

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