DisplayPort Intel Arria 10 FPGA IP Design Example User Guide
Version Information
Updated for: |
---|
Intel® Quartus® Prime Design Suite 20.3 |
IP Version 19.4.0 |
1. DisplayPort Intel FPGA IP Design Example Quick Start Guide
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 DisplayPortNote: 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.
1.1. Directory Structure
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 | |
|
|
|
|
|
|
<Platform Designer generated folder> | |
core |
|
|
|
|
|
<Platform Designer generated folder> | |
rx_phy |
|
|
|
/rx_phy_top.v | |
<Platform Designer generated folder> | |
tx_phy |
|
|
|
|
|
/tx_phy_top.v | |
<Platform Designer generated folder> |
Folders | Files |
---|---|
aldec | /aldec.do |
/rivierapro_setup.tcl | |
cadence | /cds.lib |
/hdl.var | |
/ncsim.sh | |
/ncsim_setup.sh | |
<cds_libs folder> | |
core |
|
|
|
|
|
<Platform Designer generated folder> | |
mentor | /mentor.do |
/msim_setup.tcl | |
rx_phy |
|
/rx_phy_top.v | |
|
|
<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 |
|
<Platform Designer generated folder> | |
|
|
|
|
/tx_phy_top.v | |
xcelium | /cds.lib |
/hdl.var | |
/xcelium_sim.sh | |
/xcelium_setup.sh | |
<cds_libs folder> |
1.2. Hardware and Software Requirements
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
-
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
- 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, typevsim -c -do aldec.do
ModelSim* /simulation/mentor In the command line, typevsim -c -do mentor.do
NCSim /simulation/cadence In the command line, typesource ncsim.sh
Xcelium* /simulation/xcelium In the command line, typesource xcelium.sh
VCS* /simulation/synopsys/vcs In the command line, typesource vcs_sim.sh
VCS* MX /simulation/synopsys/vcsmx In the command line, typesource 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
- 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
- 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
Parameter |
Value |
Description |
---|---|---|
Available Design Example |
||
Select Design |
|
Select the design example to be generated.
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 |
|
Select the board for the targeted
design example.
|
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
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 |
2.1. Intel Arria 10 DisplayPort SST Parallel Loopback Design Features
- 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.
- 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.
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
- 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.
- 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.
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
- 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
- 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.
User Requirement | Preserve | Remove | Add |
---|---|---|---|
DisplayPort RX Only | RX PHY Top; Core System consists of:
|
|
– |
DisplayPort TX Only | TX PHY Top; Core System consists of:
|
|
Video Pattern Generator |
2.5. Design 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:
|
RX Sub-System (Platform Designer) |
The RX sub-system consists of:
|
TX Sub-System (Platform Designer) |
The TX sub-system consists of:
|
Module | Description |
---|---|
RX PHY Top |
The RX PHY top level consists of the components
related to the receiver PHY layer.
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.
Note: 8.1 Gbps is available only in the
Intel®
Quartus® Prime Pro Edition
software.
|
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.
|
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.
|
2.6. Clocking Scheme
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 | ||
4 (quad) | 40.5 | |||
HBR (2.7 Gbps) |
2 (dual) | 135 | ||
4 (quad) | 67.5 | |||
HBR2 (5.4 Gbps) |
2 (dual) | 270 | ||
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 | ||
4 (quad) | 40.5 | |||
HBR (2.7 Gbps) |
2 (dual) | 135 | ||
4 (quad) | 67.5 | |||
HBR2 (5.4 Gbps) |
2 (dual) | 270 | ||
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
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
|
fmca_la_rx_n_8 |
Input |
1 |
DisplayPort RX power detect
|
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
|
fmca_la_rx_n_9 |
Input |
1 |
DisplayPort TX HPD
|
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 |
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
|
dp_rx_dp_sink_rx_link_rate_8bits |
Output |
8 |
RX Link Rate 8-bit indicator, used in transceiver reconfiguration management
|
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 |
B*P*3 | |
dp_rx_dp_sink_rx_vid_valid |
Output |
P | |
dp_rx_dp_sink_rx_parallel_data |
Input |
N *S*10 |
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
|
dp_tx_dp_source_tx_link_rate_8bits |
Output |
8 |
TX Link Rate 8-bit indicator, used in transceiver reconfiguration management
|
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 |
B*P*3 | |
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 |
B*P*3 | |
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 |
N*S*10 |
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 |
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 |
N*S*10 |
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 |
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.
|
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 |
N*S*10 |
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 |
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 |
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 |
B*P*3 |
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 |
B*P*3 |
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 |
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.
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
- 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.
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.
|
USER_LED[7:6] | These LEDs indicate the RX link rate.
|
2.9. Simulation Testbench
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 |
---|---|
|
Integrates Frequency Checker to measure the Link Speed clock's frequency output from the TX and RX transceiver. |
|
|

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 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.
- 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.
- For TX FPLL, these register offsets are reconfigured:
- 10 ’h12B (TXPLL M Counter)
- 10 ’h12C (TXPLL L Counter)
- For RX
CDR,
these register offsets are reconfigured:
- 10 ’h13a (RX L PFD and PD Counter)
- 10 ’h13b (RX M Counter)
- For TX FPLL, these register offsets are reconfigured:
- 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.
- 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
- 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)
- For TX FPLL, these register offsets are recalibrated:
- 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
- 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.
3.1. High-bandwidth Digital Content Protection (HDCP)
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.
HDCP IP | Functions |
---|---|
HDCP 1.3 IP |
|
HDCP 2.3 IP |
|
3.2. HDCP Over DisplayPort Design Example Architecture
- 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.
The following descriptions about the architecture of the design example correspond to the HDCP over DisplayPort design example block diagram.
- 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) RX - 16 bytes (same as TX): Global Constant (lc128)
- 320 bytes: RSA Private Key (kprivrx)
- 522 bytes: RSA Public Key Certificate (certrx)
HDCP1x TX - 5 bytes: TX Key Selection Vector (Aksv)
- 280 bytes: TX Private Device Keys (Akeys)
RX - 5 bytes: RX Key Selection Vector (Bksv)
- 280 bytes: RX Private Device Keys (Bkeys)
The design example implements the key memories as simple dual-port, dual-clock synchronous RAM. For small key size like HDCP2x TX, the IP implements the key memory using registers in regular logic.
Note: Intel does not provide the HDCP production keys with the design example or Intel FPGA IPs under any circumstances. To use the HDCP IPs or the design example, you must become an HDCP adopter and acquire the production keys directly from the Digital Content Protection LLC (DCP).To run the design example, you either edit the key memory files at compile time to include the production keys or implement logic blocks to securely read the production keys from an external storage device and write them into the key memories at run time.
- 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.
- 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
- Set up the hardware.
- Generate the design.
- Edit the HDCP key memory files to include your HDCP production keys.
- Compile the design.
- View the results.
3.4.1. 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
-
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.
- 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
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 CertificateFigure 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.4. 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
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
LED | Functions |
---|---|
user_led[0] |
RX
PHY
ready status.
|
user_led[1] |
RX DisplayPort
IP
video lock status
|
user_led[2] |
RX HDCP1x IP decryption status.
|
user_led[3] |
RX HDCP2x IP decryption status.
|
user_led[5:4] |
TX
data
rate.
|
user_led[6] |
TX HDCP1x IP encryption status.
|
user_led[7] |
TX HDCP2x IP encryption status.
|
3.5. 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.
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.
Intel® Quartus® Prime Version | IP Core Version | 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 |
---|---|---|---|
2020.09.28 | 20.3 | 19.4.0 |
|
2020.04.13 | 20.1 | 19.3.0 |
|
2019.07.30 | 19.2 | 19.1.0 |
|
2019.04.05 | 19.1 | 19.1 |
|
Date | Version | Changes |
---|---|---|
November 2017 | 2017.11.06 |
|
May 2017 | 2017.05.08 |
|
October 2016 | 2016.10.31 | Initial release. |