HDMI Intel Stratix 10 FPGA IP Design Example User Guide

RSS

UG-20168 | 2020.12.14

Version Information

Updated for:
Intel® Quartus® Prime Design Suite 20.4
IP Version 19.6.0

1. HDMI Intel FPGA IP Design Example Quick Start Guide for Intel Stratix 10 Devices

The HDMI Intel^® FPGA IP design example for Intel^® Stratix^® 10 devices features a simulating testbench and a hardware design that supports compilation and hardware testing.

The HDMI Intel^® FPGA IP offers the following design examples:

HDMI 2.1 RX-TX retransmit design with fixed rate link (FRL) mode enabled
HDMI 2.0 RX-TX retransmit design
HDCP over HDMI 2.0 design
Note: The HDCP feature is not included in the Intel^® Quartus^® Prime Pro Edition software. To access the HDCP feature, contact Intel at https://www.intel.com/content/www/us/en/broadcast/products/programmable/applications/connectivity-solutions.html.

When you generate a design example, the parameter editor automatically creates the files necessary to simulate, compile, and test the design in hardware.

Figure 1. Development Steps

1.1. Directory Structure

The directories contain the generated files for the HDMI Intel^® FPGA IP design example.

Figure 2. Directory Structure for the Design Example

Table 1. Generated RTL Files
Folders	Files
gxb	/gxb_rx.ip
	/gxb_rx_reset.ip
	/gxb_tx.ip
	/gxb_tx_fpll.ip
	/gxb_tx_reset.ip
hdmi_rx	/hdmi_rx.ip
	/hdmi_rx_top.v
	/Panasonic.hex
	/symbol_aligner.v
hdmi_tx	/hdmi_tx.ip
hdmi_tx	/hdmi_tx_top.v
i2c_slave	/i2c_avl_mst_intf_gen.v
	/i2c_clk_cnt.v
	/i2c_condt_det.v
	/i2c_databuffer.v
	/i2c_rxshifter.v
	/i2c_slvfsm.v
	/i2c_spksupp.v
	/i2c_txout.v
	/i2c_txshifter.v
	/i2cslave_to_avlmm_bridge.v
pll	/pll_hdmi.ip
pll	/pll_hdmi_reconfig.ip
common	/clock_control.ip
	/clock_crosser.v
	/dcfifo_inst.v
	/debouncer.v
	/fifo.ip
	/alt_reset_delay.v
	/device_init.v
	/output_buf_i2c.ip
	/reset_release.ip
hdr	/altera_hdmi_aux_hdr.v
	/altera_hdmi_aux_snk.v
	/altera_hdmi_aux_src.v
	/altera_hdmi_hdr_infoframe.v
	/avalon_st_mutiplexer.qsys
reconfig_mgmt	/mr_compare_pll.v
	/mr_compare_rx.v
	/mr_rate_detect.v
	/mr_reconfig_master_pll.v
	/mr_reconfig_master_rx.v
	/mr_reconfig_mgmt.v
	/mr_rom_pcs.v
	/mr_rom_pll_valuemask_8bpc.v
	/mr_rom_pll_valuemask_10bpc.v
	/mr_rom_pll_valuemask_12bpc.v
	/mr_rom_pll_valuemask_16bpc.v
	/mr_rom_rx_dprioaddr_bitmask.v
	/mr_rom_rx_valuemask.v
	/mr_state_machine.v
sdc	/s10_hdmi2.sdc
	/mr_reconfig_mgmt.sdc
	`/jtag.sdc`
	/rxtx_link.sdc

Table 2. Generated Simulation Files
Folders	Files
aldec	/aldec.do
aldec	/rivierapro_setup.tcl
cadence	/cds.lib
	/hdl.var
	/ncsim.sh
	/ncsim_setup.sh
	<`cds_libs folder`>
mentor	/mentor.do
mentor	/msim_setup.tcl
synopsys	/vcs/filelist.f
	/vcs/vcs_setup.sh
	/vcs/vcs_sim.sh
	/vcsmx/vcsmx_setup.sh
	/vcsmx/vcsmx_sim.sh
	/vcsmx/synopsys_sim_setup
xcelium	/cds.lib
	/hdl.var
	/xcelium_sim.sh
	/xcelium_setup.sh
	<`cds_libs folder`>
common	/modelsim_files.tcl
	/ncsim_files.tcl
	/riviera_files.tcl
	/vcs_files.tcl
	/vcsmx_files.tcl
	/xcelium_files.tcl
hdmi_rx	/hdmi_rx.ip
	/hdmi_rx.sopcinfo
	/Panasonic.hex
	/symbol_aligner.v
hdmi_tx	/hdmi_tx.ip
hdmi_tx	/hdmi_tx.sopcinfo

Table 3. Generated Software Files
Folders	Files
tx_control_src Note: The tx_control folder will also contain duplicates of these files.	`/i2c.c`
	`/i2c.h`
	`/main.c`
	`/xcvr_gpll_rcfg.c`
	`/xcvr_gpll_rcfg.h`
	`/intel_fpga_i2c.c`
	`/intel_fpga_i2c.h`

1.2. Generating the Design

Use the HDMI Intel^® FPGA IP parameter editor in the Intel^® Quartus^® Prime software to generate the design examples.

Figure 3. Generating the Design Flow

Create a project targeting Intel^® Stratix^® 10 device family and select the desired device.
In the IP Catalog, locate and double-click HDMI Intel^® FPGA IP . The New IP Variant or New IP Variation window appears.
Specify a top-level name for your custom IP variation. The parameter editor saves the IP variation settings in a file named <your_ip>.ip.
Click OK. The parameter editor appears.
On the IP tab, configure the desired parameters for both TX and RX.
Turn on the Support FRL parameter to generate the HDMI 2.1 design example in FRL mode. Turn it off to generate the HDMI 2.0 design example without FRL.
On the Design Example tab, select Stratix 10 HDMI RX-TX Retransmit.
Select Simulation to generate the testbench, and select Synthesis to generate the hardware design example.
You must select at least one of these options to generate the design example files. If you select both, the generation time is longer.
For Generate File Format, select Verilog or VHDL.
For Select Board, select the relevant development kit. You may change the target device using the Change Target Device parameter if your board revision does not match the grade of the default targeted device. For Stratix 10 GX FPGA L-tile Development Kit, the default device is 1SG280LU2F50E2VG, and for Stratix 10 GX FPGA H-tile Development Kit, the default device is 1SG280HU2F50E2VG.
Click Generate Example Design.

1.3. Hardware and Software Requirements

Intel uses the following hardware and software to test the design example.

Hardware

Intel^® Stratix^® 10 FPGA (L-tile or H-tile) Development Kit
HDMI Source (Graphics Processor Unit (GPU))
HDMI Sink (Monitor)
Bitec HDMI FMC 2.0 daughter card (Revision 11) or Bitec HDMI FMC 2.1 daughter card (Revision 4 or 4a)
HDMI cables

Note: If you are working on the HDMI 2.0 design example, you can select the revision of the Bitec HDMI daughter card by setting the local parameter BITEC_DAUGHTER_CARD_REV to 4, 6, or 11 in the top-level file ( s10_hdmi2_demo.v). When you change the revision, the design may swap the transceiver channels and invert the polarity according to the Bitec HDMI daughter card requirements. If you set the BITEC_DAUGHTER_CARD_REV parameter to 0, the design does not make any changes to the transceiver channels and the polarity.

Software

Intel^® Quartus^® Prime Pro Edition version 20.4 and later (for hardware testing)
ModelSim* - Intel^® FPGA Edition, ModelSim* - Intel^® FPGA Starter Edition, NCSim, Riviera-PRO* , VCS* (Verilog HDL only)/ VCS* MX, or Xcelium* Parallel simulator

1.4. Simulating the Design

The HDMI testbench simulates a serial loopback design from a TX instance to an RX instance. Internal video pattern generator, audio sample generator, sideband data generator, and auxiliary data generator modules drive the HDMI TX instance and the serial output from the TX instance connects to the RX instance in the testbench.

Figure 4. Design Simulation Flow

Go to the desired simulation folder.
Run the simulation script for the supported simulator of your choice. The script compiles and runs the testbench in the simulator.

Analyze the results.

Table 4. Steps to Run Simulation
Simulator	Working Directory	Instructions
Riviera-PRO*	/simulation/aldec	In the command line, type vsim -c -do aldec.do
NCSim	/simulation/cadence	In the command line, type source ncsim.sh
ModelSim*	/simulation/mentor	In the command line, type vsim -c -do mentor.do
VCS*	/simulation/synopsys/vcs	In the command line, type source vcs_sim.sh
VCS* MX	/simulation/synopsys/vcsmx	In the command line, type source vcsmx_sim.sh
Xcelium* Parallel	/simulation/xcelium	In the command line, type source xcelium_sim.sh

A successful simulation ends with the following message:

# SYMBOLS_PER_CLOCK 	= 2
# VIC               	= 4
# FRL_RATE          	= 0
# BPP               	= 0
# AUDIO_FREQUENCY (kHz)  = 48
# AUDIO_CHANNEL     	= 8
# Simulation pass

1.5. Compiling and Testing the Design

To compile and run a demonstration test on the hardware example design, follow these steps:

Ensure hardware example design generation is complete.
Launch the Intel^® Quartus^® Prime Pro Edition software and open the .qpf file.
- HDMI 2.1 design example with Support FRL enabled: project directory/quartus/s10_hdmi21_frl_demo.qpf
- HDMI 2.0 design example with Support FRL disabled: project directory/quartus/s10_hdmi2_demo.qpf
Click Processing > Start Compilation.
After successful compilation, a .sof file will be generated in your specified directory.
If you are running HDMI 2.1 design example, you must program the Si5341 programmable oscillator OUT4 to 100 MHz through the Intel^® Stratix^® 10 Clock Control GUI. Otherwise, skip this step.

Figure 5. Si5341 Tab
Connect to the on-board FMC (J13):
- HDMI 2.1 design example with Support FRL enabled: Bitec HDMI FMC 2.1 Daughter Card (Revision 4 or 4a)
- HDMI 2.0 design example with Support FRL disabled: Bitec HDMI FMC 2.0 Daughter Card (Revision 11)
Connect TX (P1) of the Bitec HDMI FMC Daughter Card to an external video source.
Connect RX (P2) of the Bitec HDMI FMC Daughter Card to an external video sink or video analyzer.
Ensure all switches on the development board are in default position.
Configure the selected Intel^® Stratix^® 10 device on the development board using the generated .sof file (Tools > Programmer ).
The analyzer should display the video generated from the source.

1.6. Design Limitation

You need to consider some limitations when instantiating the HDMI Intel^® FPGA IP design examples.

You may encounter longer lock time using the HDMI RX for HDMI 2.0 resolution. This limitation will be resolved in a future release.

1.7. HDMI Intel FPGA IP Design Example Parameters

Table 5. HDMI Intel^® FPGA IP Design Example Parameters for Intel^® Stratix^® 10 DevicesThese options are available for Intel^® Stratix^® 10 devices only.
Parameter	Value	Description
Available Design Example
Select Design	Stratix 10 HDMI RX-TX Retransmit	Select the design example to be generated. The generated design example has pre-configured parameter settings. It does not follow user settings.
Design Example Files
Simulation	On, Off	Turn on this option to generate the necessary files for the simulation testbench.
Synthesis	On, Off	Turn on this option to generate the necessary files for Intel^® Quartus^® Prime compilation and hardware demonstration.
Generated HDL Format
Generate File Format	Verilog, VHDL	Select your preferred HDL format for the generated design example fileset. Note: This option only determines the format for the generated top level IP files. All other files (e.g. example testbenches and top level files for hardware demonstration) are in Verilog HDL format.
Target Development Kit
Select Board	No Development Kit, Stratix 10 GX FPGA L-tile Development Kit, Stratix 10 GX FPGA H-tile Development Kit, Custom Development Kit	Select the board for the targeted design example. No Development Kit: This option excludes all hardware aspects for the design example. The IP core sets all pin assignments to virtual pins. Stratix 10 GX FPGA H-tile or L-tile Development Kit: This option automatically selects the project's target device to match the device on this development kit. You may change the target device using the Change Target Device parameter if your board revision has a different device variant. The IP core sets all pin assignments according to the development kit. Custom Development Kit: This option allows the design example to be tested on a third party development kit with an Intel FPGA. You may need to set the pin assignments on your own.
Target Device
Change Target Device	On, Off	Turn on this option and select the preferred device variant for the development kit.

2. HDMI 2.1 Design Example (Support FRL = 1)

The HDMI 2.1 design example in FRL mode demonstrates one HDMI instance parallel loopback comprising four RX channels and four TX channels.

Table 6. HDMI 2.1 Design Example for Intel^® Stratix^® 10 Devices
Design Example	Data Rate	Channel Mode	Loopback Type
Stratix10 HDMI RX-TX Retransmit	12 Gbps (FRL) 10 Gbps (FRL) 8 Gbps (FRL) 6 Gbps (FRL) 3 Gbps (FRL) <6 Gbps (TMDS)	Simplex	Parallel with FIFO buffer

Features

The design instantiates FIFO buffers to perform a direct HDMI video stream passthrough between the HDMI 2.1 sink and source.
The design is capable to switch between FRL mode and TMDS mode during run time.
The design uses LED status for early debugging stage.
The design comes with HDMI RX and TX instances.
The design demonstrates the insertion and filtering of Dynamic Range and Mastering (HDR) InfoFrame in RX-TX link module.
The design negotiates the FRL rate between the sink connected to TX and the source connected to RX. The design passes through the EDID from the external sink to the on-board RX in default configuration. The Nios^® II processor negotiates the link base on the capability of the sink connected to TX. You can also toggle the user_dipsw on-board switch to manually control the TX and RX FRL capabilities.
The design includes several debugging features.

2.1. HDMI 2.1 RX-TX Retransmit Design Block Diagram

The HDMI RX-TX retransmit design example demonstrates parallel loopback on simplex channel mode for HDMI 2.1 with Support FRL enabled.

Figure 6. HDMI 2.1 RX-TX Retransmit Block Diagram

2.2. Creating RX-Only or TX-Only Designs

For advanced users, you can use the HDMI 2.1 design to create a TX- or RX-only design.

Figure 7. Components Required for RX-Only or TX-Only Design

To use RX- or TX-only components, remove the irrelevant blocks from the design.

Table 7. RX-Only and TX-Only Design Requirements
User Requirements	Preserve	Remove	Add
HDMI RX only	RX Top	TX Top RX-TX Link CPU Subsystem Transceiver Arbiter	–
HDMI TX only	TX Top CPU Sub-System	RX Top RX-TX Link Transceiver Arbiter	Video Pattern Generator (custom module or generated from the Video and Image Processing (VIP) Suite)

Besides the RTL changes, you need to also edit the main.c script.

For HDMI TX-only designs, decouple the wait for the HDMI RX lock status by removing the following lines and replace with tx_xcvr_reconfig(tx_frl_rate);
rx_hdmi_lock = READ_PIO(PIO_IN0_BASE, PIO_RX_LOCKED_OFFSET, PIO_RX_LOCKED_WIDTH);

while (rx_hdmi_lock == 0) {

if (check_hpd_isr()) { break; }

// rx_vid_lock = READ_PIO(PIO_IN0_BASE, PIO_VID_LOCKED_OFFSET, PIO_VID_LOCKED_WIDTH);

rx_hdmi_lock = READ_PIO(PIO_IN0_BASE, PIO_RX_LOCKED_OFFSET, PIO_RX_LOCKED_WIDTH);

// Reconfig Tx after rx is locked

if (rx_hdmi_lock == 1) {

if (READ_PIO(PIO_IN0_BASE, PIO_LOOPBACK_MODE_OFFSET, PIO_LOOPBACK_MODE_WIDTH) == 1) {

rx_frl_rate = READ_PIO(PIO_IN0_BASE, PIO_RX_FRL_RATE_OFFSET, PIO_RX_FRL_RATE_WIDTH);

tx_xcvr_reconfig(rx_frl_rate);

} else {

tx_xcvr_reconfig(tx_frl_rate);

} } }
For HDMI RX-only designs, keep only the following lines in the main.c script:
REDRIVER_INIT();

hdmi_rx_init();

2.3. Hardware and Software Requirements

Intel uses the following hardware and software to test the design example.

Hardware

Intel^® Stratix^® 10 GX FPGA Development Kit
HDMI 2.1 Source (Quantum Data 980 48G Generator)
HDMI 2.1 Sink (Quantum Data 980 48G Analyzer)
Bitec HDMI FMC 2.1 daughter card (Revision 4.0)
HDMI 2.1 Category 3 cables (tested with Belkin 48Gbps HDMI 2.1 Cable)

Software

Intel^® Quartus^® Prime Pro Edition software version 20.3

2.4. Directory Structure

The directories contain the generated files for the HDMI Intel^® FPGA IP design example.

Figure 8. Directory Structure for the Design Example

Table 8. Generated RTL Files
Folders	Files/Subfolders
common	clock_control.ip
	clock_crosser.v
	dcfifo_inst.v
	edge_detector.sv
	fifo.ip
	output_buf_i2c.ip
	test_pattern_gen.v
	tpg.v
	tpg_data.v
gxb	gxb_rx.ip
	gxb_rx_reset.ip
	gxb_tx.ip
	gxb_tx_fpll.ip
	gxb_tx_reset.ip
hdmi_rx	hdmi_rx.ip
	hdmi_rx_top.v
	hdmi_ltp_chk.v
	Panasonic.hex
hdmi_tx	hdmi_tx.ip
hdmi_tx	hdmi_tx_top.v
i2c_slave	i2c_avl_mst_intf_gen.v
	i2c_clk_cnt.v
	i2c_condt_det.v
	i2c_databuffer.v
	i2c_rxshifter.v
	i2c_slvfsm.v
	i2c_spksupp.v
	i2c_txout.v
	i2c_txshifter.v
	i2cslave_to_avlmm_bridge.v
pll	pll_hdmi_reconfig.ip
	pll_frl.ip
	pll_reconfig_ctrl.v
	pll_tmds.ip
	pll_vidclk.ip
	quartus.ini
rxtx_link	`altera_hdmi_hdr_infoframe.v`
	`aux_mux.qsys`
	`aux_retransmit.v`
	`aux_src_gen.v`
	`ext_aux_filter.v`
	`rxtx_link.v`
	`scfifo_vid.ip`
reconfig	mr_rx_iopll_tmds/
	mr_rxphy/
	mr_tx_fpll/
	altera_xcvr_functions.sv
	mr_compare.sv
	mr_rate_detect.v
	mr_rx_rate_detect_top.v
	mr_rx_rcfg_ctrl.v
	mr_rx_reconfig.v
	mr_tx_rate_detect_top.v
	mr_tx_rcfg_ctrl.v
	mr_tx_reconfig.v
	rcfg_array_streamer_iopll.sv
	rcfg_array_streamer_rxphy.sv
	rcfg_array_streamer_rxphy_xn.sv
	rcfg_array_streamer_txphy.sv
	rcfg_array_streamer_txphy_xn.sv
	rcfg_array_streamer_txpll.sv
sdc	a10_hdmi2.sdc
sdc	`jtag.sdc`

Table 9. Generated Simulation FilesRefer to the Simulation Testbench section for more information.
Folders	Files
aldec	/aldec.do
aldec	/rivierapro_setup.tcl
cadence	/cds.lib
	/hdl.var
	/ncsim.sh
	/ncsim_setup.sh
	<cds_libs folder>
mentor	/mentor.do
mentor	/msim_setup.tcl
synopsys	/vcs/filelist.f
	/vcs/vcs_setup.sh
	/vcs/vcs_sim.sh
	/vcsmx/synopsys_sim_setup
	/vcsmx/vcsmx_setup.sh
	/vcsmx/vcsmx_sim.sh
xcelium	/cds.lib
	/hdl.var
	/xcelium_setup.sh
	/xcelium_sim.sh
	<cds_libs folder>
common	/modelsim_files.tcl
	/ncsim_files.tcl
	/riviera_files.tcl
	/vcs_files.tcl
	/vcsmx_files.tcl
	/xcelium_files.tcl
hdmi_rx	/hdmi_rx.ip
hdmi_rx	/Panasonic.hex
hdmi_tx	/hdmi_tx.ip

Table 10. Generated Software Files
Folders	Files
tx_control_src Note: The tx_control folder also contains duplicates of these files.	global.h
	hdmi_rx.c
	hdmi_rx.h
	hdmi_tx.c
	hdmi_tx.h
	hdmi_tx_read_edid.c
	hdmi_tx_read_edid.h
	intel_fpga_i2c.c
	intel_fpga_i2c.h
	main.c
	pio_read_write.c
	pio_read_write.h

2.5. Design Components

The HDMI Intel^® FPGA IP design example consists of the common top-level components and HDMI TX and RX top components.

2.5.1. HDMI TX Components

The HDMI TX top components include the TX core top-level components, and the IOPLL, transceiver PHY reset controller, transceiver native PHY, TX PLL, TX reconfiguration management, and the output buffer blocks.

Figure 9. HDMI TX Top Components

Table 11. HDMI TX Top Components
Module	Description
HDMI TX Core	The IP receives video data from the top level and performs auxiliary data encoding, audio data encoding, video data encoding, scrambling, TMDS encoding or packetization.
IOPLL	The IOPLL (`iopll_frl`) generates the FRL clock for the TX core. This reference clock receives the TX FPLL output clock. FRL clock frequency = Data rate per lanes x 4 / (FRL characters per clock x 18)
Transceiver PHY Reset Controller	The Transceiver PHY reset controller ensures a reliable initialization of the TX transceivers. The reset input of this controller is triggered from the top level, and it generates the corresponding analog and digital reset signal to the Transceiver Native PHY block according to the reset sequencing inside the block. The `tx_ready` output signal from this block also functions as a reset signal to the HDMI Intel^® FPGA IP to indicate the transceiver is up and running, and ready to receive data from the core.
Transceiver Native PHY	Hard transceiver block that receives the parallel data from the HDMI TX core and serializes the data from transmitting it. Note: To meet the HDMI TX inter-channel skew requirement, set the TX channel bonding mode option in the L-Tile/H-Tile Transceiver Native PHY Intel^® Stratix^® 10 FPGA IP parameter editor to PMA and PCS bonding. You also need to add the maximum skew (`set_max_skew`) constraint requirement to the digital reset signal from the transceiver reset controller (`tx_digitalreset`) as recommended in the L- and H-Tile Transceiver PHY User Guide.
TX PLL	The transmitter PLL block provides the serial fast clock to the Transceiver Native PHY block. For this HDMI Intel^® FPGA IP design example, fPLL is used as TX PLL. TX PLL has two reference clocks. Reference clock 0 is connected to the programmable oscillator (with TMDS clock frequency) for TMDS mode. In this design example, RX TMDS clock is used to connect to reference clock 0 for TMDS mode. Intel recommends you to use programmable oscillator with TMDS clock frequency for reference clock 0. Reference clock 1 is connected to a fixed 100 MHz clock for FRL mode.
TX Reconfiguration Management	In TMDS mode, the TX reconfiguration management block reconfigures the TX PLL for different output clock frequency according to the TMDS clock frequency of the specific video. In FRL mode, the TX reconfiguration management block reconfigures the TX PLL to supply the serial fast clock for 3 Gbps, 6 Gbps, 8 Gbps, 10 Gbps and 12 Gbps according to `FRL_Rate` field in the 0x31 SCDC register. The TX reconfiguration management block switches the TX PLL reference clock between reference clock 0 for TMDS mode and reference clock 1 for FRL mode.
Output buffer	This buffer acts as an interface to interact the I²C interface of the HDMI DDC and redriver components.

Table 12. Transceiver Data Rate and Oversampling Factor Each Clock Frequency Range
Mode	Data Rate	Oversampler 1 (2x oversample)	Oversampler 2 (4x oversample)	Oversample Factor	Oversampled Data Rate (Mbps)
TMDS	250–1000	On	On	8	2000–8000
TMDS	1000–6000	On	Off	2	2000–12000
FRL	3000	Off	Off	1	3000
FRL	6000	Off	Off	1	6000
FRL	8000	Off	Off	1	8000
FRL	10000	Off	Off	1	10000
FRL	12000	Off	Off	1	12000

Figure 10. TX Reconfiguration Sequence Flow

2.5.2. HDMI RX Components

The HDMI RX top components include the RX core top-level components, optional I²C slave and EDID RAM, IOPLL, transceiver PHY reset controller, RX native PHY, and the RX reconfiguration management blocks.

Figure 11. HDMI RX Top Components

Table 13. HDMI RX Top Components
Module	Description
HDMI RX Core	The IP receives the serial data from the Transceiver Native PHY and performs data alignment, channel deskew, TMDS decoding, auxiliary data decoding, video data decoding, audio data decoding, and descrambling.
I²C Slave	I²C is the interface used for Sink Display Data Channel (DDC) and Status and Data Channel (SCDC). The HDMI source uses the DDC to determine the capabilities and characteristics of the sink by reading the Enhanced Extended Display Identification Data (E-EDID) data structure. The 8-bit I²C slave addresses for E-EDID are 0xA0 and 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 on-chip RAM. The I²C slave-only controller also supports SCDC for HDMI 2.0 and 2.1 operations. The 9-bit I²C slave address for the SCDC are 0xA8 and 0xA9. When an HPD event occurs, the I²C slave performs write or read transaction to or from SCDC interface of the HDMI RX core. Link training process for Fixed Rate Link (FRL) also happens through I²C interface. During an HPD event or when the source writes a different FRL rate to the `FRL Rate` register (SCDC registers 0x31 bit[3:0]), the link training process starts. Note: This I²C slave-only controller for SCDC is not required if HDMI 2.0 or HDMI 2.1 is not intended.
EDID RAM	The design stores the EDID information using the RAM 1-Port IP. A standard two-wire (clock and data) serial bus protocol (I²C slave-only controller) transfers the CEA-861-D Compliant E-EDID data structure. This EDID RAM stores the E-EDID information. When in TMDS mode, the design supports EDID passthrough from TX to RX. During EDID passthrough, when the TX is connected to the external sink, the Nios^® II processor reads the EDID from the external sink and writes to the EDID RAM. When in FRL mode, the Nios^® II processor writes the pre-configured EDID for each link rate based on the `HDMI_RX_MAX_FRL_RATE` parameter in the global.h script. Use the following `HDMI_RX_MAX_FRL_RATE` inputs for the supported FRL rate: 1: 3G 3 Lanes 2: 6G 3 Lanes 3: 6G 4 Lanes 4: 8G 4 Lanes 5: 10G 4 Lanes (default) 6: 12G 4 Lanes
IOPLL	The HDMI RX uses one IOPLL to generate the FRL clock for the RX core. This reference clock receives the CDR recovered clock. FRL clock frequency = Data rate per lanes x 4 / (FRL characters per clock x 18)
Transceiver PHY Reset Controller	The Transceiver PHY reset controller ensures a reliable initialization of the RX transceivers. The reset input of this controller is triggered by the RX reconfiguration, and it generates the corresponding analog and digital reset signal to the Transceiver Native PHY block according to the reset sequencing inside the block.
RX Native PHY	Hard transceiver block that receives the serial data from an external video source. It deserializes the serial data to parallel data before passing the data to the HDMI RX core. This block runs on Enhanced PCS for FRL mode. RX CDR has two reference clocks. Reference clock 0 is connected to the TMDS clock. Reference clock 1 is connected to a fixed 100 MHz clock. In TMDS mode, RX CDR is reconfigured to select reference clock 0, and in FRL mode, RX CDR is reconfigured to select reference clock 1.
RX Reconfiguration Management	In TMDS mode, the RX reconfiguration management block implements rate detection circuitry with the HDMI PLL to drive the RX transceiver to operate at any arbitrary link rates ranging from 250 Mbps to 6,000 Mbps. In FRL mode, the RX reconfiguration management block reconfigures the RX transceiver to operate at 3 Gbps, 6 Gbps, 8 Gbps, 10 Gbps, or 12 Gbps depending on the FRL rate in the `SCDC_FRL_RATE` register field (0x31[3:0]). The RX reconfiguration management block switches between Standard PCS/RX for TMDS mode and Enhanced PCS for FRL mode. Refer to Figure 12.

Figure 12. RX Reconfiguration Sequence FlowThe figure illustrates the multi-rate reconfiguration sequence flow of the controller when it receives input data stream and reference clock frequency, or when the transceiver is unlocked.

2.5.2.1. HDMI RX Top Link Training Process

This design example demonstrates the HDMI RX core request for LTP5, LTP6, LTP7, and LTP8 link training patterns and qualifies the received data stream by the locked signal from the HDMI RX core.

These link training patterns start with 4 Scrambler Reset (SR) characters followed by 4096 encoded and scrambled data. After receiving the SR characters, the HDMI RX core achieves alignment and lane deskew lock to qualify the received link training pattern.

For unscrambled and not encoded link training patterns, such as LTP3, check the data output from the RX transceiver.

2.5.3. Top-Level Common Blocks

The top-level common blocks include the transceiver arbiter, the RX-TX link components, and the CPU subsystem.

Table 14. Top-Level Common Blocks
Module	Description
Transceiver Arbiter	This generic functional block prevents transceivers from recalibrating simultaneously when either RX or TX transceivers within the same physical channel require reconfiguration. The simultaneous recalibration impacts applications where RX and TX transceivers within the same channel are assigned to independent IP implementations. This transceiver arbiter is an extension to the resolution recommended for merging simplex TX and simplex RX into the same physical channel. This transceiver arbiter also assists in merging and arbitrating the Avalon^® memory-mapped RX and TX reconfiguration requests targeting simplex RX and TX transceivers within a channel as the reconfiguration interface port of the transceivers can only be accessed sequentially. The interface connection between the transceiver arbiter and TX/RX Native PHY/PHY Reset Controller blocks in this design example demonstrates a generic mode that applies for any IP combination using the transceiver arbiter. The transceiver arbiter is not required when only either RX or TX transceiver is used in a channel. The transceiver arbiter identifies the requester of a reconfiguration through its Avalon^® memory-mapped reconfiguration interfaces and ensures that the corresponding `tx_reconfig_cal_busy` or `rx_reconfig_cal_busy` is gated accordingly. For HDMI applications, only RX initiates reconfiguration. By channeling the Avalon^® memory-mapped reconfiguration request through the arbiter, the arbiter identifies that the reconfiguration request originates from the RX, which then gates `tx_reconfig_cal_busy` from asserting and allows `rx_reconfig_cal_busy` to assert. The gating prevents the TX transceiver from being moved to calibration mode unintentionally. Note: Because HDMI only requires RX reconfiguration, the `tx_reconfig_mgmt_*` signals are tied off. Also, the Avalon^® memory-mapped interface is not required between the arbiter and the TX Native PHY block. The blocks are assigned to the interface in the design example to demonstrate generic transceiver arbiter connection to TX/RX Native PHY/PHY Reset Controller.
RX-TX Link	The video data output and synchronization signals from HDMI RX core loop through a DCFIFO across the RX and TX video clock domains. The auxiliary data port of the HDMI TX core controls the auxiliary data that flow through the DCFIFO through backpressure. The backpressure ensures there is no incomplete auxiliary packet on the auxiliary data port. This block also performs external filtering: Filters the audio data and audio clock regeneration packet from the auxiliary data stream before transmitting to the HDMI TX core auxiliary data port. Filters the High Dynamic Range (HDR) InfoFrame from the HDMI RX auxiliary data and inserts an example HDR InfoFrame to the auxiliary data of the HDMI TX through the Avalon^® streaming multiplexer.
CPU Subsystem	The CPU subsystem functions as SCDC and DDC controllers, and source reconfiguration controller. The source SCDC controller contains the I²C master controller. The I²C master controller transfers the SCDC data structure from the FPGA source to the external sink for HDMI 2.0 operation. 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 also transfers the DDC data structure (E-EDID) between the HDMI source and external sink. The Nios^® II CPU acts as the reconfiguration controller for the HDMI source. The CPU relies on the periodic rate detection from the RX Reconfiguration Management module to determine if the TX requires reconfiguration. The Avalon^® memory-mapped slave translator provides the interface between the Nios^® II processor Avalon^® memory-mapped master interface and the Avalon^® memory-mapped slave interfaces of the externally instantiated HDMI source’s IOPLL and TX Native PHY. Perform link training through I²C master interface with external sink

2.6. Dynamic Range and Mastering (HDR) InfoFrame Insertion and Filtering

The HDMI Intel^® FPGA IP design example includes a demonstration of HDR InfoFrame insertion in a RX-TX loopback system.

HDMI Specification version 2.0b allows Dynamic Range and Mastering InfoFrame to be transmitted through HDMI auxiliary stream. In the demonstration, the Auxiliary Packet Generator block supports the HDR insertion. You need only to format the intended HDR InfoFrame packet as specified in the module’s signal list table and the insertion of the HDR InfoFrame occurs once every video frame.

In this example configuration, in instances where the incoming auxiliary stream already includes HDR InfoFrame, the streamed HDR content is filtered. The filtering avoids conflicting HDR InfoFrames to be transmitted and ensures that only the values specified in the HDR Sample Data module are used.

Figure 13. RX-TX Link with Dynamic Range and Mastering InfoFrame InsertionThe figure shows the block diagram of RX-TX link including Dynamic Range and Mastering InfoFrame insertion into the HDMI TX core auxiliary stream.

Table 15. Auxiliary Data Insertion Block (aux_retransmit) Signals
Signal	Direction	Width	Description
Clock and Reset
`clk`	Input	1	Clock input. This clock should be connected to the video clock.
`reset`	Input	1	Reset input.
Auxiliary Packet Signals
`tx_aux_data`	Output	72	TX Auxiliary packet output from the multiplexer.
`tx_aux_valid`	Output	1
`tx_aux_ready`	Output	1
`tx_aux_sop`	Output	1
`tx_aux_eop`	Output	1
`rx_aux_data`	Input	72	RX Auxiliary data passed to the packet filter module before entering the multiplexer.
`rx_aux_valid`	Input	1
`rx_aux_sop`	Input	1
`rx_aux_eop`	Input	1
Control Signal
`rx_vid_vsync`	Input	1	HDMI RX Video Vsync. The core inserts the HDR InfoFrame to the auxiliary stream at the rising edge of this signal.

Table 16. HDR Data Module (altera_hdmi_hdr_infoframe) Signals
Signal	Direction	Width	Description
`hb0`	Output	8	Header byte 0 of the Dynamic Range and Mastering InfoFrame: InfoFrame type code.
`hb1`	Output	8	Header byte 1 of the Dynamic Range and Mastering InfoFrame: InfoFrame version number.
`hb2`	Output	8	Header byte 2 of the Dynamic Range and Mastering InfoFrame: Length of InfoFrame.
`pb`	Input	224	Data byte of the Dynamic Range and Mastering InfoFrame.

Table 17. Dynamic Range and Mastering InfoFrame Data Byte Bundle Bit-Fields
Bit-Field	Definition	Static Metadata Type 1
7:0	Data Byte 1: {5'h0, EOTF[2:0]}
15:8	Data Byte 2: {5'h0, Static_Metadata_Descriptor_ID[2:0]}
23:16	Data Byte 3: Static_Metadata_Descriptor	display_primaries_x[0], LSB
31:24	Data Byte 4: Static_Metadata_Descriptor	display_primaries_x[0], MSB
39:32	Data Byte 5: Static_Metadata_Descriptor	display_primaries_y[0], LSB
47:40	Data Byte 6: Static_Metadata_Descriptor	display_primaries_y[0], MSB
55:48	Data Byte 7: Static_Metadata_Descriptor	display_primaries_x[1], LSB
63:56	Data Byte 8: Static_Metadata_Descriptor	display_primaries_x[1], MSB
71:64	Data Byte 9: Static_Metadata_Descriptor	display_primaries_y[1], LSB
79:72	Data Byte 10: Static_Metadata_Descriptor	display_primaries_y[1], MSB
87:80	Data Byte 11: Static_Metadata_Descriptor	display_primaries_x[2], LSB
95:88	Data Byte 12: Static_Metadata_Descriptor	display_primaries_x[2], MSB
103:96	Data Byte 13: Static_Metadata_Descriptor	display_primaries_y[2], LSB
111:104	Data Byte 14: Static_Metadata_Descriptor	display_primaries_y[2], MSB
119:112	Data Byte 15: Static_Metadata_Descriptor	white_point_x, LSB
127:120	Data Byte 16: Static_Metadata_Descriptor	white_point_x, MSB
135:128	Data Byte 17: Static_Metadata_Descriptor	white_point_y, LSB
143:136	Data Byte 18: Static_Metadata_Descriptor	white_point_y, MSB
151:144	Data Byte 19: Static_Metadata_Descriptor	max_display_mastering_luminance, LSB
159:152	Data Byte 20: Static_Metadata_Descriptor	max_display_mastering_luminance, MSB
167:160	Data Byte 21: Static_Metadata_Descriptor	min_display_mastering_luminance, LSB
175:168	Data Byte 22: Static_Metadata_Descriptor	min_display_mastering_luminance, MSB
183:176	Data Byte 23: Static_Metadata_Descriptor	Maximum Content Light Level, LSB
191:184	Data Byte 24: Static_Metadata_Descriptor	Maximum Content Light Level, MSB
199:192	Data Byte 25: Static_Metadata_Descriptor	Maximum Frame-average Light Level, LSB
207:200	Data Byte 26: Static_Metadata_Descriptor	Maximum Frame-average Light Level, MSB
215:208	Reserved
223:216	Reserved

Disabling HDR Insertion and Filtering

Disabling HDR insertion and filter enables you to verify the retransmission of HDR content already available in the source auxiliary stream without any modification in the RX-TX Retransmit design example.

To disable HDR InfoFrame insertion and filtering, set the FILTER_AUX_PKT* parameter value to any invalid aux packet (e.g. 8'hFF) in the aux_retransmit.v file to prevent the filtering of the HDR InfoFrame from the Auxiliary stream.

2.7. Design Software Flow

In the design main software flow, the Nios^® II processor configures the TI redriver setting and initializes the TX and RX paths upon power-up.

Figure 14. Software Flow in main.c Script

The software executes a while loop to monitor sink and source changes, and to react to the changes. The software may trigger TX reconfiguration, TX link training and start transmitting video.

Figure 15. TX Path Initialization Flowchart

Figure 16. RX Path Initialization Flowchart

Figure 17. TX Reconfiguration and Link Training Flowchart

Figure 18. Link Training LTS:3 Process at Specific FRL Rate Flowchart

Figure 19. HDMI TX Video Transmission Flowchart

2.8. Running the Design in Different FRL Rates

You may run your design in different FRL rates, other than the external sink's default FRL rate.

To run the design in different FRL rates:

Toggle the on-board user_dipsw0 switch to ON position.
Open the Nios^® II terminal.
Key in the following commands and press Enter to execute.

Command	Description
h	Show the help menu.
r0	Update the RX maximum FRL capability to FRL rate 0 (TMDS only).
r1	Update the RX maximum FRL capability to FRL rate 1 (3 Gbps).
r2	Update the RX maximum FRL capability to FRL rate 2 (6 Gbps, 3 lanes).
r3	Update the RX maximum FRL capability to FRL rate 3 (6 Gbps, 4 lanes).
r4	Update the RX maximum FRL capability to FRL rate 4 (8 Gbps).
r5	Update the RX maximum FRL capability to FRL rate 5 (10 Gbps).
r6	Update the RX maximum FRL capability to FRL rate 6 (12 Gbps).
t1	TX configures link rate to FRL rate 1 (3 Gbps).
t2	TX configures link rate to FRL rate 2 (6 Gbps, 3 lanes).
t3	TX configures link rate to FRL rate 3 (6 Gbps, 4 lanes).
t4	TX configures link rate to FRL rate 4 (8 Gbps).
t5	TX configures link rate to FRL rate 5 (10 Gbps).
t6	TX configures link rate to FRL rate 6 (12 Gbps).

2.9. Clocking Scheme

The clocking scheme illustrates the clock domains in the HDMI Intel^® FPGA IP design example.

Figure 20. HDMI 2.1 Design Example Clocking Scheme

Table 18. Clocking Scheme Signals
Clock	Signal Name in Design	Description
Management Clock	`mgmt_clk`	A free running 100 MHz clock for these components: Avalon-MM interfaces for reconfiguration The frequency range requirement is between 100–125 MHz. PHY reset controller for transceiver reset sequence The frequency range requirement is between 1–500 MHz. IOPLL Reconfiguration The maximum clock frequency is 100 MHz. RX Reconfiguration Management TX Reconfiguration Management CPU I²C Master
I²C Clock	`i2c_clk`	A 100 MHz clock input that clocks I²C slave, output buffers, SCDC registers, and link training process in the HDMI RX core, and EDID RAM.
TX PLL Reference Clock 0	`tx_tmds_clk`	Reference clock 0 to the TX PLL. The clock frequency is the same as the expected TMDS clock frequency from the HDMI TX TMDS clock channel. This reference clock is used in TMDS mode. For this HDMI design example, this clock is connected to the RX TMDS clock for demonstration purpose. In your application, you need to supply a dedicated clock with TMDS clock frequency from a programmable oscillator for better jitter performance. Note: Do not use a transceiver `RX` pin as a TX PLL reference clock. Your design will fail to fit if you place the HDMI TX refclk on an `RX` pin.
TX PLL Reference Clock 1	`txfpll_refclk1`/`rxphy_cdr_refclk1`	Reference clock to the TX PLL and RX CDR, as well as IOPLL for `vid_clk`. The clock frequency is 100 MHz.
TX PLL Serial Clock	`tx_bonding_clocks`	Serial fast clock generated by TX PLL. The clock frequency is set based on the data rate.
TX Transceiver Clock Out	`tx_clk`	Clock out recovered from the transceiver, and the frequency varies depending on the data rate and symbols per clock. TX transceiver clock out frequency = Transceiver data rate/Transceiver width For this HDMI design example, the TX transceiver clock out from channel 0 clocks the TX transceiver core input (`tx_coreclkin`), link speed IOPLL (`pll_hdmi`) reference clock, and the video and FRL IOPLL (`pll_vid_frl`) reference clock.
Video Clock	`tx_vid_clk`/`rx_vid_clk`	Video clock to TX and RX core. The clock runs at a fixed frequency of 225 MHz.
TX/RX FRL Clock	`tx_frl_clk`/`rx_frl_clk`	FRL clock to for TX and RX core.
RX TMDS Clock	`rx_tmds_clk`	TMDS clock channel from the HDMI RX connector and connects to an IOPLL to generate the reference clock for CDR reference clock 0. The core uses this clock when it is in TMDS mode.
RX Transceiver Clock Out	`rx_clk`	Clock out recovered from the transceiver, and the frequency varies depending on the data rate and transceiver width. RX transceiver clock out frequency = Transceiver data rate/Transceiver width For this HDMI design example, the RX transceiver clock out from channel 1 clocks the RX transceiver core input (`rx_coreclkin`), FRL IOPLL (`pll_frl`) reference clock, and LTP checker (`hdmi_ltp_chk`) reference clock.

2.10. Interface Signals

The tables list the signals for the HDMI design example with FRL enabled.

Table 19. Top-Level Signals
Signal	Direction	Width	Description
On-board Oscillator Signal
`clk_fpga_b3_p`	Input	1	100 MHz free running clock for core reference clock.
`refclk4_p`	Input	1	100 MHz free running clock for transceiver reference clock.
User Push Buttons and LEDs
`user_pb`	Input	1	Push button to control the HDMI Intel^® FPGA IP design functionality.
`cpu_resetn`	Input	1	Global reset.
`user_led_g`	Output	8	Green LED display. Refer to Hardware Setup for more information about the LED functions.
`user_dipsw`	Input	1	User-defined DIP switch. Refer to Hardware Setup for more information about the DIP switch functions.
HDMI FMC Daughter Card Pins on FMC Port
`fmcb_gbtclk_m2c_p_0`	Input	1	HDMI RX TMDS clock.
`fmcb_dp_m2c_p`	Input	4	HDMI RX clock, red, green, and blue data channels.
`fmcb_dp_c2m_p`	Output	4	HDMI TX clock, red, green, and blue data channels.
`fmcb_la_rx_p_9`	Input	1	HDMI RX +5V power detect.
`fmcb_la_rx_p_8`	Inout	1	HDMI RX hot plug detect.
`fmcb_la_rx_n_8`	Inout	1	HDMI RX I²C SDA for DDC and SCDC.
`fmcb_la_tx_p_10`	Input	1	HDMI RX I²C SCL for DDC and SCDC.
`fmcb_la_tx_p_12`	Input	1	HDMI TX hot plug detect.
`fmcb_la_tx_n_12`	Inout	1	HDMI I²C SDA for DDC and SCDC.
`fmcb_la_rx_p_10`	Inout	1	HDMI I²C SCL for DDC and SCDC.
`fmcb_la_tx_n_9`	Inout	1	HDMI I²C SDA for redriver control.
`fmcb_la_rx_p_11`	Inout	1	HDMI I²C SCL for redriver control.

Table 20. HDMI RX Top-Level Signals
Signal	Direction	Width	Description
Clock and Reset Signals
`mgmt_clk`	Input	1	System clock input (100 MHz).
`reset`	Input	1	System reset input.
`rx_tmds_clk`	Input	1	HDMI RX TMDS clock.
`i2c_clk`	Input	1	Clock input for DDC and SCDC interface.
`rxphy_cdr_refclk1`	Input	1	Clock input for RX CDR reference clock 1. The clock frequency is 100 MHz.
`rx_vid_clk`	Output	1	Video clock output.
`sys_init`	Output	1	System initialization to reset the system upon power-up.
RX Transceiver and IOPLL Signals
`rxpll_tmds_locked`	Output	1	Indicates the TMDS clock IOPLL is locked.
`rxpll_frl_locked`	Output	1	Indicates the FRL clock IOPLL is locked.
`rxphy_serial_data`	Input	4	HDMI serial data to the RX Native PHY.
`rxphy_ready`	Output	1	Indicates the RX Native PHY is ready.
`rxphy_cal_busy_raw`	Output	4	RX Native PHY calibration busy to the transceiver arbiter.
`rxphy_cal_busy_gated`	Input	4	Calibration busy signal from the transceiver arbiter to the RX Native PHY.
`rxphy_rcfg_slave_write`	Input	4	Transceiver reconfiguration Avalon^® memory-mapped interface from the RX Native PHY to the transceiver arbiter.
`rxphy_rcfg_slave_read`	Input	4
`rxphy_rcfg_slave_address`	Input	40
`rxphy_rcfg_slave_writedata`	Input	128
`rxphy_rcfg_slave_readdata`	Output	128
`rxphy_rcfg_slave_waitrequest`	Output	4
RX Reconfiguration Management
`rxphy_rcfg_busy`	Output	1	RX Reconfiguration busy signal.
`rx_tmds_freq`	Output	24	HDMI RX TMDS clock frequency measurement (in 10 ms).
`rx_tmds_freq_valid`	Output	1	Indicates the RX TMDS clock frequency measurement is valid.
`rxphy_os`	Output	1	Oversampling factor: 0: 1x oversampling 1: 5× oversampling
`rxphy_rcfg_master_write`	Output	1	RX reconfiguration management Avalon^® memory-mapped interface to transceiver arbiter.
`rxphy_rcfg_master_read`	Output	1
`rxphy_rcfg_master_address`	Output	12
`rxphy_rcfg_master_writedata`	Output	32
`rxphy_rcfg_master_readdata`	Input	32
`rxphy_rcfg_master_waitrequest`	Input	1
HDMI RX Core Signals
`rx_vid_clk_locked`	Input	1	Indicates vid_clk is stable.
`rxcore_frl_rate`	Output	4	Indicates the FRL rate that the RX core is running. 0: Legacy Mode (TMDS) 1: 3 Gbps 3 lanes 2: 6 Gbps 4 lanes 3: 6 Gbps 4 lanes 4: 8 Gbps 4 lanes 5: 10 Gbps 4 lanes 6: 12 Gbps 4 lanes 7-15: Reserved
`rxcore_frl_locked`	Output	4	Each bit indicates the specific lane that has achieved FRL lock. FRL is locked when the RX core successfully performs alignment, deskew, and achieves lane lock. For 3-lane mode, lane lock is achieved when the RX core receives Scrambler Reset (SR) or Start-Super-Block (SSB) for every 680 FRL character periods for at least 3 times. For 4-lane mode, lane lock is achieved when the RX core receives Scrambler Reset (SR) or Start-Super-Block (SSB) for every 510 FRL character periods for at least 3 times.
`rxcore_frl_ffe_levels`	Output	4	Corresponds to the `FFE_level` bit in the SCDC 0x31 register bit [7:4] in the RX core.
`rxcore_frl_flt_ready`	Input	1	Asserts to indicate the RX is ready for the link training process to start. When asserted, the `FLT_ready` bit in the SCDC register 0x40 bit 6 is asserted as well.
`rxcore_frl_src_test_config`	Input	8	Specifies the source test configurations. The value is written into the SCDC Test Configuration register in the SCDC register 0x35.
`rxcore_tbcr`	Output	1	Indicates the TMDS bit to clock ratio; corresponds to the `TMDS_Bit_Clock_Ratio` register in the SCDC register 0x20 bit 1. When running in HDMI 2.0 mode, this bit is asserted. Indicates the TMDS bit to clock ratio of 40:1. When running in HDMI 1.4b, this bit is not asserted. Indicates the TMDS bit to clock ratio of 10:1. This bit is unused for FRL mode.
`rxcore_scrambler_enable`	Output	1	Indicates if the received data is scrambled; corresponds to the `Scrambling_Enable` field in the SCDC register 0x20 bit 0.
`rxcore_audio_de`	Output	1	HDMI RX core audio interfaces Refer to the Sink Interfaces section in the HDMI Intel^® FPGA IP User Guide for more information.
`rxcore_audio_data`	Output	256
`rxcore_audio_info_ai`	Output	48
`rxcore_audio_N`	Output	20
`rxcore_audio_CTS`	Output	20
`rxcore_audio_metadata`	Output	165
`rxcore_audio_format`	Output	5
`rxcore_aux_pkt_data`	Output	72	HDMI RX core auxiliary interfaces Refer to the Sink Interfaces section in the HDMI Intel^® FPGA IP User Guide for more information.
`rxcore_aux_pkt_addr`	Output	6
`rxcore_aux_pkt_wr`	Output	1
`rxcore_aux_data`	Output	72
`rxcore_aux_sop`	Output	1
`rxcore_aux_eop`	Output	1
`rxcore_aux_valid`	Output	1
`rxcore_aux_error`	Output	1
`rxcore_gcp`	Output	6	HDMI RX core sideband signals Refer to the Sink Interfaces section in the HDMI Intel^® FPGA IP User Guide for more information.
`rxcore_info_avi`	Output	123
`rxcore_info_vsi`	Output	61
`rxcore_locked`	Output	1	HDMI RX core video ports Note: N = pixels per clock Refer to the Sink Interfaces section in the HDMI Intel^® FPGA IP User Guide for more information.
`rxcore_vid_data`	Output	N*48
`rxcore_vid_vsync`	Output	N
`rxcore_vid_hsync`	Output	N
`rxcore_vid_de`	Output	N
`rxcore_vid_valid`	Output	1
`rxcore_vid_lock`	Output	1
`rxcore_mode`	Output	1	HDMI RX core control and status ports. Note: N = symbols per clock Refer to the Sink Interfaces section in the HDMI Intel^® FPGA IP User Guide for more information.
`rxcore_ctrl`	Output	N*6
`rxcore_color_depth_sync`	Output	2
`hdmi_5v_detect`	Input	1	HDMI RX 5V detect and hotplug detect. Refer to the Sink Interfaces section in the HDMI Intel^® FPGA IP User Guide for more information.
`hdmi_rx_hpd_n`	Inout	1
`rx_hpd_trigger`	Input	1
I²C Signals
`hdmi_rx_i2c_sda`	Inout	1	HDMI RX DDC and SCDC interface.
`hdmi_rx_i2c_scl`	Inout	1	HDMI RX DDC and SCDC interface.
RX EDID RAM Signals
`edid_ram_access`	Input	1	HDMI RX EDID RAM access interface. Assert `edid_ram_access` when you want to write or read from the EDID RAM, else this signal should be kept low. When you assert `edid_ram_access`, the hotplug signal deasserts to allow write or read to the EDID RAM. When EDID RAM access is completed, you should deassert `edid_ram_assess` and the hotplug signal asserts. The source will read the new EDID due to the hotplug signal toggling.
`edid_ram_address`	Input	8
`edid_ram_write`	Input	1
`edid_ram_read`	Input	1
`edid_ram_readdata`	Output	8
`edid_ram_writedata`	Input	8
`edid_ram_waitrequest`	Output	1

Table 21. HDMI TX Top-Level Signals
Signal	Direction	Width	Description
Clock and Reset Signals
`mgmt_clk`	Input	1	System clock input (100 MHz).
`reset`	Input	1	System reset input.
`tx_tmds_clk`	Input	1	HDMI RX TMDS clock.
`txfpll_refclk1`	Input	1	Clock input for TX PLL reference clock 1. The clock frequency is 100 MHz.
`tx_vid_clk`	Output	1	Video clock output.
`tx_frl_clk`	Output	1	FRL clock output.
`sys_init`	Input	1	System initialization to reset the system upon power-up.
`tx_init_done`	Input	1	TX initialization to reset the TX reconfiguration management block and transceiver reconfiguration interface.
TX Transceiver and IOPLL Signals
`txpll_frl_locked`	Output	1	Indicates the link speed clock and FRL clock IOPLL is locked.
`txfpll_locked`	Output	1	Indicates the TX PLL is locked.
`txphy_serial_data`	Output	4	HDMI serial data from the TX Native PHY.
`txphy_ready`	Output	1	Indicates the TX Native PHY is ready.
`txphy_cal_busy`	Output	1	TX Native PHY calibration busy signal.
`txphy_cal_busy_raw`	Output	4	Calibration busy signal to the transceiver arbiter.
`txphy_cal_busy_gated`	Input	4	Calibration busy signal from the transceiver arbiter to the TX Native PHY.
`txphy_rcfg_busy`	Output	1	Indicates the TX PHY reconfiguration is in progress.
`txphy_rcfg_slave_write`	Input	4	Transceiver reconfiguration Avalon^® memory-mapped interface from the TX Native PHY to the transceiver arbiter.
`txphy_rcfg_slave_read`	Input	4
`txphy_rcfg_slave_address`	Input	40
`txphy_rcfg_slave_writedata`	Input	128
`txphy_rcfg_slave_readdata`	Output	128
`txphy_rcfg_slave_waitrequest`	Output	4
TX Reconfiguration Management
`tx_tmds_freq`	Input	24	HDMI TX TMDS clock frequency value (in 10 ms).
`tx_os`	Output	2	Oversampling factor: 0: 1x oversampling 1: 2× oversampling 2: 8x oversampling
`txphy_rcfg_master_write`	Output	1	TX reconfiguration management Avalon^® memory-mapped interface to transceiver arbiter.
`txphy_rcfg_master_read`	Output	1
`txphy_rcfg_master_address`	Output	12
`txphy_rcfg_master_writedata`	Output	32
`txphy_rcfg_master_readdata`	Input	32
`txphy_rcfg_master_waitrequest`	Input	1
`tx_reconfig_done`	Output	1	Indicates that the TX reconfiguration process is completed.
HDMI TX Core Signals
`tx_vid_clk_locked`	Input	1	Indicates `vid_clk` is stable.
`txcore_ctrl`	Input	N*6	HDMI TX core control interfaces. Note: N = pixels per clock Refer to the Source Interfaces section in the HDMI Intel^® FPGA IP User Guide for more information.
`txcore_mode`	Input	1
`txcore_audio_de`	Input	1	HDMI TX core audio interfaces. Refer to the Source Interfaces section in the HDMI Intel^® FPGA IP User Guide for more information.
`txcore_audio_mute`	Input	1
`txcore_audio_data`	Input	256
`txcore_audio_info_ai`	Input	49
`txcore_audio_N`	Input	20
`txcore_audio_CTS`	Input	20
`txcore_audio_metadata`	Input	166
`txcore_audio_format`	Input	5
`txcore_aux_ready`	Output	1	HDMI TX core auxiliary interfaces. Refer to the Source Interfaces section in the HDMI Intel^® FPGA IP User Guide for more information.
`txcore_aux_data`	Input	72
`txcore_aux_sop`	Input	1
`txcore_aux_eop`	Input	1
`txcore_aux_valid`	Input	1
`txcore_gcp`	Input	6	HDMI TX core sideband signals. Refer to the Source Interfaces section in the HDMI Intel^® FPGA IP User Guide for more information.
`txcore_info_avi`	Input	123
`txcore_info_vsi`	Input	62
`txcore_i2c_master_write`	Input	1	TX I²C master Avalon^® memory-mapped interface to I²C master inside the TX core. Note: These signals are available only when you turn on the Include I2C parameter.
`txcore_i2c_master_read`	Input	1
`txcore_i2c_master_address`	Input	4
`txcore_i2c_master_writedata`	Input	32
`txcore_i2c_master_readdata`	Output	32
`txcore_vid_data`	Input	N*48	HDMI TX core video ports. Note: N = pixels per clock Refer to the Source Interfaces section in the HDMI Intel^® FPGA IP User Guide for more information.
`txcore_vid_vsync`	Input	N
`txcore_vid_hsync`	Input	N
`txcore_vid_de`	Input	N
`txcore_vid_ready`	Output	1
`txcore_vid_overflow`	Output	1
`txcore_vid_valid`	Input	1
`txcore_frl_rate`	Input	4	SCDC register interfaces.
`txcore_frl_pattern`	Input	16
`txcore_frl_start`	Input	1
`txcore_scrambler_enable`	Input	1
`txcore_tbcr`	Input	1
I²C Signals
`nios_tx_i2c_sda_in`	Output	1	TX I²C Master interface for SCDC and DDC from the Nios^® II processor to the output buffer. Note: If you turn on the Include I2C parameter, these signals will be placed inside the TX core and will not be visible at this level.
`nios_tx_i2c_scl_in`	Output	1
`nios_tx_i2c_sda_oe`	Input	1
`nios_tx_i2c_scl_oe`	Input	1
`nios_ti_i2c_sda_in`	Output	1	TX I²C Master interface from the Nios^® II processor to the output buffer to control TI redriver on the Bitec HDMI 2.1 FMC daughter card.
`nios_ti_i2c_scl_in`	Output	1
`nios_ti_i2c_sda_oe`	Input	1
`nios_ti_i2c_scl_oe`	Input	1
`hdmi_tx_i2c_sda`	Inout	1	TX I²C interfaces for SCDC and DDC interfaces from the output buffer to the HDMI TX connector.
`hdmi_tx_i2c_scl`	Inout	1
`hdmi_tx_ti_i2c_sda`	Inout	1	TX I²C interfaces from the output buffer to the TI redriver on the Bitec HDMI 2.1 FMC daughter card.
`hdmi_tx_ti_i2c_scl`	Inout	1
Hotplug Detect Signals
`tx_hpd_req`	Output	1	HDMI TX hotplug detect interfaces.
`hdmi_tx_hpd_n`	Input	1	HDMI TX hotplug detect interfaces.

Table 22. Transceiver Arbiter Signals
Signal	Direction	Width	Description
`clk`	Input	1	Reconfiguration clock. This clock must share the same clock with the reconfiguration management blocks.
`reset`	Input	1	Reset signal. This reset must share the same reset with the reconfiguration management blocks.
`rx_rcfg_en`	Input	1	RX reconfiguration enable signal.
`tx_rcfg_en`	Input	1	TX reconfiguration enable signal.
`rx_rcfg_ch`	Input	2	Indicates which channel to be reconfigured on the RX core. This signal must always remain asserted.
`tx_rcfg_ch`	Input	2	Indicates which channel to be reconfigured on the TX core. This signal must always remain asserted.
`rx_reconfig_mgmt_write`	Input	1	Reconfiguration Avalon^® memory-mapped interfaces from the RX reconfiguration management.
`rx_reconfig_mgmt_read`	Input	1
`rx_reconfig_mgmt_address`	Input	10
`rx_reconfig_mgmt_writedata`	Input	32
`rx_reconfig_mgmt_readdata`	Output	32
`rx_reconfig_mgmt_waitrequest`	Output	1
`tx_reconfig_mgmt_write`	Input	1	Reconfiguration Avalon^® memory-mapped interfaces from the TX reconfiguration management.
`tx_reconfig_mgmt_read`	Input	1
`tx_reconfig_mgmt_address`	Input	10
`tx_reconfig_mgmt_writedata`	Input	32
`tx_reconfig_mgmt_readdata`	Output	32
`tx_reconfig_mgmt_waitrequest`	Output	1
`reconfig_write`	Output	1	Reconfiguration Avalon^® memory-mapped interfaces to the transceiver.
`reconfig_read`	Output	1
`reconfig_address`	Output	10
`reconfig_writedata`	Output	32
`rx_reconfig_readdata`	Input	32
`rx_reconfig_waitrequest`	Input	1
`tx_reconfig_readdata`	Input	1
`tx_reconfig_waitrequest`	Input	1
`rx_cal_busy`	Input	1	Calibration status signal from the RX transceiver.
`tx_cal_busy`	Input	1	Calibration status signal from the TX transceiver.
`rx_reconfig_cal_busy`	Output	1	Calibration status signal to the RX transceiver PHY reset control.
`tx_reconfig_cal_busy`	Output	1	Calibration status signal from the TX transceiver PHY reset control.

Table 23. RX-TX Link Signals
Signal	Direction	Width	Description
`vid_clk`	Input	1	HDMI video clock.
`rx_vid_lock`	Input	3	Indicates HDMI RX video lock status.
`rx_vid_valid`	Input	1	HDMI RX video interfaces.
`rx_vid_de`	Input	N
`rx_vid_hsync`	Input	N
`rx_vid_vsync`	Input	N
`rx_vid_data`	Input	N*48
`rx_aux_eop`	Input	1	HDMI RX auxiliary interfaces.
`rx_aux_sop`	Input	1
`rx_aux_valid`	Input	1
`rx_aux_data`	Input	72
`tx_vid_de`	Output	N	HDMI TX video interfaces. Note: N = pixels per clock
`tx_vid_hsync`	Output	N
`tx_vid_vsync`	Output	N
`tx_vid_data`	Output	N48*
`tx_vid_valid`	Output	1
`tx_vid_ready`	Input	1
`tx_aux_eop`	Output	1	HDMI TX auxiliary interfaces.
`tx_aux_sop`	Output	1
`tx_aux_valid`	Output	1
`tx_aux_data`	Output	72
`tx_aux_ready`	Input	1

Table 24. Platform Designer System Signals
Signal	Direction	Width	Description
`cpu_clk_in_clk_clk`	Input	1	CPU clock.
`cpu_rst_in_reset_reset`	Input	1	CPU reset.
`edid_ram_slave_translator_avalon_anti_slave_0_address`	Output	8	EDID RAM access interfaces.
`edid_ram_slave_translator_avalon_anti_slave_0_write`	Output	1
`edid_ram_slave_translator_avalon_anti_slave_0_read`	Output	1
`edid_ram_slave_translator_avalon_anti_slave_0_readdata`	Input	8
`edid_ram_slave_translator_avalon_anti_slave_0_writedata`	Output	8
`edid_ram_slave_translator_avalon_anti_slave_0_waitrequest`	Input	1
`hdmi_i2c_master_i2c_serial_sda_in`	Input	1	I²C Master interfaces from the Nios^® II processor to the output buffer for DDC and SCDC control.
`hdmi_i2c_master_i2c_serial_scl_in`	Input	1
`hdmi_i2c_master_i2c_serial_sda_oe`	Output	1
`hdmi_i2c_master_i2c_serial_scl_oe`	Output	1
`redriver_i2c_master_i2c_serial_sda_in`	Input	1	I²C Master interfaces from the Nios^® II processor to the output buffer for TI redriver setting configuration.
`redriver_i2c_master_i2c_serial_scl_in`	Input	1
`redriver_i2c_master_i2c_serial_sda_oe`	Output	1
`redriver_i2c_master_i2c_serial_scl_oe`	Output	1
`pio_in0_external_connection_export`	Input	32	Parallel input output interfaces. Bit 0: Connected to the `user_dipsw` signal to control EDID passthrough mode. Bit 1: TX HPD request Bit 2: TX transceiver ready Bits 3: TX reconfiguration done Bits 4–7: Reserved Bits 8–11: RX FRL rate Bit 12: RX TMDS bit clock ratio Bits 13–16: RX FRL locked Bits 17–20: RX FFE levels Bit 21: RX alignment locked Bit 22: RX video lock Bit 23: User push button 2 to read SCDC registers from external sink Bits 24–31: Reserved
`pio_out0_external_connection_export`	Output	32	Parallel input output interfaces. Bit 0: TX HPD acknowledgment Bit 1: TX initialization is done Bits 2–7: Reserved Bits 8–11: TX FRL rate Bits 12–27: TX FRL link training pattern Bit 28: TX FRL start Bits 29–31: Reserved
`pio_out1_external_connection_export`	Output	32	Parallel input output interfaces. Bit 0: RX EDID RAM access Bit 1: RX FLT ready Bits 2–7: Reserved Bits 8–15: RX FRL source test configuration Bits 16–31: Reserved

2.11. Design RTL Parameters

Use the HDMI TX and RX Top RTL parameters to customize the design example.

Most of the design parameters are available in the Design Example tab of the HDMI Intel^® FPGA IP parameter editor. You can still change the design example settings you made in the parameter editor through the RTL parameters.

Table 25. HDMI RX Top Parameters
Parameter	Value	Description
SUPPORT_DEEP_COLOR	0: No deep color 1: Deep color	Determines if the core can encode deep color formats.
SUPPORT_AUXILIARY	0: No AUX 1: AUX	Determines if the auxiliary channel encoding is included.
SYMBOLS_PER_CLOCK	8	Supports 8 symbols per clock for Intel^® Stratix^® 10 devices.
SUPPORT_AUDIO	0: No audio 1: Audio	Determines if the core can encode audio.
EDID_RAM_ADDR_WIDTH	8 (Default value)	Log base 2 of the EDID RAM size.

Table 26. HDMI TX Top Parameters
Parameter	Value	Description
USE_FPLL	1	Supports fPLL as TX PLL only for Intel^® Stratix^® 10 devices. Always set this parameter to 1.
SUPPORT_DEEP_COLOR	0: No deep color 1: Deep color	Determines if the core can encode deep color formats.
SUPPORT_AUXILIARY	0: No AUX 1: AUX	Determines if the auxiliary channel encoding is included.
SYMBOLS_PER_CLOCK	8	Supports 8 symbols per clock for Intel^® Stratix^® 10 devices.
SUPPORT_AUDIO	0: No audio 1: Audio	Determines if the core can encode audio.

2.12. Hardware Setup

The HDMI FRL-enabled design example is HDMI 2.1 capable and performs a loop-through demonstration for a standard HDMI video stream.

To run the hardware test, connect an HDMI-enabled device—such as a graphics card with HDMI interface—to the HDMI sink input. The design supports both HDMI 2.1 or HDMI 2.0/1.4b source and sink.

The HDMI sink decodes the port into a standard video stream and sends it to the clock recovery core.
The HDMI RX core decodes the video, auxiliary, and audio data to be looped back in parallel to the HDMI TX core through the DCFIFO.
The HDMI source port of the FMC daughter card transmits the image to a monitor.

Note: If you want to use another Intel FPGA development board, you must change the device assignments and the pin assignments. The transceiver analog setting is tested for the Intel^® Stratix^® 10 FPGA development kit and Bitec HDMI 2.1 daughter card. You may modify the settings for your own board.

On-board Push Button and User LED Functions
Push Button/LED	Function
cpu_resetn	Press once to perform system reset.
user_dipsw[0]	User-defined DIP switch to toggle the passthrough mode. OFF (default position) = Passthrough HDMI RX on the FPGA gets the EDID from external sink and presents it to the external source it is connected to. ON = You may control the RX maximum FRL rate from the Nios^® II terminal. The command modifies the RX EDID by manipulating the maximum FRL rate value. Refer to Running the Design in Different FRL Rates for more information about setting the different FRL rates.
user_dipsw[1]	User-defined DIP switch to toggle the passthrough mode. OFF (default position) = user_led[3:0] indicates RX status. ON = user_led[3:0] indicates TX status. Refer to user_led[3:0] for more details.
user_pb[0]	Press once to toggle the HPD signal to the standard HDMI source.
user_pb[1]	Reserved.
user_pb[2]	Press once to read the SCDC registers from the sink connected to the TX of the Bitec HDMI 2.1 FMC daughter card. Note: To enable read, you must set `DEBUG_MODE` to 1 in the software.
user_led[0]	user_dipsw[1] = ON	RX transceiver ready status. 0 = Not ready 1 = Ready
user_led[0]	user_dipsw[1] = OFF	TX transceiver ready status. 0 = Not ready 1 = Ready
user_led[1]	user_dipsw[1] = ON	RX FRL clock PLL lock status. 0 = Unlocked 1 = Locked
user_led[1]	user_dipsw[1] = OFF	TX FRL clock PLL lock status. 0 = Unlocked 1 = Locked
user_led[2]	user_dipsw[1] = ON	RX HDMI core alignment and deskew lock status. 0 = At least 1 channel is unlocked 1 = All channels are locked
user_led[2]	user_dipsw[1] = OFF	TX FRL start status. 0 = TX core transmits link training pattern 1 = TX core transmits normal video
user_led[3]	user_dipsw[1] = ON	RX HDMI video lock status. 0 = Unlocked 1 = Locked
user_led[3]	user_dipsw[1] = OFF	Reserved.

2.13. Simulation Testbench

The simulation testbench simulates the HDMI TX serial loopback to the RX core.

Note: This simulation testbench is not supported for designs with the Include I2C parameter enabled.

Figure 21. HDMI Intel^® FPGA IP Simulation Testbench Block Diagram

Table 27. Testbench Components
Component	Description
Video TPG	The video test pattern generator (TPG) provides the video stimulus.
Audio Sample Gen	The audio sample generator provides audio sample stimulus. The generator generates an incrementing test data pattern to be transmitted through the audio channel.
Aux Sample Gen	The aux sample generator provides the auxiliary sample stimulus. The generator generates a fixed data to be transmitted from the transmitter.
CRC Check	This checker verifies if the TX transceiver recovered clock frequency matches the desired data rate.
Audio Data Check	The audio data check compares whether the incrementing test data pattern is received and decoded correctly.
Aux Data Check	The aux data check compares whether the expected aux data is received and decoded correctly on the receiver side.

The HDMI simulation testbench does the following verification tests:

HDMI Feature	Verification
Video data	The testbench implements CRC checking on the input and output video. It checks the CRC value of the transmitted data against the CRC calculated in the received video data. The testbench then performs the checking after detecting 4 stable V-SYNC signals from the receiver.
Auxiliary data	The aux sample generator generates a fixed data to be transmitted from the transmitter. On the receiver side, the generator compares whether the expected auxiliary data is received and decoded correctly.
Audio data	The audio sample generator generates an incrementing test data pattern to be transmitted through the audio channel. On the receiver side, the audio data checker checks and compares whether the incrementing test data pattern is received and decoded correctly.

A successful simulation ends with the following message:

# SYMBOLS_PER_CLOCK 	= 2
# VIC               	= 4
# FRL_RATE          	= 0
# BPP               	= 0
# AUDIO_FREQUENCY (kHz)  = 48
# AUDIO_CHANNEL     	= 8
# Simulation pass

Table 28. HDMI Intel^® FPGA IP Design Example Supported Simulators
Simulator	Verilog HDL	VHDL
ModelSim* - Intel^® FPGA Edition/ ModelSim* - Intel^® FPGA Starter Edition	Yes	Yes
VCS* / VCS* MX	Yes	Yes
Riviera-PRO*	Yes	Yes
NCSim	Yes	No
Xcelium* Parallel	Yes	No

2.14. Design Limitations

You need to consider some limitations when instantiating the HDMI 2.1 design example.

TX is unable to operate in TMDS mode when in non-passthrough mode. To test in TMDS mode, toggle the user_dipsw switch back to passthrough mode.
The Nios^® II processor must serve the TX link training to completion without any interruption from other processes.
Image may not display properly on the television or monitor on certain resolutions. To reset the display, press the CPU_Resetn button.
HDMI RX may not be able to lock when running at 16 bpc.

2.15. Debugging Features

This design example provides certain debugging features to assist you.

2.15.1. Software Debugging Message

You can turn on the debugging message in the software to provide you run-time assistance.

To turn on the debugging message in the software, follow these steps:

Change the DEBUG_MODE to 1 in the global.h script.
Run script/build_sw.sh on the Nios^® II Command Shell.
Reprogram the generated software/tx_control/tx_control.elf file by running the command on the Nios^® II Command Shell:
```
nios2-download -r -g software/tx_control/tx_control.elf
```
Run the Nios^® II terminal command on the Nios^® II Command Shell:
```
nios2-terminal
```

When you turn on the debugging message, the following information print out:

TI redriver settings on both TX and RX are read and displayed once after programming ELF file.
Status message for RX EDID configuration and hotplug process
Resolution with or without FRL support information extracted from EDID on the sink connected to the TX. This information is displayed for every TX hotplug.
Status message for the TX link training process during TX link training.

2.15.2. SCDC Information from the Sink Connected to TX

You can use this feature to obtain SCDC information.

Run the Nios^® II terminal command on the Nios^® II Command Shell:
```
nios2-terminal
```
Press user_pb[2] on the Intel^® Stratix^® 10 FPGA development kit.

The software reads and displays the SCDC information on the sink connected to TX on the Nios^® II terminal.

2.15.3. Clock Frequency Measurement

Use this feature to check the frequency for the different clocks.

In the hdmi_rx_top and hdmi_tx_top files, uncomment “//`define DEBUG_EN 1”.
Add the refclock_measure signal from each mr_rate_detect instance to the Signal Tap Logic Analyzer to get the clock frequency of each clock (in 10 ms duration).
Compile the design with Signal Tap Logic Analyzer.
Program the SOF file and run the Signal Tap Logic Analyzer.

Table 29. Clocks
Module	mr_rate_detect Instance	Clock to be Measured
hdmi_rx_top	`rx_pll_tmds`	RX CDR reference clock 0
	`rx_clk0_freq`	RX transceiver clock out from channel 0
	`rx_vid_clk_freq`	RX video clock
	`rx_frl_clk_freq`	RX FRL clock
	`rx_hsync_freq`	Hsync frequency of the received video frame
hdmi_tx_top	`tx_clk0_freq`	TX transceiver clock out from channel 0
	`vid_clk_freq`	TX video clock
	`frl_clk_freq`	TX FRL clock
	`tx_hsync_freq`	Hsync frequency of the video frame to be transmitted

3. HDMI 2.0 Design Example

The HDMI Intel^® FPGA IP design example demonstrates one HDMI instance parallel loopback comprising three RX channels and four TX channels.

Table 30. HDMI Intel^® FPGA IP Design Example for Intel^® Stratix^® 10 Devices
Design Example	Data Rate	Channel Mode	Loopback Type
Stratix 10 HDMI RX-TX Retransmit	< 6,000 Mbps	Simplex	Parallel with FIFO buffer

Features

The design instantiates FIFO buffers to perform a direct HDMI video stream passthrough between the HDMI sink and source.
The design uses LED status for early debugging stage.
The design comes with RX and TX only options.
The design demonstrates the insertion and filtering of Dynamic Range and Mastering (HDR) InfoFrame in RX-TX link module.
The design demonstrates the management of EDID passthrough from an external HDMI sink to an external HDMI source when triggered by a TX hot-plug event.
The design uses push-button controlled HDMI TX core signals:
- mode signal to select DVI or HDMI encoded video frame
- info_avi[47], info_vsi[61], and audio_info_ai[48] signals to select auxiliary packet transmission through sidebands or auxiliary data ports

The RX instance receives a video source from the external video generator, and the data then goes through a loopback FIFO before it is transmitted to the TX instance. You need to connect an external video analyzer, monitor, or a television with HDMI connection to the TX core to verify the functionality.

3.1. HDMI RX-TX Retransmit Design Block Diagram

The HDMI RX-TX retransmit design example demonstrates parallel loopback on simplex channel mode for HDMI Intel^® FPGA IP.

Figure 22. HDMI RX-TX Retransmit Block Diagram

3.2. Creating TX or RX Only Designs

For advance users, you can use the HDMI design to create a TX or RX only design.

To use RX or TX only components, remove the irrelevant blocks from the design

User Requirement	Preserve	Remove	Add
HDMI RX Only	RX Top	TX Top RX-TX Link CPU Sub-System Transceiver Arbiter	—
HDMI TX Only	TX Top, CPU Sub-System	RX Top RX-TX Link Transceiver Arbiter	Video Pattern Generator (custom module or generated from the Video and Image Processing (VIP) Suite)

Figure 23. Components Required for RX or TX Only Design

Note: If your design only requires HDMI TX or retransmitting HDMI stream from RX to TX through video frame buffer, supply the TX PLL reference clock directly from an external programmable oscillator.

3.3. Design Components

The HDMI Intel^® FPGA IP design example requires these components.

Table 31. HDMI RX Top Components
Module	Description
HDMI RX Core	The IP receives the serial data from the Transceiver Native PHY and performs data alignment, channel deskew, TMDS decoding, auxiliary data decoding, video data decoding, audio data decoding, and descrambling.
I²C	I²C is the interface used for Sink Display Data Channel (DDC) and Status and Data Channel (SCDC). The HDMI source uses the DDC to determine the capabilities and characteristics of the sink by reading the Enhanced Extended Display Identification Data (E-EDID) data structure. The 8-bit I²C slave addresses for E-EDID are 0xA0 and 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 on-chip RAM. The I²C slave-only controller also supports SCDC for HDMI 2.0 operations. The 8-bit I²C slave address for the SCDC are 0xA8 and 0xA9. When an HPD event occurs, the I²C slave performs write or read transaction to or from SCDC interface of the HDMI RX core. Note: This I²C slave-only controller for SCDC is not required if HDMI 2.0b is not intended. If you turn on the Include I2C parameter, this block will be included inside the core and will not be visible at this level.
EDID RAM	The design stores the EDID information using the RAM 1-port IP core. A standard two-wire (clock and data) serial bus protocol (I²C slave-only controller) transfers the CEA-861-D Compliant E-EDID data structure. This EDID RAM stores the E-EDID information. Note: If you turn on the Include EDID RAM parameter, this block will be included inside the core and will not be visible at this level.
IOPLL	The IOPLL generates the RX CDR reference clock, link speed clock, and video clock for the incoming TMDS clock. Output clock 0 (Link speed clock) Output clock 1 (Video clock)
Transceiver PHY Reset Controller	The Transceiver PHY reset controller ensures a reliable initialization of the RX transceivers. The reset input of this controller is triggered by the RX reconfiguration, and it generates the corresponding analog and digital reset signal to the Transceiver Native PHY block according to the reset sequencing inside the block.
RX Native PHY	Hard transceiver block that receives the serial data from an external video source. It deserializes the serial data to parallel data before passing the data to the HDMI RX core.
RX Reconfiguration Management	RX reconfiguration management that implements rate detection circuitry with the HDMI PLL to drive the RX transceiver to operate at any arbitrary link rates ranging from 250 Mbps to 6,000 Mbps. Refer to Figure 24 below.
IOPLL Reconfiguration	IOPLL reconfiguration block facilitates dynamic real-time reconfiguration of PLLs in Intel FPGAs. This block updates the output clock frequency and PLL bandwidth in real time, without reconfiguring the entire FPGA. This block runs at 100 MHz in Intel^® Stratix^® 10 devices.

Figure 24. Multi-Rate Reconfiguration Sequence FlowThe figure illustrates the multi-rate reconfiguration sequence flow of the controller when it receives input data stream and reference clock frequency, or when the transceiver is unlocked.

Table 32. HDMI TX Top Components
Module	Description
HDMI TX Core	The IP core receives video data from the top level and performs TMDS encoding, auxiliary data encoding, audio data encoding, video data encoding, and scrambling.
IOPLL	The IOPLL supplies the link speed clock and video clock from the incoming TMDS clock. Output clock 0 (Link speed clock) Output clock 1 (Video clock)
Transceiver PHY Reset Controller	The Transceiver PHY reset controller ensures a reliable initialization of the TX transceivers. The reset input of this controller is triggered from the top level, and it generates the corresponding analog and digital reset signal to the Transceiver Native PHY block according to the reset sequencing inside the block. The `tx_ready` output signal from this block also functions as a reset signal to the HDMI Intel^® FPGA IP to indicate the transceiver is up and running, and ready to receive data from the core.
Transceiver Native PHY	Hard transceiver block that receives the parallel data from the HDMI TX core and serializes the data from transmitting it. Reconfiguration interface is enabled in the TX Native PHY block to demonstrate the connection between TX Native PHY and transceiver arbiter. No reconfiguration is performed for TX Native PHY.
TX PLL	The transmitter PLL block provides the serial fast clock to the Transceiver Native PHY block. For this HDMI Intel^® FPGA IP design example, fPLL is used as TX PLL.
IOPLL Reconfiguration	IOPLL reconfiguration block facilitates dynamic real-time reconfiguration of PLLs in Intel FPGAs. This block updates the output clock frequency and PLL bandwidth in real time, without reconfiguring the entire FPGA. This block runs at 100 MHz in Intel^® Stratix^® 10 devices.

Table 33. Transceiver Data Rate and Oversampling Factor for Each TMDS Clock Frequency Range
TMDS Clock Frequency (MHz)	TMDS Bit clock Ratio	Oversampling Factor	Transceiver Data Rate (Mbps)
85–150	1	Not applicable	3400–6000
100–340	0	Not applicable	1000–3400
50–100	0	5	2500–5000
35–50	0	3	1050–1500
30–35	0	4	1200–1400
25–30	0	5	1250–1500

Table 34. Top-Level Common Blocks
Module	Description
Transceiver Arbiter	This generic functional block prevents transceivers from recalibrating simultaneously when either RX or TX transceivers within the same physical channel require reconfiguration. The simultaneous recalibration impacts applications where RX and TX transceivers within the same channel are assigned to independent IP implementations. This transceiver arbiter is an extension to the resolution recommended for merging simplex TX and simplex RX into the same physical channel. This transceiver arbiter also assists in merging and arbitrating the Avalon-MM RX and TX reconfiguration requests targeting simplex RX and TX transceivers within a channel as the reconfiguration interface port of the transceivers can only be accessed sequentially. The interface connection between the transceiver arbiter and TX/RX Native PHY/PHY Reset Controller blocks in this design example demonstrates a generic mode that apply for any IP combination using the transceiver arbiter. The transceiver arbiter is not required when only either RX or TX transceiver is used in a channel. The transceiver arbiter identifies the requester of a reconfiguration through its Avalon-MM reconfiguration interfaces and ensures that the corresponding `tx_reconfig_cal_busy` or `rx_reconfig_cal_busy` is gated accordingly. For HDMI application, only RX initiates reconfiguration. By channeling the Avalon-MM reconfiguration request through the arbiter, the arbiter identifies that the reconfiguration request originates from the RX, which then gates `tx_reconfig_cal_busy` from asserting and allows `rx_reconfig_cal_busy` to assert. The gating prevents the TX transceiver from being moved to calibration mode unintentionally. Note: Because HDMI only requires RX reconfiguration, the `tx_reconfig_mgmt_*` signals are tied off. Also, the Avalon-MM interface is not required between the arbiter and the TX Native PHY block. The blocks are assigned to the interface in the design example to demonstrate generic transceiver arbiter connection to TX/RX Native PHY/PHY Reset Controller.
RX-TX Link	The video data output and synchronization signals from HDMI RX core loop through a DCFIFO across the RX and TX video clock domains. The General Control Packet (GCP), InfoFrames (AVI, VSI and AI), auxiliary data, and audio data loop through DCFIFOs across the RX and TX link speed clock domains. The auxiliary data port of the HDMI TX core controls the auxiliary data that flow through the DCFIFO through backpressure. The backpressure ensures there is no incomplete auxiliary packet on the auxiliary data port. This block also performs external filtering: Filters the audio data and audio clock regeneration packet from the auxiliary data stream before transmitting to the HDMI TX core auxiliary data port. Note: To disable this filtering, press `user_pb[2]`. Enable this filtering to ensure there is no duplication of audio data and audio clock regeneration packet in the retransmitted auxiliary data stream. Filters the High Dynamic Range (HDR) InfoFrame from the HDMI RX auxiliary data and inserts an example HDR InfoFrame to the auxiliary data of the HDMI TX through the Avalon ST multiplexer.
CPU Sub-System	The CPU sub-system functions as SCDC and DDC controllers, and source reconfiguration controller. The source SCDC controller contains the I²C master controller. The I²C master controller transfers the SCDC data structure from the FPGA source to the external sink for HDMI 2.0b operation. 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 also transfers the DDC data structure (E-EDID) between the HDMI source and external sink. The Nios II CPU acts as the reconfiguration controller for the HDMI source. The CPU relies on the periodic rate detection from the RX Reconfiguration Management module to determine if the 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 IOPLL and TX Native PHY. The reconfiguration sequence flow for TX is same as RX, except that the PLL and transceiver reconfiguration and the reset sequence is performed sequentially. Refer to Figure 25.

Figure 25. Reconfiguration Sequence FlowThe figure illustrates the Nios II software flow that involves the controls for I²C master and HDMI source.

3.4. Dynamic Range and Mastering (HDR) InfoFrame Insertion and Filtering

The HDMI Intel^® FPGA IP design example includes a demonstration of HDR InfoFrame insertion in a RX-TX loopback system.

Figure 26. RX-TX Link with Dynamic Range and Mastering InfoFrame InsertionThe figure shows the block diagram of RX-TX link including Dynamic Range and Mastering InfoFrame insertion into the HDMI TX core auxiliary stream.

Table 35. Auxiliary Data Insertion Block (aux_retransmit) Signals
Signal	Direction	Width	Description
Clock and Reset
`clk`	Input	1	Clock input. This clock should be connected to the video clock.
`reset`	Input	1	Reset input.
Auxiliary Packet Signals
`tx_aux_data`	Output	72	TX Auxiliary packet output from the multiplexer.
`tx_aux_valid`	Output	1
`tx_aux_ready`	Output	1
`tx_aux_sop`	Output	1
`tx_aux_eop`	Output	1
`rx_aux_data`	Input	72	RX Auxiliary data passed to the packet filter module before entering the multiplexer.
`rx_aux_valid`	Input	1
`rx_aux_sop`	Input	1
`rx_aux_eop`	Input	1
Control Signal
`rx_vid_vsync`	Input	1	HDMI RX Video Vsync. The core inserts the HDR InfoFrame to the auxiliary stream at the rising edge of this signal.

Table 36. HDR Data Module (altera_hdmi_hdr_infoframe) Signals
Signal	Direction	Width	Description
`hb0`	Output	8	Header byte 0 of the Dynamic Range and Mastering InfoFrame: InfoFrame type code.
`hb1`	Output	8	Header byte 1 of the Dynamic Range and Mastering InfoFrame: InfoFrame version number.
`hb2`	Output	8	Header byte 2 of the Dynamic Range and Mastering InfoFrame: Length of InfoFrame.
`pb`	Input	224	Data byte of the Dynamic Range and Mastering InfoFrame.

Table 37. Dynamic Range and Mastering InfoFrame Data Byte Bundle Bit-Fields
Bit-Field	Definition	Static Metadata Type 1
7:0	Data Byte 1: {5'h0, EOTF[2:0]}
15:8	Data Byte 2: {5'h0, Static_Metadata_Descriptor_ID[2:0]}
23:16	Data Byte 3: Static_Metadata_Descriptor	display_primaries_x[0], LSB
31:24	Data Byte 4: Static_Metadata_Descriptor	display_primaries_x[0], MSB
39:32	Data Byte 5: Static_Metadata_Descriptor	display_primaries_y[0], LSB
47:40	Data Byte 6: Static_Metadata_Descriptor	display_primaries_y[0], MSB
55:48	Data Byte 7: Static_Metadata_Descriptor	display_primaries_x[1], LSB
63:56	Data Byte 8: Static_Metadata_Descriptor	display_primaries_x[1], MSB
71:64	Data Byte 9: Static_Metadata_Descriptor	display_primaries_y[1], LSB
79:72	Data Byte 10: Static_Metadata_Descriptor	display_primaries_y[1], MSB
87:80	Data Byte 11: Static_Metadata_Descriptor	display_primaries_x[2], LSB
95:88	Data Byte 12: Static_Metadata_Descriptor	display_primaries_x[2], MSB
103:96	Data Byte 13: Static_Metadata_Descriptor	display_primaries_y[2], LSB
111:104	Data Byte 14: Static_Metadata_Descriptor	display_primaries_y[2], MSB
119:112	Data Byte 15: Static_Metadata_Descriptor	white_point_x, LSB
127:120	Data Byte 16: Static_Metadata_Descriptor	white_point_x, MSB
135:128	Data Byte 17: Static_Metadata_Descriptor	white_point_y, LSB
143:136	Data Byte 18: Static_Metadata_Descriptor	white_point_y, MSB
151:144	Data Byte 19: Static_Metadata_Descriptor	max_display_mastering_luminance, LSB
159:152	Data Byte 20: Static_Metadata_Descriptor	max_display_mastering_luminance, MSB
167:160	Data Byte 21: Static_Metadata_Descriptor	min_display_mastering_luminance, LSB
175:168	Data Byte 22: Static_Metadata_Descriptor	min_display_mastering_luminance, MSB
183:176	Data Byte 23: Static_Metadata_Descriptor	Maximum Content Light Level, LSB
191:184	Data Byte 24: Static_Metadata_Descriptor	Maximum Content Light Level, MSB
199:192	Data Byte 25: Static_Metadata_Descriptor	Maximum Frame-average Light Level, LSB
207:200	Data Byte 26: Static_Metadata_Descriptor	Maximum Frame-average Light Level, MSB
215:208	Reserved
223:216	Reserved

Disabling HDR Insertion and Filtering

3.5. Clocking Scheme

The clocking scheme illustrates the clock domains in the HDMI Intel^® FPGA IP design example.

Figure 27. HDMI Intel^® FPGA IP Design Example Clocking Scheme

Table 38. Clocking Scheme Signals

Clock

Signal Name in Design

Description

TX IOPLL/ TX PLL Reference Clock

hdmi_clk_in

Reference clock to the TX IOPLL and TX PLL. The clock frequency is the same as the expected TMDS clock frequency from the HDMI TX TMDS clock channel.

For this HDMI Intel^® FPGA IP design example, this clock is connected to the RX TMDS clock for demonstration purpose. In your application, you need to supply a dedicated clock with TMDS clock frequency from a programmable oscillator for better jitter performance.

Note: Do not use a transceiver RX pin as a TX PLL reference clock. Your design will fail to fit if you place the HDMI TX refclk on an RX pin.

TX Transceiver Clock Out

tx_clk

Clock out recovered from the transceiver, and the frequency varies depending on the data rate and symbols per clock.

TX transceiver clock out frequency = Transceiver data rate/ (Symbol per clock*10)

TX PLL Serial Clock

tx_bonding_clocks

Serial fast clock generated by TX PLL. The clock frequency is set based on the data rate.

TX/RX Link Speed Clock

ls_clk

Link speed clock. The link speed clock frequency depends on the expected TMDS clock frequency, oversampling factor, symbols per clock, and TMDS bit clock ratio.

TMDS Bit Clock Ratio	Link Speed Clock Frequency
0	TMDS clock frequency/ Symbol per clock
1	TMDS clock frequency *4 / Symbol per clock

TX/RX Video Clock

vid_clk

Video data clock. The video data clock frequency is derived from the TX link speed clock based on the color depth.

TMDS Bit Clock Ratio	Video Data Clock Frequency
0	TMDS clock/ Symbol per clock/ Color depth factor
1	TMDS clock *4 / Symbol per clock/ Color depth factor

Bits per Color	Color Depth Factor
8	1
10	1.25
12	1.5
16	2.0

RX TMDS Clock

tmds_clk_in

TMDS clock channel from the HDMI RX and connects to the reference clock to the IOPLL.

RX Transceiver Clock Out

rx_clk

Clock out recovered from the transceiver, and the frequency varies depending on the data rate and symbols per clock.

RX transceiver clock out frequency = Transceiver data rate/ (Symbol per clock*10)

Management Clock

mgmt_clk

A free running 100 MHz clock for these components:

Avalon-MM interfaces for reconfiguration
- The frequency range requirement is between 100–125 MHz.
PHY reset controller for transceiver reset sequence
- The frequency range requirement is between 1–500 MHz.
IOPLL Reconfiguration
- The maximum clock frequency is 100 MHz.
RX Reconfiguration for management
CPU
I²C Master

I²C Clock

i2c_clk

A 50 MHz clock input that clocks I²C slave, SCDC registers in the HDMI RX core, and EDID RAM.

3.6. Interface Signals

The tables list the signals for the HDMI Intel^® FPGA IP design example.

Table 39. Top-Level Signals
Signal	Direction	Width	Description
On-board Oscillator Signal
`clk_fpga_b3_p`	Input	1	100 MHz free running clock for core reference clock
User Push Buttons and LEDs
`user_pb`	Input	1	Push button to control the HDMI Intel^® FPGA IP design functionality
`cpu_resetn`	Input	1	Global reset
`user_led_g`	Output	8	Green LED display Refer to Table 47 for more information about the LED functions.
HDMI FMC Daughter Card Pins on FMC Port B
`fmcb_gbtclk_m2c_p_0`	Input	1	HDMI RX TMDS clock
`fmcb_dp_m2c_p`	Input	3	HDMI RX red, green, and blue data channels Bitec daughter card revision 11 [0]: RX TMDS Channel 1 (Green) [1]: RX TMDS Channel 2 (Red) [2]: RX TMDS Channel 0 (Blue) Bitec daughter card revision 4 or 6 [0]: RX TMDS Channel 1 (Green)—polarity inverted [1]: RX TMDS Channel 0 (Blue)—polarity inverted [2]: RX TMDS Channel 2 (Red)—polarity inverted
`fmcb_dp_c2m_p`	Output	4	HDMI TX clock, red, green, and blue data channels Bitec daughter card revision 11 [0]: TX TMDS Channel 2 (Red) [1]: TX TMDS Channel 1 (Green) [2]: TX TMDS Channel 0 (Blue) [3]: TX TMDS Clock Channel Bitec daughter card revision 4 or 6 [0]: TX TMDS Clock Channel [1]: TX TMDS Channel 0 (Blue) [2]: TX TMDS Channel 1 (Green) [3]: TX TMDS Channel 2 (Red)
`fmcb_la_rx_p_9`	Input	1	HDMI RX +5V power detect
`fmcb_la_rx_p_8`	Inout	1	HDMI RX hot plug detect
`fmcb_la_rx_n_8`	Inout	1	HDMI RX I²C SDA for DDC and SCDC
`fmcb_la_tx_p_10`	Input	1	HDMI RX I²C SCL for DDC and SCDC
`fmcb_la_tx_p_12`	Input	1	HDMI TX hot plug detect
`fmcb_la_tx_n_12`	Inout	1	HDMI I²C SDA for DDC and SCDC
`fmcb_la_rx_p_10`	Inout	1	HDMI I²C SCL for DDC and SCDC
`fmcb_la_tx_p_11`	Inout	1	HDMI I²C SDA for redriver control
`fmcb_la_rx_n_9`	Inout	1	HDMI I²C SCL for redriver control

Table 40. HDMI RX Top-Level Signals
Signal	Direction	Width	Description
Clock and Reset Signals
`mgmt_clk`	Input	1	System clock input (100 MHz)
`fr_clk`	Input	1	Free running clock (625 MHz) for primary transceiver reference clock. This clock is required for transceiver calibration during power-up state. This clock can be of any frequency.
`reset`	Input	1	System reset input
`reset_xcvr_powerup`	Input	1	Transceiver reset input. This signal is asserted during the reference clocks switching process (from free running clock to TMDS clock) in power-up state.
`tmds_clk_in`	Input	1	HDMI RX TMDS clock
`i2c_clk`	Input	1	Clock input for DDC and SCDC interface
`vid_clk_out`	Output	1	Video clock output
`ls_clk_out`	Output	1	Link speed clock output
`sys_init`	Input	1	System initialization to reset the system upon power-up
RX Transceiver and IOPLL Signals
`rx_serial_data`	Input	3	HDMI serial data to the RX Native PHY
`gxb_rx_ready`	Output	1	Indicates RX Native PHY is ready
`gxb_rx_cal_busy_out`	Output	3	RX Native PHY calibration busy to the transceiver arbiter
`gxb_rx_cal_busy_in`	Input	3	Calibration busy signal from the transceiver arbiter to the RX Native PHY
`iopll_locked`	Output	1	Indicate IOPLL is locked
`gxb_reconfig_write`	Input	3	Transceiver reconfiguration Avalon-MM interface from the RX Native PHY to the transceiver arbiter
`gxb_reconfig_read`	Input	3
`gxb_reconfig_address`	Input	33
`gxb_reconfig_writedata`	Input	96
`gxb_reconfig_readdata`	Output	96
`gxb_reconfig_waitrequest`	Output	3
RX Reconfiguration Management
`rx_reconfig_en`	Output	1	RX Reconfiguration enables signal
`measure`	Output	24	HDMI RX TMDS clock frequency measurement (in 10 ms)
`measure_valid`	Output	1	Indicates the measure signal is valid
`os`	Output	1	Oversampling factor: 0: No oversampling 1: 5× oversampling
`reconfig_mgmt_write`	Output	1	RX reconfiguration management Avalon memory-mapped interface to transceiver arbiter
`reconfig_mgmt_read`	Output	1
`reconfig_mgmt_address`	Output	13
`reconfig_mgmt_writedata`	Output	32
`reconfig_mgmt_readdata`	Input	32
`reconfig_mgmt_waitrequest`	Input	1
HDMI RX Core Signals
`TMDS_Bit_clock_Ratio`	Output	1	SCDC register interfaces
`audio_de`	Output	1	HDMI RX core audio interfaces Refer to the Sink Interfaces section in the HDMI Intel^® FPGA IP User Guide for more information.
`audio_data`	Output	256
`audio_info_ai`	Output	48
`audio_N`	Output	20
`audio_CTS`	Output	20
`audio_metadata`	Output	165
`audio_format`	Output	5
`aux_pkt_data`	Output	72	HDMI RX core auxiliary interfaces Refer to the Sink Interfaces section in the HDMI Intel^® FPGA IP User Guide for more information.
`aux_pkt_addr`	Output	6
`aux_pkt_wr`	Output	1
`aux_data`	Output	72
`aux_sop`	Output	1
`aux_eop`	Output	1
`aux_valid`	Output	1
`aux_error`	Output	1
`gcp`	Output	6	HDMI RX core sideband signals Refer to the Sink Interfaces section in the HDMI Intel^® FPGA IP User Guide for more information.
`info_avi`	Output	112
`info_vsi`	Output	61
`colordepth_mgmt_sync`	Output	2
`vid_data`	Output	N*48	HDMI RX core video ports Note: N = symbols per clock Refer to the Sink Interfaces section in the HDMI Intel^® FPGA IP User Guide for more information.
`vid_vsync`	Output	N
`vid_hsync`	Output	N
`vid_de`	Output	N
`mode`	Output	1	HDMI RX core control and status ports Note: N = symbols per clock Refer to the Sink Interfaces section in the HDMI Intel^® FPGA IP User Guide for more information.
`ctrl`	Output	N*6
`locked`	Output	3
`vid_lock`	Output	1
`in_5v_power`	Input	1	HDMI RX 5V detect and hotplug detect Refer to the Sink Interfaces section in the HDMI Intel^® FPGA IP User Guide for more information.
`hdmi_rx_hpd_n`	Inout	1
I²C Signals
`hdmi_rx_i2c_sda`	Inout	1	HDMI RX DDC and SCDC interface
`hdmi_rx_i2c_scl`	Inout	1	HDMI RX DDC and SCDC interface
RX EDID RAM Signals
`edid_ram_access`	Input	1	HDMI RX EDID RAM access interface. Assert `edid_ram_access` when you want to write or read from the EDID RAM, else this signal should be kept low.
`edid_ram_address`	Input	8
`edid_ram_write`	Input	1
`edid_ram_read`	Input	1
`edid_ram_readdata`	Output	8
`edid_ram_writedata`	Input	8
`edid_ram_waitrequest`	Output	1

Table 41. HDMI TX Top-Level Signals
Signal	Direction	Width	Description
Clock and Reset Signals
`mgmt_clk`	Input	1	System clock input (100 MHz)
`fr_clk`	Input	1	Free running clock (625 MHz) for primary transceiver reference clock. This clock is required for transceiver calibration during power-up state. This clock can be of any frequency.
`reset`	Input	1	System reset input
`hdmi_clk_in`	Input	1	Reference clock to TX IOPLL and TX PLL. The clock frequency is the same as the TMDS clock frequency.
`vid_clk_out`	Output	1	Video clock output
`ls_clk_out`	Output	1	Link speed clock output
`sys_init`	Input	1	System initialization to reset the system upon power-up
`reset_xcvr`	Input	1	Reset to TX transceiver
`reset_pll`	Input	1	Reset to IOPLL and TX PLL
`reset_pll_reconfig`	Output	1	Reset to PLL reconfiguration
TX Transceiver and IOPLL Signals
`tx_serial_data`	Output	4	HDMI serial data from the TX Native PHY
`gxb_tx_ready`	Output	1	Indicates TX Native PHY is ready
`gxb_tx_cal_busy_out`	Output	4	TX Native PHY calibration busy signal to the transceiver arbiter
`gxb_tx_cal_busy_in`	Input	4	Calibration busy signal from the transceiver arbiter to the TX Native PHY
`iopll_locked`	Output	1	Indicate IOPLL is locked
`txpll_locked`	Output	1	Indicate TX PLL is locked
`gxb_reconfig_write`	Input	4	Transceiver reconfiguration Avalon memory-mapped interface from the TX Native PHY to the transceiver arbiter
`gxb_reconfig_read`	Input	4
`gxb_reconfig_address`	Input	44
`gxb_reconfig_writedata`	Input	128
`gxb_reconfig_readdata`	Output	128
`gxb_reconfig_waitrequest`	Output	4
TX IOPLL and TX PLL Reconfiguration Signals
`pll_reconfig_write`/`tx_pll_reconfig_write`	Input	1	TX IOPLL/TX PLL reconfiguration Avalon memory-mapped interfaces
`pll_reconfig_read`/`tx_pll_reconfig_read`	Input	1
`pll_reconfig_address`/`tx_pll_reconfig_address`	Input	10
`pll_reconfig_writedata`/`tx_pll_reconfig_writedata`	Input	32
`pll_reconfig_readdata`/`tx_pll_reconfig_readdata`	Output	32
`pll_reconfig_waitrequest`/`tx_pll_reconfig_waitrequest`	Output	1
`os`	Input	2	Oversampling factor: 0: No oversampling 1: 3× oversampling 2: 4× oversampling 3: 5× oversampling
`measure`	Input	24	Indicates the TMDS clock frequency of the transmitting video resolution.
HDMI TX Core Signals
`ctrl`	Input	6*N	HDMI TX core control interfaces Note: N = Symbols per clock Refer to the Source Interfaces section in the HDMI Intel^® FPGA IP User Guide for more information.
`mode`	Input	1
`TMDS_Bit_clock_Ratio`	Input	1	SCDC register interfaces Refer to the Source Interfaces section in the HDMI Intel^® FPGA IP User Guide for more information.
`Scrambler_Enable`	Input	1
`audio_de`	Input	1	HDMI TX core audio interfaces Refer to the Source Interfaces section in the HDMI Intel^® FPGA IP User Guide for more information.
`audio_mute`	Input	1
`audio_data`	Input	256
`audio_info_ai`	Input	49
`audio_N`	Input	22
`audio_CTS`	Input	22
`audio_metadata`	Input	166
`audio_format`	Input	5
`i2c_master_write`	Input	1	TX I²C master Avalon^® memory-mapped interface to I²C master inside the TX core. Note: These signals are available only when you turn on the Include I2C parameter.
`i2c_master_read`	Input	1
`i2c_master_address`	Input	4
`i2c_master_writedata`	Input	32
`i2c_master_readdata`	Output	32
`aux_ready`	Output	1	HDMI TX core auxiliary interfaces Refer to the Source Interfaces section in the HDMI Intel^® FPGA IP User Guide for more information.
`aux_data`	Input	72
`aux_sop`	Input	1
`aux_eop`	Input	1
`aux_valid`	Input	1
`gcp`	Input	6	HDMI TX core sideband signals Refer to the Source Interfaces section in the HDMI Intel^® FPGA IP User Guide for more information.
`info_avi`	Input	113
`info_vsi`	Input	62
`vid_data`	Input	N*48	HDMI TX core video ports Note: N = symbols per clock Refer to the Source Interfaces section in the HDMI Intel^® FPGA IP User Guide for more information.
`vid_vsync`	Input	N
`vid_hsync`	Input	N
`vid_de`	Input	N
I²C and Hot Plug Detect Signals
`nios_tx_i2c_sda_in` Note: When you turn on the Include I2C parameter, this signal is placed in the TX core and will not be visible at this level.	Output	1	I²C Master Avalon^® memory-mapped interfaces
`nios_tx_i2c_scl_in` Note: When you turn on the Include I2C parameter, this signal is placed in the TX core and will not be visible at this level.	Output	1
`nios_tx_i2c_sda_oe` Note: When you turn on the Include I2C parameter, this signal is placed in the TX core and will not be visible at this level.	Input	1
`nios_tx_i2c_scl_oe` Note: When you turn on the Include I2C parameter, this signal is placed in the TX core and will not be visible at this level.	Input	1
`nios_ti_i2c_sda_in`	Output	1
`nios_ti_i2c_scl_in`	Output	1
`nios_ti_i2c_sda_oe`	Input	1
`nios_ti_i2c_scl_oe`	Input	1
`hdmi_tx_i2c_sda`	Inout	1	HDMI TX DDC and SCDC interfaces
`hdmi_tx_i2c_scl`	Inout	1	HDMI TX DDC and SCDC interfaces
`hdmi_ti_i2c_sda`	Inout	1	I²C interface for Bitec Daughter Card Revision 11 TI181 Control
`hdmi_tx_ti_i2c_sda`	Inout	1
`hdmi_ti_i2c_scl`	Inout	1
`hdmi_tx_ti_i2c_scl`	Inout	1
`tx_i2c_avalon_waitrequest`	Output	1	Avalon memory-mapped interfaces of I²C master
`tx_i2c_avalon_address`	Input	3
`tx_i2c_avalon_writedata`	Input	8
`tx_i2c_avalon_readdata`	Output	8
`tx_i2c_avalon_chipselect`	Input	1
`tx_i2c_avalon_write`	Input	1
`tx_i2c_irq`	Output	1
`tx_ti_i2c_avalon_waitrequest`	Output	1
`tx_ti_i2c_avalon_address`	Input	3
`tx_ti_i2c_avalon_writedata`	Input	8
`tx_ti_i2c_avalon_readdata`	Output	8
`tx_ti_i2c_avalon_chipselect`	Input	1
`tx_ti_i2c_avalon_write`	Input	1
`tx_ti_i2c_irq`	Output	1
`hdmi_tx_hpd_n`	Input	1	HDMI TX hotplug detect interfaces
`tx_hpd_ack`	Input	1
`tx_hpd_req`	Output	1

Table 42. Transceiver Arbiter Signals
Signal	Direction	Width	Description
`clk`	Input	1	Reconfiguration clock. This clock must share the same clock with the reconfiguration management blocks.
`reset`	Input	1	Reset signal. This reset must share the same reset with the reconfiguration management blocks.
`rx_rcfg_en`	Input	1	RX reconfiguration enable signal
`tx_rcfg_en`	Input	1	TX reconfiguration enable signal
`rx_rcfg_ch`	Input	2	Indicates which channel to be reconfigured on the RX core. This signal must always remain asserted.
`tx_rcfg_ch`	Input	2	Indicates which channel to be reconfigured on the TX core. This signal must always remain asserted.
`rx_reconfig_mgmt_write`	Input	1	Reconfiguration Avalon-MM interfaces from the RX reconfiguration management
`rx_reconfig_mgmt_read`	Input	1
`rx_reconfig_mgmt_address`	Input	11
`rx_reconfig_mgmt_writedata`	Input	32
`rx_reconfig_mgmt_readdata`	Output	32
`rx_reconfig_mgmt_waitrequest`	Output	1
`tx_reconfig_mgmt_write`	Input	1	Reconfiguration Avalon-MM interfaces from the TX reconfiguration management
`tx_reconfig_mgmt_read`	Input	1
`tx_reconfig_mgmt_address`	Input	11
`tx_reconfig_mgmt_writedata`	Input	32
`tx_reconfig_mgmt_readdata`	Output	32
`tx_reconfig_mgmt_waitrequest`	Output	1
`reconfig_write`	Output	1	Reconfiguration Avalon-MM interfaces to the transceiver
`reconfig_read`	Output	1
`reconfig_address`	Output	11
`reconfig_writedata`	Output	32
`rx_reconfig_readdata`	Input	32
`rx_reconfig_waitrequest`	Input	1
`tx_reconfig_readdata`	Input	1
`tx_reconfig_waitrequest`	Input	1
`rx_cal_busy`	Input	1	Calibration status signal from the RX transceiver
`tx_cal_busy`	Input	1	Calibration status signal from the TX transceiver
`rx_reconfig_cal_busy`	Output	1	Calibration status signal to the RX transceiver PHY reset control
`tx_reconfig_cal_busy`	Output	1	Calibration status signal from the TX transceiver PHY reset control

Table 43. RX-TX Link Signals
Signal	Direction	Width	Description
`reset`	Input	1	Reset to the video/audio/auxiliary/sidebands FIFO buffer.
`hdmi_tx_ls_clk`	Input	1	HDMI TX link speed clock
`hdmi_rx_ls_clk`	Input	1	HDMI RX link speed clock
`hdmi_tx_vid_clk`	Input	1	HDMI TX video clock
`hdmi_rx_vid_clk`	Input	1	HDMI RX video clock
`hdmi_rx_locked`	Input	3	Indicates HDMI RX locked status
`hdmi_rx_de`	Input	N	HDMI RX video interfaces Note: N = symbols per clock
`hdmi_rx_hsync`	Input	N
`hdmi_rx_vsync`	Input	N
`hdmi_rx_data`	Input	N48*
`rx_audio_format`	Input	5	HDMI RX audio interfaces
`rx_audio_metadata`	Input	165
`rx_audio_info_ai`	Input	48
`rx_audio_CTS`	Input	20
`rx_audio_N`	Input	20
`rx_audio_de`	Input	1
`rx_audio_data`	Input	256
`rx_gcp`	Input	6	HDMI RX sideband interfaces
`rx_info_avi`	Input	112
`rx_info_vsi`	Input	61
`rx_aux_eop`	Input	1	HDMI RX auxiliary interfaces
`rx_aux_sop`	Input	1
`rx_aux_valid`	Input	1
`rx_aux_data`	Input	72
`hdmi_tx_de`	Output	N	HDMI TX video interfaces Note: N = symbols per clock
`hdmi_tx_hsync`	Output	N
`hdmi_tx_vsync`	Output	N
`hdmi_tx_data`	Output	N48*
`tx_audio_format`	Output	5	HDMI TX audio interfaces
`tx_audio_metadata`	Output	165
`tx_audio_info_ai`	Output	48
`tx_audio_CTS`	Output	20
`tx_audio_N`	Output	20
`tx_audio_de`	Output	1
`tx_audio_data`	Output	256
`tx_gcp`	Output	6	HDMI TX sideband interfaces
`tx_info_avi`	Output	112
`tx_info_vsi`	Output	61
`tx_aux_eop`	Output	1	HDMI TX auxiliary interfaces
`tx_aux_sop`	Output	1
`tx_aux_valid`	Output	1
`tx_aux_data`	Output	72
`tx_aux_ready`	Output	1

Table 44. Platform Designer System Signals
Signal	Direction	Width	Description
`clock_bridge_0_in_clk_clk`	Input	1	CPU clock
`reset_bridge_0_reset_reset_n`	Input	1	CPU reset
`tmds_bit_clock_ratio_pio_external_connection_export`	Input	1	TMDS bit clock ratio
`measure_pio_external_connection_export`	Input	24	Expected TMDS clock frequency
`measure_valid_req_export`	Input	1 1	Indicates measure PIO is valid
`measure_valid_ack_export`	Input	1 1	Indicates measure PIO is valid
`i2c_master_i2c_serial_sda_in`	Input	1	I²C Master interfaces
`i2c_master_i2c_serial_scl_in`	Input	1
`i2c_master_i2c_serial_sda_oe`	Output	1
`i2c_master_i2c_serial_scl_oe`	Output	1
`i2c_master_ti_i2c_serial_sda_in`	Input	1
`i2c_master_ti_i2c_serial_scl_in`	Input	1
`i2c_master_ti_i2c_serial_sda_oe`	Output	1
`i2c_master_ti_i2c_serial_scl_oe`	Output	1
`edid_ram_access_pio_external_connection_export`	Output	1	EDID RAM access interfaces. Assert `edid_ram_access_pio_external_connection_export` when you want to write to or read from the EDID RAM on the RX top. Connect EDID RAM access Avalon-MM slave in Platform Designer to the EDID RAM interface on the top-level RX modules.
`edid_ram_slave_translator_address`	Output	8
`edid_ram_slave_translator_write`	Output	1
`edid_ram_slave_translator_read`	Output	1
`edid_ram_slave_translator_readdata`	Input	8
`edid_ram_slave_translator_writedata`	Output	8
`edid_ram_slave_translator_waitrequest`	Input	1
`powerup_cal_done_export`	Input	1	RX PMA Reconfiguration Avalon^® memory-mapped interfaces
`rx_pma_cal_busy_export`	Input	1
`rx_pma_ch_export`	Output	2
`rx_pma_rcfg_mgmt_address`	Output	12
`rx_pma_rcfg_mgmt_write`	Output	1
`rx_pma_rcfg_mgmt_read`	Output	1
`rx_pma_rcfg_mgmt_readdata`	Input	32
`rx_pma_rcfg_mgmt_writedata`	Output	32
`rx_pma_rcfg_mgmt_waitrequest`	Input	1
`rx_pma_waitrequest_export`	Input	1
`rx_rcfg_en_export`	Output	1
`rx_rst_xcvr_export`	Output	1
`tx_pll_rcfg_mgmt_translator_avalon_anti_slave_waitrequest`	Input	1	TX PLL Reconfiguration Avalon^® memory-mapped interfaces
`tx_pll_rcfg_mgmt_translator_avalon_anti_slave_writedata`	Output	32
`tx_pll_rcfg_mgmt_translator_avalon_anti_slave_address`	Output	11
`tx_pll_rcfg_mgmt_translator_avalon_anti_slave_write`	Output	1
`tx_pll_rcfg_mgmt_translator_avalon_anti_slave_read`	Output	1
`tx_pll_rcfg_mgmt_translator_avalon_anti_slave_readdata`	Input	32
`tx_pll_waitrequest_pio_external_connection_export`	Input	1	TX PLL waitrequest
`tx_pma_rcfg_mgmt_translator_avalon_anti_slave_address`	Output	13	TX PMA Reconfiguration Avalon^® memory-mapped interfaces
`tx_pma_rcfg_mgmt_translator_avalon_anti_slave_write`	Output	1
`tx_pma_rcfg_mgmt_translator_avalon_anti_slave_read`	Output	1
`tx_pma_rcfg_mgmt_translator_avalon_anti_slave_readdata`	Input	32
`tx_pma_rcfg_mgmt_translator_avalon_anti_slave_writedata`	Output	32
`tx_pma_rcfg_mgmt_translator_avalon_anti_slave_waitrequest`	Input	1
`tx_pma_waitrequest_pio_external_connection_export`	Input	1	TX PMA waitrequest
`tx_pma_cal_busy_pio_external_connection_export`	Input	1	TX PMA Recalibration Busy
`tx_pma_ch_export`	Output	2	TX PMA Channels
`tx_rcfg_en_pio_external_connection_export`	Output	1	TX PMA Reconfiguration Enable
`tx_iopll_rcfg_mgmt_translator_avalon_anti_slave_writedata`	Output	32	TX IOPLL Reconfiguration Avalon^® memory-mapped interfaces
`tx_iopll_rcfg_mgmt_translator_avalon_anti_slave_readdata`	Input	32
`tx_iopll_rcfg_mgmt_translator_avalon_anti_slave_waitrequest`	Input	1
`tx_iopll_rcfg_mgmt_translator_avalon_anti_slave_address`	Output	9
`tx_iopll_rcfg_mgmt_translator_avalon_anti_slave_write`	Output	1
`tx_iopll_rcfg_mgmt_translator_avalon_anti_slave_read`	Output	1
`tx_os_pio_external_connection_export`	Output	2	Oversampling factor: 0: No oversampling 1: 3× oversampling 2: 4× oversampling 3: 5× oversampling
`tx_rst_pll_pio_external_connection_export`	Output	1	Reset to IOPLL and TX PLL
`tx_rst_xcvr_pio_external_connection_export`	Output	1	Reset to TX Native PHY
`wd_timer_resetrequest_reset`	Output	1	Watchdog timer reset
`color_depth_pio_external_connection_export`	Input	2	Color depth
`tx_hpd_ack_pio_external_connection_export`	Output	1	For TX hotplug detect handshaking
`tx_hpd_req_pio_external_connection_export`	Input	1	For TX hotplug detect handshaking

3.7. Design RTL Parameters

Use the HDMI TX and RX Top RTL parameters to customize the design example.

Table 45. HDMI RX Top Parameters
Parameter	Value	Description
SUPPORT_DEEP_COLOR	0: No deep color 1: Deep color	Determines if the core can encode deep color formats.
SUPPORT_AUXILIARY	0: No AUX 1: AUX	Determines if the auxiliary channel encoding is included.
SYMBOLS_PER_CLOCK	8	Supports 8 symbols per clock for Intel^® Stratix^® 10 devices.
SUPPORT_AUDIO	0: No audio 1: Audio	Determines if the core can encode audio.
EDID_RAM_ADDR_WIDTH	8 (Default value)	Log base 2 of the EDID RAM size.

Table 46. HDMI TX Top Parameters
Parameter	Value	Description
USE_FPLL	1	Supports fPLL as TX PLL only for Intel^® Stratix^® 10 devices. Always set this parameter to 1.
SUPPORT_DEEP_COLOR	0: No deep color 1: Deep color	Determines if the core can encode deep color formats.
SUPPORT_AUXILIARY	0: No AUX 1: AUX	Determines if the auxiliary channel encoding is included.
SYMBOLS_PER_CLOCK	8	Supports 8 symbols per clock for Intel^® Stratix^® 10 devices.
SUPPORT_AUDIO	0: No audio 1: Audio	Determines if the core can encode audio.

3.8. Hardware Setup

The HDMI Intel^® FPGA IP design example is HDMI 2.0b capable and performs a loop-through demonstration for a standard HDMI video stream.

To run the hardware test, connect an HDMI-enabled device—such as a graphics card with HDMI interface—to the Transceiver Native PHY RX block, and the HDMI sink input.

The HDMI sink decodes the port into a standard video stream and sends it to the clock recovery core.
The HDMI RX core decodes the video, auxiliary, and audio data to be looped back in parallel to the HDMI TX core through the DCFIFO.
The HDMI source port of the FMC daughter card transmits the image to a monitor.

Note: If you want to use another Intel FPGA development board, you must change the device assignments and the pin assignments. The transceiver analog setting is tested for the Intel^® Stratix^® 10 FPGA development kit and Bitec HDMI FMC 2.0 daughter card. You may modify the settings for your own board.

Table 47. On-board Push Button and LED Functions
Push Button/LED	Function
cpu_resetn	Press once to perform system reset.
user_pb[0]	Press once to toggle the HPD signal to the standard HDMI source.
user_pb[1]	Press and hold to instruct the TX core to send the DVI encoded signal. Release to send the HDMI encoded signal.
user_pb[2]	Press and hold to instruct the TX core to stop sending the InfoFrames from the sideband signals. Release to resume sending the InfoFrames from the sideband signals.
USER_LED[0]	HDMI PLL lock status. Green = RX HDMI PLL is locked. Red = TX HDMI PLL is locked. Orange = Both RX and TX HDMI PLLs are locked. Off = Both RX and TX HDMI PLLs are not locked.
USER_LED[1]	Transceiver ready status. Green = RX transceiver is ready. Red = TX transceiver is ready. Orange = Both RX and TX transceivers are ready. Off = Both RX and TX transceivers are not ready.
USER_LED[2]	RX HDMI core and TX transceiver PLL lock status. Green = RX HDMI core is locked. Red = TX transceiver PLL is locked. Orange = RX HDMI core and TX transceiver PLL are locked. Off = RX HDMI core and TX transceiver PLL are not locked.
USER_LED[3]	Oversampling status. Green = RX is oversampled. Red = TX is oversampled. Orange = Both RX and TX are oversampled (Data rate < 1,000 Mbps)). Off = Both RX and TX are not oversampled (Data rate ≥ 1,000 Mbps).

3.9. Simulation Testbench

The simulation testbench simulates the HDMI TX serial loopback to the RX core.

Note: This simulation testbench is not supported for designs with the Include I2C parameter enabled.

Figure 28. HDMI Intel^® FPGA IP Simulation Testbench Block Diagram

Table 48. Testbench Components
Component	Description
Video TPG	The video test pattern generator (TPG) provides the video stimulus.
Audio Sample Gen	The audio sample generator provides audio sample stimulus. The generator generates an incrementing test data pattern to be transmitted through the audio channel.
Aux Sample Gen	The aux sample generator provides the auxiliary sample stimulus. The generator generates a fixed data to be transmitted from the transmitter.
CRC Check	This checker verifies if the TX transceiver recovered clock frequency matches the desired data rate.
Audio Data Check	The audio data check compares whether the incrementing test data pattern is received and decoded correctly.
Aux Data Check	The aux data check compares whether the expected aux data is received and decoded correctly on the receiver side.

The HDMI simulation testbench does the following verification tests:

HDMI Feature	Verification
Video data	The testbench implements CRC checking on the input and output video. It checks the CRC value of the transmitted data against the CRC calculated in the received video data. The testbench then performs the checking after detecting 4 stable V-SYNC signals from the receiver.
Auxiliary data	The aux sample generator generates a fixed data to be transmitted from the transmitter. On the receiver side, the generator compares whether the expected auxiliary data is received and decoded correctly.
Audio data	The audio sample generator generates an incrementing test data pattern to be transmitted through the audio channel. On the receiver side, the audio data checker checks and compares whether the incrementing test data pattern is received and decoded correctly.

A successful simulation ends with the following message:

# SYMBOLS_PER_CLOCK 	= 2
# VIC               	= 4
# FRL_RATE          	= 0
# BPP               	= 0
# AUDIO_FREQUENCY (kHz)  = 48
# AUDIO_CHANNEL     	= 8
# Simulation pass

Table 49. HDMI Intel^® FPGA IP Design Example Supported Simulators
Simulator	Verilog HDL	VHDL
ModelSim* - Intel^® FPGA Edition/ ModelSim* - Intel^® FPGA Starter Edition	Yes	Yes
VCS* / VCS* MX	Yes	Yes
Riviera-PRO*	Yes	Yes
NCSim	Yes	No
Xcelium* Parallel	Yes	No

3.10. Upgrading Your Design

Table 50. HDMI Design Example Compatibility with Previous Intel^® Quartus^® Prime Pro Edition Software Version
Design Example Variant	Ability to Upgrade to Intel^® Quartus^® Prime Pro Edition 20.3
HDMI 2.0 Design Example	No

For any non-compatible design examples, you need to do the following:

Generate a new design example in the current Intel^® Quartus^® Prime Pro Edition software version using the same configurations of your existing design.
Compare the whole design example directory with the design example generated using the previous Intel^® Quartus^® Prime Pro Edition software version. Port over the changes found.

4. HDCP Over HDMI 2.0/2.1 Design Example

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^® Stratix^® 10 designs.

Note: The HDCP feature is not included in the Intel^® Quartus^® Prime Pro Edition software. To access the HDCP feature, contact Intel at https://www.intel.com/content/www/us/en/broadcast/products/programmable/applications/connectivity-solutions.html.

4.1. High-bandwidth Digital Content Protection (HDCP)

High-bandwidth Digital Content Protection (HDCP) is a form of digital rights protection to create a secure connection between the source to the display.

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.

Table 51. HDCP IP Functions
HDCP IP	Functions
HDCP 1.4 IP	Authentication exchange Computation of master key (Km) Generation of random An Computation of session key (Ks), M0 and R0. Authentication with repeater Computation and verification of V and V’ Link integrity verification Computation of frame key (Ki), Mi and Ri. All cipher modes including hdcpBlockCipher, hdcpStreamCipher, hdcpRekeyCipher, and hdcpRngCipher Original encryption status signaling (DVI) and enhanced encryption status signaling (HDMI) True random number generator (TRNG) Hardware based, full digital implementation and non-deterministic random number generator
HDCP 2.3 IP	Master Key (km), Session Key (ks) and nonce (rn, riv) generation Compliant to NIST.SP800-90A random number generation Authentication and key exchange Generation of random numbers for rtx and rrx compliant to NIST.SP800-90A random number generation Signature verification of receiver certificate (certrx) using DCP public key (kpubdcp) 3072 bits RSASSA-PKCS#1 v1.5 RSAES-OAEP (PKCS#1 v2.1) encryption and decryption of Master Key (km) Derivation of kd (dkey0, dkey1) using AES-CTR mode Computation and verification of H and H’ Computation of Ekh(km) and km (pairing) Authentication with repeater Computation and verification of V and V’ Computation and verification of M and M’ System renewability (SRM) SRM signature verification using kpubdcp 3072 bits RSASSA-PKCS#1 v1.5 Session Key exchange Generation and computation of Edkey(ks) and riv. Derivation of dkey2 using AES-CTR mode Locality Check Computation and verification of L and L’ Generation of nonce (rn) Data stream management AES-CTR mode based key stream generation Asymmetric crypto algorithms RSA with modulus length of 1024 (kpubrx) and 3072 (kpubdcp) bits RSA-CRT (Chinese Remainder Theorem) with modulus length of 512 (kprivrx) bits and exponent length of 512 (kprivrx) bits Low-level cryptographic function Symmetric crypto algorithms AES-CTR mode with a key length of 128 bits Hash, MGF and HMAC algorithms SHA256 HMAC-SHA256 MGF1-SHA256 True random number generator (TRNG) NIST.SP800-90A compliant Hardware based, full digital implementation and non-deterministic random number generator

4.2. HDCP Over HDMI Design Example Architecture

The HDCP feature protects data as the data is transmitted between devices connected through an HDMI or other HDCP-protected digital interfaces.

The HDCP-protected systems include three types of devices:

Sources (TX)
Sinks (RX)
Repeaters

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.

Figure 29. HDCP Over HDMI Design Example Block Diagram

The following descriptions about the architecture of the design example correspond to the HDCP over HDMI design example block diagram. When SUPPORT_FRL = 1, the design example hierarchy is slightly different from Figure 29 but the underlying HDCP functions remain the same.

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.

You need to program the HDCP IPs with Digital Content Protection (DCP) issued production keys. Load the following keys:

Table 52. DCP-issued Production Keys
HDCP	TX/RX	Keys
HDCP2x	TX	16 bytes: Global Constant (lc128)
HDCP2x	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)
HDCP1x	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.

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

4.3. Nios II Processor Software Flow

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

Figure 30. Nios II Processor Software Flowchart

The Nios II software initializes and resets the HDMI TX PLL, TX transceiver PHY, I²C master and the external TI retimer.
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.
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.
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.
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.
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.
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.
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.
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).
Authentication is complete at this point. The software enables TX encryption.
The software initiates the HDCP1x authentication protocol that includes key exchange and authentication with repeaters.
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.
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.

4.4. Design Walkthrough

Setting up and running the HDCP over HDMI design example consists of four stages.

Set up the hardware.
Generate the design.
Edit the HDCP key memory files to include your HDCP production keys.
Compile the design.
View the results.

4.4.1. Set Up the Hardware

The first stage of the demonstration is to set up the hardware.

When SUPPORT_FRL = 0, follow these steps to set up the hardware for the demonstration:

Connect the Bitec HDMI 2.0 FMC daughter card (revision 11) to the Stratix 10 GX FPGA L-tile/H-tile development kit at FMC port B.
Connect the Stratix 10 GX FPGA L-tile/H-tile development kit to your PC using a USB cable.
Connect an HDMI cable from the HDMI RX connector on the Bitec HDMI 2.0 FMC daughter card to an HDCP-enabled HDMI device, such as a graphic card with HDMI output.
Connect another HDMI cable from the HDMI TX connector on the Bitec HDMI 2.0 FMC daughter card to an HDCP-enabled HDMI device, such as a television with HDMI input.

When SUPPORT_FRL = 1, follow these steps to set up the hardware for the demonstration:

Connect the Bitec HDMI 2.1 FMC daughter card (revision 4 or 4a) to the Stratix 10 GX FPGA L-tile/H-tile development kit at FMC port B.
Connect the Stratix 10 GX FPGA L-tile/H-tile development kit to your PC using a USB cable.
Connect an HDMI 2.1 Category 3 cables from HDMI RX connector on the Bitec HDMI 2.1 FMC daughter card to an HDCP-enabled HDMI 2.1 source, such as Quantum Data 980 48G Generator.
Connect another HDMI 2.1 Category 3 cables from the HDMI TX connector on the Bitec HDMI 2.1 FMC daughter card to an HDCP-enabled HDMI 2.1 sink, such as Quantum Data 980 48G Analyzer.

4.4.2. Generate the Design

After setting up the hardware, you need to generate the design.

Before you begin, ensure to install the HDCP feature in the Intel^® Quartus^® Prime Pro Edition software.

Click Tools > IP Catalog, and select Intel^® Stratix^® 10 as the target device family.

Note: The HDCP design example supports only Intel^® Arria^® 10 and Intel^® Stratix^® 10 devices.
In the IP Catalog, locate and double-click HDMI Intel^® FPGA IP. The New IP variation window appears.
Specify a top-level name for your custom IP variation. The parameter editor saves the IP variation settings in a file named <your_ip>.qsys or <your_ip>.ip.
Click OK. The parameter editor appears.
On the IP tab, configure the desired parameters for both TX and RX.
Turn on the Support HDCP 1.4 or Support HDCP 2.3 parameter to generate the HDCP design example.
On the Design Example tab, select Stratix 10 HDMI RX-TX Retransmit.
Select Synthesis to generate the hardware design example.
For Generate File Format, select Verilog or VHDL.
For Select Board, select the relevant development kit. You may change the target device using the Change Target Device parameter if your board revision does not match the grade of the default targeted device. For Stratix 10 GX FPGA L-tile Development Kit, the default device is 1SG280LU2F50E2VG, and for Stratix 10 GX FPGA H-tile Development Kit, the default device is 1SG280HU2F50E2VG.
Click Generate Example Design to generate the project files and the software Executable and Linking Format (ELF) programming file.

4.4.3. Include HDCP Production Keys

After generating the design, edit the HDCP key memory files to include your production keys.

To include the production keys, follow these steps.

Locate the following key memory files in the <project directory>/rtl/hdcp/ directory:
- hdcp2x_tx_kmem.v
- hdcp2x_rx_kmem.v
- hdcp1x_tx_kmem.v
- hdcp1x_rx_kmem.v
Open the hdcp2x_rx_kmem.v file and locate the predefined facsimile key R1 for Receiver Public Certificate and RX Private Key and Global Constant as shown in the examples below.

Figure 31. Wire Array of Facsimile Key R1 for Receiver Public Certificate

Figure 32. Wire Array of Facsimile Key R1 for RX Private Key and Global Constant
Locate the placeholder for the production keys and replace with your own production keys in their respective wire array in big endian format.

Figure 33. Wire Array of HDCP Production Keys (Placeholder)
Repeat Step 3 for all other key memory files. When you have finished including your production keys in all the key memory files, ensure that the USE_FACSIMILE parameter is set to 0 at the design example top level file ( <Intel Quartus Prime project name>.v)

4.4.4. Compile the Design

After you include your own production keys, you can now compile the design.

Launch the Intel^® Quartus^® Prime Pro Edition software and open <project directory>/quartus/<Intel Quartus Prime project name>.qpf.
Click Processing > Start Compilation.

4.4.5. View the Results

At the end of the demonstration, you will be able to view the results on the HDCP-enabled HDMI external sink.

To view the results of the demonstration, follow these steps:

Power up the Intel FPGA board.
Change the directory to <project directory>/quartus/.
Type the following command on the Nios II Command Shell to download the Software Object File (.sof) to the FPGA.

nios2-configure-sof output_files /<Intel Quartus Prime project name>.sof
Power up the HDCP-enabled HDMI external source and sink (if you haven't done so). The HDMI external sink displays the output of your HDMI external source.

4.4.5.1. Push Buttons and LED Functions

Use the push buttons and LED functions on the board to control your demonstration.

Table 53. Push Button and LED Indicators (SUPPORT_FRL = 0)
Push Button/LED	Functions
cpu_resetn	Press once to perform system reset.
user_pb[0]	Press once to toggle the HPD signal to the standard HDMI source.
user_pb[1]	Press and hold to instruct the TX core to send the DVI encoded signal. Release to send the HDMI encoded signal. Make sure the incoming video is in 8 bpc RGB color space.
user_pb[2]	Press and hold to instruct the TX core to stop sending the InfoFrames from the sideband signals. Release to resume sending the InfoFrames from the sideband signals.
user_led_g[0]	RX HDMI PLL lock status. 0: Unlocked 1: Locked
user_led_g[1]	RX HDMI core lock status 0: At least 1 channel unlocked 1: All 3 channels locked
user_led_g[2]	RX HDCP1x IP decryption status. 0: Inactive 1: Active
user_led_g[3]	RX HDCP2x IP decryption status. 0: Inactive 1: Active
user_led_g[4]	TX HDMI PLL lock status. 0: Unlocked 1: Locked
user_led_g[5]	TX transceiver PLL lock status. 0: Unlocked 1: Locked
user_led_g[6]	TX HDCP1x IP encryption status. 0: Inactive 1: Active
user_led_g[7]	TX HDCP2x IP encryption status. 0: Inactive 1: Active

Table 54. Push Button and LED Indicators (SUPPORT_FRL = 1)
Push Button/LED	Functions
cpu_resetn	Press once to perform system reset.
user_dipsw[0]	User-defined DIP switch to toggle the passthrough mode. OFF (default position) = Passthrough HDMI RX on the FPGA gets the EDID from external sink and presents it to the external source it is connected to. ON = You may control the RX maximum FRL rate from the Nios^® II terminal. The command modifies the RX EDID by manipulating the maximum FRL rate value. Refer to Running the Design in Different FRL Rates for more information about setting the different FRL rates.
user_dipsw[1]	User-defined DIP switch to toggle the passthrough mode. OFF (default position) = user_led[3:0] indicates RX status. ON = user_led[3:0] indicates TX status. Refer to user_led[3:0] for more details.
user_pb[0]	Press once to toggle the HPD signal to the standard HDMI source.
user_pb[1]	Reserved.
user_led[0]	user_dipsw[1] = ON	RX FRL clock PLL lock status. 0: Unlocked 1: Locked
user_led[0]	user_dipsw[1] = OFF	TX FRL clock PLL lock status. 0: Unlocked 1: Locked
user_led[1]	user_dipsw[1] = ON	RX HDMI video lock status. 0: Unlocked 1: Locked
user_led[1]	user_dipsw[1] = OFF	TX FRL start status. 0: TX core transmits link training pattern 1: TX core transmits normal video
user_led[2]	user_dipsw[1] = ON	RX HDCP1x IP decryption status. 0: Inactive 1: Active
user_led[2]	user_dipsw[1] = OFF	TX HDCP1x IP encryption status. 0: Inactive 1: Active
user_led[3]	user_dipsw[1] = ON	RX HDCP2x IP decryption status. 0: Inactive 1: Active
user_led[3]	user_dipsw[1] = OFF	TX HDCP2x IP encryption status. 0: Inactive 1: Active

4.5. Security Considerations

When using the HDCP feature, be mindful of the following security considerations.

When designing a repeater system, you must block the received video from entering the TX IP in the following conditions:
- If the received video is HDCP-encrypted (i.e. encryption status hdcp1_enabled or hdcp2_enabled from the RX IP is asserted) and the transmitted video is not HDCP-encrypted (i.e. encryption status hdcp1_enabled or hdcp2_enabled from the TX IP is not asserted).
- If the received video is HDCP TYPE 1 (i.e. streamid_type from the RX IP is asserted) and the transmitted video is HDCP 1.4 encrypted (i.e. encryption status hdcp1_enabled from the TX IP is asserted)
You should maintain the confidentiality and integrity of your HDCP production keys, and any user encryption keys.
Intel strongly recommends you to develop any Intel^® Quartus^® Prime projects and design source files that contain encryption keys in a secure compute environment to protect the keys.
Intel strongly recommends you to use the design security features in FPGAs to protect the design, including any embedded encryption keys, from unauthorized copying, reverse engineering, and tampering.

5. HDMI Intel Stratix 10 FPGA IP Design Example User Guide Archives

If an IP core version is not listed, the user guide for the previous IP core version applies.

Intel^® Quartus^® Prime Version	IP Core Version	User Guide
20.3	19.5.0	HDMI Intel Stratix 10 FPGA IP Design Example User Guide
20.2	19.4.0	HDMI Intel Stratix 10 FPGA IP Design Example User Guide
19.1	19.1	HDMI Intel Stratix 10 FPGA IP Design Example User Guide
18.0	18.0	HDMI Intel Stratix 10 FPGA IP Design Example User Guide

6. Document Revision History for the HDMI Intel Stratix 10 FPGA IP Design Example User Guide

Document Version	Intel^® Quartus^® Prime Version	Intel^® FPGA IP Version	Changes
2020.12.14	20.4	19.6.0	Updated the HDMI Intel FPGA IP Design Example Quick Start Guide for Intel^® Stratix^® 10 Devices section with information about the newly added HDMI 2.1 design example with FRL mode. Added a new chapter, Detailed Description for HDMI 2.1 Design Example (Support FRL Enabled) that contains all the relevant information about the newly added design example. Updated the HDCP Over HDMI 2.0 Design Example section: Updated topic title HDCP Over HDMI 2.0 Design Example to HDCP Over HDMI 2.0/2.1 Design Example Added new hardware setup when SUPPORT_FRL = 1 in the Set Up the Hardware section. Edited the Include HDCP Production Keys section to updated the design example top level file to <`Intel Quartus Prime project name`>.v Edited the Compile the Design section to update the .qpf file to <`projectdirectory` /quartus/<`Intel Quartus Prime project name`>.qpf Updated table name Push Button and LED Indicators to Push Button and LED Indicators (SUPPORT_FRL = 0). Added a new Table: Push Button and LED Indicators (SUPPORT_FRL =1).
2020.09.28	20.3	19.5.0	Updated the directory structure for Intel^® Stratix^® 10 design example and the generated files list in the Directory Structure section. Updated the block diagrams in the HDMI 2.0 RX-TX Retransmit Design Block Diagram, Generating TX or RX Only Designs, and Clocking Scheme sections. Updated the description for the RX and TX core components and removed the description for the PIO and I²C Master (TX) components from the Design Components section. Updated the description for the transceiver clock signals in the Clocking Scheme section. Added RX CDR reference clock information in the Clocking Scheme section. Removed irrelevant signals, and added or edited the description of the following HDMI design example signals in the Interface Signals section: `clk_fpga_b3_p` `user_led_r` `fmcb_la_tx_p_11` `fmcb_la_rx_n_9` `fr_clk` `ls_clk_out` `sys_init` `clock_bridge_0_in_clk_clk` `rx_pma`* signals `rx_rcfg_en_export` `rx_rst_xcvr_export` `tx_rcfg_en_pio_external_connection_export` `tx_iopll__rcfg_mgmt_translator_avalon_anti_slave_waitrequest` Added the `EDID_RAM_ADDR_WIDTH` parameter in the Design RTL Parameters section. Added a note that the simulation testbench is not supported for designs with the Include I2C parameter enabled and updated the simulation message in the Simulation Testbench section. Updated the Upgrading Your Design section.
2020.06.22	20.2	19.4.0	Added the build_sw_hdcp.sh script and removed the `runall.tcl` script from the Directory Structure section. The `runall.tcl` script is applicable only for the Intel^® Quartus^® Prime Standard Edition software. Added a list of HDMI Intel^® FPGA IP design examples offered for Intel^® Stratix^® 10 devices in the HDMI Intel^® FPGA IP Design Example Quick Start Guide section. Added a new section about the HDCP design example: HDCP Over HDMI 2.0 Design Examples. The HDCP feature is now available for Intel^® Stratix^® 10 devices.
2019.05.24	19.1	19.1	Updated the Directory Structure section to remove information about the i2c_master folder and the related files; and added the following files: tx_control_src/intel_fpga_i2c.h tx_control_src/intel_fpga_i2c.c Updated the Generating the Design section to change the part number for the Intel^® Stratix^® 10 device to 1SG280LU2F50E2V and 1SG280HU2F50E2VG. The design example targets the Intel^® Stratix^® 10 production device now. Edited the Hardware and Software Requirements section to include Intel^® Stratix^® 10 L-tile and update the Bitec HDMI FMC 2.0 daughter card to revision 11. Updated the HDMI Intel^® FPGA IP Design Example Parameters section to include new options for the Select Board parameter. You can choose to use either the Stratix 10 GX FPGA H-tile or L-tile development kit for your Intel^® Stratix^® 10 designs. Added the following I²C and Hot Plug Detect signals in the Interface Signals section: `nios_tx_i2c_sda_in` `nios_tx_i2c_scl_in` `nios_tx_i2c_sda_oe` `nios_tx_i2c_scl_oe` `nios_ti_i2c_sda_in` `nios_ti_i2c_scl_in` `nios_ti_i2c_sda_oe` `nios_ti_i2c_scl_oe` `hdmi_ti_i2c_sda` `hdmi_ti_i2c_sda` Removed the following I²C and Hot Plug Detect signals in the Interface Signals section: `tx_i2c_avalon_waitrequest` `tx_i2c_avalon_address` `tx_i2c_avalon_writedata` `tx_i2c_avalon_readdata` `tx_i2c_avalon_chipselect` `tx_i2c_avalon_write` `tx_i2c_avalon_irq` Added the following Platform Designer signals in the Interface Signals section: `reset_bridge_0_in_reset_reset_n` `i2c_master_i2c_serial_sda_in` `i2c_master_i2c_serial_scl_in` `i2c_master_i2c_serial_sda_oe` `i2c_master_i2c_serial_scl_oe` `i2c_master_ti_i2c_serial_sda_in` `i2c_master_ti_i2c_serial_scl_in` `i2c_master_ti_i2c_serial_sda_oe` `i2c_master_ti_i2c_serial_scl_oe` Removed the following Platform Designer signals in the Interface Signals section: `cpu_clk_reset_n` `oc_i2c_master_av_slave_translator_avalon_an ti_slave_0_address` `oc_i2c_master_av_slave_translator_avalon_an ti_slave_0_write` `oc_i2c_master_av_slave_translator_avalon_an ti_slave_0_readdata` `oc_i2c_master_av_slave_translator_avalon_an ti_slave_0_writedata` `oc_i2c_master_av_slave_translator_avalon_an ti_slave_0_waitrequest` `oc_i2c_master_av_slave_translator_avalon_an ti_slave_0_chipselect` Updated the description for `fmcb_dp_m2c_p` and `fmcb_dp_c2m_p` signals to add transceiver serial data mapping to the HDMI channels. Updated the Design RTL Parameters section to add information that the default Bitec HDMI FMC 2.0 daughter card is revision 11. Added Upgrading Your Design section to provide guidelines about upgrading your existing design to the latest version.
2018.05.07	18.0	18.0	Initial release.