Community
cancel
Showing results for 
Search instead for 
Did you mean: 

DisplayPort Design Example 13.1 (TX Only)

Downloadable TX-Only Design Examples

DisplayPort TX-Only Design Example for Stratix V GX FPGA Development Kit

DisplayPort TX-Only Design Example Project Archive for Stratix V GX FPGA Development Kit

DisplayPort TX-Only Design Example for Arria V GX FPGA Development Kit

DisplayPort TX-Only Design Example Document

Reference Documents

Altera DisplayPort MegaCore Function User Guide

Altera Transceiver PHY IP Core User Guide

Altera Video and Image Processing Suite User Guide

Altera Nios II Software Developer's Handbook

 

Introduction

This design example will demonstrate the use of the Altera DisplayPort MegaCore Function in a transmit mode (TX) only application. The design example is implemented using Altera's Qsys tool and standalone HDL modules. The design example demonstrates the following features:

• TX Only DisplayPort MegaCore

• Auto Rate Negotiation

• Transceiver Dynamic VOD and Pre-Emphasis adjustments

• Support for 1.62, 2.7, and 5.4 Gbps data rates

       (5.4 Gbps is supported only in the Stratix V device family)


The design example allows you to evaluate Altera’s DisplayPort MegaCore function and provides a quick starting point for you to create your own design using Altera’s DisplayPort MegaCore function.

This document has the following sections:

• Functional Description

• Using the Design Example

• Viewing the Results

• Appendix A Link Training

• Appendix B Transceiver Reconfiguration

Functional Description

This design example transmits a 1,920 x 1,200 color bar image over a DisplayPort TX link.

Figure 1 shows a block level diagram of the design example. The design has the following four major functional components:

• System Reset

• Clocking

• Transceiver Reconfiguration

• Qsys System

TX Main Link
TX AUX Channel
Hot Plug Detect (HPD)
Test Video Generation
Nios II Processor and Peripherals
TX Aux Debug FIFO

The following sections describe these major functional components.

System Reset

The system reset in the design example is triggered either by an external hard reset (e.g. push-button) or the PLLs not achieving or losing lock. The system reset signal is kept asserted for 32K locks, after PLLs have locked to their reference clock. This ensures the system stays in the reset state until the PLL output clocks reach a stable state.

Clocks

The design example instantiates two PLLs in the top level module: Transceiver PLL and Video PLL. These PLLs drive internal clocks required by the design. Table 1 lists the clocks used in the design, their frequencies, and the main blocks driven by the clock signals.

Clock Signal Description Loads
clk 100 MHz external source • DisplayPort IP core tx_mgmt interface

• Nios II processor and peripherals

• DisplayPort IP core transceiver reconfiguration mgmt interface

• Transceiver Reconfiguration Controller

• reconfig_mgmt_hw_ctrl module

• Video PLL input clock

162 MHz Transceiver PLL output used as the transceiver reference clock for 1.62 Gbps rate DisplayPort IP core transceiver PHY
270 MHz Transceiver PLL output used as the transceiver reference clock for 2.7, and 5.4 Gbps rates DisplayPort IP core transceiver PHY
154 MHz Video PLL outclk0. Video clock for Avalon Streaming (Avalon-ST) video datapath for 1920x1200 @ 60 Hz • DisplayPort IP Core Video Input Interface

• Test Pattern Generator IP core

• Clocked Video Output IP core

16 MHz Video PLL outclk1. Clock for 1 Mbps AUX channel interface • DisplayPort IP core AUX interface

• TX AUX Debug FIFO

Transceiver Reconfiguration

The transceiver reconfiguration is performed by two modules, reconfig_mgmt_hw_ctrl and the Transceiver Reconfiguration Controller IP core. The following transceiver features are reconfigured to obtain a functional link.

• Data Rate

• VOD

• Pre-Emphasis

The link policy maker, software running on a processor, dynamically reconfigures the data rate during link training through the reference clock switching and clock divider setting of the transceiver.

If you are not using an external re-driver (e.g. SN75DP130) and the transceiver analog reconfiguration is enabled, the link training sequence dynamically reconfigures the transmitter voltage swing and pre-emphasis settings when the sink device requests for adjustments.

For more details of the link training sequence and transceiver reconfiguration, refer to Appendix A and Appendix B.

Qsys System

TX Main Link

The DisplayPort IP core has a scalable main link with 1, 2, or 4 lanes for a total of 21.6 Gbps bandwidth. The link is a uni-directional interface from a source to a sink device. The main link has three selectable data rates: 1.62, 2.7, and 5.4 Gbps. The source sets the lane count and the link rate (referred to as the policy) according to the sink’s capabilities and required video bandwidth.

TX AUX Channel

The AUX channel is a half-duplex bidirectional channel consisting of a differential pair, providing side-band communication channel between the source and the sink devices. The AUX channel signaling is a self-clocked Manchester encoding at 1 Mbps. The AUX channel uses a master-slave hierarchy in which the TX (master) initiates all communication. The DisplayPort IP TX requires a processor (e.g. Nios II embedded processor) to act as the policy maker. Examples of TX AUX channel transactions are as follows:

• Link capability read

• Link configuration (training)

• Link status read

• Extended Display Identification Data (EDID) read

In the design example, the Nios II processor drives the TX AUX channel through the DisplayPort tx_mgmt Avalon-MM interface. Software running on the processor initiates the AUX transactions. For the API functions, AUX channel transactions and a typical user application flow, refer to the DisplayPort API Reference chapter in the DisplayPort MegaCore Function User Guide. This design example includes the API library btc_dptx_syslib and an example main program (file called ‘main.c’) that demonstrates a basic system library use.

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

This design example instantiates a bidirectional BLVDS buffer megafunction (ALTIOBUF) in the top level for TX AUX channel physical layer interface. The BLVDS buffer signaling is “DIFFERENTIAL 2.5-V SSTL Class II”.

Hot Plug Detect (HPD)

The sink device drives a hot plug detect (HPD) signal to notify the source that a sink is present. Additionally, it provides an interrupt mechanism to notify the source when a change occurs in link status or configuration.

The DisplayPort IP core TX issues an IRQ (Request to Service an Interrupt) to the Nios II processor if IRQ_EN is set to 1 and if the IP core detects a HPD event. The HPD interrupt service routine (ISR), software running on the Nios II processor, determines whether the event is the plugging of a sink device (long HPD) or a HPD IRQ (short HPD). When the ISR detects the long HPD, it initiates the link training. For details on HPD ISR sequence implemented in this design example, refer to bitec_dptx_hpd_isr function in the tx_utils.c source code file under the ‘software/dp_demo_src’ sub-directory.

Test Video Generation

The TX-only design example instantiates two Video and Image Processing (VIP) Suite components to create a video source that feeds a still color bar image to the DisplayPort TX core. The two VIP Suite IP cores are:

• Test Pattern Generator (TPG) IP core – Used to generate 1920x1200 color bars in Avalon-ST video format.


• Clocked Video Ouput (CVO) IP core - Converts the color bar test pattern in Avalon-ST video protocol to clocked video format.


For more information about the VIP Suite IP cores, refer to the VIP Suite User Guide. Figure below shows the connection between the TPG, CVO and DP TX in the design example.

Nios II Processor and Peripherals

The Nios II processor is a softcore processor with Avalon-MM data and instruction masters. The software running on the Nios II processor performs the TX link management. In this design example, the following peripheral components are instantiated in the Nios II embedded sub-system.

IP Core Function
On-Chip Memory Nios II program memory
Interval Timer Nios II system timer
System ID Unique ID for Nios II embedded system
PIO (Parallel I/O) Parallel I/O for user push-buttons and LEDs
JTAG UART Allows Host PC and Nios II system communication via USB-Blaster

TX AUX Debug FIFO

The DisplayPort IP core AUX controller lets you capture all bytes that are transmitted and received at the AUX channel, which is useful for debugging. The DisplayPort IP core supports a standard stream interface that can drive an Avalon-ST FIFO component. The TX AUX debug FIFO directly interfaces with DisplayPort IP core AUX debug port and captures the AUX debug stream sent from the DisplayPort IP core. The captured AUX debug stream is displayed in Nios II command shell during link training.

Using the Design Example

Hardware Requirements

The design was tested on the Stratix V GX FPGA Development Kit and Arria V GX FPGA Development Kit with the Bitec HSMC daughter card. However, the design example can be ported to any platform which has the required clock sources. Below is the hardware setup:

• Connect the FPGA board to your PC using a USB cable. If your board doesn’t have On-Board USB-Blaster II connection, you can use an external USB-Blaster cable.

• Connect a DisplayPort monitor to DisplayPort TX connector on your board.

Software Requirements

The design was tested using Altera Quartus II software v13.0 release.

Obtaining the Design Example

The DisplayPort TX-only design example is available for download from Altera’s wiki website:

• Stratix V GX FPGA Development Kit design example: sv_dptx_demo.zip
• Arria V GX FPGA Development Kit design example: av_dptx_demo.zip

 

Design Example Content

After you download the design example and extract the zip file contents, you will have the files defined in Table 3. In the design example, file names have a prefix; <prefix> is ‘sv’ for the Stratix V devices, and ‘av’ for the Arria V devices.

  • Verilog HDL design files
File Description
<prefix>_dp_demo.v Top-level design file for the DisplayPort TX-only design example
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
  • MegaWizard files
File Description
<prefix>_video_pll.v PLL megafunction
<prefix>_xcvr_pll.v PLL megafunction
<prefix>_aux_buffer.v Bidirectional buffer megafunction
<prefix>_xcvr_reconfig.v Transceiver Reconfiguration Controller IP core
  • Qsys System
File Description
<prefix>_control.qsys Qsys system file
  • Scripts
File Description
runall.tcl Script to run the setup project, generate the IP and Qsys system, and compile
assignments.tcl Top-level TCL file to create the project assignments
  • Software files (in the 'software' directory)
File Description
batch_script.sh Master script to program the device and build/run the software
rerun.sh Script to program the device, and rerun the software without rebuilding
dp_demo_src Directory containing the example application source code
btc_dptx_syslib Directory containing TX API system library
  • Miscellaneous
File Description
<prefix>_dp_demo.sdc Top-level timing constraint file

Compiling the Design Example

In this step you use a script to build and compile the FPGA design. Type the command:

quartus_sh -t runall.tcl <CR>


This script performs the following steps by executing the listed commands.
The <prefix> is ‘sv’ for the Stratix V devices, and ‘av’ for the Arria V devices.

• Load the required packages:

load_package flow
load_package misc

• Regenerate the MegaWizard Plug-In Manager components:

qexec "qmegawiz -silent <prefix>_video_pll.v"
qexec "qmegawiz -silent <prefix>_xcvr_pll.v"
qexec "qmegawiz -silent <prefix>_aux_buffer.v"
qexec "qmegawiz -silent <prefix>_xcvr_reconfig.v"

• Regenerate the Qsys system including the DisplayPort IP core:

qexec "ip-generate --project-directory=./ \
--output-directory=./<prefix>_control/synthesis/ \
--file-set=QUARTUS_SYNTH \
--report-file=sopcinfo:./<prefix>_control.sopcinfo \
--report-file=html:./<prefix>_control.html \
--report-file=qip:./<prefix>_control/synthesis/<prefix>_control.qip \
--component-file=./<prefix>_control.qsys"

• Create the project, overwriting any previous settings files:

project_new <prefix>_dp_demo -overwrite

• Add the assignments to the project:

source assignments.tcl

• Compile the project:

execute_flow –compile

• Clean up by closing the project:

project_close

Build, Load, and Run the Software

In this step you build the software, load it into the device, and run the software.

1. In a Windows command prompt, navigate to the ‘software’ directory in the design example project directory

2. Launch a Nios II command shell. You can launch it using several methods, for example, from the Windows task bar or within the Qsys system. To run this command from the Windows command prompt, use the command:

start "" %SOPC_KIT_NIOS2%\"Nios II Command Shell.bat" <CR>

3. From within the Nios II command shell, execute the following command to build the software, program the device (.sof file), download the Nios II program (.elf file), and launch a debug terminal:

./batch_script.sh <USB cable number> <CR>

To find the USB cable number, type:

jtagconfig <CR>

The script also creates the dp_demo, and dp_demo_bsp subdirectories inside the software directory. If you have already built the software, use the rerun.sh script to program the device (.sof), download the Nios II program (.elf), and launch the terminal: ./rerun.sh <CR> Refer to Chapter 15: Nios II Software Build Tools Reference in the Nios II Software Developer’s Handbook for a description of the commands used in these scripts.

Viewing the Results

The DisplayPort monitor will display the color bars shown in Figure below.

 

The Nios II command shell will capture and display the AUX channel transactions as shown below.

Appendix A: Link Training

The DisplayPort IP core TX configures the link rate and lane count through a link training sequence. In this design example, software running on Nios II processor performs the link training after the DP IP core detects an HPD event. When the DisplayPort IP core detects a long HPD, it asserts IRQ to the Nios II embedded processor and HPD interrupt service routine performs the link training.

Link training consists of two distinct tasks which must be completed successfully in sequence to establish the link within 10ms period. These are:

• Clock Recovery: This stage locks the receiver CR (clock recovery) PLL to the repetition of D10.2 data symbols.

• Channel Equalization / Symbol-Lock / Inter-lane Alignment: When successful, the Symbol-Lock and Inter-lane alignment must be achieved by the end of this sequence.

The following figures show the flow diagram of each training sequence for the full link training sequence performed by software.

Clock Recovery (CR) Sequence of Link Training

 

Channel Equalization (EQ) Sequence of Link Training

Appendix B: Transceiver Reconfiguration

Transceiver Reconfiguration Controller

The Transceiver Reconfiguration Controller IP core provides an Avalon-MM slave interface to dynamically reconfigure the specific functionality of the DisplayPort IP transceivers. A finite state machine (FSM) or an embedded controller, such as Nios II processor, serves as the master device which controls the reconfiguration. This design example uses a FSM as the reconfiguration master.

The Transceiver Reconfiguration Controller has address space assigned to each reconfiguration feature as listed in Table below.

Reconfiguration Feature Register Address Range
PMA Analog Control 0x08 - 0x0C
EyeQ 0x10 - 0x14
DFE 0x18 - 0x1C
AEQ 0x28 - 0x2C
ATX PLL Calibration 0x30 - 0x34
Streamer (MIF-based/Direct Write) 0x38 - 0x3C
PLL Reconfiguration 0x40 - 0x44

Register address offsets are defined as follows:

Register Offset Definition
0 Logical Channel Number (Rd/Wr)
1 Physical Channel (Rd only)
2 Ctrl/Status {err[9], busy[8], mode[3:2], rd[1], wr[0]}
3 Offset (behavior depends on mode[3:2])
4 Data

For details of the register read/write steps to reconfigure a transceiver channel, refer to the Transceiver PHY IP User Guide.

The table below lists the Transceiver Reconfiguration Controller IP parameters for this design example.

Parameter Description Value
Number of reconfiguration interfaces Total number of reconfiguration interfaces required for transceiver logical channels. Each transceiver has 1 reconfiguration interface per each duplex channel and 1 per each TX/CMU PLL. This 4 lane TX-only design example uses 4 transmitters, so total 8 reconfiguration interfaces are required on the controller. Fitter merges these interfaces during compilation. 8
Enable Analog controls Enables PMA analog reconfiguration. Reconfigurable PMA analog settings are output differential voltage (VOD), Pre-emphasis, Equalization, and Equalizer DC gain. On
Enable channel/PLL reconfiguration Enables channel/PLL reconfiguration for data rate change On

Transceiver Reconfiguration Control Logic

A high-level finite state machine (FSM) in the reconfig_mgmt_hw_ctrl.v module controls the DisplayPort transceiver reconfiguration during link training. The module includes the following sub-modules:

• reconfig_mgmt_write.v

This module generates a low level write cycle on the Avalon-MM interface to the Transceiver Reconfiguration Controller IP core.

• dp_mif_mappings.v

This module maps the various MIF settings used for reconfiguration. Mapping is based on device family and link rate. These settings are for base transceiver modes used in the IP core. It includes the reference clock sources (162 and 270 MHz) as well as the local clock divider settings. The file must match the modes of the transceiver used.

• dp_analog_mappings.v

This module maps the 2-bit VOD and Pre-emphasis settings from DisplayPort IP core to the family-specific settings.

These sub-modules map the requested link rate(tx_link_rate), voltage swing(tx_vod) and pre-emphasis(tx_emp) values to device-specific registers of the transceivers, and generate a write cycle on the reconfig_mgmt_* bus to the Transceiver Reconfiguration Controller IP core.

When the DisplayPort IP core TX makes a reconfiguration request, it drives reconfiguration data on tx_link_rate, tx_vod, and tx_emp bus and asserts tx_reconfig_req and tx_analog_reconfig_req to high. The reconfig_mgmt_hw_ctrl module asserts tx_reconfig_ack and then initiates the reconfiguration cycle. During reconfiguration, the reconfig_mgmt_hw_ctrl holds tx_reconfig_busy high and drives it low when reconfiguration completes.

The figure below shows the connection between the transceiver reconfiguration block, DisplayPort IP core, and Nios II embedded processor.


In a design where a DisplayPort re-driver (e.g. SN75DP130) regenerates the DisplayPort main link signals, the FPGA transmitter analog settings (voltage swing and pre-emphasis) can be fixed to the default values. In this case, the dynamic reconfiguration of FPGA transmitter analog settings is disabled. During link training, the DisplayPort re-driver device, which drives the DisplayPort cable, can monitor the AUX channel and automatically adjust its output signaling levels and input equalizers in response to link training commands.

If your design doesn’t use a DisplayPort re-driver device, you should enable the dynamic reconfiguration of the FPGA transmitter analog settings by turning on Support analog reconfiguration in the DisplayPort IP core parameter editor. The DisplayPort IP core analog reconfiguration interface should be exported in Qsys to connect to the reconfiguration block in the top-level module.

Transceiver Analog Parameters Set Using QSF Assignments

You can specify transceiver analog settings through the Quartus II Settings File (.qsf) when you want to change the default settings for your programming file (.sof). Table 6 lists the example analog parameters for the DisplayPort TX channel that can be set using .qsf assignments. Options for each assignment vary depending on the device's family. For the complete list of QSF assignment names and options for each assignment, refer to Transceiver PHY IP Core User Guide. You can also open the .qsf file for this design example and check the assignments.

QSF Assignment Name Pin Planner and Assignment Editor Name Assigned To
XCVR_TX_VOD Transmitter Differential Output Voltage Pin – TX serial data
XCVR_TX_PRE_EMP_1ST_POST_TAP Transmitter Pre-emphasis First Post-Tap Pin – TX serial data
XCVR_TX_SLEW_RATE_CTRL Transmitter Slew Rate Control Pin – TX serial data
Version history
Revision #:
3 of 3
Last update:
‎08-20-2020 04:27 PM
Updated by:
 
Contributors