DisplayPort Intel Arria 10 FPGA IP Design Example User Guide

RSS

UG-20075 | 2021.05.11

Version Information

Updated for:
Intel® Quartus® Prime Design Suite 21.1
IP Version 19.4.0

1. DisplayPort Intel FPGA IP Design Example Quick Start Guide

The DisplayPort Intel^® FPGA IP design examples for Intel^® Arria^® 10 devices feature a simulating testbench and a hardware design that supports compilation and hardware testing.

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

DisplayPort SST parallel loopback with a Pixel Clock Recovery (PCR) module
DisplayPort SST parallel loopback without a PCR module
DisplayPort MST parallel loopback with a PCR module
DisplayPort MST parallel loopback without a PCR module
High-bandwidth Digital Content Protection (HDCP) over DisplayPort
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 DisplayPort design example.

Figure 2. Directory Structure for the Design Example

Table 1. Other Generated Files in RTL Folder
Folders	Files
clkrec	/altera_pll_reconfig_core.v
	/altera_pll_reconfig_mif_reader.v
	/altera_pll_reconfig_top.v
	/bitec_clkrec.qip
	/bitec_clkrec.sdc
	/bitec_clkrec.v
	/bitec_dp_add.v
	/bitec_dp_cdc.v
	/bitec_dp_cdc_fifo.v
	/bitec_dp_cdc_pulse.v
	/bitec_dp_cnt.v
	/bitec_dp_dcfifo.v
	/bitec_dp_dd.v
	/bitec_dp_div.v
	/bitec_dp_mult.v
	/bitec_fpll_calc.v
	/bitec_fpll_cntrl.v
	/bitec_fpll_reconf.v
	/bitec_loop_cntrl.v
	/bitec_vsyngen.v
	/clkrec_pll135_a10.qsys ( Intel^® Quartus^® Prime Standard Edition) /clkrec_pll135_a10.ip ( Intel^® Quartus^® Prime Pro Edition)
	/clkrec_pll_a10.qsys ( Intel^® Quartus^® Prime Standard Edition) /clkrec_pll1_a10.ip ( Intel^® Quartus^® Prime Pro Edition)
	/clkrec_reset_a10.qsys ( Intel^® Quartus^® Prime Standard Edition) /clkrec_reset_a10.ip ( Intel^® Quartus^® Prime Pro Edition)
	<Platform Designer generated folder>
core	/dp_core.qsys ( Intel^® Quartus^® Prime Standard Edition) /dp_core.ip ( Intel^® Quartus^® Prime Pro Edition)
	/dp_rx.qsys ( Intel^® Quartus^® Prime Standard Edition) /dp_rx.ip ( Intel^® Quartus^® Prime Pro Edition)
	/dp_tx.qsys ( Intel^® Quartus^® Prime Standard Edition) /dp_tx.ip ( Intel^® Quartus^® Prime Pro Edition)
	<Platform Designer generated folder>
rx_phy	/gxb_rx.qsys ( Intel^® Quartus^® Prime Standard Edition) /gxb_rx.ip ( Intel^® Quartus^® Prime Pro Edition)
	/gxb_rx_reset.qsys ( Intel^® Quartus^® Prime Standard Edition) /gxb_rx_reset.ip ( Intel^® Quartus^® Prime Pro Edition)
	/rx_phy_top.v
	<Platform Designer generated folder>
tx_phy	/gxb_tx.qsys ( Intel^® Quartus^® Prime Standard Edition) /gxb_tx.ip ( Intel^® Quartus^® Prime Pro Edition)
	/gxb_tx_reset.qsys ( Intel^® Quartus^® Prime Standard Edition) /gxb_tx_reset.ip ( Intel^® Quartus^® Prime Pro Edition)
	/gxb_tx_fpll.qsys ( Intel^® Quartus^® Prime Standard Edition) /gxb_tx_fpll.ip ( Intel^® Quartus^® Prime Pro Edition)
	/tx_phy_top.v
	<Platform Designer generated folder>

Table 2. Other Generated Files in Simulation Folder
Folders	Files
aldec	/aldec.do
aldec	/rivierapro_setup.tcl
cadence	/cds.lib
	/hdl.var
	/ncsim.sh
	/ncsim_setup.sh
	<cds_libs folder>
core	/dp_core.qsys ( Intel^® Quartus^® Prime Standard Edition) /dp_core.ip ( Intel^® Quartus^® Prime Pro Edition)
	/dp_rx.qsys ( Intel^® Quartus^® Prime Standard Edition) /dp_rx.ip ( Intel^® Quartus^® Prime Pro Edition)
	/dp_tx.qsys ( Intel^® Quartus^® Prime Standard Edition) /dp_tx.ip ( Intel^® Quartus^® Prime Pro Edition)
	<Platform Designer generated folder>
mentor	/mentor.do
mentor	/msim_setup.tcl
rx_phy	/gxb_rx.qsys ( Intel^® Quartus^® Prime Standard Edition) /gxb_rx.ip ( Intel^® Quartus^® Prime Pro Edition)
	/rx_phy_top.v
	/gxb_rx_reset.qsys ( Intel^® Quartus^® Prime Standard Edition) /gxb_rx_reset.ip ( Intel^® Quartus^® Prime Pro Edition)
	<Platform Designer generated folder>
synopsys	/vcs/filelist.f
	/vcs/vcs_setup.sh
	/vcs/vcs_sim.sh
	/vcsmx/synopsys_sim_setup
	/vcsmx/vcsmx_setup.sh
	/vcsmx/vcsmx_sim.sh
testbench	/a10_dp_harness.sv
	/clk_gen.v
	/freq_check.v
	/rx_freq_check.v
	/tx_freq_check.v
	/vga_driver.v
tx_phy	/gxb_tx.qsys ( Intel^® Quartus^® Prime Standard Edition) /gxb_tx.ip ( Intel^® Quartus^® Prime Pro Edition)
	<Platform Designer generated folder>
	/gxb_tx_fpll.qsys ( Intel^® Quartus^® Prime Standard Edition) /gxb_tx_fpll.ip ( Intel^® Quartus^® Prime Pro Edition)
	/gxb_tx_reset.qsys ( Intel^® Quartus^® Prime Standard Edition) /gxb_tx_reset.ip ( Intel^® Quartus^® Prime Pro Edition)
	/tx_phy_top.v
xcelium	/cds.lib
	/hdl.var
	/xcelium_sim.sh
	/xcelium_setup.sh
	<cds_libs folder>

1.2. Hardware and Software Requirements

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

Hardware

Intel^® Arria^® 10 GX FPGA Development Kit
DisplayPort Source (Graphics Processing Unit (GPU))
DisplayPort Sink (Monitor)
Bitec DisplayPort FMC daughter card (Revisions 8.0 to 11.0)
DisplayPort cables

Software

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

1.3. Generating the Design

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

Figure 3. Generating the Design Flow

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

Note: The design example only support Intel^® Arria^® 10 devices.
In the IP Catalog, locate and double-click DisplayPort 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 or <your_ip>.qsys .
You may select a specific Intel^® Arria^® 10 device in the Device field, or keep the default Intel^® Quartus^® Prime software device selection.
Click OK. The parameter editor appears.
Configure the desired parameters for both TX and RX.

Note: The Nios II software has the capability to read and print out the DisplayPort Main Stream Attribute (MSA) information in the Nios II terminal. To read or print the MSA information, turn on the Enable GPU Control parameter.
On the Design Example tab, select DisplayPort SST Parallel Loopback With PCR, DisplayPort SST Parallel Loopback Without PCR, DisplayPort MST Parallel Loopback With PCR, or DisplayPort MST Parallel Loopback Without PCR.
Select Simulation to generate the testbench, and select Synthesis to generate the hardware design example.

Note: DisplayPort MST design examples are supported only in synthesis; they are not supported in simulation.

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 Target Development Kit, select Arria 10 GX FPGA Development Kit . If you select the development kit, then the target device (selected in step 4) changes to match the device on the development kit. For Arria 10 GX FPGA Development Kit, the default device is 10AX115S2F45I1SG .
Click Generate Example Design to generate the project files and the software Executable and Linking Format (ELF) programming file.

1.4. Simulating the Design

The DisplayPort Intel^® FPGA IP design example testbench simulates a serial loopback design from a TX instance to an RX instance. An internal video pattern generator module drives the DisplayPort TX instance and the RX instance video output connects to CRC checkers in the testbench.

Figure 4. Design Simulation Flow

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

Analyze the results.

Table 3. Steps to Run Simulation
Simulator	Working Directory	Instructions
Riviera-PRO*	/simulation/aldec	In the command line, type vsim -c -do aldec.do
ModelSim*	/simulation/mentor	In the command line, type vsim -c -do mentor.do
NCSim	/simulation/cadence	In the command line, type source ncsim.sh
Xcelium*	/simulation/xcelium	In the command line, type source xcelium.sh
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

A successful simulation ends with the following message:

# SINK CRC_R = ac9c, CRC_G = ac9c, CRC_B = ac9c,
# SOURCE CRC_R = ac9c, CRC_G = ac9c, CRC_B = ac9c,
# Pass: Test Completed

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 software and open <project directory>/quartus/a10_dp_demo.qpf.

Note:

The latest Bitec DisplayPort FMC daughter card has different schematics compared to the earlier revisions.

Table 4. RX Transceiver Channel Mapping
Parameter	Revisions 8 and Earlier	Revision 10	Revision 11	Description
Polarity	Not inverted	Inverted	Inverted	When RX polarity is inverted, each lane at the `rx_polinv` port of the Native PHY is driven to 1 in the rx_phy_top.v file. When RX polarity is not inverted, each lane at the `rx_polinv` port of the Native PHY is driven to 0 in the rx_phy_top.v file.
Order	Not reversed	Not reversed	Reversed	The `rx_parallel_data` port of the Native PHY is directly mapped to the `rx_parallel_data` port of the DisplayPort IP.

Table 5. TX Transceiver Channel Mapping
Parameter	Revisions 8 and Earlier	Revision 10	Revision 11	Description
Polarity	Inverted	Not inverted	Not inverted	When TX polarity is inverted, each lane at the `tx_polinv` port of the Native PHY is driven to 1 in the tx_phy_top.v file. When TX polarity is not inverted, each lane at the `tx_polinv` port of the Native PHY is driven to 0 in the tx_phy_top.v file.
Order	Reversed	Not reversed	Not reversed	When the lane order is reversed, the data input at the `tx_parallel_data` port of the Native PHY is swapped in the tx_phy_top.v file based on the lane count configuration. When the lane order is not reversed, `tx_parallel_data` port of the Native PHY is directly mapped to the `tx_parallel_data` port of the DisplayPort IP.

To support all revisions, the design example top level RTL file at <project directory>/rtl/a10_dp_demo.v and the software config.h file include a local parameter for you to select the FMC revision.

DisplayPort Intel^® FPGA IP version 19.3.0:

localparam BITEC_DP_CARD_REV = 2;

// 0 = Bitec FMC DP card rev.4 - 8,

// 1 = rev.10

// 2 = rev.11

in <project>/software/dp_demo/config.h:

#define BITEC_DP_CARD_REV 2

// set to 0 = Bitec FMC DP card rev.4 - 8

// set to 1 = Bitec FMC DP card rev.10

// set to 2 = Bitec FMC DP card rev.11

The default value is 2. If the config.h file is updated, you must run build_sw.sh in the script folder before compiling the Intel^® Quartus^® Prime project to ensure the software is effective.

Click Processing > Start Compilation.
After successful compilation, the Intel^® Quartus^® Prime software generates a .sof file in your specified directory.
Connect the DisplayPort RX connector on the Bitec daughter card to an external video source, such as the graphics card on a PC.
Connect the DisplayPort TX connector on the Bitec daughter card to a video analyzer or a DisplayPort sink device, such as a PC monitor.
Ensure all switches on the development board are in default position.
Configure the selected Intel^® Arria^® 10 device on the development board using the generated .sof file (Tools > Programmer ).
The DisplayPort sink device displays the video generated from the video source.

1.5.1. Regenerating ELF File

By default, the ELF file is generated when you generate the dynamic design example. However, in some cases, you need to regenerate the ELF file if you modify the software file or regenerate the dp_core.qsys file. Regenerating the dp_core.qsys file updates the .sopcinfo file, which requires you to regenerate the ELF file.

Go to <project directory>/software and edit the code if necessary.
Go to <project directory>/script and execute the following build script:
source build_sw.sh
- On Windows, search and open Nios II Command Shell. In the Nios II Command Shell, go to <project directory>/script and execute source build_sw.sh.
Note: To execute build script on Windows 10, your system requires Windows Subsystems for Linux (WSL). For more information about WSL installation steps, refer to the Nios II Software Developer Handbook.
- On Linux, launch the Platform Designer, and open Tools > Nios II Command Shell. In the Nios II Command Shell, go to <project directory>/script and execute source build_sw.sh.
Make sure an .elf file is generated in <project directory>/software/dp_demo.
Download the generated .elf file into the FPGA without recompiling the .sof file by running the following script:
nios2-download <project directory>/software/dp_demo/*.elf
Push the reset button on the FPGA board for the new software to take effect.

1.6. DisplayPort Intel FPGA IP Design Example Parameters

Table 6. DisplayPort Intel^® FPGA IP Design Example Parameters for Intel^® Arria^® 10 Devices
Parameter	Value	Description
Available Design Example
Select Design	None DisplayPort SST Parallel Loopback with PCR DisplayPort SST Parallel Loopback without PCR DisplayPort MST Parallel Loopback with PCR DisplayPort MST Parallel Loopback without PCR	Select the design example to be generated. None: No design example is available for the current parameter selection DisplayPort SST Parallel Loopback with PCR: This design example demonstrates parallel loopback from DisplayPort sink to DisplayPort source through a Pixel Clock Recovery (PCR) module when you turn off the Enable Video Input Image Port parameter. DisplayPort SST Parallel Loopback without PCR: This design example demonstrates parallel loopback from DisplayPort sink to DisplayPort source without a Pixel Clock Recovery (PCR) module when you turn on the Enable Video Input Image Port parameter. DisplayPort MST Parallel Loopback with PCR: This design example demonstrates parallel loopback from DisplayPort sink to DisplayPort source through a Pixel Clock Recovery (PCR) module when you turn off the Enable Video Input Image Port parameter and turn on the Support MST parameter for TX and RX. DisplayPort MST Parallel Loopback without PCR: This design example demonstrates parallel loopback from DisplayPort sink to DisplayPort source without a Pixel Clock Recovery (PCR) module when you turn on the Enable Video Input Image Port parameter and turn on the Support MST parameter for TX and RX. Note: Only DisplayPort SST Parallel Loopback with PCR is available in the Intel^® Quartus^® Prime Standard Edition.
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 Intel^® Arria^® 10 GX FPGA 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. Intel^® Arria^® 10 GX FPGA 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. Parallel Loopback Design Examples

The DisplayPort Intel^® FPGA IP design examples demonstrate parallel loopback from DisplayPort RX instance to DisplayPort TX instance with or without a Pixel Clock Recovery (PCR) module.

Table 7. DisplayPort Intel^® FPGA IP Design Example for Intel^® Arria^® 10 Devices
Design Example	Designation	Data Rate	Channel Mode	Loopback Type
DisplayPort SST parallel loopback with PCR	DisplayPort SST	HBR3, HBR2, HBR, and RBR	Simplex	Parallel with PCR
DisplayPort SST parallel loopback without PCR	DisplayPort SST	HBR3, HBR2, HBR, and RBR	Simplex	Parallel without PCR
DisplayPort MST parallel loopback with PCR	DisplayPort MST	HBR3, HBR2, HBR, and RBR	Simplex	Parallel with PCR
DisplayPort MST parallel loopback without PCR	DisplayPort MST	HBR3, HBR2, HBR, and RBR	Simplex	Parallel without PCR

Note: DisplayPort SST parallel loopback without PCR design example and support for HBR3 are available only in the Intel^® Quartus^® Prime Pro Edition software.

2.1. Intel Arria 10 DisplayPort SST Parallel Loopback Design Features

The SST parallel loopback design examples demonstrate the transmission of a single video stream from DisplayPort sink to DisplayPort source with or without Pixel Clock Recovery (PCR).

Figure 5. Intel^® Arria^® 10 DisplayPort SST Parallel Loopback with PCR

In this variant, the DisplayPort source’s parameter, TX_SUPPORT_IM_ENABLE, is turned off and the standard VSYNC/HSYNC/DE video interface is used.
The DisplayPort sink receives video and or audio streaming from external video source such as GPU and decodes it into parallel video interface.
The IOPLL drives the video clock at a fixed frequency (in this case, 160 MHz).
If DisplayPort sink’s MAX_LINK_RATE is configured to HBR2 and PIXELS_PER_CLOCK is configured to Dual, the video clock runs at 300 MHz to support 4Kp60 pixel rate (594/2 = 297 MHz). Otherwise, the video clock runs at 160 MHz.
The design uses the pixel recovery clock (PCR) to recover the pixel clock according to the received MSA information from the sink and converts the RX parallel video interface to the standard VSYNC/HSYNC/DE interface.
The PCR output drives the source video interface and encodes to the DisplayPort main link before transmitting to the monitor.
The recovered clock drives the TX video clock.

Figure 6. Intel^® Arria^® 10 DisplayPort SST Parallel Loopback without PCR

In this variant, the DisplayPort source’s parameter, TX_SUPPORT_IM_ENABLE, is turned on (“1”) and the video image interface is used.
The DisplayPort sink receives video and or audio streaming from external video source such as GPU and decodes it into parallel video interface.
The DisplayPort sink video output directly drives the DisplayPort source video interface and encodes to the DisplayPort main link before transmitting to the monitor.
The IOPLL drives both the DisplayPort sink and source video clocks at a fixed frequency.
If DisplayPort sink and source's MAX_LINK_RATE parameter is configured to HBR2 and PIXELS_PER_CLOCK is configured to Dual, the video clock runs at 300 MHz to support 4Kp60 pixel rate (594/2 = 297 MHz). Otherwise, the video clock runs at 160 MHz.

Table 8. Design Example Variant Comparison
Design Example	PCR Module	Enable Video Image Interface	Adaptive Sync	Video Interface
DisplayPort SST parallel loopback with PCR	Required	No	Not supported	Standard `VSYNC`/`HSYNC`/`DE` interface (`txN_video_in`)
DisplayPort SST parallel loopback without PCR	Not required	Yes	Supported	Video Image Interface (`txN_video_in_im`)

2.2. Intel Arria 10 DisplayPort MST Parallel Loopback Design Features

The MST parallel loopback design examples demonstrate the transmission of two to four video streams from DisplayPort sink to DisplayPort source with or without Pixel Clock Recovery (PCR).

Figure 7. Intel^® Arria^® 10 DisplayPort MST Parallel Loopback with PCR

In this variant, the DisplayPort source’s parameter, TX_SUPPORT_IM_ENABLE, is turned off and the standard VSYNC/HSYNC/DE video interface is used.
Due to the limitation of PLL numbers on the Intel^® Arria^® 10 board, by default the IP chooses only 1 stream from the input streams and transmits to the Pixel Clock Recovery block. The Test Pattern Generator (TPG) generates the remaining output streams and the streams display 1080p60 color bar image. For example, if the MST maximum stream count is four, one output video stream is chosen to display, and the remaining three video streams show the same image, which is 1080p60 color bar.
You can change the video to a different stream using the user_pb[2] push button. Every time you press user_pb[2] , the next video stream displays.
The design examples support up to four streams for audio and video data.
The MST design examples use fixed EDID and do not support EDID passthrough.
You can modify the bandwidth assignment for each stream in the tx_utils.c file.
stream 0: btc_dptxll_stream_set_pixel_rate(0,0,594000/MST_RX_STREAMS);

stream 1: btc_dptxll_stream_set_pixel_rate(0,1,594000/MST_RX_STREAMS);

stream 2: btc_dptxll_stream_set_pixel_rate(0,2,594000/MST_RX_STREAMS);

stream 3: btc_dptxll_stream_set_pixel_rate(0,3,594000/MST_RX_STREAMS);
The maximum resolution supported for 4 stream counts is 1080p60.

Figure 8. Intel^® Arria^® 10 DisplayPort MST Parallel Loopback without PCR

In this variant, the DisplayPort source’s parameter, TX_SUPPORT_IM_ENABLE, is turned on (“1”) and the video image interface is used.
The DisplayPort sink receives video and or audio streaming from external video source such as GPU and decodes it into parallel video interface.
The DisplayPort sink video output directly drives the DisplayPort source video interface and encodes to the DisplayPort main link before transmitting to the monitors.
The MST design examples support up to four streams for audio and video data.
The design examples use fixed EDID and do not support EDID passthrough.
The design examples support a total bandwidth of 594 MHz, distributed equally across the streams. For example, if you enable four streams, each stream would be 148.5 MHz.
You can modify the bandwidth assignment for each stream in the tx_utils.c file.
stream 0: btc_dptxll_stream_set_pixel_rate(0,0,594000/MST_RX_STREAMS);

stream 1: btc_dptxll_stream_set_pixel_rate(0,1,594000/MST_RX_STREAMS);

stream 2: btc_dptxll_stream_set_pixel_rate(0,2,594000/MST_RX_STREAMS);

stream 3: btc_dptxll_stream_set_pixel_rate(0,3,594000/MST_RX_STREAMS);
The maximum resolution supported for 4 stream counts is 1080p60.

Table 9. Design Example Variant Comparison
Design Example	PCR Module	Enable Video Image Interface	Adaptive Sync	Video Interface
DisplayPort MST parallel loopback with PCR	Required	No	Not supported	Standard `VSYNC`/`HSYNC`/`DE` interface (`txN_video_in`)
DisplayPort MST parallel loopback without PCR	Not required	Yes	Supported	Video Image Interface (`txN_video_in_im`)

2.3. Enabling Adaptive Sync Support

To enable support for the Adaptive Sync feature in the design examples without PCR, you need to edit the MSA_TIMING_PAR_IGNORED bit of the DPCD 00007h register and the MSA_TIMING_PAR_IGNORE_EN bit of the DPCD 00107h register in the rx_utils.c file in the software folder.

Note: The Adaptive Sync feature is applicable only when you turn on the Enable GPU control parameter.

To edit the bits:

Locate data[7] = 0x80; // DPCD_ADDR_DOWN_STREAM_PORT_COUNT.
Change 0x80 to 0xC0.
Locate data[7] = 0x00; // DPCD_ADDR_DOWNSPREAD_CTRL
Change 0x00 to 0x80.
Regenerate the ELF file, refer to Regenerating ELF File.
After programming the SOF file into the FPGA, program the updated ELF file into the FPGA.

2.4. Creating RX-Only or TX-Only Designs

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

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

To use RX- or TX-only components:

Remove the irrelevant blocks from the design.
Edit the config.h file in the software folder to specify if DP_SUPPORT_RX and DP_SUPPORT_TX is 1 or 0. The default setting for both parameters is 1.
- For TX-only design, set DP_SUPPORT_RX and BITEC_RX_GPUMODE to 0.
- For RX-only design, set DP_SUPPORT_TX to 0.

Table 10. RX-Only and TX-Only Design Requirements
User Requirement	Preserve	Remove	Add
DisplayPort RX Only	RX PHY Top; Core System consists of: RX sub-system CPU sub-system	TX Top PCR (if not needed) Transceiver Arbiter	–
DisplayPort TX Only	TX PHY Top; Core System consists of: TX sub-system CPU sub-system	RX Top PCR Transceiver Arbiter	Video Pattern Generator

2.5. Design Components

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

Table 11. Core System Components
Module	Description
Core System (Platform Designer)	The core system consists of the Nios II Processor and its necessary components, DisplayPort RX and TX core sub-systems. This system provides the infrastructure to interconnect the Nios II processor with the DisplayPort Intel^® FPGA IP (RX and TX instances) through Avalon memory-mapped (Avalon-MM) interface within a single Platform Designer system to ease the software build flow. This system consists of: CPU Sub-System RX Sub-System TX Sub-System
RX Sub-System (Platform Designer)	The RX sub-system consists of: Clock Source—The clock source to the DisplayPort RX core. This sub-system has two clock sources integrated: 100 MHz and 16 MHz. Reset Bridge—The bridge that connects the external signal to the sub-system. This bridge synchronizes to the respective clock source before it is used. DisplayPort RX Core—DisplayPort Sink IP core, VESA DisplayPort Standard version 1.4. Debug FIFO—This FIFO captures all DisplayPort RX auxiliary cycles, and prints out in the Nios II Debug terminal. PIO—The parallel IO that triggers the MSA capture, and prints out when the on-board push button (PB) is pressed. Avalon-MM Pipeline Bridge—This Avalon-MM bridge interconnects the Avalon-MM interface between components within the RX sub-system to the Nios II processor in the Core sub-system. EDID—The EDID RAM is only used to store the desired EDID value in the RAM and connect to the DisplayPort Sink IP core. This component is only used when you disable the Enable GPU Control option in the RX core.
TX Sub-System (Platform Designer)	The TX sub-system consists of: Clock Source—The clock source to the DisplayPort TX core. This sub-system has two clock sources integrated: 100 MHz and 16 MHz. Reset Bridge—The bridge that connects the external signal to the sub-system. This bridge synchronizes to the respective clock source before it is used. DisplayPort TX Core—DisplayPort Source IP core, VESA DisplayPort Standard version 1.4. Debug FIFO—This FIFO captures all DisplayPort TX auxiliary cycles, and prints out in the Nios II Debug terminal. This component is only used when the `TX_AUX_DEBUG` parameter is turned on. PIO—The parallel IO that triggers the DPTX register update in software (tx_utils.c). Avalon-MM Pipeline Bridge—This Avalon-MM bridge interconnects the Avalon-MM interface between components within the TX sub-system to the Nios II processor in the Core sub-system.

Table 12. DisplayPort RX PHY Top and TX PHY Top Components
Module	Description
RX PHY Top	The RX PHY top level consists of the components related to the receiver PHY layer. Transceiver Native PHY (RX)—The transceiver block that receives the serial data from an external video source and deserializes it to 20-bit or 40-bit parallel data to the DisplayPort sink IP core. This block supports up to 8.1 Gbps (HBR3) data rate with 4 channels. Transceiver PHY Reset Controller—The RX Reconfiguration Management module triggers the reset input of this controller to generate the corresponding analog and digital reset signals to the Transceiver Native PHY block according to the reset sequencing. RX Reconfiguration Management—This block reconfigures and recalibrates the Transceiver Native PHY block to receive serial data in the supported data rates (RBR, HBR, HBR2, and HBR3). Note: 8.1 Gbps is available only in the Intel^® Quartus^® Prime Pro Edition software.
TX PHY Top	The TX PHY top level consists of the components related to the transmitter PHY layer. Transceiver Native PHY (TX)—The transceiver block that receives 20-bit or 40-bit parallel data from the DisplayPort Intel^® FPGA IP and serializes the data before transmitting it. This block supports up to 8.1 Gbps (HBR3) data rate with 4 channels. Note: You must set the TX channel bonding mode to PMA and PCS bonding and the PCS TX Channel bonding master parameter to 0 (default is auto). Transceiver PHY Reset Controller—The TX Reconfiguration Management module triggers the reset input of this controller to generate the corresponding analog and digital reset signals to the Transceiver Native PHY block according to the reset sequencing. TX Reconfiguration Management—This block reconfigures and recalibrates the Transceiver Native PHY and TX PLL blocks to transmit serial data in the required data rates (RBR, HBR, HBR2, and HBR3). TX PLL—The transmitter PLL block provides a fast serial fast clock to the Transceiver Native PHY block. For the DisplayPort Intel^® FPGA IP design example, Intel^® uses transmitter fractional PLL (FPLL). Note: 8.1 Gbps is available only in the Intel^® Quartus^® Prime Pro Edition software.

Table 13. Loopback Top Component
Module	Description
Pixel Clock Recovery (PCR)	This module recovers pixel clock (derived from the DisplayPort Sink MSA information). PCR dynamically detects the received video format and recovers the corresponding pixel clock. This module also integrates a DCFIFO as video data buffer from the receiver and transmitter clock domains. This module supports resolutions up to 8Kp30 only. Note: Your design may not require PCR if you use your own recovery logic or any of the Video and Image Processing (VIP) IP cores.

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-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 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.
IOPLL	IOPLL generates common source clock: `dp_rx_vid_clkout` and `clk_16` (16 MHz) for the DisplayPort system. `dp_rx_vid_clkout`—used as RX core video clock of the video data stream and PCR video input clock. `clk_16`—Used as DisplayPort auxiliary clock and PCR reference clock.

2.6. Clocking Scheme

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

Figure 10. DisplayPort Intel^® FPGA IP Design Example Clocking Scheme

Table 15. Clocking Scheme Signals
Clock	Signal Name in Design	Description
TX PLL Refclock	`tx_pll_refclk`	135 MHz TX PLL reference clock, that is divisible by the transceiver for all DisplayPort data rates (1.62 Gbps, 2.7 Gbps, and 5.4 Gbps). Note: The reference clock source of the TX PLL refclock is located at the HSSI `refclk` pin.
TX Transceiver Clockout	`gxb_tx_clkout`	TX clock recovered from the transceiver, and the frequency varies depending on the data rate and symbols per clock.
		Data Rate	Symbols per Clock	Frequency (MHz)
		RBR (1.62 Gbps)	2 (dual)	81
		RBR (1.62 Gbps)	4 (quad)	40.5
		HBR (2.7 Gbps)	2 (dual)	135
		HBR (2.7 Gbps)	4 (quad)	67.5
		HBR2 (5.4 Gbps)	2 (dual)	270
		HBR2 (5.4 Gbps)	4 (quad)	135
		HBR3 (8.1 Gbps)	4 (quad)	202.5

TX PLL Serial Clock	`gxb_tx_bonding_clocks`	Serial fast clock generated by TX PLL. The clock frequency is set based on the data rate.
RX Refclock	`rx_cdr_refclk`	135 MHz transceiver clock data recovery (CDR) reference clock, that is divisible by all DisplayPort data rates (1.62 Gbps, 2.7 Gbps, and 5.4 Gbps). Note: The reference clock source of the RX refclock is located at the HSSI `refclk` pin.
RX Transceiver Clockout	`gxb_rx_clkout`	RX clock recovered from the transceiver, and the frequency varies depending on the data rate and symbols per clock.
		Data Rate	Symbols per Clock	Frequency (MHz)
		RBR (1.62 Gbps)	2 (dual)	81
		RBR (1.62 Gbps)	4 (quad)	40.5
		HBR (2.7 Gbps)	2 (dual)	135
		HBR (2.7 Gbps)	4 (quad)	67.5
		HBR2 (5.4 Gbps)	2 (dual)	270
		HBR2 (5.4 Gbps)	4 (quad)	135
		HBR3 (8.1 Gbps)	4 (quad)	202.5

Management Clock	`rx_rcfg_mgmt_clk` `tx_rcfg_mgmt_clk`	A free running 100 MHz clock for both Avalon-MM interfaces for reconfiguration and PHY reset controller for transceiver reset sequence.
		Component		Required Frequency (MHz)
		Avalon-MM reconfiguration		100 – 125
		Transceiver PHY reset controller		1 – 500

Audio Clock	`dp_audio_clk`	DisplayPort audio clock.
16 MHz Clock	`clk_16`	160 MHz clock used to encode and decode auxiliary channel in the DisplayPort Intel^® FPGA IP source and sink IP cores. This clock is also used as a reference clock in the Pixel Clock module for fractional calculation.
Calibration Clock	`dp_rx_clk_cal` `dp_tx_clk_cal`	A 50 MHz calibration clock input that must be synchronous to the Transceiver Reconfiguration module's clock. This clock is used in the DisplayPort Intel^® FPGA IP core's reconfiguration logic.
RX Video Clock	`dp_rx_vid_clkout`	Video clock for DisplayPort sink to clock video data stream. If `MAX_LINK_RATE` = HBR2 and `PIXELS_PER_CLOCK` = Dual, video clock uses 300 MHz. Otherwise, fixed to 160 MHz.
TX Video Clock	`tx_vid_clk`	Recovered video clock from the PCR module that reflects the actual video clock frequency. Used when DisplayPort source's `TX_SUPPORT_IM_ENABLE` = 0.
TX IM Clock	`tx_im_clk`	Video clock for DisplayPort source to clock video data stream. Must be the same as the RX video clock in this design. Used when DisplayPort source's `TX_SUPPORT_IM_ENABLE` = 1.

2.7. Interface Signals and Parameters

The tables list the signals and parameter for the DisplayPort Intel^® FPGA IP design example.

Table 16. Top-Level Signals
Signal	Direction	Width	Description
On-board Oscillator Signal
`refclk1_p`	Input	1	100 MHz clock source used as IOPLL reference clock and Avalon-MM management clock
User Push Buttons and LEDs
`user_pb[0]`	Input	1	Push button to trigger MSA print out during debug
`user_pb[2]`	Input	1	Push button to switch to the next video stream, for the MST parallel loopback with PCR design example.
`cpu_resetn`	Input	1	Global reset
`user_led_g`	Output	8	Green LED display Note: Refer to Hardware Setup for the on-board user LED functions.
DisplayPort FMC Daughter Card Pins on FMC Port A
`fmca_gbtclk_m2c_p`	Input	1	135 MHz dedicated transceiver reference clock from FMC port A
`fmca_dp_m2c_p`	Input	N	DisplayPort RX serial data Note: N = RX maximum lane count
`fmca_dp_c2m_p`	Output	N	DisplayPort TX serial data Note: N = TX maximum lane count
`fmca_la_tx_p_10`	Input	1	DisplayPort RX cable detect 1 = Cable detected 0 = Cable not detected
`fmca_la_rx_n_8`	Input	1	DisplayPort RX power detect 1 = Power not detected 0 = Power detected
`fmca_la_tx_n_9`	Input	1	DisplayPort RX Aux In
`fmca_la_rx_n_6`	Output	1	DisplayPort RX Aux Out
`fmca_la_tx_p_9`	Output	1	DisplayPort RX Aux OE
`fmca_la_rx_p_6`	Output	1	DisplayPort RX HPD 1 = HPD asserted 0 = HPD deasserted
`fmca_la_rx_n_9`	Input	1	DisplayPort TX HPD 1 = HPD asserted 0 = HPD deasserted
`fmca_la_tx_p_12`	Input	1	DisplayPort TX Aux In
`fmca_la_rx_p_10`	Output	1	DisplayPort TX Aux Out
`fmca_la_rx_n_10`	Output	1	DisplayPort TX Aux OE
`fmca_la_tx_n_12`	Output	1	TX CAD for Bitec FMC Rev. 8
`fmca_la_tx_p_14`	Output	1	TX CAD for Bitec FMC Rev. 10 and 11
FMC On-board Retimer Reconfiguration Interface
`fmca_la_tx_p_0`	Inout	1	Bitec FMC Rev. 10: PS8460_SDA Bitec FMC Rev. 11: MCDP6000_SDA
`fmca_la_tx_n_0`	Inout	1	Bitec FMC Rev. 10: PS8460_SCL Bitec FMC Rev. 11: MCDP6000_SDL
`fmca_la_rx_p_0`	Output	1	Bitec FMC Rev. 10: PS8460_EQ0 Bitec FMC Rev. 11: Unused
`fmca_la_rx_n_0`	Output	1	Bitec FMC Rev. 10: PS8460_EQ1 Bitec FMC Rev. 11: Unused
`fmca_la_tx_p_1`	Output	1	Bitec FMC Rev. 10: PS8460_PDN Bitec FMC Rev. 11: Unused
`fmca_la_tx_n_1`	Output	1	Bitec FMC Rev. 10: PS8460_CFG0 Bitec FMC Rev. 11: Unused
`fmca_la_tx_p_2`	Output	1	Bitec FMC Rev. 10: PS8460_CFG1 Bitec FMC Rev. 11: Unused
`fmca_la_tx_n_2`	Output	1	Bitec FMC Rev. 10: PS8460_CFG2 Bitec FMC Rev. 11: Unused

Table 17. DisplayPort Intel^® FPGA IP Signals (Platform Designer System)
Signal	Direction	Width	Description
Clock and Reset
`clk_100_in_clk`	Input	1	100 MHz clock to CPU sub-system
`cpu_reset_bridge_in_reset_n`	Input	1	Reset to CPU sub-system (active low)
DisplayPort RX Signals
`dp_rx_reset_bridge_in_reset_n`	Input	1	Reset to RX sub-system (active low)
`dp_rx_clk_16_in_clk`	Input	1	RX Auxiliary clock (16 MHz)
`dp_rx_dp_sink_clk_cal`	Input	1	RX reconfiguration calibration clock
`dp_rx_pio_0_in_port`	Input	1	Push button IO for debug purpose
`dp_rx_dp_sink_rx_audio_valid`	Output	1	RX Audio Interface Note: M = RX audio channel
`dp_rx_dp_sink_rx_audio_mute`	Output	1
`dp_rx_dp_sink_rx_audio_infoframe`	Output	40
`dp_rx_dp_sink_rx_audio_lpcm_data`	Output	M*32
`dp_rx_dp_sink_rx_aux_in`	Input	1	RX auxiliary interface
`dp_rx_dp_sink_rx_aux_out`	Output	1
`dp_rx_dp_sink_rx_aux_oe`	Output	1
`dp_rx_dp_sink_rx_hpd`	Output	1	RX HPD
`dp_rx_dp_sink_rx_cable_detect`	Input	1	RX cable detect (active high)
`dp_rx_dp_sink_rx_pwr_detect`	Input	1	RX power detect (active high)
`dp_rx_dp_sink_rx_msa`	Output	217	DisplayPort RX MSA
`dp_rx_dp_sink_rx_lane_count`	Output	5	DisplayPort RX lane count
`dp_rx_dp_sink_rx_link_rate`	Output	2	RX Link Rate 2-bit indicator, used in PCR RBR: 2‘b00 HBR: 2‘b01 HBR2: 2‘b10 HBR3: 2'b11
`dp_rx_dp_sink_rx_link_rate_8bits`	Output	8	RX Link Rate 8-bit indicator, used in transceiver reconfiguration management RBR: 0x06 HBR: 0x0A HBR2: 0x14 HBR3: 0x1E
`dp_rx_dp_sink_rx_ss_valid`	Output	1	DisplayPort RX secondary stream interface
`dp_rx_dp_sink_rx_ss_data`	Output	160
`dp_rx_dp_sink_rx_ss_sop`	Output	1
`dp_rx_dp_sink_rx_ss_eop`	Output	1
`dp_rx_dp_sink_rx_ss_clk`	Output	1
`dp_rx_dp_sink_rx_stream_valid`	Output	1	RX post scrambler stream data. For debug purpose. Note: S = RX symbols per clock
`dp_rx_dp_sink_rx_stream_clk`	Output	1
`dp_rx_dp_sink_rx_stream_data`	Output	S*32
`dp_rx_dp_sink_rx_stream_ctrl`	Output	S*4
`dp_rx_dp_sink_rx_vid_clk`	Input	1	DisplayPort RX video stream interface. Note: B = RX bits per color, P = RX pixels per clock
`dp_rx_dp_sink_rx_vid_sol`	Output	1
`dp_rx_dp_sink_rx_vid_eol`	Output	1
`dp_rx_dp_sink_rx_vid_sof`	Output	1
`dp_rx_dp_sink_rx_vid_eof`	Output	1
`dp_rx_dp_sink_rx_vid_locked`	Output	1
`dp_rx_dp_sink_rx_vid_interlace`	Output	1
`dp_rx_dp_sink_rx_vid_field`	Output	1
`dp_rx_dp_sink_rx_vid_overflow`	Output	1
`dp_rx_dp_sink_rx_vid_data`	Output	BP3
`dp_rx_dp_sink_rx_vid_valid`	Output	P
`dp_rx_dp_sink_rx_parallel_data`	Input	N S10	DisplayPort parallel data from RX Native PHY Note: N = RX maximum lane count, S = RX symbols per clock
`dp_rx_dp_sink_rx_std_clkout`	Input	N	CDR clock out from RX Native PHY Note: N = RX maximum lane count
`dp_rx_dp_sink_rx_restart`	Output	1	Reset signal to RX Native PHY Reset controller when RX data loses alignment. Triggered by the DisplayPort RX core.
`dp_rx_dp_sink_rx_reconfig_req`	Output	1	Transceiver reconfiguration interface to the RX reconfiguration management module Note: N = RX maximum lane count
`dp_rx_dp_sink_rx_reconfig_ack`	Input	1
`dp_rx_dp_sink_rx_reconfig_busy`	Input	1
`dp_rx_dp_sink_rx_bitslip`	Output	N
`dp_rx_dp_sink_rx_cal_busy`	input	N
`dp_rx_dp_sink_rx_analogreset`	Output	N
`dp_rx_dp_sink_rx_digitalreset`	Output	N
`dp_rx_dp_sink_rx_is_lockedtoref`	Input	N
`dp_rx_dp_sink_rx_is_lockedtodata`	Input	N
`dp_rx_dp_sink_rx_set_locktoref`	Output	N
`dp_rx_dp_sink_rx_set_locktodata`	Output	N
DisplayPort TX Signals
`dp_tx_reset_bridge_in_reset_n`	Input	1	Reset to TX sub-system
`dp_tx_clk_16_in_clk`	Input	1	TX Auxiliary clock (16 MHz)
`dp_tx_dp_source_clk_cal`	Input	1	TX reconfiguration calibration clock
`dp_tx_dp_source_tx_audio_valid`	Input	1	TX audio channel interface Note: M = TX audio channel
`dp_tx_dp_source_tx_audio_mute`	Input	1
`dp_tx_dp_source_tx_audio_lpcm_data`	Input	M*32
`dp_tx_dp_source_tx_audio_clk`	Input	1
`dp_tx_dp_source_tx_aux_in`	Input	1	TX auxiliary interface
`dp_tx_dp_source_tx_aux_out`	Output	1
`dp_tx_dp_source_tx_aux_oe`	Output	1
`dp_tx_dp_source_tx_hpd`	Input	1	TX HPD
`dp_tx_dp_source_tx_link_rate`	Output	2	TX Link Rate 2-bit indicator, used in transceiver reconfiguration management RBR: 2‘b00 HBR: 2‘b01 HBR2: 2‘b10 HBR3: 2'b11
`dp_tx_dp_source_tx_link_rate_8bits`	Output	8	TX Link Rate 8-bit indicator, used in transceiver reconfiguration management RBR: 0x06 HBR: 0x0A HBR2: 0x14 HBR3: 0x1E
`dp_tx_dp_source_tx_ss_ready`	Output	1	DisplayPort TX secondary stream interface
`dp_tx_dp_source_tx_ss_valid`	Input	1
`dp_tx_dp_source_tx_ss_data`	Input	128
`dp_tx_dp_source_tx_ss_sop`	Input	1
`dp_tx_dp_source_tx_ss_eop`	Input	1
`dp_tx_dp_source_tx_ss_clk`	Output	1
`dp_tx_dp_source_tx_vid_clk`	Input	1	DisplayPort TX video stream (VYSNC/HSYNC/DE) interface (only used when `TX_SUPPORT_IM_ENABLE` = 0) Note: B = TX bits per color, P = TX pixels per clock.
`dp_tx_dp_source_tx_vid_data`	Input	BP3
`dp_tx_dp_source_tx_vid_v_sync`	Input	P
`dp_tx_dp_source_tx_vid_h_sync`	Input	P
`dp_tx_dp_source_tx_vid_de`	Input	P
`dp_tx_dp_source_tx_im_clk`	Input	1	DisplayPort TX video image interface (only used when `TX_SUPPORT_IM_ENABLE` = 1) Note: B = TX bits per color, P = TX pixels per clock.
`dp_tx_dp_source_tx_im_sol`	Input	1
`dp_tx_dp_source_tx_im_eol`	Input	1
`dp_tx_dp_source_tx_im_sof`	Input	1
`dp_tx_dp_source_tx_im_eof`	Input	1
`dp_tx_dp_source_tx_im_data`	Input	BP3
`dp_tx_dp_source_tx_im_valid`	Input	1
`dp_tx_dp_source_tx_im_locked`	Input	1
`dp_tx_dp_source_tx_im_interlace`	Input	1
`dp_tx_dp_source_tx_im_field`	Input	1
`dp_tx_dp_source_tx_parallel_data`	Output	NS10	DisplayPort parallel data to TX Native PHY Note: N = TX maximum lane count, S = TX symbols per clock
`dp_tx_dp_source_tx_std_clkout`	Input	N	TX Native PHY clock out Note: N = TX maximum lane count
`dp_tx_dp_source_tx_pll_locked`	Input	1	TX PLL locked indicator
`dp_tx_dp_source_tx_reconfig_req`	Output	1	Transceiver Reconfiguration interface to TX reconfiguration management module Note: N = TX maximum lane count
`dp_tx_dp_source_tx_reconfig_ack`	Input	1
`dp_tx_dp_source_tx_reconfig_busy`	Input	1
`dp_tx_dp_source_tx_pll_powerdown`	Output	1
`dp_tx_dp_source_tx_analog_reconfig_req`	Output	1
`dp_tx_dp_source_tx_analog_reconfig_ack`	Input	1
`dp_tx_dp_source_tx_analog_reconfig_busy`	Input	1
`dp_tx_dp_source_tx_vod`	Output	N*2
`dp_tx_dp_source_tx_emp`	Output	N*2
`dp_tx_dp_source_tx_analogreset`	Output	N
`dp_tx_dp_source_tx_digitalreset`	Output	N
`dp_tx_dp_source_tx_cal_busy`	Input	N

Table 18. RX PHY Top-Level Signals
Signal	Direction	Width	Description
`rx_cdr_refclk`	Input	1	RX Native PHY CDR reference clock. This design example uses 135 MHz.
`dp_rx_clk_cal`	Output	1	50 MHz DisplayPort RX reconfiguration calibration clock. This clock must be synchronous to `rcfg_mgmt_clk`.
`rx_cdr_resetn`	Input	1	RX Native PHY reset (active low)
`video_pll_locked`	Input	1	This signal indicates that the video PLL (video clock and clk16) is stable and locked. Use as reset to the DisplayPort Intel^® FPGA IP and the transceiver.
`dp_rx_link_rate_8bits`	Input	8	RX link rate indicator, used in transceiver reconfiguration management
`rx_rcfg_mgmt_reset`	Input	1	RX reconfiguration reset
`rx_rcfg_mgmt_clk`	Input	1	RX reconfiguration management clock (100 MHz)
`rx_rcfg_en`	Output	1	RX reconfiguration enable signal
`rx_rcfg_write`	Output	1	Reconfiguration Avalon^® memory-mapped interfaces that interact with Transceiver Arbiter Note: N = RX maximum lane count (1, 2, or 4)
`rx_rcfg_read`	Output	1
`rx_rcfg_address`	Output	12
`rx_rcfg_writedata`	Output	32
`rx_rcfg_readdata`	Input	32
`rx_rcfg_waitrequest`	Input	1
`rx_rcfg_cal_busy`	Input	N
`gxb_rx_rcfg_write`	Input	N	Reconfiguration Avalon^® memory-mapped interfaces from Transceiver Arbiter Note: N = RX maximum lane count (1, 2, or 4)
`gxb_rx_rcfg_read`	Input	N
`gxb_rx_rcfg_address`	Input	N*10
`gxb_rx_rcfg_writedata`	Input	N*32
`gxb_rx_rcfg_readdata`	Output	N*32
`gxb_rx_rcfg_waitrequest`	Output	N
`gxb_rx_rcfg_cal_busy`	Output	N
`gxb_rx_clkout`	Output	N	RX Native PHY CDR clock out Note: N = RX maximum lane count (1, 2, or 4)
`gxb_rx_serial_data`	Input	N	DisplayPort Serial Data to RX Native PHY Note: N = RX maximum lane count (1, 2, or 4)
`dp_rx_parallel_data`	Output	NS10	DisplayPort parallel data to DisplayPort RX core Note: N = RX maximum lane count (1, 2, or 4), S = RX symbols per clock (2 or 4)
`dp_rx_restart`	Input	1	Reset signal to the RX Native PHY Reset controller when RX data loses alignment. Triggered by the DisplayPort RX core.
`dp_rx_rcfg_req`	Input	1	Transceiver Reconfiguration interface from the DisplayPort RX core Note: N = RX maximum lane count (1, 2, or 4)
`dp_rx_rcfg_ack`	Output	1
`dp_rx_rcfg_busy`	Output	1
`dp_rx_is_lockedtoref`	Output	N
`dp_rx_is_lockedtodata`	Output	N
`dp_rx_bitslip`	Input	N
`dp_rx_cal_busy`	Output	1
`dp_rx_set_locktoref`	Input	N
`dp_rx_set_locktodata`	Input	N

Table 19. TX PHY Top-Level Signals
Signal	Direction	Width	Description
`tx_pll_refclk`	Input	1	TX transceiver PLL reference clock. This design example uses 135 MHz.
`dp_tx_clk_cal`	Output	1	50 MHz DisplayPort TX reconfiguration calibration clock. This clock must be synchronous to `rcfg_mgmt_clk`.
`tx_pll_resetn`	Input	1	TX transceiver PLL reset (active low)
`video_pll_locked`	Input	1	This signal indicates that the video PLL (video clock and clk16) is stable and locked. Use as reset to the DisplayPort Intel^® FPGA IP and the transceiver.
`tx_cad`	Output	1	Driven to FMC card TX CAD. Tied to 0.
`dp_tx_link_rate_8bits`	Input	8	TX Link Rate indicator, used in transceiver reconfiguration management. RBR: 0x06 HBR: 0x0A HBR2: 0x14 HBR3: 0x1E
`tx_rcfg_mgmt_reset`	Input	1	TX reconfiguration reset
`tx_rcfg_mgmt_clk`	Input	1	TX reconfiguration management clock (100 MHz)
`tx_rcfg_en`	Output	1	TX reconfiguration enable signal
`tx_rcfg_write`	Output	1	Reconfiguration Avalon^® memory-mapped interfaces to Transceiver Arbiter Note: N = TX maximum lane count (1, 2, or 4)
`tx_rcfg_read`	Output	1
`tx_rcfg_address`	Output	12
`tx_rcfg_writedata`	Output	32
`tx_rcfg_readdata`	Input	32
`tx_rcfg_waitrequest`	Input	1
`tx_rcfg_cal_busy`	Input	N
`gxb_tx_rcfg_write`	Input	N	Reconfiguration Avalon^® memory-mapped interfaces from Transceiver Arbiter Note: N = TX maximum lane count (1, 2, or 4)
`gxb_tx_rcfg_read`	Input	N
`gxb_tx_rcfg_address`	Input	N*10
`gxb_tx_rcfg_writedata`	Input	N*32
`gxb_tx_rcfg_readdata`	Output	N*32
`gxb_tx_rcfg_waitrequest`	Output	N
`gxb_tx_rcfg_cal_busy`	Output	N
`gxb_tx_clkout`	Output	N	Transceiver clock out Note: N = TX maximum lane count (1, 2, or 4)
`gxb_tx_serial_data`	Output	N	DisplayPort Serial Data from Transceiver Note: N = TX maximum lane count
`dp_tx_parallel_data`	Input	NS10	DisplayPort Parallel Data from DisplayPort TX Core Note: N = TX maximum lane count (1, 2, or 4), S = TX symbols per clock (2 or 4)
`dp_tx_rcfg_req`	Input	1	Transceiver Reconfiguration interface from DisplayPort TX Core Note: N = TX maximum lane count (1, 2, or 4)
`dp_tx_rcfg_ack`	Output	1
`dp_tx_rcfg_vod`	Input	8
`dp_tx_rcfg_emp`	Input	8
`dp_txpll_rcfg_req`	Input	1
`dp_txpll_rcfg_ack`	Output	1
`dp_tx_rcfg_busy`	Output	1
`dp_txpll_powerdown`	Input	1
`dp_tx_cal_busy`	Output	N
`dp_txpll_locked`	Output	1

Table 20. 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 21. Pixel Clock Recovery Signals
The PCR module in the dynamic generation design example is an enhanced version where 2 Fractional PLLs (FPLLs) are used.
Signal	Direction	Width	Description
`areset`	Input	1	PCR reset
`clk`	Input	1	Control loop clock (16 MHz)
`clk_135`	Input	1	135 MHz clock
`rx_link_clk`	Input	1	RX Native PHY CDR clock out
`rx_link_rate`	Input	2	RX link rate 2-bit indicator
`rx_msa`	Input	217	RX MSA
`vidin_clk`	Input	1	RX video clock. If `MAX_LINK_RATE` = HBR2 and `PIXELS_PER_CLOCK` = Dual, uses 300 MHz. Otherwise, fixed to 160 MHz.
`vidin_data`	Input	BP3	RX video stream interface from RX core Note: B = RX bits per color, P = RX pixels per clock.
`vidin_valid`	Input	1
`vidin_locked`	Input	1
`vidin_sof`	Input	1
`vidin_eof`	Input	1
`vidin_sol`	Input	1
`vidin_eol`	Input	1
`rec_clk`	Output	1	Reconstructed/recovered video clock
`rec_clk_x2`	Output	1	Reconstructed/recovered video clock (2x faster); not used
`vidout`	Output	BP3	TX video stream interface Note: B = TX bits per color, P = TX pixels per clock.
`hsync`	Output	1
`vsync`	Output	1
`de`	Output	1
`field2`	Output	1

Table 22. Pixel Clock Recovery ParametersYou can use these parameters to configure the clock recovery core.
Parameter	Default Value	Description
`PIXELS_PER_CLOCK`	1	Specifies how many pixels in parallel (for each clock cycle) are gathered from the DisplayPort RX core (1, 2 or 4).
`BPP`	24	Specifies the width (in bits) of a single pixel. 1 bit per pixel is equivalent to 3* bits per color.
`CLK_PERIOD_NS`	10	Specifies the period (in nanoseconds) of the clock signal connected to the port. In this design example, the value used is 62.
`DEVICE_FAMILY`	Intel^® Arria^® 10	Identifies the family of the device used.
`FIXED_NVID`	0	Specifies the configuration of the DisplayPort RX received video clocking used. 1 if GPU NVID is fixed to 'h8000 0 if GPU NVID is not fixed Select 0 if you require the PCR to inter-operate with any GPU. Select 1 if you want to optimize resources but take note that this option may not work with certain GPUs.

2.8. Hardware Setup

The DisplayPort Intel^® FPGA IP design example is 8Kp30 capable and performs a loop-through for a standard DisplayPort video stream.

To run the hardware test, connect a DisplayPort-enabled source device to the DisplayPort FMC daughter card sink input.
The DisplayPort sink decodes the port into a standard video stream and sends it to the clock recovery core.
The clock recovery core synthesizes the original video pixel clock to be transmitted together with the received video data.
Note: You require the clock recovery feature to produce video without using a frame buffer.
The clock recovery core then sends the video data to the DisplayPort source and the Transceiver Native PHY TX block.
Connect the DisplayPort FMC daughter card source port to a monitor to display the image.

Table 23. On-board User LED Functions
LEDs	Function
USER_LED[0]	This LED indicates that the source is successfully lane-trained. At this point, the IP core asserts `rx0_vid_locked`.
USER_LED[5:1]	These LEDs illuminate design example lane counts. 4'b0001 = 1 lane 4'b0010 = 2 lanes 4'b0100 = 4 lanes
USER_LED[7:6]	These LEDs indicate the RX link rate. 2'b00 = RBR 2'b01 = HBR 2'b10 = HBR2 2'b11 = HBR3

2.9. Simulation Testbench

The simulation testbench simulates the DisplayPort TX serial loopback to RX.

Figure 11. DisplayPort Intel^® FPGA IP Simplex Mode Simulation Testbench Block Diagram

Table 24. Testbench Components
Component	Description
Video Pattern Generator	This generator produces color bar patterns that you can configure. You can parameterize the video format timing.
Testbench Control	This block controls the test sequence of the simulation and generates the necessary stimulus signals to the TX core. The testbench control block also reads the CRC value from both source and sink to make comparisons.
RX Link Speed Clock Frequency Checker	This checker verifies if the RX transceiver recovered clock frequency matches the desired data rate.
TX Link Speed Clock Frequency Checker	This checker verifies if the TX transceiver recovered clock frequency matches the desired data rate.

The simulation testbench does the following verifications:

Test Criteria	Verification
Link Training sweep across all data rates from HBR3 to HBR2 to HBR and RBR Read the DPCD registers to check if the DP Status sets and measures both TX and RX Link Speed frequency.	Integrates Frequency Checker to measure the Link Speed clock's frequency output from the TX and RX transceiver.
Run video pattern from TX to RX. Verify the CRC for both source and sink to check if they match.	Connects video pattern generator to the DisplayPort Source to generate the video pattern. Testbench control next reads out both Source and Sink CRC from DPTX and DPRX registers and compares to ensure both CRC values are identical. Note: To ensure CRC is calculated, you must enable the Support CTS test automation parameter.

A successful simulation ends with the following message:

Table 25. DisplayPort Design Example Supported EDA Simulators
Simulator	Supported Platform	Supported Language
Riviera-PRO*	Windows/Linux	VHDL and Verilog HDL
ModelSim*	Windows/Linux	VHDL and Verilog HDL
NCSim	Linux	Verilog HDL
Xcelium* Parallel	Linux	Verilog HDL
VCS* / VCS* MX	Linux	VHDL and Verilog HDL

2.10. DisplayPort Transceiver Reconfiguration Flow

The VESA DisplayPort Standard version 1.4 supports 4 link rates (8.1 Gbps, 5.4 Gbps, 2.7 Gbps, and 1.62 Gbps). You can dynamically switch from 1 data rate to another. Transceiver reconfiguration is required to support dynamic link rate switching.

The DisplayPort Intel^® FPGA IP design examples require some level of reconfiguration and recalibration but with some modification. In these design examples, the pre-calibration method is implemented to reduce the transceiver reconfiguration duration.

Figure 12. Transceiver Reconfiguration Flowchart

The following sequences describe the flow.

Upon power up or push button reset, the DisplayPort reconfiguration module initiates the transceiver reconfiguration to sweep across all supported link rate and all lane count.
1. For TX FPLL, these register offsets are reconfigured:
  - 10 ’h12B (TXPLL M Counter)
  - 10 ’h12C (TXPLL L Counter)
2. For RX CDR, these register offsets are reconfigured:
  - 10 ’h13a (RX L PFD and PD Counter)
  - 10 ’h13b (RX M Counter)
After reconfiguration completes, recalibration initiates per data rate.
After calibration completes, the pre-defined calibrated registers will be stored according to the respective data rate.
1. For TX FPLL, these register offsets are recalibrated:
  - 10 ’h10A (PLL VCO Frequency Band 0 fix low bits)
  - 10’h10B (PLL VCO Frequency Band 0 dyn)
  - 10’h142 (PLL VCO Frequency Band 0 fix high bits)
  - 10 ’h123 (PLL VCO Frequency Band 1 fix)
  - 10’h124 (PLL VCO Frequency Band 1 dyn)
  - 10’h125
  - 10’h126
2. For RX CDR, these register offsets are recalibrated:
  - 10 ’h132 (CDR VCO Speed fix)
  - 10 ’h133 (Charge Pump Vcc register)
  - 10’h134 (CDR VCO Speed fix)
  - 10 ’h135 (LF PFD and PD Register)
  - 10 ’h136 (CDR VCO Speed fix)
  - 10 ’h137 (CDR VCO Speed fix)
  - 10 ’h139 (Charge Pump current PFD and PD register)
Steps 1 through 3 are repeated until all supported data rates are covered.
When the pre-calibration steps complete, the reconfiguration module is ready to start DisplayPort link training.
Whenever the DisplayPort Intel^® FPGA IP sends a new link rate request, the reconfiguration module initiates reconfiguration to the transceiver.
The reconfiguration flow includes retrieving the calibrated register offset value that corresponds to the link rate and reconfigure it to the transceiver. No recalibration is required.
When reconfiguration completes, the transceiver is ready to receive the link rate.
The DisplayPort reconfiguration module continues to monitor if a new link rate request is detected. If it detects a new request, the module repeats step 5.

2.11. Transceiver Lane Configurations

If you want to configure your design to use 1, 2 or 4 lanes targeting different versions of Bitec FMC daughter cards, you have to configure the pin assignments accordingly in the Intel^® Quartus^® Prime Pro Settings File (QSF).

To configure the DisplayPort Intel^® FPGA IP design example using 1, 2 or 4 lanes, follow these steps:

In both the DisplayPort Source and Sink parameter editors, set the Maximum lane count parameter to 1, 2 or 4.
Generate the design example.

Make the following assignments in the Assignment Editor.

Table 26. Pin Assignments for Bitec FMC Revision 8 or Earlier
DisplayPort	Pin Location ( Intel^® Arria^® 10 Development Kit)	Four Lanes	Two Lanes	One Lane
Source	BC7	fmca_dp_c2m_p[0]	Not applicable	Not applicable
	BC8	fmca_dp_c2m_n[0]
	BD5	fmca_dp_c2m_p[1]
	BD6	fmca_dp_c2m_n[1]
	BB5	fmca_dp_c2m_p[2]	fmca_dp_c2m_p[0]
	BB6	fmca_dp_c2m_n[2]	fmca_dp_c2m_n[0]
	BC3	fmca_dp_c2m_p[3]	fmca_dp_c2m_p[1]	fmca_dp_c2m_p[0]
	BC4	fmca_dp_c2m_n[3]	fmca_dp_c2m_n[1]	fmca_dp_c2m_n[0]
Sink	AW7	fmca_dp_m2c_p[0]	fmca_dp_m2c_p[0]	fmca_dp_m2c_p[0]
	AW8	fmca_dp_m2c_n[0]	fmca_dp_m2c_n[0]	fmca_dp_m2c_n[0]
	BA7	fmca_dp_m2c_p[1]	fmca_dp_m2c_p[1]	Not applicable
	BA8	fmca_dp_m2c_n[1]	fmca_dp_m2c_n[1]
	AY5	fmca_dp_m2c_p[2]	Not applicable
	AY6	fmca_dp_m2c_n[2]
	AV5	fmca_dp_m2c_p[3]
	AV6	fmca_dp_m2c_n[3]
Transceiver Avalon^® Memory-Mapped Interface Group	XCVR_RECONFIG_GROUP	Enable	Disable	Disable

Table 27. Pin Assignments for Bitec FMC Revision 10
DisplayPort	Pin Location ( Intel^® Arria^® 10 Development Kit)	Four Lanes	Two Lanes	One lane
Source	BC7	fmca_dp_c2m_p[0]	fmca_dp_c2m_p[0]	fmca_dp_c2m_p[0]
	BC8	fmca_dp_c2m_n[0]	fmca_dp_c2m_n[0]	fmca_dp_c2m_n[0]
	BD5	fmca_dp_c2m_p[1]	fmca_dp_c2m_p[1]	Not Applicable
	BD6	fmca_dp_c2m_n[1]	fmca_dp_c2m_n[1]
	BB5	fmca_dp_c2m_p[2]	Not Applicable
	BB6	fmca_dp_c2m_n[2]
	BC3	fmca_dp_c2m_p[3]
	BC4	fmca_dp_c2m_n[3]
Sink	AW7	fmca_dp_m2c_p[0]	fmca_dp_m2c_p[0]	fmca_dp_m2c_p[0]
	AW8	fmca_dp_m2c_n[0]	fmca_dp_m2c_n[0]	fmca_dp_m2c_n[0]
	BA7	fmca_dp_m2c_p[1]	fmca_dp_m2c_p[1]	Not Applicable
	BA8	fmca_dp_m2c_n[1]	fmca_dp_m2c_n[1]
	AY5	fmca_dp_m2c_p[2]	Not Applicable
	AY6	fmca_dp_m2c_n[2]
	AV5	fmca_dp_m2c_p[3]
	AV6	fmca_dp_m2c_n[3]
Merging of Reconfiguration Interfaces	XCVR_RECONFIG_GROUP	Enable	Enable	Enable

Table 28. Pin Assignments for Bitec FMC Revision 11
DisplayPort	Pin Location ( Intel^® Arria^® 10 Development Kit)	Four Lanes	Two Lanes	One Lane
Source	BC7	fmca_dp_c2m_p[0]	fmca_dp_c2m_p[0]	fmca_dp_c2m_p[0]
	BC8	fmca_dp_c2m_n[0]	fmca_dp_c2m_n[0]	fmca_dp_c2m_n[0]
	BD5	fmca_dp_c2m_p[1]	fmca_dp_c2m_p[1]	Not applicable
	BD6	fmca_dp_c2m_n[1]	fmca_dp_c2m_n[1]
	BB5	fmca_dp_c2m_p[2]	Not applicable
	BB6	fmca_dp_c2m_n[2]
	BC3	fmca_dp_c2m_p[3]
	BC4	fmca_dp_c2m_n[3]
Sink	AW7	fmca_dp_m2c_p[0]	Not applicable	Not applicable
	AW8	fmca_dp_m2c_n[0]
	BA7	fmca_dp_m2c_p[1]
	BA8	fmca_dp_m2c_n[1]
	AY5	fmca_dp_m2c_p[2]	fmca_dp_m2c_p[0]
	AY6	fmca_dp_m2c_n[2]	fmca_dp_m2c_n[0]
	AV5	fmca_dp_m2c_p[3]	fmca_dp_m2c_p[1]	fmca_dp_m2c_p[0]
	AV6	fmca_dp_m2c_n[3]	fmca_dp_m2c_n[1]	fmca_dp_m2c_n[0]
Transceiver Avalon^® Memory-Mapped Interface Group	XCVR_RECONFIG_GROUP	Enable	Disable	Disable

Note: You can disable the non-applicable pin assignments in the Assignment Editor.

3. HDCP Over DisplayPort Design Example for Intel Arria 10 Devices

The HDCP over DisplayPort hardware design example helps you to evaluate the functionality of the HDCP feature and enables you to use the feature in your Intel^® Arria^® 10 designs.

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.

3.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.3 and HDCP Specification version 2.3.

The HDCP 1.3 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 29. HDCP IP Functions
HDCP IP	Functions
HDCP 1.3 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 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

3.2. HDCP Over DisplayPort Design Example Architecture

The HDCP feature protects data as the data is transmitted between devices connected through a DisplayPort 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 DisplayPort inputs and outputs. It instantiates the FIFO buffers to perform a direct DisplayPort video stream pass-through between the DisplayPort 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 13. HDCP Over DisplayPort Design Example Block Diagram

The following descriptions about the architecture of the design example correspond to the HDCP over DisplayPort design example block diagram. When SUPPORT HDCP KEY MANAGEMENT = 1, the design example hierarchy is slightly different from Figure 13 but the underlying HDCP functions remain the same.

The HDCP1x and HDCP2x are IPs that are available through the DisplayPort Intel^® FPGA IP parameter editor. When you configure the DisplayPort 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 DisplayPort IP configures itself in the cascade topology where the HDCP2x and HDCP1x IPs are connected back-to-back.
- The HDCP egress interface of the DisplayPort TX sends unencrypted audio video data.
- The unencrypted data gets encrypted by the active HDCP block and sent back into the DisplayPort 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 30. 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 DisplayPort AUX channel. The AUX controller is embedded within the DisplayPort IP.
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 DisplayPort application, the HDCP TX and HDCP RX IPs communicate the HDCP register values over the AUX channel. For a repeater application, the DisplayPort IP is configured in GPU mode where the HDCP registers in DPCD are defined in the embedded Nios^® II processor. The Nios^® II processor acts as an authentication master for the HDCP RX. The Nios^® II processor processes all HDCP register values received from the AUX controller in the DisplayPort sink before sending the values to the HDCP RX IP and vice versa.
In a true repeater demonstration where propagating topology information upstream is required, the Nios^® II processor drives the Repeater Message Port ( Avalon^® memory-mapped) of both HDCP2x and HDCP1x RX IPs. The Nios^® II processor clears the RX REPEATER bit to 0 when it detects the connected downstream device is not HDCP-capable or when no downstream device 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 device is HDCP-capable.

3.3. Nios II Processor Software Flow

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

Figure 14. Nios II Processor Software Flowchart

The VESA DisplayPort Standard v1.4 supports four link rates (1.62 Gbps, 2.7 Gbps, 5.4 Gbps and 8.1 Gbps). You can dynamically switch from one data rate to another. Transceiver reconfiguration is required to support dynamic link rate switching. The DisplayPort IP design example implements pre-calibration method to reduce the transceiver reconfiguration duration. Upon power-up or push button reset, the DisplayPort reconfiguration block initiates the transceiver reconfiguration to sweep across all supported link rates and all lane counts. After each data rate completes reconfiguration, each data rate recalibrates. After calibration for each data rate completes, the pre-defined calibrated registers will be stored according to the respective date rate.
When the precalibration step completes, the reconfiguration block is ready to start DisplayPort link training. Whenever the DisplayPort IP sends a new link rate request or hot-plug event, the reconfiguration block initiates reconfiguration to the transceiver. The reconfiguration flow includes retrieving the calibrated register offset value that corresponds to the link rate and reconfiguring the value to the transceiver. No recalibration is required. When reconfiguration completes, the transceiver is ready to receive the link rate and HDCP authentication can be initiated.
The Nios^® II software starts the HDCP activity by commanding the DisplayPort AUX controller to read RxCaps followed by Bcaps from external RX to detect if the downstream device is HDCP-capable, or otherwise:
- If the returned HDCP_CAPABLE bit of RxCaps is 1, the downstream device is HDCP2x-capable.
- If the returned HDCP_CAPABLE bit of Bcaps is 1, the downstream device is HDCP1x-capable.
- If the returned HDCP_CAPABLE bits of both RxCaps and Bcaps are 0, the downstream device is either not HDCP-capable or inactive.
- If the downstream device 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 device 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 processes the CP_IRQ interrupts if there is any, and reads the RxStatus register from external RX. If the software detects the REAUTH_REQ bit is set, it initiates re-authentication and disables TX encryption.
When the downstream device is a repeater and the READY bit of the RxStatus register is set to 1, this usually indicates the downstream device topology has changed. So, the Nios II software commands the AUX controller to read the ReceiverID_List from downstream device 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.
When the Nios^® II software encounters CP_IRQ interrupts, it 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 device is a repeater and the READY bit of the Bcaps register is set to 1, this usually indicates that the downstream device topology has changed. So, the Nios^® II software commands the AUX controller to read the KSV list value from the downstream device 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.

3.4. Design Walkthrough

Setting up and running the HDCP over DisplayPort design example consists of five stages.

Set up the hardware.
Generate the design.
Edit the HDCP key memory files to include your HDCP production keys.
1. Store plain HDCP production keys in the FPGA (Support HDCP Key Management = 0)
2. Store encrypted HDCP production keys in the external flash memory or EEPROM (Support HDCP Key Management = 1)
Compile the design.
View the results.

3.4.1. Set Up the Hardware

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

To set up the hardware for the demonstration:

Connect the Bitec DisplayPort FMC daughter card (revision 10) to the Intel^® Arria^® 10 development kit at FMC port A.
Connect the Intel^® Arria^® 10 development kit to your PC using a USB cable.
Connect a DisplayPort cable from the DisplayPort RX connector on the Bitec DisplayPort FMC daughter card to an HDCP-enabled DisplayPort device, such as a graphic card with DisplayPort output.
Connect another DisplayPort cable from the DisplayPort TX connector on the Bitec DisplayPort FMC daughter card to an HDCP-enabled DisplayPort device, such as a display monitor with DisplayPort input.

3.4.2. Generate the Design

Use the DisplayPort Intel^® FPGA IP parameter editor in the Intel^® Quartus^® Prime Pro Edition software to generate the design example.

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

Click Tools > IP Catalog, and select Intel^® Arria^® 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 DisplayPort 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.
You may select a specific device in the Device field, or keep the default software device selection.
Click OK. The parameter editor appears.
Configure the desired parameters for both TX and RX

Note: To enable the HDCP feature on RX, turn on the Enable GPU Mode parameter.
Turn on Support HDCP Key Management parameter if you want to store the HDCP production key in an encrypted format in the external flash memory or EEPROM. Otherwise, turn off this parameter to store the HDCP production key in plain format in the FPGA.
On the Design Example tab, select DisplayPort SST Parallel Loopback With PCR.
Select Synthesis to generate the hardware design example.
For Target Development Kit, select Arria 10 GX FPGA Development Kit. If you select the development kit, then the target device (selected in step 4) changes to match the device on the development kit. For Arria 10 GX FPGA Development Kit, the default device is 10AX115S2F45I1SG.
Click Generate Example Design to generate the project files and the software Executable and Linking Format (ELF) programming file.

3.4.3. Include HDCP Production Keys

3.4.3.1. Store plain HDCP production keys in the FPGA (Support HDCP Key Management = 0)

After generating the design, you need to 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 15. Wire Array of Facsimile Key R1 for Receiver Public Certificate

Figure 16. 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 17. 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 (a10_dp_demo.v ).

3.4.3.2. Store encrypted HDCP production keys in the external flash memory or EEPROM (Support HDCP Key Management = 1)

Figure 18. High Level Overview of HDCP Key Management

When Support HDCP Key Management parameter is turned on, you hold control of HDCP production key encryption by using the key encryption (KEYENC) design that Intel provides. You must provide the HDCP production keys and a 128 bits HDCP protection key. The HDCP protection key encrypts the HDCP production key and the encrypted key is stored in the external flash memory (ie. EEPROM) on DisplayPort daughter card.

Turn on the Support HDCP Key Management parameter and the key decryption feature (KEYDEC) becomes available in the HDCP IP cores. You must use the same HDCP protection key in the KEYDEC to retrieve the HDCP production keys at run time for processing engines. KEYENC and KEYDEC support Atmel AT24CS32 32-Kbit serial EEPROM, Atmel AT24C16A 16-Kbit serial EEPROM and compatible I2C EEPROM devices with at least 16-Kbit rom size.

To include the HDCP production keys in the KEYENC design and program the encrypted HDCP production keys onto the EEPROM, follow these steps:

Copy the hardware demonstration files from the following path to your working directory: <IP Root Directory>/hdcp2x/hw_demo/key_encryption/<Device Family Name>
Locate the top level design file (<Device Family Name>_hdcp_key_encryption.v) in the rtl/ directory and modify the parameter DAUGHTER_CARD_TYPE to 1.
Locate the software file (main.c) in the software/key_encrypt_src/ directory and modify the software parameter #EEPROM_REVISION to 1.
Locate the software header file (hdcp_keys.h) in the software/key_encrypt_src/ directory and include your HDCP production keys and HDCP protection key in big endian format as shown in the examples below.
Figure 19. Data array of Facsimile Key R1 for RX Private Key

Figure 20. Data arrays of HDCP Production Keys (Placeholder)

Figure 21. Data array of HDCP Protection Key (Predefined key)
Run ./runall.tcl. This script executes the following commands:
- Generate IP catalog files
- Generate the Platform Designer system
- Create an Intel^® Quartus^® Prime project
- Create a software workspace and build the software
- Perform a full compilation
Download the Software Object File (.sof) to the FPGA to program the encrypted HDCP production keys onto the EEPROM.
To generate the EEPROM image file, edit the read_mem.tcl to make sure the hardware_name and device_name are matching to the running hardware.
Run "quartus_stp -t read_mem.tcl". The script generates an EEPROM image file in .hex file format under the same directory.

Generate the DisplayPort SST Parallel Loopback With PCR design example with Support HDCP 2.3 and Support HDCP 1.4 parameters turned on, then follow these steps to include the HDCP protection key.

Locate the following Memory Initialization Files (.mif) in the <project directory>/rtl/hdcp/ directory:
- hdcp2x_rx_kmem.mif
- hdcp2x_tx_kmem.mif
- hdcp1x_rx_kmem.mif
- hdcp1x_tx_kmem.mif
Open the hdcp2x_rx_kmem.mif file. Locate the predefined HDCP protection key as shown in the example below and replace with your HDCP protection key in big endian format.
Figure 22. HDCP protection key initialized in hdcp2x_rx_kmem.mif
Repeat Step 2 for the other memory initialization files as shown in the examples below.
Figure 23. HDCP protection key initialized in hdcp2x_tx_kmem.mif

Figure 24. HDCP protection key initialized in hdcp1x_rx_kmem.mif

Figure 25. HDCP protection key initialized in hdcp1x_tx_kmem.mif

3.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/a10_dp_demo.qpf .

Note: To support all Bitec DisplayPort FMC daughter card revisions, the design example top level RTL file at <project directory>/rtl/a10_dp_demo.v and the software config.h file include a local parameter for you to select the FMC revision. The default value is 1. If the config.h file is updated, you must run build_sw_hdcp.sh in the script folder before compiling the Intel^® Quartus^® Prime project to ensure the software is effective.
Click Processing > Start Compilation.

3.4.5. View the Results

At the end of the demonstration, you will be able to view the results on the HDCP-enabled DisplayPort 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/ directory.
Type the following command on the Nios II Command Shell to download the Software Object File (.sof) to the FPGA.
nios2-configure-sof <Intel Quartus Prime project name>.sof
Power up the HDCP-enabled DisplayPort external source and sink (if you have not done so). The DisplayPort external sink displays the output of your DisplayPort external source.

3.4.5.1. LED Functions

The LEDs on the board indicates the demonstration status.

Table 31. LED Indicators
LED	Functions
user_led[0]	RX PHY ready status. 0: Not ready 1: Ready
user_led[1]	RX DisplayPort IP video lock status 0: Unlocked 1: Locked
user_led[2]	RX HDCP1x IP decryption status. 0: Inactive 1: Active
user_led[3]	RX HDCP2x IP decryption status. 0: Inactive 1: Active
user_led[5:4]	TX data rate. 2'b00: RBR 2'b01: HBR 2'b10: HBR2 2'b11: HBR3
user_led[6]	TX HDCP1x IP encryption status. 0: Inactive 1: Active
user_led[7]	TX HDCP2x IP encryption status. 0: Inactive 1: Active

3.5. Protection of Encryption Key Embedded in FPGA Design

Many FPGA designs implement encryption, and there is often the need to embed secret keys in the FPGA bitstream. In newer device families, such as Intel^® Stratix^® 10 and Intel Agilex, there is a Secure Device Manager block that can securely provision and manage these secret keys. Where these features do not exist, you can secure the content of the FPGA bitstream, including any embedded secret user keys, with encryption.

You can keep the user keys secure within your design environment, and ideally add to the design using an automated secure process. The following steps show how you can implement such a process with Intel^® Quartus^® Prime tools.

Develop and optimize the HDL in Intel^® Quartus^® Prime in a non-secure environment.
Transfer the design to a secure environment and implement an automated process to update the secret key. The on-chip memory embed the key value. When the key is updated, the memory initialization file (.mif) can change and the “quartus_cdb --update_mif” assembler flow can change the HDCP protection key without re-compiling. This step is very quick to run and preserves the original timing.
The Intel^® Quartus^® Prime bitstream would then encrypt with the FPGA key before transferring the encrypted bitstream back to the non-secure environment for final testing and deployment.

It is recommended to disable all debug access that can recover the secret key from the FPGA. You can disable the debug capabilities completely by disabling the JTAG port, or selectively disable and review that no debug features such as in-system memory editor or Signal Tap can recover the key. Refer to AN556 for further information on using FPGA security features including specific steps on how to encrypt the FPGA bitstream and configure security options such as disabling JTAG access.

Note: You can consider the additional step of obfuscation or encryption with another key of the secret key in the MIF storage.

3.6. 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 rx_hdcp1_enabled or rx_hdcp2_enabled from the RX IP is asserted) and the transmitted video is not HDCP-encrypted (i.e. encryption status tx_hdcp1_enabled or tx_hdcp2_enabled from the TX IP is not asserted).
- If the received video is HDCP TYPE 1 (i.e. rx_streamid_type from the RX IP is asserted) and the transmitted video is HDCP 1.3 encrypted (i.e. encryption status tx_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.

3.7. Debug Guidelines

3.7.1. HDCP Status Signals

There are several signals that are useful to identify the working condition of the HDCP IP cores. These signals are available at the design example top-level and are tied to the onboard LEDs:

Table 32. Signal Name
Signal Name	Function
rx_hdcp1_enabled	RX HDCP1x IP Decryption Status 0: Inactive 1: Active
rx_hdcp2_enabled	RX HDCP2x IP Decryption Status 0: Inactive 1: Active
tx_hdcp1_enabled	TX HDCP1x IP Encryption Status 0: Inactive 1: Active
tx_hdcp2_enabled	TX HDCP2x IP Encryption Status 0: Inactive 1: Active

Refer to Table 31 for their respective LED placements.

The active state of these signals indicates that the HDCP IP is authenticated and receiving/sending encrypted video stream. For each direction, only HDCP1x or HDCP2x encryption/decryption status signals is active. For example, if either rx_hdcp1_enabled or rx_hdcp2_enabled is active, the HDCP on the RX side is enabled and decrypting the encrypted video stream from the upstream video source.

3.7.2. Modifying HDCP Software Parameters

To facilitate the HDCP debugging process, you can modify the parameters in hdcp.c. Table below summarizes the list of configurable parameters and their functions.

Parameter	Function
SUPPORT_HDCP1X	Enable HDCP 1.3 on TX side
SUPPORT_HDCP2X	Enable HDCP 2.3 on TX side
DEBUG_MODE_HDCP	Enable debug messages for TX HDCP
REPEATER_MODE	Enable repeater mode for HDCP design example

To modify the parameters, change the values to the desired values in hdcp.c. Before starting the compilation, make the following change in the build_sw_hdcp.sh:

Locate the following line and comment it out to prevent the modified software file being replaced by the original files from the Intel^® Quartus^® Prime Software installation path.
Run “./build_sw_hdcp.sh” to compile the updated software.
The generated .elf file can be included into the design through two methods:
1. Run “nios2-download -g <elf file name>”. Reset the system after the downloading process is completed to ensure proper functionality.
2. Run “quartus_cdb –-update_mif” to update the memory initialization files. Run assembler to generate new .sof file which includes the updated software

3.7.3. HDCP Key Mapping from DCP Key Files

This section describes the mapping of the HDCP production keys stored in DCP key files into the wire array of the HDCP kmem files.

3.7.3.1. hdcp1x_tx_kmem.v and hdcp1x_rx_kmem.v files

For hdcp1x_tx_kmem.v and hdcp1x_rx_kmem.v files

These two files are sharing the same format
To identify the correct HDCP1 TX DCP key file for hdcp1x_tx_kmem.v, make sure the first 4 bytes of the file are “0x01, 0x00, 0x00, 0x00”.
To identify the correct HDCP1 RX DCP key file for hdcp1x_rx_kmem.v, make sure the first 4 bytes of the file are “0x02, 0x00, 0x00, 0x00”.
The keys in the DCP key files are in little-endian format. To use in kmem files, you must convert them into big-endian.

Figure 26. Byte mapping from HDCP1 TX DCP key file into hdcp1x_tx_kmem.v

This figure shows the exact byte mapping from HDCP1 TX DCP key file into hdcp1x_tx_kmem.v. The same mapping applies to hdcp1x_rx_kmem.v.

Note: The byte number displays in below format:

Key size in bytes * key number + byte number in current row + constant offset + row size in bytes * row number
308*n indicates that each key set has 308 bytes.
7*y indicates that each row has 7 bytes.

Figure 27. HDCP1 TX DCP key file filling with junk values

Figure 28. Wire Arrays of hdcp1x_tx_kmem.v

Example of hdcp1x_tx_kmem.v and how its wire arrays map to the example of HDCP1 TX DCP key file in Figure 27

3.7.3.2. hdcp2x_rx_kmem.v file

For hdcp2x_rx_kmem.v file

To identify the correct HDCP2 RX DCP key file for hdcp2x_rx_kmem.v, make sure the first 4 bytes of the file are “0x00, 0x00, 0x00, 0x02”.
The keys in the DCP key files are in little-endian format

Figure 29. Byte mapping from HDCP2 RX DCP key file into hdcp2x_rx_kmem.v

Figure below shows the exact byte mapping from HDCP2 RX DCP key file into hdcp2x_rx_kmem.v

Note: The byte number displays in below format:

Key size in bytes * key number + byte number in current row + constant offset + row size in bytes * row number
862*n indicates that each key set has 862 bytes.
16*y indicates that each row has 16 bytes. There is an exception in cert_rx_prod where ROW 32 has only 10 bytes.

Figure 30. HDCP2 RX DCP key file filling with junk values

Figure 31. Wire Arrays of hdcp2x_rx_kmem.v

This figure shows the wire arrays for hdcp2x_rx_kmem.v (cert_rx_prod, kprivrx_qinv_prod, and lc128_prod) map to the example of HDCP2 RX DCP key file in Figure 30

3.7.3.3. hdcp2x_tx_kmem.v file

For hdcp2x_tx_kmem.v file:

To identify the correct HDCP2 TX DCP key file for hdcp2x_tx_kmem.v, make sure the first 4 bytes of the file are “0x00, 0x00, 0x00, 0x01”.
The keys in the DCP key files are in little-endian format.
Alternatively, you can apply the lc128_prod from hdcp2x_rx_kmem.v directly into hdcp2x_tx_kmem.v. The keys share the same values.
Figure 32. Wire array of hdcp2x_tx_kmem.v

This figure shows the exact byte mapping from HDCP2 TX DCP key file into hdcp2x_tx_kmem.v

3.7.4. Frequently Asked Questions (FAQ)

Table 33. Failure Symptoms and Guidelines
Number	Failure Symptom	Guideline
1.	The RX is receiving encrypted video, but the TX is sending a static video in blue or black colour.	This is due to the unsuccessful TX authentication with external sink. A HDCP-capable repeater must not transmit the video in unencrypted format if the incoming video from the upstream is encrypted. To achieve this, a static video in blue or black colour replaces the outgoing video when the TX HDCP encryption status signal is inactive while the RX HDCP decryption status signal is active. For the exact guidelines, refer to Security Considerations. However, this behaviour may deter the debugging process when enabling the HDCP design. Below is the method to disable the video blocking in the design example: Locate the following port connection at the top level of the design example. This port belongs to the hdmi_tx_top module. Modify the port connection into the following line:
2.	TX HDCP encryption status signal is active but snow picture is displayed at the downstream sink.	This is due to the downstream sink does not decrypt the outgoing encrypted video correctly. Make sure you provide the global constant (LC128) to the TX HDCP IP. The value must be the production value and correct.
3.	TX HDCP encryption status signal is unstable or always inactive.	This is due to the unsuccessful TX authentication with downstream sink. To facilitate the debugging process, you can enable the DEBUG_MODE_HDCP parameter in hdcp.c. Refer to Modifying HDCP Software Parameters on the guidelines. The following 3a-3c are the possible causes of unsuccessful TX authentication.
3a.	The software debug log keeps printing this message “HDCP 1.4 is not supported by the downstream (Rx)”.	The message indicates the downstream sink does not support both HDCP 2.3 and HDCP 1.3. Make sure the downstream sink supports HDCP 2.3 or HDCP 1.3.
3b.	TX authentication fails halfway.	This is due to any part of the TX authentication such as signature verification, locality check etc can fail. Make sure the downstream sink is using production key but not facsimile key.
3c.	The software debug log keeps printing “Re-authentication is required” after the HDCP authentication is completed.	This message indicates the downstream sink has requested re-authentication because the received video was not decrypted correctly. Make sure you provide the global constant (LC128) to the TX HDCP IP. The value must be the production value and the value is correct.
4	RX HDCP decryption status signal is inactive although the upstream source has enabled HDCP.	This indicates that the RX HDCP IP has not achieved the authenticated state. By default, the REPEATER_MODE parameter is enabled in the design example. If the REPEATER_MODE is enabled, make sure the TX HDCP IP is authenticated. When the REPEATER_MODE parameter is enabled, the RX HDCP IP attempts authentication as a repeater if the TX is connected to a HDCP-capable sink. The authentication stops halfway while waiting for the TX HDCP IP to complete the authentication with downstream sink and pass the RECEIVERID_LIST to the RX HDCP IP. Timeout as defined in the HDCP Specification is 2 seconds. If the TX HDCP IP is unable to complete the authentication in this period, the upstream source treats the authentication as fail and initiates re-authentication as specified in the HDCP Specification. Note: Refer to Modifying HDCP Software Parameters for the method to disable the REPEATER_MODE parameter for debugging purpose. After disabling the REPEATER_MODE parameter, the RX HDCP IP always attempt authentication as an endpoint receiver. The TX HDCP IP does not gate the authentication process. If the REPEATER_MODE parameter is not enabled, make sure the HDCP key provided to the HDCP IP is the production value and the value is correct.
5	RX HDCP decryption status signal is unstable.	This means the RX HDCP IP has requested re-authentication right after the authenticated state is achieved. This is probably due to the incoming encrypted video is not decrypted correctly by the RX HDCP IP. Make sure the global constant (LC128) provided to the RX HDCP IP core is production value and the value is correct.

4. DisplayPort Intel Arria 10 FPGA IP Design Example User Guide Archives

IP versions are the same as the Intel^® Quartus^® Prime Design Suite software versions up to 19.1. From Intel^® Quartus^® Prime Design Suite software version 19.2 or later, IP cores have a new IP versioning scheme.

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.4.0	DisplayPort Intel Arria 10 FPGA IP Design Example User Guide
20.1	19.3.0	DisplayPort Intel Arria 10 FPGA IP Design Example User Guide
19.2	19.1.0	DisplayPort Intel Arria 10 FPGA IP Design Example User Guide
19.1	19.1	DisplayPort Intel Arria 10 FPGA IP Design Example User Guide
17.1	17.1	Intel FPGA DisplayPort IP Core Design Example for Arria 10 Devices User Guide
17.0	17.0	Intel Arria 10 DisplayPort IP Core Design Example User Guide
16.1	16.1	DisplayPort IP Core Design Example User Guide

5. Revision History for DisplayPort Intel Arria 10 FPGA IP Design Example User Guide

Document Version	Intel^® Quartus^® Prime Version	Intel^® FPGA IP Version	Changes
2021.05.11	21.1	19.4.0	Added SUPPORT HDCP KEY MANAGEMENT = 1 to the description for Figure : HDCP Over DisplayPort Design Example Block Diagram. Added the steps in HDCP over DisplayPort design example in Design Walkthrough. Added the step to turn on Support HDCP Key Management parameter in Generate the Design. Added a new subsection Store encrypted HDCP production keys in the external flash memory or EEPROM (Support HDCP Key Management = 1). Added a new chapter Protection of Encryption Key Embedded in FPGA Design. Added a new chapter Debug Guidelines and subsection HDCP Status Signals, Modifying HDCP Software Parameter, and Frequently Asked Questions.
2020.09.28	20.3	19.4.0	Updated and renamed the Configuring Single or Dual Lanes section to Transceiver Lane Configurations. Added pin assignments for Bitec FMC revision 10 in the Transceiver Lane Configurations section. Updated the pin assignments for Bitec FMC revision 8 or earlier, and revision 11 with transceiver Avalon^® memory-mapped interface group information in the Transceiver Lane Configurations section.
2020.04.13	20.1	19.3.0	Updated the Bitec DisplayPort card revision and the IP version in the local parameter in the RTL file at `<project directory>`/rtl/a10_dp_demo.v and the software config.h file in the Compiling and Testing the Design section. Updated the description for the `fmca_la_tx_n_12` signal and added a new signal, `fmca_la_tx_p_14` for DisplayPort FMC daughter card pins in the Interface Signals and Parameters section for DisplayPort loopback design examples. Replaced the description about the Parade Tech PS8460 Retimer signals with the FMC On-board Retimer Reconfiguration Interface signals in the Interface Signals and Parameters section for DisplayPort loopback design examples. Added information about the HDCP design example in the HDCP Over DisplayPort Design Examples section. This information is removed from the DisplayPort Intel^® FPGA IP User Guide.
2019.07.30	19.2	19.1.0	Added information about the DisplayPort MST parallel loopback with and without a PCR module design examples in the DisplayPort Intel^® FPGA IP Design Example Quick Start Guide section. Updated the files and folders in the Directory Structure section. Added support for the Bitec DisplayPort FMC daughter card revision 11 in the Hardware and Software Requirements section. Added information about the DisplayPort MST parallel loopback with and without a PCR module design examples in the Generating the Design, DisplayPort Intel^® FPGA IP Design Example Parameters, and DisplayPort Intel^® FPGA IP Design Example Detailed Description sections. Updated the Regenerating ELF File section to include information about WSL and provided a link to the Nios II Software Developer Handbook. Updated the Compiling and Testing the Design section to include information about the Bitec DisplayPort FMC daughter card revision 11 and channel mapping. Updated the Configuring Single or Dual Lanes section with information about the Bitec DisplayPort FMC daughter card revision 11.
2019.04.05	19.1	19.1	Renamed Intel FPGA DisplayPort to DisplayPort Intel^® FPGA IP . Updated the Directory Structure section to add the Xcelium* Parallel simulator files. Added instructions to run simulation using the Xcelium* Parallel simulator in the Simulation the Design section. Edited the DisplayPort Design Example Supported EDA Simulators table in the Simulation Testbench section to include Xcelium* Parallel simulator and the supported platforms. Removed the `/altera_avalon_i2c` file from the Directory Structure section. It is not added in the core folder. Moved the .c and .h software files to a new folder in the Directory Structure section. These files are now in the dp_demo subfolder in version 19.1 of the DisplayPort Intel^® FPGA IP . Updated the Bitec DisplayPort FMC daughter card local parameter in the Compiling and Testing the Design section. Edited the note about CRC calculation in the Simulation Testbench section. To ensure CRC is calculated, you must enable the Support CTS test automation parameter. Updated the frequency rate for HBR quad symbols per clock to 67.5 for the RX and TX Transceiver Clockout descriptions in the Clocking Scheme section. Added the Intel^® Arria^® 10 DisplayPort SST Parallel Loopback with Adaptive Sync Support section to provide guidelines to add the Adaptive Sync feature, Added the Configuring Single or Dual Lanes section to provide guidelines to make the correct pin assignments for single and dual lanes. Added a link to AN 883: Intel Arria 10 DisplayPort TX-only Design in the Creating RX-only or TX-only Designs section. This application note provides information about how to create TX-only designs to transmit 4Kp60 video output generated by the Test Pattern Generator II Intel FPGA IP.

Date	Version	Changes
November 2017	2017.11.06	Renamed DisplayPort IP core to Intel FPGA DisplayPort IP as per Intel rebranding. Changed the term Qsys to Platform Designer. Renamed the design examples to DisplayPort SST Parallel Loopback With PCR and DisplayPort SST Parallel Loopback Without PCR. Updated information that the Intel FPGA DisplayPort IP core now conforms to VESA DisplayPort Standard version 1.4. Added data link rate support for HBR3 (8.10 Gbps). This rate is available only in quad symbols per clock for Intel^® Arria^® 10 devices in Intel^® Quartus^® Prime Pro Edition. Added new pins for DisplayPort FMC Daughter Card Pins on FMC Port A. Added a link for workaround to avoid jitter of PLL cascading or non-dedicated clock paths for Intel^® Arria^® 10 PLL reference clock.
May 2017	2017.05.08	Rebranded as Intel. Changed the part number. Added files designated for Intel^® Quartus^® Prime Pro Edition. Added information for a new design example variant: Arria 10 DP SST Parallel Loopback Without PCR. Added information about the new TX video image interface. Edited the function description for USER_LED[5:1]. The actual lane count should be 4'b0010 = 2 lanes and 4'b0100 = 4 lanes. Added information about DisplayPort transceiver reconfiguration flow. Added guidelines to regenerate .elf file. Added link to archived version of the Arria 10 DisplayPort IP Core Design Example User Guide.
October 2016	2016.10.31	Initial release.