1 8.1 Gbps
is available only in the
Intel®
Quartus® Prime Pro Edition software.

DisplayPort Terms and Acronyms

The tables list the commonly used DisplayPort terms and acronyms.

Table 1. DisplayPort Acronyms

Acronym

Description

API

Application Programming Interface

AUX

Auxiliary

bpc

Bit Per Component

bpp

Bit 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

Table 2. DisplayPort Terms

Term

Definition

Link Symbol Clock (LSym_Clk)

Link Symbol clock frequency (f_LSym_Clk) across link rate: -

HBR3 (8.1Gbps) = 810 MHz

HBR2 (5.4Gbps) = 540 MHz

HBR (2.7Gbps) = 270 MHz

RBR (1.62Gbps) = 162 MHz

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.

About This IP Core

This document describes the
Intel® FPGA DisplayPort IP core, 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

Main Link transports video and audio streams with embeddd clocking to
decoupled pixel and audio clocks from the transmission clock. The IP core transmits Main
Link's data in scrambled ANSI 8/10B format and inlcudes redundancy in the data
transmission for error detection. For secondary data, such as audio, the IP core 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.

Figure 1. DisplayPort Source and Sink Communication

Device Family Support

Table 3. Intel Device Family
Support

Device Family

Support Level

Intel®
Arria® 10

Final

Intel®
Cyclone® 10 GX

Advance

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
Intel® FPGA DisplayPort IP core for each Intel FPGA family.

Table 4. Link Rate Support by Device Family

Device Family

Dual Symbol

(20-Bit
Mode)

Quad Symbol

(40-Bit
Mode)

FPGA Fabric Speed Grade

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

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

Stratix V

RBR, HBR, HBR2

RBR, HBR, HBR2

1, 2, 3

IP Core Verification

Before releasing a publicly available version of the
Intel® FPGA DisplayPort IP core, 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
Intel® FPGA DisplayPort IP core in
hardware for different platforms and environments.

Getting Started

This chapter provides a general overview of the Intel FPGA IP core design flow to help you quickly get started with
the
Intel® FPGA DisplayPort IP core. The IP core is installed as part
of the
Intel®
Quartus® Prime installation process. You can select
and parameterize any Intel FPGA IP core from
the library. Intel provides an integrated
parameter editor that allows you to customize the DisplayPort IP core to support a wide
variety of applications. The parameter editor guides you through the setting of
parameter values and selection of optional ports.

Installing and Licensing Intel FPGA IP Cores

The
Intel®
Quartus® Prime software installation
includes the
Intel® FPGA IP library. This library provides
many useful IP cores for your production use without the need for an additional license.
Some
Intel® FPGA IP cores require purchase of a separate
license for production use. The
Intel® FPGA IP Evaluation Mode allows
you to evaluate these licensed
Intel® FPGA IP cores in
simulation and hardware, before deciding to purchase a full production IP core license.
You only need to purchase a full production license for licensed
Intel® IP cores after you complete hardware
testing and are ready to use the IP in production.

The
Intel®
Quartus® Prime software installs IP cores in the
following locations by default:

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 or contact your local Intel FPGA representative.

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.

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

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.

The
Intel® FPGA DisplayPort
hardware demonstration evaluates the functionality of the
Intel® FPGA DisplayPort IP core and provides a starting point for you to
create your own design.
The example design uses a fully functional OpenCore
Plus evaluation version, giving you the freedom to explore the core and understand its
performance in hardware.

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.

Note: If you use another Intel FPGA development board, you must change the device
assignments and the pin assignments. You make these changes in the assignments.tcl file. If you use another DisplayPort
daughter card, you must change the pin assignments, Platform Designer system, and software.

Note: When rxN_vid_clock is used for transferring the sink device's video data and
control, the clock frequency must be equal or faster than the upstream device Stream
Clock (Strm_Clk) / PIXELS_PER_CLOCK. For example:

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

The DisplayPort hardware demonstration uses the IOPLL to drive
rxN_vid_clock with a fixed clock frequency.

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

Table 8. LED Function. The development board user LEDs illuminate to indicate the
function described in the table below.

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.

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.

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 Altera
fPLL Reconfiguration Controller internal registers.

Reconfiguration Controller: This block serializes the parameter values and writes them to the Altera fPLL IP core.

Altera fPLL: Generates the recovered video clock and a second clock with twice the frequency.

Clock Recovery Core Parameters

You can use these parameters to configure the clock recovery core.

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

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.

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.

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.

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

Copy the Design Files to Your Working Directory

In this step, you copy the hardware demonstration files to your
working directory.

You can also copy the design example through the
Intel® FPGA DisplayPort parameter editor. Turn on Generate Example Design on the
Intel® FPGA DisplayPort parameter editor before you
generate your design. The software copies the SST design example files from altera/altera_dp/hw_demo/<device_board> to your
working directory.

Note: The
generated design example may not be aligned to your configured parameter
settings.

Your working directory should contain the files shown in the following
tables.

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.

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.

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.

For Link Training Pattern Sequence 2:

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:

All the POST_LT_ADJ_REQ registers and flow
definition are available only in the VESA DisplayPort
Standard 1.3 .

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

A typical MST source user application must perform the following steps to display an image on
a connected DisplayPort sink device:

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.

DisplayPort Source

The DisplayPort source consists of a DisplayPort encoder block, a
transceiver management block, and a controller interface block with an Avalon-MM interface for connecting with an embedded controller such
as a Nios II processor.

Figure 11. DisplayPort Source Top-Level Block Diagram

Figure 12. DisplayPort Source Functional Block Diagram

The source accepts a standard H-sync, V-sync, and data enable video stream
for encoding. The IP core 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.

Main Data Path

The IP core 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.

Video Packetizer Path

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 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
Intel® FPGA DisplayPort IP core 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 core 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.

Note: A minimal DisplayPort system should support
both 6 and 8 bpc. The VESA DisplayPort Standard requires
support for a mandatory VGA fail-safe mode (640 x 480 at 6 bpc).

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.

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 encoder inserts the secondary stream packets into the merged video and MSA
data.

Training and Link Quality Patterns Generator

The IP core 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.

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 core clocks the AUX controller using a 16 MHz
clock input (aux_clk).

Source Embedded DisplayPort (eDP) Support

The
Intel® FPGA DisplayPort IP core 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 core supports:

Full (normal) link training—default

Fast link training—mandatory eDP feature

Source Interfaces

The following tables list the source’s port interfaces. Your
instantiation contains only the interfaces that you have enabled.

Table 13. Controller Interface

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
Intel® FPGA DisplayPort IP core is
unable to respond to a read or write request. Forces the GPU to wait
until the IP core is ready to proceed with the transfer.

tx_mgmt_irq

IRQ

clk

tx_mgmt_irq

Output

Interrupt for embedded controller

Table 14. Transceiver Management Interface . n is the number of TX
lanes.

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.

Note: For devices using a
50-MHz xcvr_mgmt_clk clock, connect the same
clock directly also to the clk_cal signal. For
devices using a 100-MHz xcvr_mgmt_clk clock,
connect the same clock to clk_cal signal
through a by-2 divider.

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
DP_TX_STATUS register to determine the cause of the
interrupt. Writing to the
DP_TX_STATUS register clears the pending interrupt
event.

AUX Interface

The IP core 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 core provides a standard stream
interface that you can use to drive an Avalon-ST FIFO component directly.

Note: The frequency of
txN_vid_clk must be halved when YCbCr 4:2:0 is used because
two pixels are fed into a single clock cycle.

Table 23. YCbCr 4:2:0 Input Data Ordering Compared to RGB 4:4:4

Pixel Indexes

R Position

G Position

B Position

0 and 1

Y1

Y0

Cb0 (Even lines)

Cr0 (Odd lines)

2 and 3

Y3

Y2

Cb2 (Even lines)

Cr2 (Odd lines)

4 and 5

Y5

Y4

Cb4 (Even lines)

Cr4 (Odd lines)

...

...

...

...

If you set Pixel input mode to Dual or
Quad, the IP core 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.

Video Interface (TX Video IM Enable = 1)

If you enable the video image interface feature, the core uses the
video image interface (txN_video_in_im).

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.

Figure 15. Video Image Interface Ports Timing Diagram

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

The source core measures only some of the MSA parameters from the incoming video signal:

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

Note: The source core needs only HTOTAL because the core calculates the value
of MVID from the interval time between txN_im_sol pulses and
the amount of pixels accounted for. The source core ignores the rest of the MSA parameters and
forwards to the connected sink.

TX Transceiver Interface

The transceiver or Native PHY IP core instance is no longer instantiated within
the
Intel® FPGA DisplayPort IP core.

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

Note: The transceiver requires a reconfiguration controller. Reset the
transceiver to a default state upon power-up.

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.

Secondary Stream Interface

You can transmit the secondary stream data over the DisplayPort
main link through the secondary stream (txN_ss)
interface. This interface uses handshaking and back pressure to control packet
delivery.

Note: The
Intel® FPGA DisplayPort IP core supports Infoframe SDP versions
1.2 and 1.3 over the Main-Link. INFOFRAME SDP version 1.2 shall be used to convey Audio
INFOFRAME control information, as specified in CEA-861-F and
CEA-861.2. Other INFOFRAME coding types, as specified in
CEA-861-F, Table 5, and CEA-861.3, shall use INFOFRAME SDP
version 1.3. Refer to the DisplayPort Specification Section 2.2.5.1 for
detailed definition.

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.

Figure 18. Typical Secondary Stream Packet Flow

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.

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.

You can configure the audio port for the number of audio channels required in
the design. You can use 2 or 8 channels. Each channel’s audio data is sent to the
txN_audio_lpcm_data port.

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

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
Intel® FPGA DisplayPort IP core for
2 or 8 channels, you can transmit any number of audio channels fewer than or equal to
the number of channels you selected.

To transmit 1 channel of audio over the IP core configured at 2 audio
channels:

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

Figure 21. Typical 3-Channel Audio Flow Over 8-Channel Audio TX Core

The
Intel® FPGA DisplayPort IP core internally calculates
the Maud based on a fixed (8000h) to generate the Audio Timestamp packet. The IP core
generates the Audio InfoFrame packet based on the information from the DisplayPort
source audio registers: LFEBPL, CA, LSV, and DM_INH. The IP core 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 core 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.

Source Clock Tree

The source uses the following clocks:

Local pixel clock
(txN_vid_clk), which clocks video data into the IP core.

Main link clock (tx_ss_clk), which clocks data out of the IP core 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 core requires to encode or decode the AUX
channel.

A separate clock (clk) clocks the Avalon-MM interface.

txN_audio_clk for the audio interface.

Figure 22. Source Clock Tree

DisplayPort Sink

The DisplayPort sink consists of a DisplayPort decoder block, a
transceiver management block, and a controller interface block with an Avalon-MM interface for connecting with an embedded controller such
as the Nios II processor.

Figure 23. DisplayPort Sink Top-Level Block Diagram

Figure 24. DisplayPort Sink Functional Block Diagram

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 core 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 core performs the
following actions:

The IP core aligns the data
stream and performs 8B/10B decoding.

The IP core deskews the data
and then descrambles it.

The IP core 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 core 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 core
outputs an AUX debugging stream so that you can inspect the activity on the AUX channel in
real time.

Sink Embedded DisplayPort (eDP) Support

The
Intel® FPGA DisplayPort IP core 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

Sink Interfaces

The following tables summarize the sink’s interfaces. Your
instantiation contains only the interfaces that you have enabled.

Table 25. Controller Interface

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
Intel® FPGA DisplayPort IP core is
unable to respond to a read or write request. Forces the GPU to
wait until the IP core is ready to proceed with the
transfer.

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.

AUX Interface

The IP core 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.

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 core supports a standard stream
interface that can drive an Avalon-ST FIFO
component directly.

EDID Interface

You can use the
Avalon-MM 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-MM interface uses an 8-bit address with
an 8-bit data bus. The interface assumes a read latency of 1.

Note: The IP core does not instantiate this interface if your design uses a
controller to control the sink; for instance when you turn on the
Enable GPU control parameter.

Debugging Interface

Link Parameters Interface

The sink provides link level data for debugging and configuring external
components using the
rx_lane_count
port.

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

Table 33. rxN_stream_data
Bit Allocation

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

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.

Figure 25. Video Out Image Port Timing Diagram

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.

If you set Pixel output mode to
Dual or Quad, the IP core 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.

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

Note: The transceiver requires a reconfiguration controller. Reset the
transceiver to a default state upon power-up.

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.

Note: The
Intel® FPGA DisplayPort IP core supports Infoframe SDP versions 1.2 and
1.3 over the Main-Link. INFOFRAME SDP version 1.2 shall be used to convey Audio
INFOFRAME control information, as specified in CEA-861-F
and CEA-861.2. Other INFOFRAME coding types, as specified
in CEA-861-F, Table 5, and CEA-861.3, shall use INFOFRAME SDP version 1.3. Refer to the VESA DisplayPort Standard version 1.2a, Section 2.2.5.1 for
detailed definition.

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.

Figure 28. rxN_ss Input Data Format

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 can use the 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.

Figure 29. Typical Secondary Stream Packet

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.

Figure 30. rxN_audio Data Output

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.

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.

Table 37. rxN_msa_conduit Port Signals

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:

vbid[0] -
VerticalBlanking_Flag

vbid[1] -
FieldID_Flag (for progressive video, this remains 0)

vbid[2] -
Interlace_Flag

vbid[3] -
NoVideoStream_Flag

vbid[4] -
AudioMute_Flag

vbid[5] - HDCP SYNC
DETECT

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.

The MISC0[7:1] and
MISC1[7] fields indicate the color
encoding format. The color depth is indicated in MISC0[7:5]:

000 -
6 bpc

001 -
8 bpc

010 -
10 bpc

011 -
12 bpc

100 -
16 bpc

For details about the encoding format, refer to the
VESA DisplayPort Standard version
1.4.

7:0

msa_MISC1[7:0]

Sink Clock Tree

The IP core 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 core 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).

The IP core crosses the reconstructed pixel data into a local video clock
(rxN_vid_clk) through an output DCFIFO, which drives
the pixel stream output. The rxN_vid_clk frequency must
be higher than or equal to the video clock in the up-stream source.

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 core also requires a 16-MHz
clock (aux_clk) to drive the internal AUX controller and an
Avalon clock for the
Avalon-MM interface (clk).

Note: This option only determines the format for the
generated top level IP files. All other files (e.g. example
testbenches and top level files for hardware demonstration) are
in Verilog HDL format.

Target Development Kit

Select Board

No Development Kit, Arria 10 GX
FPGA Development Kit, Custom Development Kit

Select the board for the targeted
design example.

No Development Kit: This option excludes
all hardware aspects for the design example. The IP core
sets all pin assignments to virtual pins.

Arria 10 GX FPGA Development Kit: This
option automatically selects the project's target device to
match the device on this development kit. You may change the
target device using the Change Target
Device parameter if your board revision has
a different device variant. The IP core sets all pin
assignments according to the development kit.

Custom Development Kit: This option allows
the design example to be tested on a third-party development
kit with an Intel FPGA. You may need to set the pin
assignments on your own.

Target
Device

Change Target Device

On, Off

Turn on this option and select the
preferred device variant for the development kit.

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

If you
select dual pixels per clock, the pixel clock is ½ of the full
rate clock and the video port becomes two times wider.

If you
select four pixels per clock, the pixel clock is ¼ of the full
rate clock and the video port becomes four times wider.

Scrambler seed
value

Select the initial seed value for the scrambler
block.

DP: 16’hFFFF

eDP: 16’hFFFE

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.

Intel FPGA DisplayPort Sink Parameters

You set parameters for the sink using the
Intel® FPGA DisplayPort parameter editor.

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

If you
select dual pixels per clock, the pixel clock is ½ of the full
rate clock and the video port becomes two times wider.

If you
select four pixels per clock, the pixel clock is ¼ of the full
rate clock and the video port becomes four times wider.

Sink scrambler seed value

Select the initial seed value for the scrambler
block.

DP: 16’hFFFF

eDP: 16’hFFFE

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

Intel FPGA DisplayPort IP Core Simulation Example

The DisplayPort simulation example allows you to evaluate the
functionality of the
Intel® FPGA DisplayPort IP core and provides a
starting point for you to create your own simulation. This example targets the
ModelSim® SE simulator.

The simulation example instantiates the
Intel® FPGA DisplayPort
IP core 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.