DisplayPort Intel FPGA IP User Guide
Version Information
Updated for: |
---|
Intel® Quartus® Prime Design Suite 20.2 |
IP Version 19.3.0 |
1. DisplayPort Intel FPGA IP Quick Reference
The DisplayPort Intel® FPGA IP provides support for next-generation video display interface technology.
The DisplayPort Intel® FPGA IP is part of the Intel® FPGA IP Library, which is distributed with the Intel® Quartus® Prime software..
Information |
Description |
|
---|---|---|
IP Core Information |
Core Features |
|
Typical Application |
|
|
Device Family Support |
Intel® Stratix® 10 (H-tile and L-tile), Intel® Arria® 10, Intel® Cyclone® 10 GX, Arria V, Cyclone® V, and Stratix® V FPGA devices. |
|
Design Tools |
|
1.1. DisplayPort Terms and Acronyms
Acronym | Description |
---|---|
API | Application Programming Interface |
AUX | Auxiliary |
bpc | Bits per Component |
bpp | Bits per Pixel |
BE | Blanking End |
BS | Blanking Start |
DP | DisplayPort |
DPCD | DisplayPort Configuration Data |
eDP | Embedded DisplayPort |
EDID | Enhanced Display Identification Data |
GPU | Graphics Processor Unit |
HBR | High Bit Rate (2.7 Gbps per lane) |
HBR2 | High Bit Rate 2 (5.4 Gbps per lane) |
HBR3 | High Bit Rate 3 (8.1 Gbps per lane) |
HPD | Hot Plug Detect |
MST | Multi-Stream Transport |
Maud | M value for audio |
Mvid | M value for video |
Naud | N value for audio |
Nvid | N value for video |
RBR | Reduced Bit Rate (1.62 Gbps per lane) |
RGB | Red Green Blue |
RX | Receiver |
SDP | Secondary-Data Packet |
SE | SDP End |
SR | Scrambler Reset |
SS | SDP Start |
SST | Single-Stream Transport |
TX | Transmitter |
Term | Definition |
---|---|
Link Symbol Clock (LSym_Clk) | Link Symbol clock frequency (f_LSym_Clk) across link rate: -
Note:
LSym_Clk is
equivalent to LS_Clk in VESA DisplayPort
Standard version 1.4.
|
Link Speed Clock (ls_clk) |
Transceiver recovered clock out. Link Speed clock frequency equals: f_LSym_Clk / SYMBOLS_PER_CLOCK. |
Stream Clock or Pixel Clock (Strm_Clk) |
Used for transferring stream data into a DisplayPort transmitter within a DisplayPort Source device or from a DisplayPort receiver within a DP Sink device. Video and audio (optional) are likely to have separate stream clocks. Stream clock frequency (f_Strm_Clk) represent the pixel rate. For example, f_Strm_Clk for 1080p60 (CEA-861-F VIC16) is 148.5 Mhz. |
Video Clock (vid_clk) |
Video clock frequency equals: f_Strm_Clk / PIXELS_PER_CLOCK |
2. About This IP
This document describes the DisplayPort Intel® FPGA IP, which provides support for next-generation video display interface technology. The Video Electronics Standards Association (VESA) defines the DisplayPort standard as an open digital communications interface for use in internal connections such as:
- Interfaces within a PC or monitor
- External display connections, including interfaces between a PC and monitor or projector, between a PC and TV, or between a device such as a DVD player and TV display
The DisplayPort Intel® FPGA IP supports scalable Main Link with 1, 2, or 4 lanes, with 4 selectable data rates on each lane: 1.62 Gbps, 2.7 Gbps, 5.4 Gbps, and 8.1 Gbps.
Main Link transports video and audio streams with embedded clocking to decoupled pixel and audio clocks from the transmission clock. The IP transmits Main Link's data in scrambled ANSI 8B/10B format and includes redundancy in the data transmission for error detection. For secondary data, such as audio, the IP uses Solomon Reed coding for error detection.
The DisplayPort's AUX channel consists of an AC-coupled terminated differential pair. AUX channel uses Manchester II coding for its channel coding and provides a data rate of 1 Mbps. Each transaction takes less than 500 µs with a maximum burst data size of 16 bytes.
2.1. Release Information
Intel® FPGA IP versions match the Intel® Quartus® Prime Design Suite software versions until v19.1. Starting in Intel® Quartus® Prime Design Suite software version 19.2, Intel® FPGA IP has a new versioning scheme.
The Intel® FPGA IP version (X.Y.Z) number can change with each Intel® Quartus® Prime software version. A change in:
- X indicates a major revision of the IP. If you update the Intel® Quartus® Prime software, you must regenerate the IP.
- Y indicates the IP includes new features. Regenerate your IP to include these new features.
- Z indicates the IP includes minor changes. Regenerate your IP to include these changes.
Item |
Description |
---|---|
IP Version |
19.3.0 |
Intel® Quartus® Prime Version | 20.2 |
Release Date |
2020.06.22 |
Ordering Code |
IP-DP |
2.2. Device Family Support
Device Family | Support Level |
---|---|
Intel® Stratix® 10 (H-tile and L-tile) | Final |
Intel® Arria® 10 | Final |
Intel® Cyclone® 10 GX | Final |
Arria V GX/GT/GS | Final |
Arria V GZ | Final |
Cyclone V | Final |
Stratix V | Final |
The following terms define device support levels for Intel FPGA IP cores:
- Advance support—the IP core is available for simulation and compilation for this device family. Timing models include initial engineering estimates of delays based on early post-layout information. The timing models are subject to change as silicon testing improves the correlation between the actual silicon and the timing models. You can use this IP core for system architecture and resource utilization studies, simulation, pinout, system latency assessments, basic timing assessments (pipeline budgeting), and I/O transfer strategy (data-path width, burst depth, I/O standards tradeoffs).
- Preliminary support—the IP core is verified with preliminary timing models for this device family. The IP core meets all functional requirements, but might still be undergoing timing analysis for the device family. It can be used in production designs with caution.
- Final support—the IP core is verified with final timing models for this device family. The IP core meets all functional and timing requirements for the device family and can be used in production designs.
The following table lists the link rate support offered by the DisplayPort Intel® FPGA IP for each Intel FPGA family.
Device Family | Dual Symbol (20-Bit Mode) |
Quad Symbol (40-Bit Mode) |
FPGA Fabric Speed Grade |
---|---|---|---|
Intel® Stratix® 10 (H-tile and L-tile) | RBR, HBR, HBR2 | RBR, HBR, HBR2, HBR3 | 1, 2, 3 2 |
Intel® Arria® 10 | RBR, HBR, HBR2 | RBR, HBR, HBR2, HBR3 | 1, 2 |
Intel® Cyclone® 10 GX | RBR, HBR, HBR2 | RBR, HBR, HBR2, HBR3 | 5, 6 |
Stratix V | RBR, HBR, HBR2 | RBR, HBR, HBR2 | 1, 2, 3 |
Arria V GX/GT/GS | RBR, HBR | RBR, HBR, HBR2 | 3, 4, 5 |
Arria V GZ | RBR, HBR, HBR2 | RBR, HBR, HBR2 | Any supported speed grade |
Cyclone V | RBR, HBR | RBR, HBR | Any supported speed grade |
Device Family | Adaptive Sync Support |
---|---|
Intel® Stratix® 10 (H-tile and L-tile) | Yes |
Intel® Arria® 10 | Yes |
Intel® Cyclone® 10 GX | Yes |
To enable the Adaptive Sync feature, refer to Table 29 and Video Interface (TX Video IM Enable = 1). For detailed implementation of the feature, refer to the DisplayPort SST Parallel Loopback with Adaptive Sync Support section in the respective DisplayPort Intel® FPGA IP design example user guides.
2.3. IP Core Verification
Before releasing a publicly available version of the DisplayPort Intel® FPGA IP, Intel runs a comprehensive verification suite in the current version of the Intel® Quartus® Prime software. These tests use standalone methods and the Platform Designer system integration tool to create the instance files. These files are tested in simulation and hardware to confirm functionality. Intel tests and verifies the DisplayPort Intel® FPGA IP in hardware for different platforms and environments.
2.4. Performance and Resource Utilization
The resource utilization data indicates typical expected performance for the DisplayPort Intel® FPGA IP.
The following table lists the resources and expected performance for selected variations. The results were obtained using the Intel® Quartus® Prime Pro Edition software version 20.2 for the following devices:
- Intel® Arria® 10 (10AX115S2F45I1SG)
- Intel® Cyclone® 10 GX (10CX220YF780E5G)
- Intel® Stratix® 10 (1SG280HU1F50E2VGS1)
Device | Streams | Direction | Symbol per Clock | ALMs | Logic Registers | Memory | ||
---|---|---|---|---|---|---|---|---|
Primary | Secondary | Bits | M10K or M20K | |||||
Intel® Stratix® 10 | SST (Single Stream) | RX | Dual | 5,200 | 7,700 | 640 | 16,256 | 11 |
Quad | 7,100 | 9,500 | 880 | 18,816 | 14 | |||
TX | Dual | 5,100 | 7,100 | 420 | 12,176 | 15 | ||
Quad | 7,100 | 9,200 | 550 | 22,688 | 29 | |||
Intel® Arria® 10 |
SST (Single Stream) | RX | Dual | 4,200 | 6,900 | 1,200 | 16,256 | 11 |
Quad | 6,000 | 8,800 | 1,600 | 18,816 | 14 | |||
TX | Dual | 4,700 | 6,300 | 1,000 | 6,728 | 6 | ||
Quad | 6,700 | 8,400 | 1,200 | 16,520 | 13 | |||
MST (4 Streams) |
RX | Quad | 20,100 | 24,400 | 4,500 | 58,368 | 32 | |
TX | Quad | 26,400 | 29,000 | 4,300 | 21,728 | 34 | ||
Intel® Cyclone® 10 GX | SST (Single Stream) | RX | Dual | 4,200 | 7,000 | 1,200 | 16,256 | 11 |
Quad | 6,000 | 8,800 | 1,600 | 18,816 | 14 | |||
TX | Dual | 4,600 | 6,200 | 1,000 | 10,568 | 8 | ||
Quad | 6,800 | 8,400 | 1,200 | 17,096 | 13 | |||
MST (4 Streams) |
RX | Dual | 22,000 | 24,400 | 4,400 |
58,368 |
32 | |
TX | Quad | 26,500 | 29,000 | 4,400 | 36,576 | 32 |
Device | HDCP IP | Symbols per Clock | ALMs | Combinatorial ALUTs | Registers | M20K | DSP |
---|---|---|---|---|---|---|---|
Intel® Arria® 10 | HDCP 2.3 TX | Dual |
6,752 |
10,724 |
13,138 |
10 |
3 |
Quad |
9,934 |
16,760 |
16,716 |
10 |
3 |
||
HDCP 2.3 RX | Dual |
7,395 |
11,721 |
13,775 |
11 |
3 |
|
Quad |
10,547 |
17,674 |
17,335 |
11 |
3 |
||
HDCP 1.3 TX | Dual |
2,505 |
3,826 |
5,336 |
2 |
0 |
|
Quad |
3,724 |
5,648 |
5,882 |
2 |
0 |
||
HDCP 1.3 RX | Dual |
1,995 |
2,879 |
4,248 |
3 |
0 |
|
Quad |
3,270 |
4,810 |
4,851 |
3 |
0 |
||
Intel® Stratix® 10 | HDCP 2.3 TX | Dual |
7,723 |
11,555 |
13,685 |
10 |
3 |
Quad |
10,767 |
17,154 |
17,842 |
10 |
3 |
||
HDCP 2.3 RX | Dual |
8,431 |
12,626 |
14,647 |
11 |
3 |
|
Quad |
11,304 |
18,071 |
18,586 |
11 |
3 |
||
HDCP 1.3 TX | Dual |
3,154 |
4,108 |
5,181 |
2 |
0 |
|
Quad |
4,794 |
6,194 |
7,640 |
2 |
0 |
||
HDCP 1.3 RX | Dual |
2,602 |
3,355 |
4,245 |
3 |
0 |
|
Quad |
4,229 |
5,428 |
6,452 |
3 |
0 |
3. Getting Started
This chapter provides a general overview of the Intel FPGA IP design flow to help you quickly get started with the DisplayPort Intel® FPGA IP. The IP is installed as part of the Intel® Quartus® Prime installation process. You can select and parameterize any Intel FPGA IP from the library. Intel provides an integrated parameter editor that allows you to customize the DisplayPort IP to support a wide variety of applications. The parameter editor guides you through the setting of parameter values and selection of optional ports.
3.1. Installing and Licensing Intel FPGA IP Cores
The Intel® Quartus® Prime software installs IP cores in the following locations by default:
Location | Software | Platform |
---|---|---|
<drive>:\intelFPGA_pro\quartus\ip\altera | Intel® Quartus® Prime Pro Edition | Windows* |
<drive>:\intelFPGA\quartus\ip\altera | Intel® Quartus® Prime Standard Edition | Windows |
<home directory>:/intelFPGA_pro/quartus/ip/altera | Intel® Quartus® Prime Pro Edition | Linux* |
<home directory>:/intelFPGA/quartus/ip/altera | Intel® Quartus® Prime Standard Edition | Linux |
3.1.1. Intel FPGA IP Evaluation Mode
- Simulate the behavior of a licensed Intel® FPGA IP core in your system.
- Verify the functionality, size, and speed of the IP core quickly and easily.
- Generate time-limited device programming files for designs that include IP cores.
- Program a device with your IP core and verify your design in hardware.
Intel® FPGA IP Evaluation Mode supports the following operation modes:
- Tethered—Allows running the design containing the licensed Intel® FPGA IP indefinitely with a connection between your board and the host computer. Tethered mode requires a serial joint test action group (JTAG) cable connected between the JTAG port on your board and the host computer, which is running the Intel® Quartus® Prime Programmer for the duration of the hardware evaluation period. The Programmer only requires a minimum installation of the Intel® Quartus® Prime software, and requires no Intel® Quartus® Prime license. The host computer controls the evaluation time by sending a periodic signal to the device via the JTAG port. If all licensed IP cores in the design support tethered mode, the evaluation time runs until any IP core evaluation expires. If all of the IP cores support unlimited evaluation time, the device does not time-out.
- Untethered—Allows running the design containing the licensed IP for a limited time. The IP core reverts to untethered mode if the device disconnects from the host computer running the Intel® Quartus® Prime software. The IP core also reverts to untethered mode if any other licensed IP core in the design does not support tethered mode.
When the evaluation time expires for any licensed Intel® FPGA IP in the design, the design stops functioning. All IP cores that use the Intel® FPGA IP Evaluation Mode time out simultaneously when any IP core in the design times out. When the evaluation time expires, you must reprogram the FPGA device before continuing hardware verification. To extend use of the IP core for production, purchase a full production license for the IP core.
You must purchase the license and generate a full production license key before you can generate an unrestricted device programming file. During Intel® FPGA IP Evaluation Mode, the Compiler only generates a time-limited device programming file (<project name> _time_limited.sof) that expires at the time limit.
Intel® licenses IP cores on a per-seat, perpetual basis. The license fee includes first-year maintenance and support. You must renew the maintenance contract to receive updates, bug fixes, and technical support beyond the first year. You must purchase a full production license for Intel® FPGA IP cores that require a production license, before generating programming files that you may use for an unlimited time. During Intel® FPGA IP Evaluation Mode, the Compiler only generates a time-limited device programming file (<project name> _time_limited.sof) that expires at the time limit. To obtain your production license keys, visit the Self-Service Licensing Center.
The Intel® FPGA Software License Agreements govern the installation and use of licensed IP cores, the Intel® Quartus® Prime design software, and all unlicensed IP cores.
3.2. Specifying IP Parameters and Options
- Create a Intel® Quartus® Prime project using the New Project Wizard available from the File menu.
- On the Tools menu, click IP Catalog.
-
Under Installed IP,
double-click Library > Interface Protocols > Audio&Video >
DisplayPort Intel® FPGA IP
.
The parameter editor appears.
- In the parameter editor, specify a top-level name for your custom IP variation. This name identifies the IP core variation files in your project. If prompted, also specify the targeted Intel FPGA family and output file HDL preference. Click OK.
-
Specify parameters and options in the DisplayPort parameter editor:
- Optionally select preset parameter values. Presets specify all initial parameter values for specific applications (where provided).
- Specify parameters defining the IP core functionality, port configurations, and device-specific features.
- Specify options for processing the IP core files in other EDA tools.
- Click Generate to generate the IP and supporting files, including simulation models.
- Click Close when file generation completes.
- Click Finish.
- If you generate the DisplayPort Intel® FPGA IP instance in a Intel® Quartus® Prime project, you are prompted to add Intel® Quartus® Prime IP File (.qip) and Intel® Quartus® Prime Simulation IP File (.sip) to the current Intel® Quartus® Prime project.
3.3. Simulating the Design
You can simulate your DisplayPort Intel® FPGA IP variation using the simulation model that the Intel® Quartus® Prime software generates. The simulation model files are generated in vendor-specific subdirectories of your project directory. The DisplayPort Intel® FPGA IP includes a simulation example.
The following sections teach you how to simulate the generated DisplayPort Intel® FPGA IP variation with the generated simulation model.
3.3.1. Simulating with the ModelSim Simulator
To simulate using the Mentor Graphics* ModelSim* simulator, perform the following steps:
- Start the ModelSim simulator.
- In ModelSim, change directory to the project simulation directory <variation>_sim/mentor.
-
Type the following commands to set up the required libraries and
compile the generated simulation model:
do msim_setup.tcl
ld
run -all
3.4. Compiling the Full Design and Programming the FPGA
You can use the Start Compilation command on the Processing menu in the Intel® Quartus® Prime software to compile your design. After successfully compiling your design, program the targeted Intel FPGA with the Programmer and verify the design in hardware.
4. DisplayPort Intel FPGA IP Hardware Design Examples
The implementation of the DisplayPort Intel® FPGA IP on hardware requires additional components specific to the targeted device.
4.1. DisplayPort Intel FPGA IP Hardware Design Examples for Intel Arria 10, Intel Cyclone 10 GX, and Intel Stratix 10 Devices
For detailed information about the DisplayPort Intel® FPGA IP design examples, refer to the respective design example user guides.
4.2. HDCP Over DisplayPort Design Example for Intel Arria 10 and Intel Stratix 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 and Intel® Stratix® 10 designs.
For detailed information about the HDCP over DisplayPort design examples, refer to the Intel® Arria® 10 and Intel® Stratix® 10 design example user guides.
4.3. DisplayPort Intel FPGA IP Hardware Design Examples for Arria V, Cyclone V, and Stratix V Devices
This design performs a loop-through for a standard DisplayPort video stream. You connect a DisplayPort-enabled device—such as a graphics card with DisplayPort interface—to the Transceiver Native PHY RX, and the DisplayPort 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. 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. The DisplayPort source port of the daughter card transmits the image to a monitor.
- Arria V GX FPGA Starter Kit
- Cyclone V GT FPGA Development Kit
- Stratix V GX FPGA Development Kit
The DisplayPort sink uses its internal state machine to negotiate link training upon power up. A Nios II embedded processor performs the source link management; software performs the link training management.
Clock | Frequency | Description |
---|---|---|
AUX Clock | 16 MHz | Used as primary clock source for Auxiliary encoder and decoder. Refer to Source AUX Interface and Sink AUX Interface for more information. |
Control Clock | 60 MHz | Used for Pixel Clock Recovery (PCR) module loop controller and fPLL reconfiguration blocks. |
Native PHY Reference Clock | 135 MHz | Used as Native PHY reference clock for Transceiver CMU PLL. |
Video Clock | 160 MHz or 300 MHz | Video Clock has two functions in this demonstration.
|
- If the upstream device transmits video data at 1080@60 (Strm_Clk = 148.5 MHz) and the sink device is configured at PIXELS_PER_CLOCK = 1, the device must drive rxN_vid_clk at a minimal frequency of 148.5 MHz.
- If the sink device is configured at PIXELS_PER_CLOCK = 4, the device must drive rxN_vid_clk at a minimal frequency of 37.125 MHz (148.5 MHz/4).
- For designs with HBR2 at PIXELS_PER_CLOCK = 4, the recommended rxN_vid_clock frequency is 160 MHz to support 4K@60 resolution
- For designs with HBR2 at PIXELS_PER_CLOCK = 2, the recommended rxN_vid_clock frequency is 300 MHz to support 4K@60 resolution
Supported Intel FPGAs | Function |
---|---|
USER_LED[0] |
This LED indicates that source is successfully lane-trained and is sending video. rxN_vid_locked drives this LED. This LED turns off if the source is not driving good video. |
USER_LED[1] |
This LED illuminates for 1-lane designs. |
USER_LED[2] |
This LED illuminates for 2-lane designs. |
USER_LED[3] |
This LED illuminates for 4-lane designs. |
USER_LED[7:6] |
These LEDs indicate the RX link rate.
|
- The Bitec HSMC daughter card has inverted transceiver polarity. When creating your own sink (RX) design, use the Invert transceiver polarity option to enable or disable inverted polarity.
- The DisplayPort standard
reverses the RX and TX transceiver channels to minimize noise for one- or two-lane
applications. If you create your own design targeting the Bitec daughter card,
ensure that the following signals share the same transceiver channel:
- TX0 and RX3
- TX1 and RX2
- TX2 and RX1
- TX3 and RX0
During operation, you can adjust the DisplayPort source resolution (graphics card) from the PC and observe the effect on the IP core. The Nios II software prints the source and sink AUX channel activity. Press a push-button to print the current TX and RX MSAs.
Refer to the assignments.tcl file for an example of how the channels are assigned in the hardware demonstration.
4.3.1. Clock Recovery Core
To synthesize the video pixel clock from the link clock, the clock recovery core gathers information about the current MSA and the currently used link rate from the DisplayPort sink.
The clock recovery core produces resynchronized video data together with the following clocks:
- Recovered video pixel clock
- Second clock with twice the recovered pixel clock frequency
The video output data is synchronous to the recovered video clock. You can use the second clock as a reference clock for the TX transceiver, which is optionally used to serialize the video output data.
The clock recovery core clocks the video data input gathered from the DisplayPort sink into a dual-clock FIFO at the received video clock speed. The core reads from the video data input using the recovered video clock.
- Video Timing Generator: This block uses the received MSA to create h-sync , v-sync, and data enable signals that are synchronized to the recovered video clock.
- Loop Controller: This block monitors the FIFO fill level and regulates its throughput by altering the original Mvid value read from the MSA. The block feeds the modified Mvid to the fPLL Controller, which calculates a set of parameters suitable for the fPLL Controller. This set of parameters provides the value to create a recovered video clock frequency corresponding to the new Mvid value. The calculated fPLL parameters are written by the fPLL Reconfiguration Avalon Master to the fPLL Reconfiguration Controller internal registers.
- Reconfiguration Controller: This block serializes the parameter values and writes them to the fPLL IP core.
- fPLL: Generates the recovered video clock and a second clock with twice the frequency.
4.3.1.1. Clock Recovery Core Parameters
Parameter | Default Value | Description |
---|---|---|
SYMBOLS_PER_CLOCK | 4 | Specifies the configuration of the
DisplayPort RX transceiver used. Set to 2 for 20-bit mode (Dual symbol) or to 4 for 40-bit mode (Quad symbol). |
CLK_PERIOD_NS | 10 | Specifies the period (in nanoseconds) of the control
clock input signal connected to the port. Note: The recommended control clock frequency is 60 MHz. Set this parameter
to 17.
|
DEVICE_FAMILY | Arria V | Identifies the device used. The values are Arria V, Cyclone V, and Stratix V. |
FIXED_NVID | 0 | Specifies the configuration of the DisplayPort RX
received video clocking used. Set to 1 for asynchronous clocking, where the Nvid value is fixed to 32’h8000. Set to 0 if the value of Nvid is a variable of 32'h8000 or any other value. Note: Most DisplayPort source devices transmit video using
asynchronous clocking. For optimized resource usage, Intel recommends you to set the
FIXED_NVID parameter to
1.
|
PIXELS_PER_CLOCK | 4 | Specifies how many pixels in parallel (for each clock
cycle) are gathered from the DisplayPort RX. Set to 1 for single pixel, 2 for dual, or 4 for quad pixels per clock cycle. |
BPP | 48 | Specifies the width (in bits) of a
single pixel. Set to 18 for 6-bit color, 24 for 8-bit color, and so on up to 48 for 16-bit color. |
4.3.1.2. Clock Recovery Interface
The following table lists the signals for the clock recovery core.
Interface |
Port Type |
Clock Domain |
Port |
Direction |
Description |
---|---|---|---|---|---|
control clock |
Clock |
N/A |
clk |
Input |
Control logic clock. This clock runs the loop controller and fPLL reconfiguration related blocks. Intel® recommends you use a 60 MHz clock. |
RX link clock |
Clock |
N/A |
rx_link_clk |
Input |
DisplayPort transceiver link clock. This clock is a divided version of the RX main link clock or divided by 4.
|
reset |
Reset |
clk |
areset |
Input |
Asynchronous reset. This is an active-high signal. |
RX link rate |
Conduit |
asynchronous | rx_link_rate[1:0] |
Input |
DisplayPort RX link rate.
You need this information for the clock recovery clock to correctly calculate the fPLL parameters. |
RX MSA |
Conduit |
rx_link_clk | rx_msa[216:0] |
Input |
A set of different signals containing the following information:
You must connect this set of signals as is from the DisplayPort Intel® FPGA IP to the clock recovery core. |
Video Input |
Conduit |
vidin_clk | vidin_clk |
Input |
Pixel clock. |
vidin_data (BPP*PIXELS_PER_CLOCK–1:0) |
Input |
Pixel data. |
|||
vidin_valid |
Input |
You must assert this signal when all signals on this port are valid. |
|||
vidin_sol |
Input |
Start of video line. |
|||
vidin_eol |
Input |
End of video line. |
|||
vidin_sof |
Input |
Start of video frame. |
|||
vidin_eof |
Input |
End of video frame. |
|||
vidin_locked |
Input |
You must assert this signal when the DisplayPort RX is locked to a valid received video stream.
|
|||
Video Output |
Conduit |
rec_clk |
rec_clk |
Output |
Reconstructed video clock. |
rec_clk_x2 |
Output |
Reconstructed video clock double frequency. |
|||
vidout (BPP*PIXELS_PER_CLOCK–1:0) |
Output |
Pixel data. |
|||
hsync |
Output |
Horizontal sync. This signal can be active-high or active-low depending on the sync polarity from MSA. |
|||
vsync |
Output |
Vertical sync. This signal can be active-high or active-low depending on the sync polarity from MSA. |
|||
de |
Output |
Data enable. This signal is always active high. |
|||
field2 |
Output |
The clock recovery core asserts this signal during the second video field for interlaced timings. |
|||
reset_out |
Output |
The clock recovery core asserts this signal when the other video output signals are not valid. This signal is asynchronous. |
4.3.1.2.1. Video Input Port
When the PIXELS_PER_CLOCK parameter is greater than 1, all input pixels are supposed to be valid when you assert vidin_valid. The parameter only supports timings with horizontal active width divisible by 2 (PIXELS_PER_CLOCK = 2) or 4 (PIXELS_PER_CLOCK = 4).
The clock recovery core video output port produces pixel data with standard hsync, vsync, or de timing. All signals are synchronous to the reconstructed video clock rec_clk, unless mentioned otherwise. For designs using a TX transceiver, you can use rec_clk as its reference clock.
You can use rec_clk_x2 as a reference clock for transceivers that have reference clocks with frequencies lower than the minimum pixel clock frequency received. For example, the Video Graphics Array (VGA) 25-MHz resolution when the transceiver's minimum reference clock is 40 MHz.
The clock recovery core asserts reset_out when the remaining port signals are not valid. For example, during a recovered video resolution change when the rec_clk and rec_clk_x2 signals are not yet locked and stable. Intel recommends that you use reset_out to reset the downstream logic connected to the video output port.
During the hardware demonstration operation, you can adjust the DisplayPort source resolution (graphics card) from the PC and observe the effect on the IP core. The Nios II software prints the source and sink AUX channel activity. Press one of the push buttons to print the current TX and RX MSA.
4.3.2. Transceiver and Clocking
The device’s Gigabit transceivers operate at 5.4, 2.7, and 1.62 Gbps, and require a 135-MHz single reference clock. When the link rate changes, the state machine only reconfigures the transceiver PLL settings.
Parameters |
Single Reference Clock Settings |
---|---|
Datapath Options |
|
Enable TX datapath |
On |
Enable RX datapath |
On |
Enable standard PCS |
On |
Number of data channels |
1, 2 or 4 |
Note: If you select 1 or 2, you must instantiate the
PHY instance multiple times for all data channels as per maximum
lane count parameter. These values are for non-bonded mode.
|
|
Bonding mode |
×1* or ×N |
Note: If you select ×1, you must instantiate the PHY
instance multiple times for all data channels as per maximum
lane count parameter. This value is for non-bonded mode.
|
|
Enable simplified data interface | |
PMA |
|
Data rate |
1620 Mbps (when TX maximum link rate = 1.62 Gbps) 2700 Mbps (when TX maximum link rate = 2.7 Gbps) 5400 Mbps (when TX maximum link rate = 5.4 Gbps) |
TX local clock division factor |
1 |
TX PMA |
|
Enable TX PLL dynamic reconfiguration |
On |
Number of TX PLLs |
1 |
Main TX PLL logical index |
0 |
Number of TX PLL reference clock |
1 |
TX PLL0 |
|
PLL type |
CMU |
Reference clock frequency |
135 MHz |
Selected reference clock source |
0 |
Selected clock network |
×1 or ×N |
Note: If you select ×1, you must instantiate the PHY
instance multiple times for all data channels as per maximum
lane count parameter. This value is for non-bonded mode.
|
|
RX PMA |
|
Enable CDR dynamic reconfiguration | On |
Number of CDR reference clocks |
1 |
Selected CDR reference clock |
0 |
Selected CDR reference clock frequency |
135 MHz |
PPM detector threshold |
1000 ppm |
Enable rx_is_lockedtodata port |
On |
Enable rx_is_lockedtoref port |
On |
Enable rx_set_locktodata and rx_set_locktoref ports |
On |
Standard PCS |
|
Standard PCS protocol mode |
Basic |
Standard PCS/PMA interface width |
20 |
Byte Serializer and Deserializer |
|
Enable TX byte serializer |
Off (when symbol output mode is Dual) On (when symbol output mode is Quad) |
Enable RX byte deserializer |
Off (when symbol output mode is Dual) On (when symbol output mode is Quad) |
4.3.3. Required Hardware
The hardware demonstration requires the following hardware:
-
Intel FPGA kit (includes
USB cable to connect the board to your PC); the demonstration supports the following
kits:
- Stratix V GX FPGA Development Kit (5SGXEA7K2F40C2)
- Arria V GX FPGA Starter Kit (5AGXFB3H4F40C5)
- Cyclone V GT FPGA Development Kit (5CGTFD9E5F35C7)
- Bitec DisplayPort daughter card (HSMC revision 11 and later)
- PC with a DisplayPort output
- Monitor with a DisplayPort input
- Two DisplayPort cables
- One cable connects from the graphics card to the FPGA development board
- The other cable connects from the FPGA development board to the monitor
4.3.4. Design Walkthrough
Setting up and running the DisplayPort hardware demonstration consists of the following steps. A variety of scripts automate these steps.
- Set up the hardware.
- Copy the design files to your working directory.
- Build the FPGA design.
- Build the software, download it into the FPGA, and run the software.
- Power-up the DisplayPort monitor and view the results.
4.3.4.1. Set Up the Hardware
Set up the hardware using the following steps:
- Connect the Bitec daughter card to the FPGA development board.
-
Connect the development board to your PC using a USB cable.
Note: The FPGA development board has an On-Board Intel® FPGA Download Cable II connection. If your version of the board does not have this connection, you can use an external Intel® FPGA Download Cable. Refer to the documentation for your board for more information.
- Connect a DisplayPort cable from the DisplayPort TX on the Bitec HSMC daughter card to a DisplayPort monitor (do not power up the monitor).
- Power-up the development board.
- Connect one end of a DisplayPort cable to your PC (do not connect the other end to anything).
4.3.4.2. Copy the Design Files to Your Working Directory
Copy the files using the command:
cp -r <IP root directory>/ altera / altera_dp / hw_demo /<device_board> <working directory>
where <device_board> is av_sk_4k for Arria V GX starter kit, cv for Cyclone V GT development kit, sv for Stratix V development kit, mst_av for Arria V MST design, and mst_sv for Stratix V MST design.
Your working directory should contain the files shown in the following tables.
File Type |
File |
Description |
---|---|---|
Verilog HDL design files |
top.v |
Top-level design file. |
bitec_reconfig_alt_ <prefix> .v |
Reconfiguration manager top-level. This module is a high-level FSM that generates the control signals to reconfigure the VOD and pre-emphasis, selects the PLL reference clock, and reconfigures the clock divider setting. The FSM loops through all the channels and transceiver settings. |
|
altera_pll_reconfig_core.v altera_pll_reconfig_mif_reader.v altera_pll_reconfig_top.v bitec_cc_fifo.v bitec_cc_pulse.v bitec_clkrec.v bitec_fpll_cntrl.v bitec_fpll_reconf.v bitec_loop_cntrl.v bitec_vsyncgen.v clkrec_pll_ <prefix> .v |
Clock recovery core encrypted design files. |
|
IP Catalog files |
video_pll <prefix> .v pll_135.v gxb_reconfig.v gxb_reset.v gxb_rx.v gxb_tx.v |
IP Catalog variants for the various helper IP cores. |
Platform Designer system |
control.qsys |
Platform Designer system file. |
Intel® Quartus® Prime IP files |
bitec_reconfig_alt_ <prefix> .qip bitec_clkrec_dist.qip bitec_clkrec.qip |
Intel® Quartus® Prime IP files that list the required submodule files. |
Scripts |
runall.tcl |
Script to set up the project, generate the IP and Platform Designer system, and compile. |
assignments.tcl |
Top-level TCL file to create the project assignments. |
|
build_ip.tcl |
TCL file to build the DisplayPort example design IP blocks. |
|
build_sw.sh |
Script to compile the software. |
|
Miscellaneous |
example.sdc |
Top-level SDC file. |
bitec_clkrec.sdc |
Clock recovery core SDC file. |
|
Software files (in the software directory) |
dp_demo_src\ |
Directory containing the example application source code. |
btc_dprx_syslib\ |
System library for the RX API. |
|
btc_dptx_syslib\ |
System library for the TX API. |
4.3.4.3. Build the FPGA Design
In this step, you use a script to build and compile the FPGA design. Type the command:
./runall.tcl ( Intel® Quartus® Prime Standard Edition)
This script basically builds the IPs and software, as well as performs Intel® Quartus® Prime full compilation.
4.3.4.4. Load and Run the Software
In this step, you load the software into the device and run the software.
- In a Windows Command prompt, navigate to the hardware demonstration software directory.
- Launch a Nios II command shell. You can launch it using several methods, for example, from the Windows task bar or within the Platform Designer system.
-
From within the Nios II command shell, execute the following
command to program the device, download the Nios II program, and launch a debug
terminal:
bash nios2-configure-sof <project_name>.sof <USB cable number>; nios2-terminal<USB cable number>
Note: To find <USB cable number>, use the jtagconfig command. -
To
download the Software .elf file separately, execute the
following command in the Nios II command shell:
bash nios2-download <project_name>.elf
4.3.4.5. View the Results
In this step you view the results of the hardware demonstration in the Nios II command shell and on the DisplayPort monitor.
- Power-up the connected DisplayPort monitor.
-
Connect the free end of the Display Port cable that you connected to your PC
to the DisplayPort RX on the Bitec daughter card. The PC now has the
DisplayPort monitor available as a second monitor. The hardware demonstration
loops through and displays the graphic card output as received by the sink core.
Note: Some PC drivers and graphic card adapters do not enable the DisplayPort hardware automatically upon hot plug detection. You may need to start the adapter’s control utility (e.g. Catalist Control Center, NVIDIA Control Panel) and manually enable the DisplayPort display.Figure 9. Loop-through Hardware Demonstration
-
You can use your graphic card control panel to adjust the resolution of the DisplayPort monitor, which typically results in link training, related AUX channel traffic, and a corresponding new image size on the monitor.
Note: If you do not see visible output on the monitor, press push button (CPU_RESETN) to generate a reset, causing the DisplayPort TX core to re-train the link.
Press push button 0 (USER_PB[0]) to retrieve MSA statistics from the source and sink connections. The Nios II Command Shell displays the AUX channel traffic during link training with the monitor.
Figure 10. MSA OutputThe Nios II AUX printout shows each message packet on a separate line.
- The first field is the incremental timestamp in microseconds.
- The second field indicates whether the message packet is from or to the DisplayPort sink (SNK) or source (SRC).
- The next two fields show the request and response headers and payloads. The DPCD address field on request messages are decoded into the respective DPCD location names.
When connected and enabled, USER_PB[0] on the development board illuminates to indicate that the DisplayPort receiver has locked correctly.
4.3.5. DisplayPort Link Training Flow
The DisplayPort source device accesses the sink’s DPCD register block through the AUX channel to determine the sink’s capability and status and initiate the Link Training command.
- The DisplayPort source reads the DPCD Capabilities fields offset 0x00000 – 0x0000D to determine the sink device’s capability.
- The source writes to the Link Configuration field offset 0x00100 – 0x00101 to configure the Link Bandwidth and Lane Count according to the sink device’s requirements.
- The source writes to offset 0x00102 to select Training Pattern 1 and Disable Scrambling. The source sends Training Pattern 1 through the Main Link at the same time.
- The source writes to offset 0x00103 – 0x00106 to configure the Link Training Control for every lane.
- The source reads from offset 0x0000E for TRAINING_AUX_RD_INTERVAL value.
- The source waits for a period of time specified in TRAINING_AUX_RD_INTERVAL before it reads the Link Status (0x00202 – 0x00207) from the sink device.
- If the clock recovery core (CR_DONE) fails in one or more
lanes:
- The source checks for the Link Driver setting adjust request (0x00206 – 0x00207) and responds accordingly.
- In the same Link Driver setting, if the source has already repeated Training Pattern Sequence 1 for 5 times, the source will lower the Link Bandwidth (from HBR2 to HBR to RBR) in offset 0x00100 and starts back at Step 1.
- If the Link Bandwidth is already in the lowest rate (RBR), then Link Training fails.
- The source writes to offset 0x00102 to select Training Pattern 2 and Disable Scrambling. The source sends Training Pattern 2 through the Main Link at the same time.
- The source writes to offset 0x00103 – 0x00106 to configure the Link Training Control for every lane.
- The source reads from offset 0x0000E for TRAINING_AUX_RD_INTERVAL value.
- The source waits for a period of time specified in TRAINING_AUX_RD_INTERVAL before it reads the Link Status (0x00202 – 0x00207) from the sink device.
- If CR_DONE (0x00202) fails in one or more lanes, abort Training Pattern Sequence 2, and restart Training Pattern Sequence 1.
- If CR_DONE passes all lanes, check if the following
operations fail or pass:
- CHANNEL_EQ_DONE
- SYMBOL_LOCKED
- INTERLANE_ALIGN_DONE
- If CHANNEL_EQ_DONE, SYMBOL_LOCKED or
INTERLANE_ALIGN_DONE fails in one or more lanes:
- The source checks for the Link Driver setting adjust request (0x00206 – 0x00207) and responds accordingly.
- In the same Link Driver setting, if the source has already repeated Training Pattern Sequence 2 for 5 times, the source will lower the Link Bandwidth (from HBR2 to HBR to RBR) in offset 0x00100, aborts Training Pattern Sequence 2, and restarts Link Training Pattern Sequence 1.
- If the Link Bandwidth is already in the lowest rate (RBR), then Link Training fails.
- If Training Pattern Sequence 2 passes, then Link Training completes.
- The source writes to offset 0x00102 to disable Link Training.Note: If both DisplayPort source and sink support HBR2, replace Training Pattern Sequence 2 with Training Pattern Sequence 3.
4.3.6. DisplayPort Post Link Training Adjust Request Flow (LQA)
The DisplayPort sink supports Post Link Training Adjust Request Sequence feature (as defined in the VESA DisplayPort Standard 1.3).
- During Link Training Sequence, when the source reads DPCD offset 0x00002, and the sink have 0x00002 bit [5] (POST_LT_ADJ_REQ_SUPPORT) set to 1.
- If the source supports this feature, it writes to offset 0x00101 bit [5] (POST_LT_ADJ_REQ_GRANTED) to grant Post Link Training Adjust Request.
- After Link Training Sequence completes, the source writes to offset 0x00102 to disable Link Training.
- The sink sets DPCD 0x00204 bit [1] (POST_LT_ADJ_REQ_IN_PROGRESS) to 1 and fine-tunes the Link driver setting (Voltage swing and Pre-emphasis).
- The source reads offset 0x00204 bit [1] to check if Sink Post Link Training Adjust Sequence is in progress.
- After 5 – 10 ms, the source reads DPCD ADJUST_REQUEST_LANE x (0x00206 – 0x00207).
- If the value changes, the source writes to offset 0x00206 – 0x00207 to configure the Link driver setting accordingly to the requested value.
- If value not changed, repeat steps 5 – 6. If these steps are repeated 6 times, the source clears offset 0x00101 bit [5] to not grant and proceed to Normal Active Video Transmission.
- If the sink device's Link Status (0x00202 – 0x00204) clears
after step 6,
- Abort Post Link Training Adjust Request Sequence.
- The source clears offset 0x00101 bit [5] (not grant).
- Restart with Link Training Sequence 1.
All the POST_LT_ADJ_REQ registers and flow definition are available only in the VESA DisplayPort Standard 1.3 .
4.3.7. DisplayPort MST Source User Application
For MST source instantiations, you need to create a user application at the top software layer to invoke the Link Layer level API functions of the btc_dptxll_syslib library.
The btc_dptxll_syslib library handles most of the Link Layer functionality. The library performs marginal SST operation, which in turn, becomes evident for MST operations. The btc_dptxll_syslib library uses the services provided by the btc_dptx_syslib library.
You can use the user application to perform MST discovery topology by invoking a single API function (btc_dptxll_mst_get_device_port()). In turn, the btc_dptxll_syslib library implements this functionality by invoking a number of btc_dptx_syslib MST messaging functions such as btc_dptx_mst_link_address_req(), btc_dptx_mst_enum_path_req(), and btc_dptx_mst_remote_i2c_rd_req().
- Wait for HPD signal to become 1.
- Read the connected sink DPCD version and MST capabilities.
- If the sink is not MST capable, only a single-stream (SST) connection is possible. In this case, no further action is required as SST connections are mostly handled automatically.
- If the sink supports MST, skip this step.
- Perform MST topology discovery by collecting all device ports reachable through the connected sink. Invoke btc_dptxll_mst_get_device_ports() until either its outcome is valid or an error is returned. For a successful return value, move to the following step.
- Browse through the list of the device ports and search for a suitable device output port. This step highly depends on the definition of suitable device port. Some applications may require reading of the device port EDID to check the desired resolution supported by the port (use btc_dptxll_mst_edid_read_req() and btc_dptxll_mst_edid_read_rep() API functions). If a suitable device output port is found, move to the next step.
- Verify if the main link connection between the DisplayPort source and connected sink is
still up.
- If the link is down, perform a new Link Training.
- If the link is up, move to the next step.
Note: While you can perform the earlier steps even when the main link connection is down, the following steps require the connection to be up. The source needs the connection to calculate the available data bandwidth and make allocation. - Set the video pixel rate of the desired stream by invoking btc_dptxll_stream_set_pixel_rate().
- Calculate the required VCP size for the stream by invoking btc_dptxll_stream_calc_VCP_size().
- Verify if the required VCP size (number of time slots needed to transport the stream) is available to transport to the desired device output port. Then, move to the next step.
- Allocate the stream data to be transported to the desired device output port by invoking btc_dptxll_stream_allocate_req()
- Wait for the source to make allocation. Invoke btc_dptxll_stream_allocate_rep() until either the allocation is complete or an error is returned. For a successful allocation, move to the following step.
- The allocation of the stream to the device output port completes. MST data transport is now active.
- Handle received CONNECTION_STATUS_NOTIFY messages according to the changed topology.
5. DisplayPort Source
The DisplayPort source consists of a DisplayPort encoder block, a transceiver management block, a controller interface block, and an HDCP interface block with an Avalon® memory-mapped interface for connecting with an embedded controller such as a Nios® II processor.
The source accepts a standard H-sync, V-sync, and data enable video stream for encoding. The IP latches and processes the video data, such as color reordering, before processing it using the txN_video_in input. N represents the stream number: tx_video_in (Stream 0), tx1_video_in (Stream 1), tx2_video_in (Stream 2), and tx3_video_in (Stream 3). Streams 1, 2, and 3 are only available when you turn on the Support MST parameter and specify the Max stream count parameter to 2, 3, or 4 streams respectively.
The video data width supports 6 to 16 bits per color (bpc) and is user selectable. If you set Pixel input mode to Dual or Quad, the video input can accept two or four pixels per clock, thereby extending the pixel clock rate capability.
5.1. Main Data Path
The main link data path consists of the video packetizer, video geometry measurement, audio and secondary stream encoder, and training and link quality patterns generator.
The IP multiplexes data from these four paths and transmits it through a scrambler and an 8B/10B encoder. All the symbols, both those transmitted during video display period and those transmitted during video blanking period, are skewed by two Link symbol period between adjacent lanes.
5.1.1. Video Packetizer Path
The video packetizer path provides video data resampling and packetization.
The video packetizer path consists of the following steps:
- The mixed-width DCFIFO crosses the video data from the video clock domain (txN_vid_clk) into the main link clock domain (tx_ss_clk) generated by the transceiver. This main clock can be 270, 202.5, 135, 81, 67.5, or 40.5 MHz, depending on the actual main link rate requested and the symbols per clock.
- The pixel steer block aligns the video data so that the first active pixel of each video line occupies the least significant position.
- The pixel packer block decimates the video data to the requested lane count (1, 2, or 4).
- The pixel gearbox block resamples the video data according to the specified color depth. You can optimize the gearbox by implementing fewer color depths. For example, you can reduce the resources required to implement the system by supporting only the maximum color depths you need instead of the complete set of color depths specified in the VESA DisplayPort Standard.
- The DisplayPort Intel® FPGA IP packetizes the resampled data. The VESA DisplayPort Standard requires data to be sent in a transfer unit (TU), which can be 32 to 64 link symbols long. To reduce complexity, the DisplayPort source uses a fixed 64-symbol TU. The specification also requires that the video data be evenly distributed within the TUs composing a full active video line. A throttle function distributes the data and regulates it to ensure that the TUs leaving the IP are evenly packed. The pixel packetizer punctuates the outgoing video stream with the correct packet comma codes, such as blank end (BE), fill start (FS), and fill end (FE). Internally, the pixel packetizer uses a symbol and a TU counter to ensure that it respects the TU boundaries.
- The blank start generator determines when to send the blank start (BS) comma codes with their corresponding video data packets. This block operates in enhanced or standard framing mode.
5.1.2. Video Geometry Measurement Path
The video geometry measurement path determines the video geometry (such as HTOTAL, VTOTAL, and VHEIGHT) required for the DisplayPort main stream attributes (MSA), which are sent once every vertical blanking interval.
The MSA generator provides the MSA packet framed with secondary start (SS) and secondary end (SE) comma codes based on the requested lane count. The multiplexer then combines the packetized data from the video packetizer path and the MSA data into a single stream.
5.1.3. Audio and Secondary Stream Encoder Path
The audio encoder generates the Audio InfoFrame, Audio Timestamp, and Audio Sample packets from the incoming audio sample data stream. The secondary stream scheduler arbitrates the data flow among the Audio InfoFrame, Audio Timestamp, and Audio Sample packets and the incoming secondary stream packet into a single secondary stream in a round robin method.
Based on the requested lane count, the secondary stream encoder packetizes and inserts the secondary stream packets into the combined packetized video and MSA data.
The secondary stream encoder path consists of the following steps:
- The secondary stream encoder determines the valid windows of opportunity during vertical and horizontal blanking regions for secondary stream packets.
- The secondary stream encoder derives the parity byte and performs nibble interleaving for enhancing error-correcting capability.
- The encoder packetizes the secondary stream packets with SS and SE.
- The encoder inserts the secondary stream packets into the merged video and MSA data.
5.1.4. Training and Link Quality Patterns Generator
The IP multiplexes the packetized data, MSA data, and blank generator data into a single stream.
The combined data goes through a scrambler and an 8B/10B encoder, and is available as a 20-bit double-rate or a 40-bit quad-rate DisplayPort encoded video port. The 20- or 40-bit port connects directly to the Intel FPGA high-speed output transceiver.
During training periods, the source can send the DisplayPort clock recovery and symbol lock test patterns (training pattern 1, training pattern 2, and training pattern 3, respectively), upon receiving the request from downstream DisplayPort sink.
- Transmission of a Nyquist pattern (repetition of D10.2 symbols without scrambling)
- Symbol Error measurement pattern
- PRBS7 bit pattern
- Custom 80-bit repeating pattern
- HBR2 Compliance EYE pattern
Only the Symbol Error measurement pattern and HBR2 Compliance EYE pattern require both scrambling and 8B/10B encoding. The PBRS7 pattern and Custom 80-bit pattern do not require scrambling or 8B/10B encoding. Training patterns 1, 2, and 3, and D10.2 test pattern require only 8B/10B encoding.
5.2. Controller Interface
The controller controls the main link data path and the sideband channel.
5.3. Sideband Channel
The AUX controller interface works with a simple serial-port-type peripheral that operates in a polled mode. It captures all bytes sent from and received by the AUX channel, which is useful for debugging. The IP clocks the AUX controller using a 16 MHz clock input (aux_clk).
5.4. Source Embedded DisplayPort (eDP) Support
The DisplayPort Intel® FPGA IP is compliant with eDP version 1.3. eDP is based on the VESA DisplayPort Standard. It has the same electrical interface and can share the same video port on the controller. The DisplayPort source IP supports:
- Full (normal) link training—default
- Fast link training—mandatory eDP feature
5.5. HDCP 1.3 TX Architecture
- Control and Status Registers Layer
- Authentication Layer
- Video Stream and Secondary Data Layer
The Nios® II processor typically drives the HDCP 1.3 TX core. The processor implements the authentication protocol. The processor accesses the IP through the Control and Status Port (tx_csr interface) using Avalon® memory-mapped interface.
The HDCP specifications requires the HDCP 1.3 TX core to be programmed with the DCP-issued production keys – Device Private Keys (Akeys) and Key Selection Vector (Aksv). The IP retrieves the key from the on-chip memory externally to the core through the HDCP Key Port (tx_hdcp interface). The on-chip memory must store the key data in the arrangement in the table below.
Address | Content |
---|---|
6'h28 | {16’d0, Aksv[39:0]} |
6'h27 | Akeys39[55:0] |
6'h26 | Akeys38[55:0] |
... | ... |
6'h01 | Akeys01[55:0] |
6'h00 | Akeys00[55:0] |
When authenticating with the HDCP 1.3 repeater device, the HDCP 1.3 TX core must perform the second part of the authentication protocol. This second part corresponds to the computation of the SHA-1 hash digest for all downstream device KSVs which are written to the registers in Control and Status Register Layer using the Control and Status Port (Avalon-MM).
The Video Stream and Secondary Data layer receives audio and video content over its Video and Secondary Data Input Port, and performs the encryption operation. The Video Stream and Secondary Data Layer detects the Encryption Status Signaling (ESS) provided by the DisplayPort TX core to determine when to encrypt frames.
You can use the HDCP 1.3 registers to perform authentication. The HDCP 1.3 TX core supports full handshaking mechanism for authentication. Every issued command should be followed by polling of the assertion of its corresponding status bit before proceeding to issuing the next command. The value of AUTH_CMD must be in one-hot format that only one bit can be set at a time.
Address | Register | R/W | Reset | Bit | Bit Name | Description |
---|---|---|---|---|---|---|
0x00 | AUTH_CMD (one-hot) | WO | 0x00000000 | 31:6 | Reserved | Reserved. |
5 | GO_V | Set to 1 to compute V and compare against V’ during authentication with repeater. Self-cleared. | ||||
4 | Reserved | Reserved. | ||||
3 | GEN_RI | Set to 1 to generate and receive R0 during authentication exchange or Ri during link integrity verification. Ri-Ri’ comparison should be performed by Nios II processor. Self-cleared. | ||||
2 | GO_KM | Set to 1 to compute master key (km). Self-cleared. | ||||
1 | GEN_AKSV | Set to 1 to request and receive Aksv. Self-cleared. | ||||
0 | GEN_AN | Set to 1 to generate and receive new true random An. Self-cleared. | ||||
0x01 | AUTH_MSGDATAIN | WO | 0x00000000 | 31:8 | Reserved | Reserved. |
7:0 | MSGDATAIN |
Write messages (in byte) from receiver in burst mode.
|
||||
0x02 | AUTH_STATUS | RO | 0x00000000 | 31 | KM_OK | Asserted by the core to indicate the received Bksv is valid. Poll KM_DONE until it is set before reading KM_OK. |
30 | V_OK | Asserted by the core to indicate V-V’ comparison is passed. Poll V_DONE until it is set before reading V_OK. | ||||
29:6 | Reserved | Reserved. | ||||
5 | V_DONE | Asserted by the core when V is generated. Self-cleared upon next GO_V is set. | ||||
4 | Reserved | Reserved | ||||
3 | RI_DONE | Asserted by the core when Ri is generated. Self-cleared upon next GEN_RI is set. | ||||
2 | KM_DONE | Asserted by the core when Km is generated. Self-cleared upon next GO_KM is set. | ||||
1 | AKSV_DONE | Asserted by the core when Aksv is ready to be read from MSGDATAOUT. Self-cleared upon next GEN_AKSV is set. | ||||
0 | AN_DONE | Asserted by the core when new random An is generated and ready to be read from MSGDATAOUT. Self-cleared upon next GEN_AN is set. | ||||
0x03 | AUTH_MSGDATAOUT | RO | 0x00000000 | 31:8 | Reserved | Reserved. |
7:0 | MSGDATAOUT |
Read messages (in byte) from the IP in burst mode.
|
||||
0x04 | VID_CTL | RW | 0x00000000 | 31:1 | Reserved | Reserved. |
0 | HDCP_ENABLE | Set to 1 to enable HDCP 1.3 encryption. Set to 0 if HDCP 1.3 encryption is not required especially when it is in unauthenticated state. | ||||
0x05 | BCAPS | RW | 0x00000000 | 31:2 | Reserved | Reserved.. |
1 | REPEATER | Downstream repeater capability. Write bit 6 (REPEATER) of Bcaps received from downstream to this offset. | ||||
0 | Reserved | Reserved. |
5.6. HDCP 2.3 TX Architecture
- Control and Status Registers Layer
- Authentication and Cryptographic Layer
- Video Stream and Secondary Data Layer
The Nios® II processor typically drives the HDCP 2.3 TX core. The processor implements the authentication protocol. The processor accesses the IP through the Control and Status Port (tx_csr interface) using Avalon® memory-mapped interface.
The HDCP specifications requires the HDCP 2.3 TX core to be programmed with the DCP-issued production key – Global Constant (lc128). The IP retrieves the key from the on-chip memory externally to the core through the HDCP Key Port (tx_hdcp interface). The on-chip memory must store the key data in the arrangement in the table below.
Address | Content |
---|---|
2'h3 | lc128[127:96] |
2'h2 | lc128[95:64] |
2'h1 | lc128[63:32] |
2'h0 | lc128[31:0] |
The Video Stream and Secondary Data Layer receives audio and video content over its Video and Secondary Data Input port, and performs the encryption operation. The Video Stream and Secondary Data Layer detects the Encryption Status Signaling (ESS) provided by the DisplayPort TX core to determine when to encrypt frames.
You can use the HDCP 2.3 registers to perform authentication. The HDCP 2.3 TX core supports full handshaking mechanism for authentication. Every issued command should be followed by polling of the assertion of its corresponding status bit before proceeding to issuing the next command. The value of CRYPTO_CMD must be in one-hot encoding format that only one bit can be set at a time.
Address | Register | R/W | Reset | Bit | Bit Name | Description |
---|---|---|---|---|---|---|
0x00 | CRPYTO_CMD (one-hot) | WO | 0x00000000 | 31:11 | Reserved | Reserved |
10 | GO_HMAC_M | Set to 1 to compute M and verify against M’. Self-cleared upon operation is busy. | ||||
9 | GO_HMAC_V | Set to 1 to compute V and verify against V’. Self-cleared upon operation is busy. | ||||
8 | GEN_RIV | Set to 1 to generate and receive new random riv. Self-cleared upon operation is busy. | ||||
7 | GEN_EDKEYKS | Set to 1 to generate and receive new random Edkey(ks). Self-cleared upon operation is busy. | ||||
6 | GO_HMAC_L | Set to 1 to compute L and verify against L’. Self-cleared upon operation is busy. | ||||
5 | GEN_RN | Set to 1 to generate and receive new random rn. Self-cleared upon operation is busy. | ||||
4 | GO_HMAC_H | Set to 1 to compute H and verify against H’. Self-cleared upon operation is busy. | ||||
3 | GO_KD | Set to 1 to compute kd (dkey0, dkey1). Self-cleared upon operation is busy. | ||||
2 | GEN_EKPUBKM | Set to 1 to generate and receive new random Ekpub(km). Self-cleared upon operation is busy. | ||||
1 | GO_SIG | Set to 1 to verify signature (certrx or SRM). Self-cleared upon operation is busy. | ||||
0 | GEN_RTX | Set to 1 to generate and receive new random rtx. Self-cleared upon operation is busy. | ||||
0x01 | CRYPTO_MSGDATAIN | WO | 0x00000000 | 31:8 | Reserved | Reserved |
7:0 | MSGDATAIN |
Write messages (in byte) from receiver in burst mode.
|
||||
0x02 | CRYPTO_STATUS | RO | 0x00000000 | 31 | SIG_OK | Asserted by the core to indicate signature verification is passed. Poll SIG_DONE until it is set before reading SIG_OK. |
30 | H_OK | Asserted by the core to indicate H-H’ comparison is passed. Poll H_DONE until it is set before reading H_OK. | ||||
29 | L_OK | Asserted by the core to indicate L-L’ comparison is passed. Poll L_DONE until it is set before reading L_OK. | ||||
28 | V_OK | Asserted by the core to indicate V-V’ comparison is passed. Poll V_DONE until it is set before reading V_OK. | ||||
27 | M_OK | Asserted by the core to indicate M-M’ comparison is passed. Poll M_DONE until it is set before reading M_OK. | ||||
26:11 | Reserved | Reserved | ||||
10 | M_DONE | Asserted by the core when M-M’ comparison is done. Self-cleared upon next GO_HMAC_M is set. | ||||
9 | V_DONE | Asserted by the core when V-V’ comparison is done. Self-cleared upon next GO_HMAC_V is set. | ||||
8 | RIV_DONE | Asserted by the core when riv is generated and ready to be read from MSGDATAOUT. Self-cleared upon next GEN_RIV is set. | ||||
7 | EDKEYKS_DONE | Asserted by the core when Edkey(ks) is generated and ready to be read from MSGDATAOUT. Self-cleared upon next GEN_EDKEYKS is set. | ||||
6 | L_DONE | Asserted by the core when L-L’ comparison is done. Self-cleared upon next GO_HMAC_L is set. | ||||
5 | RN_DONE | Asserted by the core when rn is generated and ready to be read from MSGDATAOUT. Self-cleared upon next GEN_RN is set. | ||||
4 | H_DONE | Asserted by the core when H-H’ comparison is done. Self-cleared upon next GO_HMAC_H is set. | ||||
3 | KD_DONE | Asserted by the core when kd is generated. Self-cleared upon next GO_KD is set. | ||||
2 | EKPUBKM_DONE | Asserted by the core when Ekpub(km) is generated and ready to be read from MSGDATAOUT. Self-cleared upon next GEN_EKPUBKM is set. | ||||
1 | SIG_DONE | Asserted by the core when signature verification is done. Self-cleared upon next GO_SIG is set. | ||||
0 | RTX_DONE | Asserted by the core when rtx is generated and ready to be read from MSGDATAOUT. Self-cleared upon next GEN_RTX is set. | ||||
0x03 | CRYPTO_MSGDATAOUT | RO | 0x00000000 | 31:8 | Reserved | Reserved. |
7:0 | MSGDATAOUT |
Read messages (in byte) from the IP in burst mode.
|
||||
0x04 | VID_CTL | RW | 0x00000000 | 31:2 | Reserved | Reserved. |
1 | TYPE |
|
||||
0 | HDCP_ENABLE | Set to 1 to enable HDCP 2.3 encryption. Set to 0 if HDCP 2.3 encryption is not required especially when it is in unauthenticated state. |
5.7. Source Interfaces
The following tables list the source’s port interfaces. Your instantiation contains only the interfaces that you have enabled.
Interface |
Port Type |
Clock Domain |
Port |
Direction |
Description |
---|---|---|---|---|---|
clk |
Clock |
N/A |
clk |
Input |
Clock for embedded controller |
reset |
Reset |
clk |
reset |
Input |
Reset for embedded controller |
tx_mgmt |
AV-MM |
clk | tx_mgmt_address[8:0] | Input |
32-bit word addressing address |
tx_mgmt_chipselect |
Input |
Assert for valid read or write access |
|||
tx_mgmt_read | Input |
Assert to indicate a read transfer |
|||
tx_mgmt_write | Input |
Assert to indicate a write transfer |
|||
tx_mgmt_writedata[31:0] | Input |
Data for write transfers |
|||
tx_mgmt_readdata[31:0] | Output | Data for read transfers | |||
tx_mgmt_waitrequest | Output | Asserted when the DisplayPort Intel® FPGA IP is unable to respond to a read or write request. Forces the GPU to wait until the IP is ready to proceed with the transfer. | |||
tx_mgmt_irq |
IRQ |
clk |
tx_mgmt_irq |
Output | Interrupt for embedded controller |
Interface |
Port Type |
Clock Domain |
Port |
Direction |
Description |
---|---|---|---|---|---|
xcvr_mgmt_clk |
Clock |
N/A |
xcvr_mgmt_clk | Input |
Transceiver management clock |
clk_cal |
Clock |
N/A |
clk_cal | Input |
A 50-MHz calibration clock input. This clock must be synchronous to the clock used for the Transceiver Reconfiguration block (xvcr_mgmt_clk), external to the DisplayPort source. |
tx_analog_reconfig |
Conduit |
xcvr_mgmt_clk | tx_vod[2n - 1:0] | Output |
Transceiver analog reconfiguration handshaking |
tx_emp[2n - 1:0] | Output | ||||
tx_analog_reconfig_req | Output | ||||
tx_analog_reconfig_ack | Input | ||||
tx_analog_reconfig_busy | Input | ||||
tx_reconfig |
Conduit |
xcvr_mgmt_clk | tx_link_rate[1:0] | Output |
Transceiver link rate reconfiguration handshaking |
tx_link_rate_8bits[7:0] | Output | ||||
tx_reconfig_req | Input | ||||
tx_reconfig_ack | Input | ||||
tx_reconfig_busy | Input |
Video Interface
When you turn off Enable Video input Image port, the source uses the standard HSYNC/VSYNC/DE ports in txN_vid_clk and txN_video_in interfaces.
Interface |
Port Type |
Clock Domain |
Port |
Direction |
Description |
---|---|---|---|---|---|
txN_vid_clk |
Clock |
N/A |
txN_vid_clk | Input |
Video clock |
txN_video_in |
Conduit |
txN_vid_clk | txN_vid_data[3v*p-1:0] | Input |
Video data and standard H/V synchronization video port input |
txN_vid_v_sync[p-1:0] | Input | ||||
txN_vid_h_sync[p-1:0] | Input | ||||
txN_vid_de[p-1:0] | Input |
When you turn on Enable Video input Image port, the source uses the txN_im_clk and txN_video_in_im interfaces.
Interface |
Port Type |
Clock Domain |
Port |
Direction |
Description |
---|---|---|---|---|---|
txN_im_clk |
Clock |
N/A |
txN_im_clk | Input |
Video Image clock |
txN_video_in |
Conduit |
txN_im_clk | txN_im_sol | Input |
Start of video line |
txN_im_eol | Input |
End of video line |
|||
txN_im_sof | Input |
Start of video frame |
|||
txN_im_eof | Input |
End of video frame |
|||
txN_im_data[3v*p-1:0] | Input |
Video input data |
|||
txN_im_valid[p-1:0] | Input |
Video data valid. Each bit must assert when all other signals on this port are valid and the corresponding pixel belongs to active video. |
|||
txN_im_locked | Input |
Video locked
|
|||
txN_im_interlace | Input |
Video interlaced
|
|||
txN_im_field | Input |
Video field
|
Interface |
Port Type |
Clock Domain |
Port |
Direction |
Description |
---|---|---|---|---|---|
aux_clk |
Clock |
N/A |
aux_clk | Input |
AUX channel clock |
aux_reset |
Reset |
aux_clk | aux_reset | Input |
Active-high AUX channel reset |
tx_aux |
Conduit |
aux_clk | tx_aux_in | Input |
AUX channel data input |
tx_aux_out | Output |
AUX channel data output |
|||
tx_aux_oe | Output |
Output buffer enable |
|||
tx_hpd | Input |
Hot plug detect |
|||
tx_aux_debug |
AV-ST |
aux_clk | tx_aux_debug_data[31:0] | Output |
Formatted AUX channel debug data |
tx_aux_debug_valid | Output |
Asserted when all the other signals on this port are valid |
|||
tx_aux_debug_sop | Output |
Start of packet (start of AUX request or reply) |
|||
tx_aux_debug_eop | Output |
End of packet (end of AUX request or reply) |
|||
tx_aux_debug_err | Output |
Asserted when an AUX channel bit error is detected |
|||
tx_aux_debug_cha | Output |
The channel number for data being transferred on the current cycle. Used as AUX channel data direction. 0 = Reply (from DisplayPort sink) 1 = Request (to DisplayPort sink) |
Interface |
Signal Type |
Clock Domain |
Port |
Direction |
Description |
---|---|---|---|---|---|
tx_ss_clk |
Clock |
N/A |
tx_ss_clk | Output |
TX transceiver clock out and clock for secondary stream |
Secondary Stream (txN_ss) |
AV-ST |
tx_ss_clk | txN_ss_data[127:0] | Input |
Secondary stream interface |
txN_ss_valid | Input | ||||
txN_ss_ready | Output | ||||
txN_ss_sop | Input | ||||
txN_ss_eop | Input |
Interface |
Signal Type |
Clock Domain |
Port |
Direction |
Description |
---|---|---|---|---|---|
Audio (txN_audio) |
Clock | N/A | txN_audio_clk | Input | Audio clock |
Conduit | txN_audio_clk | txN_audio_lpcm_data [m*32-1:0] | Input |
m channels of 32-bit audio sample data. |
|
txN_audio_valid | Input |
Must be asserted when valid data is available on txN_audio_lpcm_data |
|||
txN_audio_mute | Input |
Must be asserted when audio is muted |
Interface |
Port Type |
Clock Domain |
Port |
Direction |
Description |
---|---|---|---|---|---|
TX transceiver interface | Clock | N/A | tx_std_clkout[n–1:0] | Input | TX transceiver clock out. Equivalent to Link Speed Clock (ls_clk). |
Conduit | tx_std_clkout | tx_parallel_data[n*s*10–1:0] | Output | Parallel data for TX transceiver | |
Conduit | N/A | tx_pll_powerdown | Output | PLL power down for TX transceiver | |
Conduit | xcvr_mgmt_clk | tx_digitalreset[n–1:0] | Output | Resets the digital TX portion of
TX transceiver Note: Required only for Arria V, Cyclone V, and
Stratix V devices.
|
|
Conduit | N/A | tx_analogreset[n–1:0] | Output | Resets the analog TX portion of
TX transceiver Note: Required only for Arria V, Cyclone V, and
Stratix V devices.
|
|
Conduit | N/A | tx_cal_busy[n–1:0] | Input | Calibration in progress signal from TX transceiver | |
Conduit | N/A | tx_pll_locked | Input | PLL locked signal from TX transceiver |
Interface |
Port Type |
Clock Domain |
Port |
Direction |
Description |
|
---|---|---|---|---|---|---|
HDCP Clocks (hdcp_clks) | Reset | – | hdcp_reset | Input | Main asynchronous reset for HDCP. | |
Clock | – | csr_clk | Input |
HDCP clock for control and status registers. Typically, shares the Nios II processor clock (100 MHz). |
||
– | crypto_clk | Input |
HDCP 2.3 clock for authentication and cryptographic layer. You can use any clock with a frequency of up to 200 MHz. Not applicable for HDCP 1.3. Note: The clock frequency determines the
authentication latency.
|
|||
CSR Interface (tx_csr) | Avalon-MM | csr_clk | tx_csr_addr[7:0] | Input |
The Avalon-MM slave port that provides access to internal control and status register, mainly for authentication messages transfer. This interface is expected to operate at Nios II processor clock domain. Because of the extremely large bit portion of message, the IP transfers the message in burst mode with full handshaking mechanism. Write transfers always have a wait time of 0 cycle while read transfers have a wait time of 1 cycle. The addressing should be accessed as word addressing in the Platform Designer flow. For example, addressing of 4 in the Nios II software selects the address of 1 in the slave. |
|
tx_csr_wr | Input | |||||
tx_csr_rd | Input | |||||
tx_csr_wrdata[31:0] | Input | |||||
tx_csr_rddata[31:0] | Output | |||||
HDCP Key and Status Interface (tx_hdcp) | Conduit (Key) | crypto_clk |
tx_kmem_wait[0] (HDCP 2.3) tx_kmem_wait[1] (HDCP 1.3) |
Input |
Always keep this signal asserted until the key is ready to be read. |
|
tx_kmem_rdaddr[3:0] (HDCP 2.3) tx_kmem_rdaddr[9:4] (HDCP 1.3) |
Output |
Key read address bus. [3:2] = Reserved. |
||||
tx_kmem_q[31:0] (HDCP 2.3) tx_kmem_q[87:32] (HDCP 1.3) |
Input |
Key data for read transfers. Read transfer always have a wait time of 1 cycle. |
||||
Conduit | tx_std_clkout[0] | tx_hdcp1_enabled | Output | This signal is asserted by the IP if the outgoing video and secondary data are HDCP 1.3 encrypted. | ||
tx_hdcp2_enabled | Output | This signal is asserted by the IP if the outgoing video and secondary data are HDCP 2.3 encrypted. | ||||
csr_clk | tx_hdcp1_disable | Input | Assert this signal
to disable the HDCP 1.3 IP. Note: You must reset the HDCP IP
(hdcp_reset) after toggling
this signal. You must not call the software API
hdcp_main() while this signal is asserted. You
must call the software API hdcp_unauth() after
deasserting this signal.
|
|||
tx_hdcp2_disable | Input | Assert this signal
to disable the HDCP 2.3 IP. Note: You must reset the HDCP IP
(hdcp_reset) after toggling
this signal. You must not call the software API
hdcp_main() while this signal is asserted. You
must call the software API hdcp_unauth() after
deasserting this signal.
|
5.7.1. Controller Interface
The controller interface allows you to control the source from an external or on-chip controller, such as the Nios II processor.
The controller can control the DisplayPort link parameters and the AUX channel controller.
The AUX channel controller interface works with a simple serial-port-type peripheral that operates in a polled mode. Because the DisplayPort AUX protocol is a master-slave interface, the DisplayPort source (the master) starts a transaction by sending a request and then waits for a reply from the attached sink.
The controller interface includes a single interrupt source. The interrupt notifies the controller of an HPD signal state change. Your system can interrogate the DPTX_TX_STATUS register to determine the cause of the interrupt. Writing to the DPTX_TX_STATUS register clears the pending interrupt event.
5.7.2. AUX Interface
The IP has three ports that control the serial data across the AUX channel:
- Data input (tx_aux_in)
- Data output (tx_aux_out)
- Output enable (tx_aux_oe). The output enable port controls the direction of data across the bidirectional link.
These ports are clocked by the source’s 16 MHz clock (aux_clk).
The source’s AUX controller captures all bytes sent from and received by the AUX channel, which is useful for debugging. The IP provides a standard stream interface that you can use to drive an Avalon-ST FIFO component directly.
5.7.3. Video Interface
The core sends video to be encoded through the txN_video_in or txN_video_in_im interface, depending on whether or not you turn on the TX Video IM Enable parameter.
Interface | Video Data Constraints | Calculated MSA Parameters | User-provided Required MSA Parameters | User-provided Optional MSA Parameters | Adaptive Sync Support |
---|---|---|---|---|---|
txN_video_in |
|
All | None | None | No |
txN_video_in_im |
Video data temporally correct |
|
HTOTAL |
|
Yes |
5.7.3.1. Video Interface (TX Video IM Enable = 0)
You specify the data input width through the Maximum video input color depth parameter. The same input port transfers RGB and YCbCr data in 4:4:4, 4:2:2, or 4:2:0 color format. Data is most-significant bit aligned.
Color Format | Description |
---|---|
Sub-sampled 4:2:2 color format |
|
Sub-sampled 4:2:0 color format |
|
Pixel Indexes | R Position | G Position | B Position |
---|---|---|---|
0 and 1 |
Y1 |
Y0 |
|
2 and 3 |
Y3 |
Y2 |
|
4 and 5 |
Y5 |
Y4 |
|
... | ... | ... | ... |
If you set Pixel input mode to Dual or Quad, the IP sends two or four pixels in parallel, respectively. To support video resolutions with horizontal active, front porch, or back porch of a length not divisible by 2 or 4, the data enable, horizontal sync, and vertical sync signals are widened.
The following figure shows the pixel data order from the least significant bits to the most significant bits.
5.7.3.2. Video Interface (TX Video IM Enable = 1)
The txN_video_in_im ports replace the txN_video_in ports when you turn on the TX Video IM Enable parameter. The txN_video_in_im ports (N = 0 to 3) transmit video data when either the horizontal/vertical syncs or the exact pixel clock is not available. The streams need synchronization pulses at the start and end of active lines and active frames.
The timing diagram below illustrates the behavior of the ports when TX_PIXELS_PER_CLOCK = 4, TX_VIDEO_BPC = 10, and line length = 16 pixels.
- You specify the data input width through the Maximum video input color depth parameter. The core uses the same output port to transfer both RGB and YCbCr data in either 4:4:4, 4:2:2, or 4:2:0 color format.
- The data organization and pixel ordering of the txN_im_data ports are identical to the ones of the txN_vid_data signals.
- When you configure the Pixel input mode parameter to Dual or Quad, the IP sends two or four pixels in parallel respectively.
- The txN_im_valid signal is widened to support video horizontal resolutions not divisible by two or four. For example, if TX_PIXELS_PER_CLOCK = 2, txN_im_valid[0] must assert when pixel N belongs to active video and txN_im_valid[1] must assert when pixel N+1 belongs to active video.
- For interlaced video, the core samples txN_im_field when txN_im_sof asserts. When txN_im_field asserts, it marks txN_im_data as belonging to the top field.
- The frequency of the txN_im_clk signal must be equal to or higher than the frequency of the maximum video pixel clock to be transmitted divided by the pixel input mode.
- Not all clock cycles need to contain valid (active) pixel data; only those indicated by the assertion of txN_im_valid.
- The txN_video_in_im ports support the Adaptive Sync feature.
- MVID
- HWIDTH
- VHEIGHT VSP and VSW
The GPU MSA registers for the remaining MSA parameters are Read/Write and you can set the value for these parameters:
- HTOTAL and VTOTAL
- HSP and HSW
- HSTART and VSTART
5.7.4. TX Transceiver Interface
The transceiver or Native PHY IP core instance is no longer instantiated within the DisplayPort Intel® FPGA IP.
The DisplayPort Intel® FPGA IP uses a soft 8B/10B encoder. This interface provides TX encoded video data (tx_parallel_data) in either dual symbol (20-bit) or quad symbol (40-bit) mode and drives the digital reset (tx_digitalreset), analog reset (tx_analogreset), and PLL powerdown signals (tx_pll_powerdown) of the transceiver.
5.7.5. Transceiver Reconfiguration Interface
You can reconfigure the transceiver to accept single reference clock. The single reference clock is a 135 MHz clock for all bit rates: RBR, HBR, HBR2, and HBR3.
During run-time, you can reconfigure the transceiver to operate in either one of the bit rates by changing TX PLL divide ratio.
When the IP makes a request, the tx_reconfig_req port goes high. The user logic asserts tx_reconfig_ack and then reconfigures the transceiver. During reconfiguration, the user logic holds tx_reconfig_busy high. The user logic drives it low when reconfiguration completes.
5.7.6. Transceiver Analog Reconfiguration Interface
The tx_analog_reconfig interface uses the tx_vod and tx_emp transceiver management control ports. You must map these ports for the device you are using. To change these values, the core drives tx_analog_reconfig_req high. Then, the user logic sets tx_analog_reconfig_ack high to acknowledge and drives tx_analog_reconfig_busy high during reconfiguration. When reconfiguration completes, the user logic drives tx_analog_reconfig_busy low.
5.7.7. Secondary Stream Interface
The core calculates the associated parity bytes. The secondary stream interface uses the start-of-packet (SOP) and end-of-packet (EOP) to determine if the current input is a header or payload.
The ready latency is 1 clock cycle for the payload sub-packets. When core is ready, it sends the header forward. When the header is forwarded, the 16-byte payload (DB0 … DB15 and DB16 … DB31) must be available and the core must assert its associated valid signal on the next clock cycle when the output ready signal is high. The valid signal must remain low until the ready signal is high.
The core supports only 16-byte and 32-byte payloads. Payloads that contain only the first 16 data bytes can assert the EOP on the second valid pulse to terminate the packet sequence. The core clocks in the data to the secondary stream interface through tx_ss_clk. tx_ss_clk is at the same phase and frequency as the main link lane 0 clock.
You can also use the secondary stream data packet to transport HDR metadata. CTA-861-G specification defines the HDR InfoFrame packet information as Packet Type, Version, data packets, and so on. The HDR metadata must follow InfoFrame SDP version 1.3 format defined in the VESA DisplayPort Standard version 1.4a.
For example, if the CTA-861-G specification-defined HDR InfoFrame type is 0x07, the VESA DisplayPort Standard version 1.4a-defined SDP InfoFrame Header Byte 1 as secondary-data packet type is 80h + Non-audio InfoFrame type value. The Header Byte 1 (HB1 in Figure 20) must be written to 87h.
5.7.8. Audio Interface
The audio encoder is upstream of the secondary stream encoder. It generates the Audio InfoFrame, Audio Timestamp, and Audio Sample packets from the incoming audio sample data stream. Then, it sends the three packet types to the secondary stream encoder before they are transmitted to the downstream sink device.
- Channel 1 audio data should be present at txN_audio_lpcm_data[31:0]
- Channel 2 audio data should be present at txN_audio_lpcm_data[63:32] and so on.
The IP requires a txN_audio_valid signal for designs in which the txN_audio_clk signal is higher than the actual sample clock. The txN_audio_valid signal qualifies the audio data on the txN_audio_lpcm_data input. If txN_audio_clk is the actual sample clock, you can tie the txN_audio_valid signal to 1.
The figure and table below illustrate the audio sample data bits and bit field definitions, respectively.
Bit Name |
Bit Position |
Description |
---|---|---|
Audio sample word |
Byte 2, bits 7:0 Byte 1, bits 7:0 Byte 0, bits 7:0 |
Audio data. The data content depends on the audio coding type. For LPCM audio, the audio most significant bit (MSB) is placed in byte 2, bit 7. If the audio data size is less than 24 bits, unused least significant bits (LSB) must be zero padded. |
V |
Byte 3, bit 0 |
Validity flag. |
U |
Byte 3, bit 1 |
User bit. |
C |
Byte 3, bit 2 |
Channel status. |
P |
Byte 3, bit 3 |
Parity bit. |
PR |
Byte 3, bits 4 - 5 |
Preamble code and its correspondence with IEC-60958 preamble: 00: Subframe 1 and start of the audio block (11101000 preamble) 01: Subframe1 (1110010 preamble) 10: Subframe 2 (1110100 preamble) |
R |
Byte3, bit 6 |
Reserved bit; must be 0. |
SP |
Byte 3, bit 7 |
Sample present bit: 1: Sample information is present and can be processed. 0: Sample information is not present. All one-sample channels, used or unused, must have the same sample present bit value. This bit is useful for situations in which 2-channel audio is transported over a 4-lane main link. In this operation, main link lanes 2 and 3 may or may not have the audio sample data. This bit indicates whether the audio sample is present or not. |
When you configure the DisplayPort Intel® FPGA IP for 2 or 8 channels, you can transmit any number of audio channels fewer than or equal to the number of channels you selected.
- You must configure the source audio register's CH_COUNT bits to 000b using the embedded controller.
- You also need to set the SP bit to 1 and the other bits to 0 on the txN_audio_lpcm_data[63:32] signal. The IP performs 2-channel layout mapping for 1 and 2 audio channels, which requires the SP bit to be the same for all one-sample channels.
- You must configure the source audio register's CH_COUNT bits to 010b using the embedded controller.
- You also need to provide the data as shown in the figure below.
The DisplayPort Intel® FPGA IP internally calculates the Maud based on a fixed (8000h) to generate the Audio Timestamp packet. The IP generates the Audio InfoFrame packet based on the information from the DisplayPort source audio registers: LFEBPL, CA, LSV, and DM_INH. The IP continues transmitting the Audio Timestamp, Audio InfoFrame, and Audio Sample packets even when the main video stream is no longer transmitting. When there is no video stream, the IP transmits an Audio Sample packet after each BS symbol, and transmits an Audio Timestamp and Audio InfoFrame once after every 512th BS symbol set.
The source automatically generates the Audio InfoFrame and fills it with only information about the number of channels used.
Use the audio channel status to provide any information about the audio stream needed by downstream devices.
5.8. Source Clock Tree
The source uses the following clocks:
- Local pixel clock (txN_vid_clk), which clocks video data into the IP.
- Main link clock (tx_ss_clk), which clocks data out of the IP and into the high-speed serial output (HSSI) components. The main link clock is the output of the CMU PLL clock. You can supply the CMU PLL with the single reference clock (135 MHz). You can use other frequencies by changing the CMU PLL divider ratios and/or reconfiguring the transceiver. The 20- or 40- bit data fed to the HSSI is synchronized to a single HSSI[0] clock. If you select the dual symbol mode, this clock is equal to the link rate divided by 20 (270, 135, or 81 MHz). If you select the quad symbol mode, this clock is equal to the link rate divided by 40 (202.5, 135, 67.5, or 40.5 MHz). The core supports only asynchronous local pixel clock and main link clock.
- 16 MHz clock (aux_clk), which the IP requires to encode or decode the AUX channel.
- A separate clock (clk) clocks the Avalon-MM interface.
- txN_audio_clk for the audio interface.
6. DisplayPort Sink
The DisplayPort sink consists of a DisplayPort decoder block, a transceiver management block, a controller interface block, and an HDCP interface block with an Avalon® memory-mapped interface for connecting with an embedded controller such as the Nios II processor.
The device transceiver sends 20-bit (dual symbol) or 40-bit (quad symbol) parallel DisplayPort data to the sink. Each data lane is clocked in to the IP by its own respective clock output from the transceiver. Inside the sink, the four independent clock domains are synchronized to the lane 0 clock. Then, the IP performs the following actions:
- The IP aligns the data stream and performs 8B/10B decoding.
- The IP deskews the data and then descrambles it.
- The IP splits the
unscrambled data stream into parallel paths.
- The SS decoder block performs secondary stream decoding, which the core transfers into the rx_ss_clk domain through a DCFIFO.
- The main data path extracts all pixel data from the incoming stream. Then, the gearbox block resamples the pixel data into the current bit-per-pixel data width. Next, the IP core crosses the pixel data into the rxN_vid_clk domain through a DCFIFO. Finally, the IP steers the data into a single, dual, or quad pixel data stream.
- MSA decode path.
- Video decode path.
You configure the sink to output the video data as a proprietary data stream. You specify the output pixel data width at 6, 8, 10, 12, or 16 bpc. This format can interface with downstream Video and Image Processing (VIP) Suite components.
The AUX controller can operate in an autonomous mode in which the sink controls all AUX channel activity without an external embedded controller. The IP outputs an AUX debugging stream so that you can inspect the activity on the AUX channel in real time.
6.1. Sink Embedded DisplayPort (eDP) Support
The DisplayPort Intel® FPGA IP is compliant with eDP version 1.3. eDP is based on the VESA DisplayPort Standard. It has the same electrical interface and can share the same video port on the controller. The DisplayPort sink supports:
- Full (normal) link training—default
- Fast link training—mandatory eDP feature
- Black video—mandatory eDP feature
6.2. Sink Non-GPU Mode Support
The DisplayPort sink capability registers are implemented in the IP and support limited features.
DPCD Offset | DPCD Register | Default Value | Description |
---|---|---|---|
0000h |
DPCD_REV |
12h |
DPCD revision 1.2 |
0001h |
MAX_LINK_RATE |
Configurable through parameter editor |
|
0002h |
MAX_LANE_COUNT |
Configurable through parameter editor |
|
POST_LT_ADJ_REQ_SUPPORTED |
0b |
Not supported | |
TPS3_SUPPORTED |
1b |
Supported | |
ENHANCED_FRAME_CAP |
0b |
Not supported | |
0003h |
MAX_DOWNSPREAD |
1b |
Down-spread up to 0.5% |
NO_AUX_TRANSACTION_LINK_TRAINNG |
1b |
Supported | |
TPS4_SUPPORTED |
1b |
Supported | |
0005h |
DOWN_STREAM_PORT_PRESENT |
00h |
Not supported |
0006h |
MAIN_LINK_CHANNEL_CODING |
01h |
8B/10B |
0007h |
MSA_TIMING_PAR_IGNORED |
0b |
Not supported |
OUI Support |
1b |
Supported | |
000Eh |
TRAINING_AUX_RD_INTERVAL |
00h |
|
EXTENDED_RECEIVER_CAPABILITY_FIELD_PRESENT |
1b |
Supported |
6.3. HDCP 1.3 RX Architecture
The HDCP 1.3 RX core is fully autonomous. For DisplayPort application, the HDCP transmitter and the HDCP receiver communicates the HDCP register values over the AUX channel. Turn on the Enable GPU control parameter and use a Nios® II processor to drive the HDCP 1.3 RX core through the HDCP Register Port ( Avalon® memory-mapped interface). The HDCP Register Port is not exposed and will be automatically driven when you enable the Support HDCP 1.3 parameter.
The HDCP specifications requires the HDCP 1.3 RX core to be programmed with the DCP-issued production key – Device Private Keys (Bkeys) and Key Selection Vector (Bksv). The IP retrieves the key from the on-chip memory externally to the core through the HDCP Key Port (rx_hdcp interface). The on-chip memory must store the key data in the arrangement shown in the table below.
Address | Content |
---|---|
6'h28 | {16’d0, Bksv[39:0]} |
6'h27 | Bkeys39[55:0] |
6'h26 | Bkeys38[55:0] |
... | ... |
6'h01 | Bkeys01[55:0] |
6'h00 | Bkeys00[55:0] |
The Video Stream and Secondary Data Layer receives audio and video content over its Video and Secondary Data Input Port, and performs the decryption operation. The Video Stream and Secondary Data Layer detects the Encryption Status Signaling (ESS) provided by the DisplayPort IP to determine when to decrypt frames.
To implement the HDCP 1.3 RX core as a repeater upstream interface, the IP must propagate certain information such as KSV list and Bstatus to the upstream transmitter and to be used for SHA-1 hash digest. The repeater downstream interface (TX) must provide this information through the Repeater Message Port (rx_rpt_msg interface) using the Avalon® memory-mapped interface. You can use the same clock source to drive the clocking for the HDCP Register Port (or the controller interface of the DisplayPort Intel® FPGA IP) and Repeater Message Port.
The mapping for the RX registers defined in the following table is equivalent to the address space for HDCP 1.3 receiver defined in the HDCP specification.
Address | Register | R/W | Reset | Bit | Bit Name | Description |
---|---|---|---|---|---|---|
0x00 | BKSV0 | RO | – | 7:0 | – | Bit [7:0] of HDCP Receiver KSV. |
0x01 | BKSV1 | 7:0 | Bit [15:8] of HDCP Receiver KSV. | |||
0x02 | BKSV2 | 7:0 | Bit [23:16] of HDCP Receiver KSV. | |||
0x03 | BKSV3 | 7:0 | Bit [31:24] of HDCP Receiver KSV. | |||
0x04 | BKSV4 | 7:0 | Bit [39:32] of HDCP Receiver KSV. | |||
0x05 | RO_PRIME0 | RO | 0x00 | 7:0 | – | Authentication response. Bit [7:0] of RO’. |
0x06 | RO_PRIME1 | 7:0 | – | Authentication response. Bit [15:8] of RO’. | ||
0x07 | AKSV0 | WO | 0x00 | 7:0 | – | Bit [7:0] of HDCP Transmitter KSV. |
0x08 | AKSV1 | 7:0 | Bit [15:8] of HDCP Transmitter KSV. | |||
0x09 | AKSV2 | 7:0 | Bit [23:16] of HDCP Transmitter KSV. | |||
0x0A | AKSV3 | 7:0 | Bit [31:24] of HDCP Transmitter KSV. | |||
0x0B | AKSV4 | 7:0 | Bit [39:32] of HDCP Transmitter KSV. | |||
0x0C | AN0 | WO | 0x00 | 7:0 | – | Bit [7:0] of HDCP Session Random Number An. |
0x0D | AN1 | 7:0 | Bit [15:8] of HDCP Session Random Number An. | |||
0x0E | AN2 | 7:0 | Bit [23:16] of HDCP Session Random Number An. | |||
0x0F | AN3 | 7:0 | Bit [31:24] of HDCP Session Random Number An. | |||
0x10 | AN4 | 7:0 | Bit [39:32] of HDCP Session Random Number An. | |||
0x11 | AN5 | 7:0 | Bit [47:40] of HDCP Session Random Number An. | |||
0x12 | AN6 | 7:0 | Bit [55:48] of HDCP Session Random Number An. | |||
0x13 | AN7 | 7:0 | Bit [63:56] of HDCP Session Random Number An. | |||
0x14 | V_PRIME_H0_0 | RO | 0x00 | 7:0 | – | H0 part of SHA-1 hash value used in the authentication protocol HDCP repeaters. Bit [7:0] of H0 value. |
0x15 | V_PRIME_H0_1 | 7:0 | Bit [15:8] of H0 value. | |||
0x16 | V_PRIME_H0_2 | 7:0 | Bit [23:16] of H0 value. | |||
0x17 | V_PRIME_H0_3 | 7:0 | Bit [31:24] of H0 value. | |||
0x18 | V_PRIME_H1_0 | RO | 0x00 | 7:0 | – | H1 part of SHA-1 hash value used in the authentication protocol HDCP repeaters. Bit [7:0] of H1 value. |
0x19 | V_PRIME_H1_1 | 7:0 | Bit [15:8] of H1 value. | |||
0x1A | V_PRIME_H1_2 | 7:0 | Bit [23:16] of H1 value. | |||
0x1B | V_PRIME_H1_3 | 7:0 | Bit [31:24] of H1 value. | |||
0x1C | V_PRIME_H2_0 | RO | 0x00 | 7:0 | – | H2 part of SHA-1 hash value used in the authentication protocol HDCP repeaters. Bit [7:0] of H2 value. |
0x1D | V_PRIME_H2_1 | 7:0 | Bit [15:8] of H2 value. | |||
0x1E | V_PRIME_H2_2 | 7:0 | Bit [23:16] of H2 value. | |||
0x1F | V_PRIME_H2_3 | 7:0 | Bit [31:24] of H2 value. | |||
0x20 | V_PRIME_H3_0 | RO | 0x00 | 7:0 | – | H3 part of SHA-1 hash value used in the authentication protocol HDCP repeaters. Bit [7:0] of H3 value. |
0x21 | V_PRIME_H3_1 | 7:0 | Bit [15:8] of H3 value. | |||
0x22 | V_PRIME_H3_2 | 7:0 | Bit [23:16] of H3 value. | |||
0x23 | V_PRIME_H3_3 | 7:0 | Bit [31:24] of H3 value. | |||
0x24 | V_PRIME_H4_0 | RO | 0x00 | 7:0 | – | H4 part of SHA-1 hash value used in the authentication protocol HDCP repeaters. Bit [7:0] of H4 value. |
0x25 | V_PRIME_H4_1 | 7:0 | Bit [15:8] of H4 value. | |||
0x26 | V_PRIME_H4_2 | 7:0 | Bit [23:16] of H4 value. | |||
0x27 | V_PRIME_H4_3 | 7:0 | Bit [31:24] of H4 value. | |||
0x28 | BCAPS | RO | 0x000 | 7:2 | Reserved |
These bits read as 0. |
1 | REPEATER |
HDCP repeater capability. 0 = Receiver is not a repeater. 1 = Receiver is a repeater. |
||||
0 | HDCP_CAPABLE | This bit reads as 1. | ||||
0x29 | BSTATUS | RO | 0x00 | 7:4 | Reserved | These bits read as 0. |
3 | REAUTHENTICATION_REQUEST | Refer to HDCP on DisplayPort specification version 1.3 for more information. | ||||
2 | LINK_INTEGRITY_FAILURE | |||||
1 | RO'_AVAILABLE | |||||
0 | READY | |||||
0x2A | BINFO0 | RO | 0x00 | 7 | MAX_DEVS_EXCEEDED | Topology error indicator. When set to 1, more than 127 downstream devices are attached. |
6:0 | DEVICE_COUNT | Total number of attached downstream devices. Always zero for HDCP receivers. This count does not include the HDCP repeater itself, but only the downstream devices from the HDCP repeater. | ||||
0x2B | BINFO1 | RO | 0x00 | 7:4 | Reserved | These bits read as 0. |
3 | MAX_CASCADE_EXCEEDED | Topology error indicator. When set to 1, more than 7 levels of video repeater are cascaded together. | ||||
2:0 | DEPTH | 3-bit repeater cascade depth. This value gives the number of attached levels throughout the connection topology. | ||||
0x2C | KSV_FIFO | RO | 0x00 | 7:0 | – | Key selection vector FIFO. Used to pull downstream KSVs from HDCP repeaters using auto-incrementing address. All bytes read as 0x00 for HDCP receivers that are not HDCP repeaters (REPEATER=0). |
0x3E | CTRL | WO | 0x00 | 31 | Reserved | Reserved. |
30 | CP_IRQ_DET | Set to 1 to reset the CP_IRQ_STATUS flag in the STATUS register. | ||||
29 | KSV_FIFO_OFFSET_RST | Set to 1 to reset the offset of the KSV_FIFO register. | ||||
28 | EXIT_AUTH | Exit authenticated state. | ||||
27:0 | Reserved | Reserved. | ||||
0x3F | STATUS | RO | 0x00 | 31:20 | Reserved | Reserved. |
19 | AUTHENTICATED |
0: HDCP 1.3x event is in authenticated state. 1: HDCP 1.3x event is in unauthenticated state. |
||||
18 | CP_IRQ_STATUS |
0: No HDCP 1.3 event. 1: An HDCP 1.3 event occurred and HPD interrupts were generated. |
||||
17:0 | Reserved | Reserved. |
Address | Register | R/W | Reset | Bit | Bit Name | Description |
---|---|---|---|---|---|---|
0x00 | RPT_KSV_LIST | WO | 0x00000000 | 31:8 | Reserved | Reserved |
7:0 | KSV_LIST | Byte write KSV List in big endian order. | ||||
0x01 | RPT_BSTATUS | RW | 0x00000000 | 31:19 | Reserved | Reserved |
18 | REQUEST | Read-only. Asserted by the core to request for KSV_LIST and BSTATUS. This usually happens when re-authentication is triggered by the connected upstream. Note that when REQUEST is asserted, the READY should also be asserted. | ||||
17 | READY | Read-only. Asserted by the core to indicate KSV_LIST and BSTATUS are processed. Write KSV_LIST and BSTATUS after this bit is asserted. | ||||
16 | VALID | Set to 1 after KSV_LIST and BSTATUS are written. Self-cleared by the core after KSV_LIST and BSTATUS are read. | ||||
15:0 | BSTATUS |
[15:12]: Reserved. [11]: MAX_CASCADE_EXCEEDED [10:8]: DEPTH [7]: MAX_DEVS_EXCEEDED [6:0]: DEVICE_COUNT |
||||
0x02 | RPT_MISC | RW | – | 31:1 | Reserved | Reserved. |
0 | REPEATER |
Set to 0 if no downstream is connected or if the connected downstream is not HDCP 1.3-capable. This means the receiver IP is an end-point receiver rather than a repeater. Set to 1 if the connected downstream is HDCP-capable. |
6.4. HDCP 2.3 RX Architecture
The HDCP 2.3 RX core is fully autonomous. For DisplayPort application, the HDCP transmitter and the HDCP receiver communicates the HDCP register values over the AUX channel. Turn on the Enable GPU control parameter and use a Nios® II processor to drive the HDCP 2.3 RX core through the HDCP Register Port ( Avalon® memory-mapped interface). The HDCP Register Port is not exposed and will be automatically driven when you enable the Support HDCP 2.3 parameter.
The HDCP specifications requires the HDCP 2.3 RX core to be programmed with the DCP-issued production key – Global Constant (lc128), RSA private key (kprivrx) and RSA Public Key Certificate (certrx). The IP retrieves the key from the on-chip memory externally to the core through the HDCP Key Port (rx_hdcp interface). The on-chip memory must store the key data in the arrangement shown in the table below.
Address | Content |
---|---|
8'hE3 | lc128[127:96] |
8'hE2 | lc128[95:64] |
8'hE1 | lc128[63:32] |
8'hE0 | lc128[31:0] |
8'hDF | kprivrx_p[511:480] |
... | ... |
8'hD0 | kprivrx_p[31:0] |
8'hCF | kprivrx_q[511:480] |
... | ... |
8'hC0 | kprivrx_q[31:0] |
8'hBF | kprivrx_dp[511:480] |
... | ... |
8'hB0 | kprivrx_dp[31:0] |
8'hAF | kprivrx_dq[511:480] |
... | ... |
8'hA0 | kprivrx_dq[31:0] |
8'h9F | kprivrx_qinv[511:480] |
... | ... |
8'h90 | kprivrx_qinv[31:0] |
8'h83–8'h8F | Reserved |
8'h82 | {16’d0, certrx[4175:4160]} |
8'h81 | certrx[4159:4128] |
... | ... |
8'h01 | certrx[63:32] |
8'h00 | certrx[31:0] |
The Video Stream and Secondary Data Layer receives audio and video content over its Video and Secondary Data Input Port, and performs the decryption operation. The Video Stream and Secondary Data Layer detects the Encryption Status Signaling (ESS) provided by the DisplayPort IP to determine when to decrypt frames.
To implement the HDCP 2.3 RX core as a repeater upstream interface, the IP must propagate certain information such as ReceiverID List and RxInfo to the upstream transmitter and to be used for HMAC computation. The repeater downstream interface (TX) must provide this information using the Repeater Message Port (rx_rpt_msg interface) using the Avalon® memory-mapped interface. You can use the same clock source to drive the clocking for the HDCP Register Port (or the controller interface of the DisplayPort Intel® FPGA IP) and Repeater Message Port.
The mapping for the RX registers and RX Repeater registers are defined in the following tables.
Address | Register | R/W | Reset | Bit | Bit Name | Description |
---|---|---|---|---|---|---|
0x40 | CTRL | RW | 0x00000000 | 31 | Reserved | Reserved. |
30 | CP_IRQ_DET | Write-only. Set to 1 to reset the CP_IRQ_STATUS flag in the RXSTATUS register. | ||||
29 | STOP_DET | Write-only. Set to 1 to indicate the end of HDCP messages. | ||||
28:1 | Reserved | Reserved. | ||||
0 | TYPE |
0: Type 0 content stream. 1: Type 1 content stream. |
||||
0x41 | RXSTATUS | RO | 0x00000000 | 31:19 | Reserved | Reserved. |
18 | CP_IRQ_STATUS |
0: No HDCP 2.3 event. 1: An HDCP 2.3 event occurred and HPD interrupts were generated. |
||||
17:5 | Reserved | Reserved. | ||||
4 | LINK_INTEGRITY_FAILURE | RxStatus[4:0]. Refer to the HDCP on DisplayPort Specification version 2.3 for more information. |
||||
3 | REAUTH_IRQ | |||||
2 | PAIRING_AVAILABLE | |||||
1 | HPRIME_AVAILABLE | |||||
0 | READY | |||||
0x42 | MESSAGES | RW | 0x00000000 | 31:8 | Reserved | Reserved. |
7:0 | MESSAGES | Write or read messages (in bytes) to or from the IP in burst mode. | ||||
0x43 | RXCAPS | RO | 0x00020002 | 31:24 | Reserved | Reserved. |
23:16 | VERSION | Default value is 0x02. | ||||
15:2 | RECEIVER_CAPABILITY_MASK | Reserved. Read as 0. | ||||
1 | HDCP_CAPABLE | Default value is 0x01. Indicates that the RX is HDCP 2.3 capable. | ||||
0 | REPEATER |
0: Indicates that the RX is an endpoint receiver. 1: Indicates that the RX is a repeater that supports downstream connections. |
Address | Register | R/W | Reset | Bit | Bit Name | Description |
---|---|---|---|---|---|---|
0x00 | RPT_RCVDID_LIST | WO | 0x00000000 | 31:8 | Reserved | Reserved |
7:0 | RCVDID_LIST | Byte write ReceiverID_List in big endian order. | ||||
0x01 | RPT_RXINFO | RW | 0x00000000 | 31:19 | Reserved | Reserved |
18 | REQUEST | Read-only. Asserted by the core to request for RCVDID_LIST and RXINFO. This usually happens when re-authentication is triggered by the connected upstream. Note that when REQUEST is asserted, the READY should also be asserted. | ||||
17 | READY | Read-only. Asserted by the core to indicate RCVDID_LIST and RXINFO are processed. Write RCVDID_LIST and RXINFO after this bit is asserted. | ||||
16 | VALID | Set to 1 after RCVDID_LIST and RXINFO are written. Self-cleared by the core after RCVDID_LIST and RXINFO are read. | ||||
15:0 | RXINFO |
[15:12]: Reserved. [11:9]: DEPTH [8:4]: DEVICE_COUNT [3]: MAX_DEVS_EXCEEDED [2]: MAX_CASCADE_EXCEEDED [1]: HDCP2_REPEATER_DOWNSTREAM [0]: HDCP1_DEVICE_DOWNSTREAM |
||||
0x02 | RPT_TYPE | RO | 0x00000000 | 31:9 | Reserved | Reserved |
8 | VALID | Asserted by the core to indicate content stream TYPE is valid. Self-cleared by the core after TYPE is read. | ||||
7:0 | TYPE |
0x00: Type 0 Content Stream 0x01: Type 1 Content Stream 0x02-0xFF: Reserved. Treated as Type 1 Content Stream. |
||||
0x03 | RPT_MISC | RW | 0x00000000 | 31:1 | Reserved | Reserved. |
0 | REPEATER |
Set to 0 if no downstream is connected or if the connected downstream is not HDCP 2.3-capable. This means the receiver IP is an end-point receiver rather than a repeater. Set to 1 if the connected downstream is HDCP- capable. |
6.5. Sink Interfaces
The following tables summarize the sink’s interfaces. Your instantiation contains only the interfaces that you have enabled.
Interface |
Port Type |
Clock Domain |
Port |
Direction |
Description |
---|---|---|---|---|---|
clk |
Clock |
N/A |
clk |
Input |
Clock for embedded controller. |
reset |
Reset |
clk | reset |
Input |
Active-high reset signal for embedded controller. |
rx_mgmt |
AV-MM |
clk | rx_mgmt_address[8:0] |
Input |
32-bit word addressing address. |
rx_mgmt_chipselect |
Input |
Must be asserted for valid read or write access. |
|||
rx_mgmt_read |
Input |
Must be asserted to indicate a read transfer. |
|||
rx_mgmt_write |
Input |
Must be asserted to indicate a write transfer. |
|||
rx_mgmt_writedata[31:0] |
Input |
Data for write transfers. |
|||
rx_mgmt_readdata[31:0] |
Output |
Data for read transfers. |
|||
rx_mgmt_waitrequest |
Output |
Asserted when the DisplayPort Intel® FPGA IP is unable to respond to a read or write request. Forces the GPU to wait until the IP is ready to proceed with the transfer. |
|||
rx_mgmt_irq |
IRQ |
clk |
rx_mgmt_irq |
Output |
The IP asserts this signal to issue an interrupt to the GPU. |
Interface |
Port Type |
Clock Domain |
Port |
Direction |
Description |
---|---|---|---|---|---|
xcvr_mgmt_clk |
Clock |
N/A |
xcvr_mgmt_clk |
Input |
Transceiver management clock. |
clk_cal |
Clock |
N/A |
clk_cal | Input |
Calibration clock. |
rx_reconfig |
Conduit |
xcvr_mgmt_clk | rx_link_rate[1:0] |
Output |
Transceiver link rate reconfiguration handshaking. |
rx_link_rate_8bits[7:0] |
Output |
||||
rx_reconfig_req |
Output |
||||
rx_reconfig_ack |
Input |
||||
rx_reconfig_busy |
Input |
||||
rx_analog_reconfig |
Conduit |
xcvr_mgmt_clk | rx_vod [2n-1:0] |
Output |
Transceiver analog reconfiguration handshaking. |
rx_emp [2n-1:0] |
Output |
||||
rx_analog_reconfig_req |
Output |
Interface |
Port Type |
Clock Domain |
Port |
Direction |
Description |
---|---|---|---|---|---|
rxN_vid_clk |
Clock |
N/A |
rxN_vid_clk |
Input |
Video clock. |
rxN_video_out |
Conduit |
rx_vid_clk | rxN_vid_valid[p-1:0] |
Output |
Each bit is asserted when all other signals (except rxN_vid_overflow) on this port are valid and the corresponding pixel belongs to active video. Width configurable. |
rxN_vid_sol |
Output |
Start of video line. |
|||
rxN_vid_eol |
Output |
End of video line. |
|||
rxN_vid_sof |
Output |
Start of video frame. |
|||
rxN_vid_eof |
Output |
End of video frame. |
|||
rxN_vid_locked |
Output |
1 = Video locked 0 = Video unlocked |
|||
rxN_vid_overflow |
Output |
1 = Video data overflow detected 0 = No overflow detected This signal is always valid. |
|||
rxN_vid_interlace |
Output |
1 = Interlaced 0 = Progressive |
|||
rxN_vid_field |
Output |
1 = Top field 0 = Bottom field (or progressive) |
|||
rxN_vid_data[3v*p-1:0] |
Output |
Width configurable. |
Interface |
Port Type |
Clock Domain |
Port |
Direction |
Description |
---|---|---|---|---|---|
aux_clk |
Clock |
N/A |
aux_clk |
Input |
AUX channel clock. |
aux_reset |
Reset |
aux_clk | aux_reset |
Input |
Active-high AUX channel reset. |
rx_aux |
Conduit |
aux_clk | rx_aux_in |
Input |
AUX channel data input. |
rx_aux_out |
Output |
AUX channel data output. |
|||
rx_aux_oe |
Output |
Output buffer enable. |
|||
rx_hpd |
Output |
Hot plug detect. |
|||
rx_cable_detect |
Input |
Upstream cable detect. |
|||
rx_pwr_detect |
Input |
Upstream power detect. |
|||
rx_aux_debug |
AV-ST |
aux_clk | rx_aux_debug_data[31:0] |
Output |
Formatted AUX channel debug data. |
rx_aux_debug_valid |
Output |
Asserted when all the other signals on this port are valid. |
|||
rx_aux_debug_sop |
Output |
Start of packet (start of AUX request or reply). |
|||
rx_aux_debug_eop |
Output |
End of packet (end of AUX request or reply). |
|||
rx_aux_debug_err |
Output |
Indicates if the IP detects an error in the current byte. |
|||
rx_aux_debug_cha |
Output |
The channel number for data being transferred on the current cycle. Used as AUX channel data direction. 1 = Reply (to DisplayPort source) 0 = Request (from DisplayPort source) |
|||
EDID (rx_edid) |
AV-MM | aux_clk | rx_edid_address[7:0] |
Output |
8-bit byte addressing address. |
rx_edid_read |
Output |
Asserted to indicate a read transfer. |
|||
rx_edid_write |
Output |
Asserted to indicate a write transfer. |
|||
rx_edid_writedata[7:0] |
Output |
Data for write transfers. |
|||
rx_edid_readdata[7:0] |
Input |
Data for read transfers. |
|||
rx_edid_waitrequest |
Input |
Must be asserted when the Slave is unable to respond to a read or write request. Forces the DisplayPort Intel® FPGA IP to wait until the Slave is ready to proceed with the transfer. |
Interface |
Signal Type |
Clock Domain |
Port |
Direction |
Description |
---|---|---|---|---|---|
Link Parameters (rx_params) |
Conduit |
aux_clk | rx_lane_count[4:0] |
Output |
Sink current link lane count value. |
Debugging (rxN_stream) |
Conduit |
rx_ss_clk | rxN_stream_data[4*8*s–1:0] |
Output |
Post scrambler data. |
rxN_stream_ctrl[4*s–1:0] |
Output |
Post scrambler comma marker. The IP asserts each bit when the relative 8-bit byte is a comma code, and deasserts each bit when the byte is a data value. Bit 0 qualifies rxN_stream_data[7:0] byte, bit 1qualifies the rxN_stream_data[15:8] byte, and so on. |
|||
rxN_stream_valid |
Output |
Asserted for one clock cycle when rxN_stream_data[63:0] and rxN_stream_ctrl[7:0] are valid. |
|||
rxN_stream_clk |
Output |
Port clock. |
Interface |
Signal Type |
Clock Domain |
Port |
Direction |
Description |
---|---|---|---|---|---|
rx_ss_clk |
Clock |
N/A |
rx_ss_clk |
Output |
Clock. |
MSA (rxN_msa_conduit) |
Conduit |
rx_ss_clk | rxN_msa[216:0] |
Output |
Output for current MSA parameters received from the source. |
Secondary Stream (rxN_ss) |
AV-ST |
rx_ss_clk |
rxN_ss_data[159:0] |
Output |
Secondary stream interface. |
rxN_ss_valid |
Output |
||||
rxN_ss_sop |
Output |
||||
rxN_ss_eop |
Output |
Interface |
Signal Type |
Clock Domain |
Port |
Direction |
Description |
---|---|---|---|---|---|
Audio (rxN_audio) |
Conduit | rx_ss_clk | rxN_audio_lpcm_data[m*32–1:0] |
Output |
N channels of 32-bit audio sample data. |
rxN_audio_valid |
Output |
Asserted when valid data is available on rxN_audio_lpcm_data. |
|||
rxN_audio_mute |
Output |
Asserted when audio is muted. |
|||
rxN_audio_infoframe[39:0] |
Output |
40-bit bundle containing the Audio InfoFrame packet. |
Interface |
Port Type |
Clock Domain |
Port |
Direction |
Description |
---|---|---|---|---|---|
RX transceiver interface | Clock |
N/A |
rx_std_clkout[n–1:0] |
Input |
RX transceiver recovered clock. Equivalent to Link Speed Clock (ls_clk). |
Conduit | rx_xcvr_clkout | rx_parallel_data[n*s*10–1:0] |
Input |
Parallel data from RX transceiver. |
|
Conduit | rx_xcvr_clkout | rx_restart |
Output |
Use to reset the RX PHY Reset Controller when the RX data loses alignment. Note: Required for
Intel®
Arria® 10,
Intel®
Cyclone® 10 GX,
and
Intel®
Stratix® 10
devices. Not used in Arria V, Cyclone V, and Stratix V
devices.
|
|
Conduit |
N/A |
rx_is_lockedtoref[n–1:0] |
Input |
When asserted, indicates that the RX CDR PLL is locked to the reference clock. |
|
Conduit |
N/A |
rx_is_lockedtodata[n–1:0] |
Input |
When asserted, indicates that the RX CDR PLL is locked to the incoming data. |
|
Conduit | rx_xcvr_clkout | rx_bitslip[n–1:0] |
Output |
Use to control bit slipping manually. |
|
Conduit |
N/A |
rx_cal_busy[n–1:0] |
Input |
Calibration in progress signal from RX transceiver. |
|
Conduit | xcvr_mgmt_clk | rx_analogreset[n–1:0] |
Output |
When asserted, resets the RX CDR. Note: Required only for Arria V, Cyclone V, and Stratix V
devices.
|
|
Conduit | xcvr_mgmt_clk | rx_digitalreset[n–1:0] |
Output |
When asserted, resets the RX PCS. Note: Required only for Arria V, Cyclone V, and Stratix V
devices.
|
|
Conduit | xcvr_mgmt_clk | rx_set_locktoref[n–1:0] |
Output |
Forces the RX CDR circuitry to lock to the phase and frequency of the input reference clock. |
|
Conduit | xcvr_mgmt_clk | rx_set_locktodata[n–1:0] |
Output |
Forces the RX CDR circuitry to lock to the received data. |
Interface |
Port Type |
Clock Domain |
Port |
Direction |
Description |
|
---|---|---|---|---|---|---|
HDCP Clocks (hdcp_clks) | Reset | – | hdcp_reset | Input | Main asynchronous reset for HDCP. | |
Clock | – | crypto_clk | Input |
HDCP 2.3 clock for authentication and cryptographic layer. You can use any clock with a frequency up to 200 MHz. Not applicable for HDCP 1.3. Note: The clock frequency determines the
authentication latency.
|
||
– | rpt_msg_clk | Input | HDCP clock for the
Repeater registers in the Control and Status Register layer. Typically, shares the clock (100 MHz) that drives the repeater downstream Nios® II processor. |
|||
Repeater Message Interface (rx_rpt_msg) | Avalon-MM | rpt_msg_clk | rx_rpt_msg_addr[7:0] | Input |
The Avalon memory-mapped slave port that provides access to the Repeater registers, mainly for ReceiverID_List and RxInfo. This interface is expected to operate at repeater downstream Nios II processor clock domain. Because of the extremely large bit portion of message, the IP transfers the message in burst mode with full handshaking mechanism. Write transfers always have a wait time of 0 cycle while read transfers have a wait time of 1 cycle. The addressing should be accessed as word addressing in the Platform Designer flow. For example, addressing of 4 in the Nios II software selects the address of 1 in the slave. |
|
rx_rpt_msg_wr | Input | |||||
rx_rpt_msg_rd | Input | |||||
rx_rpt_msg_wrdata[31:0] | Input | |||||
rx_rpt_msg_rddata[31:0] | Output | |||||
HDCP Key and Status Interface (rx_hdcp) | Conduit (Key) | crypto_clk |
rx_kmem_wait[0] (HDCP 2.3) rx_kmem_addr[1] (HDCP 1.3) |
Input |
Always keep this signal asserted until the key is ready to be read. |
|
rx_kmem_rdaddr[7:0] (HDCP 2.3) rx_kmem_rdaddr[13:8] (HDCP 1.3) |
Output | Key read address bus. | ||||
rx_kmem_rddata[31:0] (HDCP 2.3) rx_kmem_rddata[87:32] (HDCP 1.3) |
Input | Key read data
transfer. Read transfer always have 1 cycle of wait time. |
||||
Conduit | rx_std_clkout[0] | rx_hdcp1_enabled | Output | This signal is asserted by the IP if the incoming video and auxiliary data are HDCP 1.3 encrypted. | ||
rx_hdcp2_enabled | Output | This signal is asserted by the IP if the incoming video and auxiliary data are HDCP 2.3 encrypted. | ||||
rx_streamid_type | Output |
|
||||
clk | rx_hdcp1_disable | Input | Assert this signal
to disable the HDCP 1.3 IP. Note: You must reset the HDCP IP (hdcp_reset) and trigger a Hot
Plug event after toggling this signal.
|
|||
rx_hdcp2_disable | Input | Assert this signal
to disable the HDCP 2.3 IP. Note: You must reset the HDCP IP (hdcp_reset) and trigger a Hot
Plug event after toggling this signal.
|
6.5.1. Controller Interface
The controller interface allows you to control the sink from an external or on-chip controller, such as the Nios II processor for debugging. The controller interface is an Avalon-MM slave that also allows access to the sink’s internal status registers.
The sink asserts the rx_mgmt_irq port when issuing an interrupt to the controller.
6.5.2. AUX Interface
The IP has three ports to control the serial data across the AUX channel:
- Data input (rx_aux_in)
- Data output (rx_aux_out)
- Output enable (rx_aux_oe). The output enable port controls the direction of data across the bidirectional link.
A state machine decodes the incoming AUX channel’s Manchester encoded data using the 16 MHz clock. The message parsing drives the state machine input directly. The state machine performs all lane training and EDID link-layer services.
The sink’s AUX interface also generates appropriate HPD IRQ events. These events occur if the sink’s main link decoder detects a signal loss.
The sink core uses the rx_cable_detect signal to detect when a source (upstream) device is physically connected and the rx_pwr_detect signal to detect when a source device is powered. The sink core keeps the rx_hpd signal deasserted if both the rx_cable_detect and rx_pwr_detect signals are not asserted.
6.5.2.1. AUX Debug Interface
The AUX controller lets you capture all bytes sent from and received by the AUX channel, which is useful for debugging. The IP supports a standard stream interface that can drive an Avalon® streaming FIFO component directly.
6.5.2.2. EDID Interface
You can use the Avalon® memory-mapped EDID interface to access an on-chip memory region containing the sink’s EDID data. The AUX sink controller reads and writes to this memory region according to traffic on the AUX channel.
The Avalon® memory-mapped interface uses an 8-bit address with an 8-bit data bus. The interface assumes a read latency of 1.
Refer to the VESA Enhanced Extended Display Identification Data Implementation Guide for more information.
6.5.3. Debugging Interface
6.5.3.1. Link Parameters Interface
The sink provides link level data for debugging and configuring external components using the rx_lane_count port.
6.5.3.2. Video Stream Out Interface
This interface provides access to the post-scrambler DisplayPort data, which is useful for low-level debugging source equipment. The 8-bit symbols received are organized as shown in the following table, where n increases with time (at each main link clock cycle, by 2 for dual-symbol mode or by 4 for quad-symbol mode).
Bit | Dual-Symbol Mode | Quad-Symbol Mode |
---|---|---|
127:120 |
Not applicable |
Lane 3 symbol n + 3 |
119:112 |
Not applicable |
Lane 3 symbol n + 2 |
111:104 |
Not applicable |
Lane 3 symbol n + 1 |
103:96 |
Not applicable |
Lane 3 symbol n |
95:88 |
Not applicable |
Lane 2 symbol n + 3 |
87:80 |
Not applicable |
Lane 2 symbol n + 2 |
79:72 |
Not applicable |
Lane 2 symbol n + 1 |
71:64 |
Not applicable |
Lane 2 symbol n |
63:56 |
Lane 3 symbol n + 1 |
Lane 1 symbol n + 3 |
55:48 |
Lane 3 symbol n |
Lane 1 symbol n + 2 |
47:40 |
Lane 2 symbol n + 1 |
Lane 1 symbol n + 1 |
39:32 |
Lane 2 symbol n |
Lane 1 symbol n |
31:24 |
Lane 1 symbol n + 1 |
Lane 0 symbol n + 3 |
23:16 |
Lane 1 symbol n |
Lane 0 symbol n + 2 |
15:8 |
Lane 0 symbol n + 1 |
Lane 0 symbol n + 1 |
7:0 |
Lane 0 symbol n |
Lane 0 symbol n |
When data is received, data is produced on lane 0, lanes 0 and 1, or on all four lanes according to how many lanes are currently used and link trained on the main link. The IP provides the data output immediately after the data passes through the descrambler and features all control symbols, data, and original timing. As data is always valid at each and every clock cycle, the rxN_stream_valid signal remains asserted.
6.5.4. Video Interface
This interface (rxN_video_out) allows access to the video data as a non-Avalon-ST stream. You can use this stream to interface with an external pixel clock recovery function. The stream provides synchronization pulses at the start and end of active lines, and at the start and end of active frames.
The rxN_vid_overflow signal is always valid, regardless of the logical state of rxN_vid_valid. rxN_vid_overflow is asserted for at least one clock cycle when the sink core internal video data FIFO runs into an overflow condition. This condition can occur when the rxN_vid_clk frequency is too low to transport the received video data successfully.
Specify the maximum data color depth in the DisplayPort parameter editor. The same output port transfers both RGB and YCbCr data in 4:4:4, 4:2:2, or 4:2:0 color format. Data is most-significant bit aligned and formatted for 4:4:4.
Color Format | Description |
---|---|
Sub-sampled 4:2:2 color format |
|
Sub-sampled 4:2:0 color format |
|
Pixel Indexes | R Position | G Position | B Position |
---|---|---|---|
0 and 1 |
Y1 |
Y0 |
|
2 and 3 |
Y3 |
Y2 |
|
4 and 5 |
Y5 |
Y4 |
|
... | ... | ... | ... |
If you set Pixel output mode to Dual or Quad, the IP produces two or four pixels in parallel, respectively. To support video resolutions with horizontal active, front and pack porches with lengths that are not divisible by two or four, rxN_vid_valid is widened. For example, for two pixels per clock, rxN_vid_valid[0] is asserted when pixel N belongs to active video and rxN_vid_valid[1] is asserted when pixel n + 1 belongs to active video.
The following figure shows the pixel data order from the least significant bits to the most significant bits.
6.5.5. Clocked Video Input Interface
The rxN_video_out interface may interface with a clocked video input (CVI). CVI accepts the following video signals with a separate synchronization mode: datavalid, de, h_sync, v_sync, f, locked, and data.
The DisplayPort rxN_video_out interface has the following signals: rxN_vid_valid, rxN_vid_sol, rxN_vid_eol, rxN_vid_sof, rxN_vid_eof, rxN_vid_locked, and rxN_vid_data.
CVI Signal |
DisplayPort Sink Signal |
Comment |
---|---|---|
vid_data | rx_vid_data |
Video data |
vid_datavalid |
– |
Drive high because the video data is not oversampled. |
vid_f |
rx_vid_field |
Drive low because the video data is progressive. |
vid_locked | rx_vid_locked |
The core asserts this signal when a stable stream is present. |
vid_de | rx_vid_valid |
Indicates the active picture region of a line. |
vid_h_sync | rx_vid_eol |
The rx_vid_eol signal generates the vid_h_sync pulse by delaying it (by 1 clock cycle) to appear in the horizontal blanking period after the active video ends (rx_vid_valid is deasserted). |
vid_v_sync | rx_vid_eof |
The rx_vid_eof signal generates the vid_v_sync pulse by delaying it (by 1 clock cycle) to appear in the vertical blanking period after the active video ends (rx_vid_valid is deasserted). |
Verilog HDL CVI — DisplayPort Sink Example
// CVI V-sync and H-sync are derived from delayed versions of the eol and eof signals
always @ (posedge clk_video) begin rx_vid_h_sync <= rx_vid_eol; rx_vid_v_sync <= rx_vid_eof; endassign vid_data = rx_vid_data;
assign vid_datavalid = 1’b1;
assign vid_f = 1’b0;
assign vid_locked = rx_vid_locked;
assign vid_h_sync = rx_vid_h_sync;
assign vid_de = rx_vid_valid;
assign vid_v_sync = rx_vid_v_sync;
6.5.6. RX Transceiver Interface
The transceiver or Native PHY IP core instance is no longer instantiated within the DisplayPort Intel® FPGA IP. The DisplayPort Intel® FPGA IP uses a soft 8B/10B decoder. This interface receives RX transceiver recovered data (rx_parallel_data) in either dual symbol (20-bit) or quad symbol (40-bit) mode, and drives the digital reset (rx_digitalreset), analog reset (rx_analogreset), and controls the CDR circuitry locking mode.
6.5.7. Transceiver Reconfiguration Interface
You can reconfigure the transceiver to accept a single reference clock of 135 MHz for all bit rates: RBR, HBR, HBR2, and HBR3.
During run-time, you can reconfigure the transceiver to operate in either one of the bit rate by changing RX CDR PLLs divider ratio.
When the IP makes a request, the rx_reconfig_req port goes high. The user logic asserts rx_reconfig_ack, and then reconfigures the transceiver. During reconfiguration, the user logic holds rx_reconfig_busy high. The user logic drives it low when reconfiguration completes.
6.5.8. Secondary Stream Interface
The secondary streams data can be received through the rxN_ss interfaces. The interfaces do not allow for back-pressure and assume the downstream logic can handle complete packets. The rxN_ss interface does not distinguish between the types of packets it receives.
The format of the rxN_ss interface output corresponds to four 15-nibble code words as specified by the VESA DisplayPort Standard version 1.2a, Section 2.2.6.3. These 15-nibble code words are typically supplied to the downstream Reed-Solomon decoder. The format differs for both header and payload, as shown in the following figure.
The following figure shows a typical secondary stream packet with the four byte header (HB0, HB1, HB2, and HB3) and 32-byte payload (DB0, ..., DB31). Each symbol has an associated parity nibble (PB0, ..., PB11). Downstream logic uses start-of-packet and end-of-packet to determine if the current input is a header or payload symbol.
Data is clocked out of the rxN_ss port using the rx_ss_clk signal. This signal is the same phase and frequency as the main link lane 0 clock.
6.5.9. Audio Interface
The audio interfaces are downstream from the secondary stream decoder. They extract and decode the Audio InfoFrame packets, Audio Timestamp packets, and Audio Sample data.
The Audio Timestamp packet payload contains M and N values, which the sink uses to recover the source’s audio sample clock. The rxN_audio port uses the values to generate the rxN_audio_valid signal according to sample audio data. Data is clocked out using the rx_ss_clk signal. The rx_ss_clk signal comes from the rx parallel clock from the RX transceiver. This clock runs at link data rate/20 for dual symbol mode and link data rate/40 for quad symbol mode.
The sink generates the rxN_audio_valid signal using the M and N values, and asserts it at the current audio sample clock rate. The rxN_audio_mute signal indicates whether audio data is present on the DisplayPort interface.
The captured Audio InfoFrame is available on the audio port. The 5-byte port corresponds to the 5 bytes used in the Audio InfoFrame (refer to CEA-861-D). The Audio InfoFrame describes the type of audio content.
6.5.10. Non-GPU Mode EDID Interface
6.5.11. MSA Interface
The rxN_msa_conduit ports allow designs access to the MSA and VB-ID parameters on a top-level port. The following table shows the 217-bit port bundle assignments. The prefixes msa and vbid denote parameters from the MSA and Vertical Blank ID (VB-ID) packets, respectively.
The sink asserts bit msa_valid when all msa_ signals are valid and deasserts during MSA update. The sink assigns the MSA parameters to zero when it is not receiving valid video data.
The sink asserts the msa_lock bit when the MSA fields have been correctly formatted for the last 15 video frames. Because msa_lock changes state only when msa_valid = 1, you can use its rising edge to strobe new MSA values following an idle video period; for example, when the source changes video resolution. You can use its deasserted state to invalidate received video data.
The sink asserts bit vbid_strobe for one clock cycle when it detects the VB-ID and all vbid_ signals are valid to be read.
Bit |
Signal |
Description |
---|---|---|
216 |
msa_lock |
0 = MSA fields format error. 1 = MSA fields correctly formatted. |
215 |
vbid_strobe |
0 = VB-ID fields invalid, 1 = VB-ID fields valid. |
214:209 |
vbid_vbid[5:0] |
VB-ID bit field:
|
208:201 |
vbid_Mvid[7:0] | Least significant 8 bits of Mvid for the video stream |
200:193 |
vbid_Maud[7:0] | Least significant 8 bits of Maud for the audio stream |
192 |
msa_valid | 0 = MSA fields are invalid or being updated, 1 = MSA fields are valid |
191:168 |
msa_Mvid[23:0] | Mvid value for the main video stream. Used for stream clock recovery from link symbol clock. |
167:144 |
msa_Nvid[23:0] |
Nvid value for the main video stream. Used for stream clock recovery from link symbol clock. |
143:128 |
msa_Htotal[15:0] | Horizontal total of received video stream in pixels |
127:112 |
msa_Vtotal[15:0] | Vertical total of received video stream in lines |
111 |
msa_HSP | H-sync polarity 0 = Active high, 1 = Active low |
110:96 |
msa_HSW[14:0] | H-sync width in pixel count |
95:80 |
msa_Hstart[15:0] | Horizontal active start from H-sync start in pixels (H-sync width + Horizontal back porch) |
79:64 |
msa_Vstart[15:0] | Vertical active start from V-sync start in lines (V-sync width + Vertical back porch) |
63 |
msa_VSP | V-sync polarity 0 = Active high, 1 = Active low |
62:48 |
msa_VSW[14:0] | V-sync width in lines |
47:32 |
msa_Hwidth[15:0] | Active video width in pixels |
31:16 |
msa_Vheight[15:0] | Active video height in lines |
15:8 |
msa_MISC0[7:0] | The MISC0[7:1] and
MISC1[7] fields indicate the color
encoding format. The color depth is indicated in MISC0[7:5]:
For details about the encoding format, refer to the VESA DisplayPort Standard version 1.4. |
7:0 |
msa_MISC1[7:0] |
6.6. Sink Clock Tree
The IP receives DisplayPort serial data across the high-speed serial interface (HSSI). The HSSI requires a 135 MHz clock for correct data locking. You can supply this frequency to the HSSI using a reference clock provided by an Intel FPGA PLL or pins.
The IP synchronizes HSSI 20- or 40-bit data to a single HSSI[0] clock that clocks the data into the DisplayPort front-end decoder.
- If you select dual symbol mode, this clock is equal to the link rate divided by 20 (270, 135, or 81 MHz).
- If you turn on quad symbol mode, this clock is equal to the link rate divided by 40 (202.5, 135, 67.5, or 40.5 MHz).
- If rxN_vid_clk is slower than the up-stream video clock, the DCFIFO overflows.
- If the rxN_vid_clk is faster than the up-stream source video clock, the output port experiences a deassertion of the valid port on cycles in which pixel data is not available.
The optimum frequency is the exact clock rate in the up-stream source. You require pixel clock recovery techniques to determine this clock frequency.
Secondary stream data is clocked by rx_ss_clk. The sink IP also requires a 16-MHz clock (aux_clk) to drive the internal AUX controller and an Avalon clock for the Avalon® memory-mapped interface (clk).
7. DisplayPort Intel FPGA IP Parameters
7.1. DisplayPort Intel FPGA IP Source Parameters
You set parameters for the source using the DisplayPort Intel® FPGA IP parameter editor.
Parameter |
Description |
---|---|
Device family |
Select the targeted device family: Intel® Stratix® 10, Intel® Arria® 10, Intel® Cyclone® 10 GX, Arria V GX, Arria V GZ, Cyclone V, or Stratix V. |
Support DisplayPort source |
Turn on to enable DisplayPort source. |
Maximum video input color depth |
Determines the maximum video input color depth (bits per color) supported by the DisplayPort source. Select 6, 8, 10, 12 or 16 bpc. Note: DisplayPort source supports RGB, YCbCr 4:4:4, YCbCr
4:2:2, and YCbCr 4:2:0 video formats by default.
|
TX maximum link rate |
Select the maximum link rate supported: 8.1 Gbps, 5.4 Gbps, 2.7 Gbps, or 1.62 Gbps. Note: Cyclone V devices only support up to 2.7 Gbps. 8.10
Gbps is only available in quad symbols per clock for
Intel®
Arria® 10,
Intel®
Cyclone® 10 GX, and
Intel®
Stratix® 10 devices.
|
Maximum lane count |
Select the maximum lanes supported: 1, 2, or 4. Note: If you turn on the Support MST parameter, the maximum lane count is
fixed to 4 lanes.
|
Symbol output mode |
Determines the TX transceiver data width in symbols per clock. Select dual (20 bits) or quad (40 bits). Dual symbol mode saves logic resource but requires the core to run at twice the clock frequency of quad symbol mode. If timing closure is a problem in the device, you should consider using quad symbol mode. |
Pixel input mode |
Select the number of pixels per clock (single, dual, or quad symbol).
|
Scrambler seed value |
Select the initial seed value for the scrambler block.
|
Enable Video input Image port |
Turn on to enable the video image interface. Turn off to use the traditional HSYNC/VSYNC/DE video input interface. |
Support analog reconfiguration |
Turn on to reconfigure VOD and pre-emphasis values. |
Enable AUX debug stream |
Turn on to send source AUX traffic output to an Avalon-ST port. |
Support CTS test automation |
Turn on to support CTS test automation. |
Support GTC |
The Global Time Code (GTC) feature is not available. However, if you want to use this feature, contact your nearest Intel FPGA sales representative or file a Service Request. |
Support secondary data channel |
Turn on to enable secondary data. |
Support audio data channel |
Turn on to enable audio packet encoding. Note: To use this parameter, you must turn on the
Support secondary data
channel parameter.
|
Number of audio data channels |
Select the number of audio channels (2 or 8). |
Support MST |
Turn on to enable multi-stream support.
Note: For multi-stream support, the maximum lane
count is fixed to four lanes.
|
Max stream count |
Specify the maximum amount of streams supported: 2, 3, or 4. Note: To use this parameter, you must turn on the
Support MST parameter.
|
Support HDCP 1.3 |
Turn on to enable HDCP 1.3 TX support. This parameter can only be used when you specify these settings:
Note: The HDCP-related parameters are 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 .
|
Support HDCP 2.3 |
Turn on to enable HDCP 2.3 TX support. This parameter can only be used when you specify these settings:
Note: The HDCP-related parameters are 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 .
|
7.2. DisplayPort Intel FPGA IP Sink Parameters
You set parameters for the sink using the DisplayPort Intel® FPGA IP parameter editor.
Parameter |
Description |
---|---|
Device family |
Select the targeted device family: Intel® Stratix® 10, Intel® Arria® 10, Intel® Cyclone® 10 GX, Arria V GX, Arria V GZ, Cyclone V, or Stratix V. |
Support DisplayPort sink |
Turn on to enable DisplayPort sink. |
Maximum video output color depth |
Determines the maximum video input color depth (bits per color) supported by the DisplayPort source. Select 6, 8, 10, 12 or 16 bpc. DisplayPort sink supports RGB, YCbCr 4:4:4, YCbCr 4:2:2, and YCbCr 4:2:0 video formats by default. |
RX maximum link rate |
Select the maximum link rate supported: 8.1 Gbps, 5.4 Gbps, 2.7 Gbps, or 1.62 Gbps. Note: Cyclone V devices only support up to 2.7 Gbps. 8.10
Gbps is only available in quad symbols per clock for
Intel®
Arria® 10,
Intel®
Cyclone® 10 GX, and
Intel®
Stratix® 10 devices.
|
Maximum lane count |
Select the maximum lanes supported: 1, 2, or 4. Note: If you turn on the Support MST parameter, the maximum lane count is
fixed to 4 lanes.
|
Symbol input mode |
Determines the RX transceiver data width in symbols per clock. Select dual (20 bits) or quad (40 bits). Dual symbol mode saves logic resource but requires the core to run at twice the clock frequency of quad symbol mode. If timing closure is a problem in the device, you should consider using quad symbol mode. |
Pixel output mode |
Select the number of pixels per clock (single, dual, or quad symbol).
|
Sink scrambler seed value |
Select the initial seed value for the scrambler block.
|
Export MSA |
Turn on to enable the sink to export the MSA interface to the top-level port interface. |
IEEE OUI |
Specify an IEEE organizationally unique identifier (OUI) as part of the DPCD registers. |
Enable GPU control |
Turn on to use an embedded controller to control the sink. |
Enable AUX debug stream |
Turn on to enable AUX traffic output to an Avalon-ST port. |
Support CTS test automation |
Turn on to support automated test features. |
Support GTC |
The Global Time Code (GTC) feature is not available. However, if you want to use this feature, contact your nearest Intel FPGA sales representative or file a Service Request. |
Support secondary data channel |
Turn on to enable secondary data. |
Support audio data channel |
Turn on to enable audio packet decoding. Note: To use this parameter, you must also turn on
Support secondary data
channel.
Note: The
IP does not support audio data channel if you turn on the Support MST parameter.
|
Number of audio data channels |
Select the number of audio channels (2 or 8). |
Support MST |
Turn on to enable multi-stream support. You must turn on Enable GPU control to support MST mode.Note: For multi-stream support, the maximum lane count is
fixed to four lanes.
|
Max stream count |
Specify the maximum amount of streams supported: 2,
3, or 4.
Note: To use this parameter, you must turn on the
Support MST
parameter.
|
Support HDCP 1.3 |
Turn on to enable HDCP 1.3 RX support. This parameter can only be used when you specify these settings:
Note: The HDCP-related parameters are 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 .
|
Support HDCP 2.3 |
Turn on to enable HDCP 2.3 RX support. This parameter can only be used when you specify these settings:
Note: The HDCP-related parameters are 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 .
|
8. DisplayPort Intel FPGA IP Simulation Example
The DisplayPort simulation example allows you to evaluate the functionality of the DisplayPort Intel® FPGA IP and provides a starting point for you to create your own simulation. This example targets the ModelSim* SE simulator.
The simulation example instantiates the DisplayPort Intel® FPGA IP with default settings, TX and RX enabled, and 8 bits per color. The core has the Support CTS test automation parameter turned on, which is required for the simulation to pass.
The test harness instantiates the design under test (DUT) and a VGA driver. It also generates the clocks and top-level stimulus. The design manipulates the tx_mgmt interface in the main loop to establish a link and send several frames of video data. The test harness checks that the sent data’s CRC matches the received data’s CRC for three frames.
8.1. Design Walkthrough
Setting up and running the DisplayPort simulation example consists of the following steps:
- Copy the simulation files to your target directory.
- Generate the IP simulation files and scripts, and compile and simulate.
-
View the results.
You use a script to automate these steps.
8.1.1. Copy the Simulation Files to Your Working Directory
Copy the simulation example files to your working directory using the command:
cp -r <IP root directory>/altera/altera_dp/sim_example/<device> <working directory>
where <device> is av for Arria V devices, cv for Cyclone V devices, and sv for Stratix V devices.
Your working directory should contain the files shown below.
File Type |
File |
Description |
---|---|---|
System Verilog HDL design files |
<prefix>_dp_harness.sv |
Top-level test harness. |
Verilog HDL design files |
<prefix>_dp_example.v |
Design under test (DUT). |
dp_mif_mappings.v |
Table translating MIF mappings for transceiver reconfiguration. |
|
dp_analog_mappings.v |
Table translating VOD and pre-emphasis settings. |
|
reconfig_mgmt_hw_ctrl.v |
Reconfiguration manager top-level. |
|
reconfig_mgmt_write.v |
Reconfiguration manager FSM for a single write command. |
|
clk_gen.v |
Clock generation file. |
|
freq_check.sv |
Top-level file for the frequency checker. |
|
rx_freq_check.sv |
RX frequency checker. |
|
tx_freq_check.sv |
TX frequency checker. |
|
vga_driver.v |
VGA driver (generates a test image). |
|
IP Catalog files |
<prefix>_ dp.v |
IP Catalog variant for the DisplayPort Intel® FPGA IP. |
<prefix>_ xcvr_reconfig.v |
IP Catalog variant for the transceiver reconfiguration core. |
|
<prefix>_ native_phy_rx.v |
IP Catalog variant for the RX transceiver. | |
<prefix>_ native_phy_tx.v | IP Catalog variant for the TX transceiver. | |
Scripts |
runall.sh |
This script generates the IP simulation files and scripts, and compiles and simulates them. |
msim_dp.tcl |
Compiles and simulates the design in the ModelSim* software. |
|
Waveform .do files |
all.do |
Waveform that shows a combination of all waveforms. |
reconfig.do |
Waveform that shows the signals involved in reconfiguring the transceiver. |
|
rx_video_out.do |
Waveform that shows the rx_video_out signals from the DisplayPort Intel® FPGA IP mapped to the CVI input. |
|
tx_video_in.do |
Waveform that shows the tx_vid_v_sync, tx_vid_h_sync, de, tx_vid_de, tx_vid_f, and tx_vid_data[23:0] signals at 256 pixels per line and 8 bpp, |
|
Miscellaneous files |
readme.txt |
Documentation for the simulation example. |
edid_memory.hex |
Initial content for the EDID ROM. |
8.1.2. Generate the IP Simulation Files and Scripts, and Compile and Simulate
In this step you use a script to generate the IP simulation files and scripts, and compile and simulate them. Type the command:
sh runall.sh
This script executes the following commands:
- Generate the simulation files for
the DisplayPort, transceivers, and transceiver reconfiguration IP cores:
Arria V, Cyclone V, and Stratix V devices; (where <prefix> is av for Arria V devices, cv for Cyclone V devices, and sv for Stratix V devices)
- qmegawiz -silent <prefix>_xcvr_reconfig.v
- qmegawiz -silent <prefix>_dp.v
- qmegawiz -silent <prefix>_native_phy_rx.v
- qmegawiz -silent <prefix>_native_phy_tx.v
- Merge the four resulting msim_setup.tcl scripts to create a single mentor/msim_setup.tcl:
Arria V, Cyclone V, and Stratix V devices; (where <prefix> is av for Arria V devices, cv for Cyclone V devices, and sv for Stratix V devices)
ip-make-simscript --spd=./<prefix>_xcvr_reconfig.spd --spd=./<prefix>_dp.spd --spd=./<prefix>_native_phy_rx.spd --spd=./<prefix>_native_phy_tx.spd
- Compile and simulate the design in
the
ModelSim*
software:
vsim -c -do msim_dp.tcl
The simulation sends several frames of video after reconfiguring the DisplayPort source (TX) and sink (RX) to use the HBR (2.7 G) rate. A successful result is seen by the CTS test automation logic’s CRC checks. These checks compare the CRC of the transmitted image with the result measured at the sink. The result is successful if the sink detects three matching frames.
Example Successful Result
# Testing Link HBR Rate Training Pattern 1 # Testing Video Input Frame Number = 00 # Testing Link HBR Rate Training Pattern 2 # TX Frequency Change Detected, Measured Frequency = 135 MHz # RX Frequency Change Detected, Measured Frequency = 135 MHz # ... # SINK CRC_R = 9b40, CRC_G = 9b40, CRC_B = 9b40, # SOURCE CRC_R = 9b40, CRC_G = 9b40, CRC_B = 9b40, # Pass: Test Completed
8.1.3. View the Results
You can view the results in the ModelSim* GUI by loading various .do files in the Wave viewer.
- Launch the ModelSim* GUI with the vsim command.
- In the ModelSim* Tcl window, execute the dataset open command: dataset open vsim.wlf
- Select View > Open Wave files.
-
Load the
.do files to view the waveforms (refer back to Table 7-1 for a listing of the files).
Figure 38. RX Reconfiguration WaveformIn the timing diagram below, rx_link_rate is set to 1 (HBR). When the core makes a request, the rx_reconfig_req port goes high. The user logic asserts rx_reconfig_ack and then reconfigures the transceiver. During reconfiguration, the user logic holds rx_reconfig_busy high; the user logic drives it low when reconfiguration completes.Figure 39. TX Reconfiguration WaveformIn the timing diagram below, tx_link_rate is set to 1 (HBR). When the core makes a request, the tx_reconfig_req port goes high. The user logic asserts tx_reconfig_ack and then reconfigures the transceiver. During reconfiguration, the user logic holds tx_reconfig_busy high; the user logic drives it low when reconfiguration completes.Figure 40. TX Analog Reconfiguration Waveform In the timing diagram below, tx_vod and tx_emp are both set to 00. When the core makes a request, the tx_analog_reconfig_req port goes high. The user logic asserts tx_analog_reconfig_ack and then reconfigures the transceiver. During reconfiguration, the user logic holds tx_analog_reconfig_busy high; the user logic drives it low when reconfiguration completes.Figure 41. RX Video WaveformThis timing diagram shows an example RX video waveform when interfacing to CVI. The rx_vid_eol signal generates the h_sync pulse by delaying it (by 1 clock cycle) to appear in the horizontal blanking period after the active video ends (VALID is deasserted). The rx_vid_eof signal generates the v_sync pulse by delaying it (by 1 clock cycle) to appear in the vertical blanking period after the active video ends (VALID is deasserted).
9. DisplayPort API Reference
You can use the DisplayPort Intel® FPGA IP to instantiate sources and sinks. Source instantiations require an embedded controller (Nios II processor or another controller) to act as the policy maker. Sink instantiations greatly benefit from and may optionally use a controller.
Intel provides software for source and sink instantiations as two system libraries for the Nios II processor (btc_dptx_syslib and btc _dprx_syslib, respectively). The IP includes an example main program (dp_demo_src/main.c), which demonstrates basic system library use.
9.1. Using the Library
The following figure describes a typical user application flow. The user application must initialize the library as its first operation. Next, the application should initialize the instantiated devices (sink and/or source), partly in the btc_dptx_syslib and btc_dprx_syslib data structures and partly in the user application. You must also implement interrupt service routines (ISRs) to handle interrupts generated by the DisplayPort core.
When initialization completes, the user application should periodically invoke the library monitoring function.
The following figure shows a more detailed view of these operations. For a sink application, the user application must initialize the DPCD content and the EDID. Additionally, for both source and sink applications, an interrupt ISR must be registered.
Sink instantiations issue an interrupt to the GPU when an AUX channel Request is received from the connected source. Source instantiations issue an interrupt to the GPU when a logic state change is detected on the HPD signal generated by the connected DisplayPort sink.
Because sources always act as AUX channel masters, they can manage AUX communication by initiating a transaction (by sending a request) and then polling the IP registers waiting to receive a reply. Optionally, source instantiations can also issue an interrupt to the GPU when an AUX channel reply is received from the connected DisplayPort sink, allowing the GPU to execute other tasks while waiting for AUX channel replies.
Enable or disable source and sink interrupts with the following library macros:
- BTC_DPTX_ENABLE_HPD_IRQ()
- BTC_DPTX_DISABLE_HPD_IRQ()
- BTC_DPTX_ENABLE_AUX_IRQ()
- BTC_DPTX_DISABLE_AUX_IRQ()
- BTC_DPRX_ENABLE_IRQ()
- BTC_DPRX_DISABLE_IRQ()
btc_dprx_syslib manages one to four sink instances by disabling all GPU interrupts when invoked and restoring them to their previous state on exiting. Therefore, most of the library public functions implement critical sections.
The GPU main program should minimize overhead when serving interrupts generated by sink instances (i.e., interrupts related to a connected source’s AUX channel requests).
Interrupts generated by source instances (i.e. interrupts related to a connected sink’s HPD activity) can be served with a lower priority. In designs where the same GPU handles both source and sink instances, the GPU must allow for nested interrupts originated by sinks. That is, a sink must be allowed to interrupt a source interrupt service routine (but not another sink interrupt service routine).
Typical Sink ISR Implementation
btc_dprx_aux_get_request (0,&cmd,&address,&length,data); btc_dprx_aux_handler(0,cmd,address,length,data);
Typical Source ISR Implementation
BTC_DPTX_DISABLE_HPD_IRQ(...); <Enable nested interrupt> if (HPD asserted) { <read Sink EDID> <set video output resolution> btc_dptx_link_training(...); } else if (HPD deasserted) btc_dptx_video_enable(..., 0); else if (IRQ_HPD) { <check link status> if (Test Automation request) btc_dptx_test_autom(…); } <Disable nested interrupt> BTC_DPTX_DISABLE_HPD_IRQ(...);
9.2. btc_dprx_syslib API Reference
This section provides information about the DisplayPort sink system library functions (btc_dprx_syslib), including:
- C prototype
- Function description
- Whether the function is thread-safe when running in a multi-threaded environment
- Whether the function can be invoked from an ISR
- Example
9.3. btc_dprx_aux_get_request
Prototype: |
int btc_dprx_aux_get_request( BYTE rx_idx BYTE *cmd, unsigned int *address, BYTE *length, BYTE *data) |
Thread-safe: |
Yes |
Available from ISR: |
Yes |
Include: |
< btc_dprx_syslib.h > |
Return: |
0 = success, 1 = fail |
Parameters: |
|
Description: |
This function retrieves an AUX channel request issued by the connected DisplayPort source. cmd and address are the command byte and the address in the original request received, respectively (refer to the VESA DisplayPort Standard for more details). When the request is a write, *data fills with the data bytes sent by the source. To support address-only requests, length is the original len byte sent by the source incremented by one. |
Example: |
btc_dprx_aux_get_request(0, pcmd, padd, plen, pwrdata); |
9.4. btc_dprx_aux_handler
Prototype: |
int btc_dprx_aux_handler( BYTE rx_idx BYTE cmd, unsigned int address, BYTE length, BYTE *data) |
Thread-safe: |
Yes |
Available from ISR: |
Yes |
Include: |
< btc_dprx_syslib.h > |
Return: |
0 = success, 1 = fail |
Parameters: |
|
Description: |
This function processes an AUX channel request issued by the connected DisplayPort source. cmd and address are the command byte and the address in the original request received, respectively (refer to the VESA DisplayPort Standard for more details). When the request is a write, data must point to the data bytes sent by the source. To support address-only requests, length is the original len byte sent by the source incremented by one. When the request is a read, data is not used and can be NULL. This function provides all the functionality of the DPCD registers implemented inside the system library, including:
|
Example: |
btc_dprx_aux_handler(0, pcmd, padd, plen, pwrdata); |
9.5. btc_dprx_aux_post_reply
Prototype: |
int btc_dprx_aux_post_reply( BYTE rx_idx BYTE cmd, BYTE size, BYTE *data) |
Thread-safe: |
Yes |
Available from ISR: |
Yes |
Include: |
< btc_dprx_syslib.h > |
Return: |
0 = success, 1 = fail |
Parameters: |
|
Description: |
This function transmits an AUX channel reply to the connected DisplayPort source. cmd is the reply command byte (refer to the VESA DisplayPort Standard for more details). When the reply includes read data, *data fills with the data bytes sent to the source. To support replies with no data returned, size is the actual len byte sent to the source incremented by one. |
Example: |
btc_dprx_aux_post_reply (0, 0x10, 0, NULL); //Reply AUX_NACK |
9.6. btc_dprx_baseaddr
Prototype: |
unsigned int btc_dprx_baseaddr(BYTE rx_idx) |
Thread-safe: |
Yes |
Available from ISR: |
Yes |
Include: |
< btc_dprx_syslib.h > |
Return: |
0 = success, 1 = fail |
Parameters |
rx_idx—Sink instance index (0 - 3) |
Description: |
This function returns the RX instance’s base address connected to the given port number. |
Example: |
addr = btc_dprx_baseaddr(0); |
9.7. btc_dprx_dpcd_gpu_access
Prototype: |
int btc_dprx_dpcd_gpu_access( BYTE rx_idx BYTE wrcmd, unsigned int address, BYTE length, BYTE *data) |
Thread-safe: |
Yes |
Available from ISR: |
Yes |
Include: |
< btc_dprx_syslib.h > |
Return: |
0 = success, 1 = fail |
Parameters: |
|
Description: |
This function allows the controller to access the sink’s DPCD locations (implemented in the system library) for reading and writing data. data must point to a location containing length bytes (writes) or be able to accommodate length bytes (reads). |
Example: |
btc_dprx_dpcd_gpu_access(0, 1, 0x00000, 1, pwrdata); |
9.8. btc_dprx_edid_set
Prototype: |
int btc_dprx_edid_set( BYTE rx_idx BYTE port, BYTE *edid_data, BYTE num_blocks) |
Thread-safe: |
Yes |
Available from ISR: |
Yes |
Include: |
< btc_dprx_syslib.h > |
Return: |
0 = success, 1 = fail |
Parameters: |
|
Description: |
This function allows the controller to set the content of the sink’s EDID implemented in the system library. The library references the EDID data and does not copy it. One block is 128 bytes long. The system library accepts a maximum of 4 blocks (512 bytes long EDIDs). Each streaming sink port has its own EDID. |
Example: |
btc_dprx_edid_set(0, 0, pmy_edid, 2); |
9.9. btc_dprx_hpd_get
Prototype: |
int btc_dprx_hpd_get(BYTE rx_idx) |
Thread-safe: |
Yes |
Available from ISR: |
Yes |
Include: |
<btc_dprx_syslib.h> |
Return: |
0 = success, 1 = fail |
Parameters: |
rx_idx—Sink instance index (0 - 3) |
Description: |
Returns the current logic level of the RX HPD. |
Example: |
btc_dprx_hpd_get(0); |
9.10. btc_dprx_hpd_pulse
Prototype: |
void btc_dprx_hpd_pulse( BYTE rx_idx BYTE dev_irq_vect0, BYTE dev_irq_vect1, BYTE link_irq_vect0) |
Thread-safe: |
Yes |
Available from ISR: |
Yes |
Include: |
< btc_dprx_syslib.h > |
Return: |
– |
Parameters: |
|
Description: |
This function deasserts (sets to 0) the RX HPD for 750 s. You can use this function to send an IRQ_HPD pulse to the connected DisplayPort source. DPCD locations 0x0201 and 0x2003-0x2005 are set accordingly to given parameters before the pulse is generated and IRQ vector information is provided to the source. Before invoking this function, you must have invoked btc_dprx_hpd_set with level = 1 (HPD must be set to 1). |
Example: |
btc_dprx_hpd_pulse(0, 0, 0, 0); |
9.11. btc_dprx_hpd_set
Prototype: |
void btc_dprx_hpd_set( BYTE rx_idx, int level) |
Thread-safe: |
Yes |
Available from ISR: |
Yes |
Include: |
< btc_dprx_syslib.h > |
Return: |
– |
Parameters: |
|
Description: |
This function allows the controller to set the logic level of the RX HPD. |
Example: |
btc_dprx_hpd_set(0,1); |
9.12. btc_dprx_lt_eyeq_init
Prototype: |
void btc_dprx_lt_eyeq_init( BYTE rx_idx BYTE enabled, BYTE log_chan_from, BYTE log_chan_to unsigned int rcnf_base_addr) |
Thread-safe: |
Yes |
Available from ISR: |
Yes |
Include: |
< btc_dprx_syslib.h > |
Return: |
0 = success, 1 = fail |
Parameters: |
|
Description: |
This function to enable or disable equalizer (AC Gain) automatic management using the Eye Viewer feature of supporting devices. When enabled, a number of RX transceiver features must be supported and their reconfiguration must be enabled too. |
Example: |
btc_dprx_lt_eyeq_init (0,1,0,3,RECONFIG_MGMT_BASE); |
9.13. btc_dprx_lt_force
Prototype: |
void btc_dprx_lt_force(BYTE rx_idx) |
Thread-safe: |
Yes |
Available from ISR: |
Yes |
Include: |
< btc_dprx_syslib.h > |
Return: |
– |
Parameters: |
rx_idx—Sink instance index (0 - 3) |
Description: |
This function brings the main link down and generates an IRQ_HPD forcing the connected source to perform a new Link Training. |
Example: |
btc_dprx_lt_force (0); |
9.14. btc_dprx_rtl_ver
Prototype: |
void btc_dprx_rtl_ver( BYTE *major BYTE *minor, BYTE *rev) |
Thread-safe: |
Yes |
Available from ISR: |
Yes |
Include: |
< btc_dprx_syslib.h > |
Return: |
– |
Parameters: |
|
Description: |
This function returns the version of the RX core (RTL). |
Example: |
btc_dprx_rtl_ver(&maj, &min, &rev); |
9.15. btc_dprx_sw_ver
Prototype: |
void btc_dprx_sw_ver( BYTE *major BYTE *minor, BYTE *rev) |
Thread-safe: |
Yes |
Available from ISR: |
Yes |
Include: |
< btc_dprx_syslib.h > |
Return: |
– |
Parameters: |
|
Description: |
This function returns the version of the RX system library. |
Example: |
btc_dprx_sw_ver(&maj, &min, &rev); |
9.16. btc_dprx_syslib_add_rx
Prototype: |
int btc_dprx_syslib_add_rx( BYTE rx_idx, unsigned int rx_base_addr, unsigned int rx_irq_id, unsigned int rx_irq_num, unsigned int rx_num_of_sinks, unsigned int options) |
Thread-safe: |
No |
Available from ISR: |
No |
Include: |
< btc_dprx_syslib.h > |
Return: |
0 = success, 1 = fail |
Parameters: |
|
Description: |
This function declares a sink (RX) instance to the system library. It should be invoked once for each existing sink instance, starting from rx_idx = 0. After all sinks have been declared, invoke btc_dprx_syslib_ init ( ). |
Example: |
btc_dprx_syslib_add_rx (0, DP_RX_SINK_BASE, DP_RX_SINK_IRQ_INTERRUPT_CONTROLLER_ID, DP_RX_SINK_IRQ, 2, BTC_DPRX_OPT_DISABLE_ERRMON); |
9.17. btc_dprx_syslib_info
Prototype: |
void btc_dprx_syslib_info( BYTE *max_sink_num, BYTE *mst_support) |
Thread-safe: |
Yes |
Available from ISR: |
Yes |
Include: |
< btc_dprx_syslib.h > |
Return: |
None |
Parameters: |
|
Description: |
This function returns information about the system library capabilities. On return, max_sink_num is set with the maximum number of supported sink instances (1 - 4) and mst_support is set to zero if MST is not supported and 1 if it is supported. |
Example: |
btc_dprx_syslib_info(pmaxsink,pmst); |
9.18. btc_dprx_syslib_init
Prototype: |
int btc_dprx_syslib_init(void) |
Thread-safe: |
No |
Available from ISR: |
No |
Include: |
< btc_dprx_syslib.h > |
Return: |
0 = success, 1 = fail |
Parameters: |
No |
Description: |
This function initializes the system library. It should be invoked once after btc_dprx_syslib_add_ rx ( ). |
Example: |
btc_dprx_syslib_init(); |
9.19. btc_dprx_syslib_monitor
Prototype: |
int btc_dprx_syslib_monitor(void) |
Thread-safe: |
No |
Available from ISR: |
No |
Include: |
< btc_dprx_syslib.h > |
Return: |
0 = success, 1 = fail |
Parameters: |
No |
Description: |
This function calls the system library sink housekeeping monitor, which is responsible for:
The software should invoke this function periodically or at least every 50 ms. |
Example: |
btc_dprx_syslib_monitor(); |
9.20. btc_dprx_mst_link_addr_rep_set
Prototype: |
int btc_dprx_mst_link_addr_rep_set ( BYTE rx_idx, BYTE dfp_num, BYTE input_port, BYTE peer_device_type, BYTE messaging_capability_status, BYTE displayport_device_plug_status, BYTE legacy_device_plug_status, BYTE dpcd_revision) |
Thread-safe: |
No |
Available from ISR: |
No |
Include: |
< btc_dprx_syslib.h > |
Return: |
0 = success, 1 = fail |
Parameters: |
|
Description: |
This function sets the values used for LINK_ADDRESS_DOWN_REP. |
9.21. btc_dprx_mst_conn_stat_notify_req
Prototype: |
int btc_dprx_mst_conn_stat_notify_req ( BYTE rx_idx, BYTE dfp_num, BYTE legacy_device_plug_status, BYTE displayport_device_plug_status, BYTE messaging_capability_status, BYTE input_port, BYTE peer_device_type) |
Thread-safe: |
No |
Available from ISR: |
No |
Include: |
< btc_dprx_syslib.h > |
Return: |
0 = success, 1 = fail |
Parameters: |
|
Description: |
This function issues a CONNECTION_STATUS_NOTIFY UP_REQUEST MST node broadcast sideband message. |
Example: | btc_dprx_mst_conn_stat_notify_req(0, 8, 0, 1, 1, 1, 3); |
9.22. btc_dprx_mst_conn_stat_notify_rep
Prototype: |
int btc_dprx_mst_conn_stat_notify_rep ( BYTE rx_idx, BYTE *GUID, BYTE *reas_for_nak, BYTE *nak_data) |
Thread-safe: |
No |
Available from ISR: |
No |
Include: |
< btc_dprx_syslib.h > |
Return: |
0 = ACK, 1 = NAK, 2 = not ready |
Parameters: |
|
Description: |
This function returns the connected Upstream DisplayPort source reply to the last issued CONNECTION_STATUS_NOTIFY UP_REQUEST MST node broadcast sideband message. Call this function until either ACK or NACK is returned. ‘2’ is returned when the reply has not yet been received. |
Example: | btc_dprx_mst_conn_stat_notify_rep(0, p_GUID, p_rfn, p_nd); |
9.23. btc_dptx_syslib API Reference
This section provides information about the DisplayPort source system library functions (btc_dptx_syslib), including:
- C prototype
- Function description
- Whether the function is thread-safe when running in a multi- threaded environment
- Whether the function can be invoked from an ISR
- Example
9.24. btc_dptx_aux_i2c_read
Prototype: |
int btc_dptx_aux_i2c_read( BYTE tx_idx, BYTE address, BYTE size, BYTE *data, BYTE mot) |
Thread-safe: |
No |
Available from ISR: |
Yes |
Include: |
< btc_dptx_syslib.h > |
Return: |
0 = success, 1 = fail |
Parameters: |
|
Description: |
This function reads 1 to 16 data bytes from the connected DisplayPort sink’s I2C interface mapped over the AUX channel. |
Example: |
btc_dptx_aux_i2c_read(0, 0x50, 16, data, 1); |
9.25. btc_dptx_aux_i2c_write
Prototype: |
int btc_dptx_aux_i2c_write( BYTE tx_idx, BYTE address, BYTE size, BYTE *data, BYTE mot) |
Thread-safe: |
No |
Available from ISR: |
Yes |
Include: |
< btc_dptx_syslib.h > |
Return: |
0 = success, 1 = fail |
Parameters: |
|
Description: |
This function writes 1 to 16 data bytes to the connected DisplayPort sink’s I2C interface mapped over the AUX channel. |
Example: |
btc_dptx_aux_i2c_write(0, 0x50, 1, data, 1); |