A5E-DP-Example¶
Overview¶
The A5E DisplayPort example builds on the base A5E reference design and adds the dp_subsys subsystem, which drives a DisplayPort connector directly from the FPGA fabric.
The design is a DisplayPort source. It generates its own video with a test pattern generator in the fabric, encodes it with the DisplayPort IP, and transmits it over four serial lanes to an attached monitor. There is no DisplayPort input, and no video is taken from the HPS.
The subsystem is self-contained. A NiosV soft processor inside the subsystem runs the DisplayPort demo firmware, which handles hot plug detect, reads the monitor's capabilities over the AUX channel, trains the link and starts the video stream. That firmware is compiled into the FPGA image, so the example runs as soon as the FPGA is configured. Unlike the other example designs, this one presents nothing to Linux: there is no lightweight bridge connection, no device tree overlay and no Linux device.
This example is provided for the MitySOM, MitySOM-Mini and MitySBC platforms, but not on every model. The DisplayPort lanes are carried on a GTS transceiver bank, and the smaller FPGA densities do not bond that bank out of the package. Each platform routes DisplayPort to a different bank, so the minimum device differs by platform:
| Platform | GTS bank | Smallest device with DisplayPort |
|---|---|---|
| MitySOM | 4A | A5E 052 (524 KLE) |
| MitySOM-Mini | 1B | A5E 028 (282 KLE) |
| MitySBC | 4C | A5E 052 (524 KLE) |
Building this example for a module below the threshold stops with an error naming the bank concerned, so an unsupported part is caught at compile time rather than at the connector.
DisplayPort Subsystem¶
The subsystem contains fifteen blocks. The control plane:
- cpu - a NiosV/m soft processor running the DisplayPort demo firmware
- onchip_mem - 256 KB of on-chip RAM holding that firmware, initialised at FPGA configuration
- jtag_uart - the demo's console, reached over the JTAG cable
- sys_clock_timer - timestamp timer for the firmware
- sysid - system identifier
- dp_tx_mgmt_bridge - bridges the processor to the DisplayPort IP's management interface
- dp_core_pio_board - 32-bit output PIO for board control, for Altera's DisplayPort board and not used in this example
- reset_ctrl - two-stage reset sequencer that holds the subsystem in reset until both PLLs lock
The video datapath:
- vvp_tpg - test pattern generator, the video source for this example
- vvp_cvo - clocked video output, which adds the blanking and sync timing
- vvp_fr2cv - full raster to clocked video converter
- dp_video_bridge - adapts the video stream onto the DisplayPort IP's video input
The link:
- dp_source - the DisplayPort IP, configured as a transmitter
- dp_xcvr_bridge - adapts the IP's transceiver interface to the GTS PHY
- dp_gts_tx - the GTS transceiver driving the four DisplayPort lanes
Two clock bridges bring external clocks in: mgmt_clock for the 100 MHz management clock and refclk_150 for the 150 MHz transceiver reference clock. Two IOPLLs, dp_iopll and dp_pxl_iopll, derive the internal clocks from the management clock.
control plane
┌──────────────────────────────────────────────────────┐
│ cpu (NiosV/m) │
│ ├──► onchip_mem (256 KB, holds the firmware) │
│ ├──► jtag_uart (demo console) │
│ ├──► sys_clock_timer / sysid │
│ ├──► dp_core_pio_board │
│ └──► dp_tx_mgmt_bridge ──► dp_source.tx_mgmt │
└──────────────────────────────────────────────────────┘
video datapath
┌─────────┐ ┌─────────┐ ┌───────────┐ ┌──────────────────┐
│ vvp_tpg │───►│ vvp_cvo │───►│ vvp_fr2cv │───►│ dp_video_bridge │
└─────────┘ └─────────┘ └───────────┘ └────────┬─────────┘
1920x1080 adds blanking │
test pattern and sync ▼
┌──────────────────┐
│ dp_source │
│ (DisplayPort IP)│──► AUX_TX_DRV_OE/OUT/IN
└────────┬─────────┘◄── TX_HPD
▼
┌──────────────────┐
│ dp_xcvr_bridge │
└────────┬─────────┘
▼
DISPPORT_REF_CLK ──► refclk_150 ─────────────► ┌──────────────────┐
(150 MHz) │ dp_gts_tx │──► DISPPORT_TX_P/N[3:0]
└──────────────────┘
h2f_user0_clk ──► mgmt_clock ──┬──► dp_iopll ──► 300 MHz, 16 MHz
(100 MHz) ├──► dp_pxl_iopll ──► pixel clock
└──► cpu and every management interface
What This Project Offers¶
This project provides:
- A complete DisplayPort transmit path from a video source in the fabric to the connector
- A working instantiation of the DisplayPort IP with its AUX channel and hot plug detect wired to the connector
- DisplayPort demo firmware running on a NiosV in the fabric, with an interactive console for link status and DPCD access
- A video pipeline built from the Video and Vision Processing suite, ready to have the test pattern generator swapped for a real video source
Link and Video Capabilities¶
| Property | Value |
|---|---|
| Direction | Transmit only, no DisplayPort input |
| Lanes | 4 |
| Maximum link rate | 8.1 Gbps per lane (HBR3) |
| Output resolution | 1920x1080 at 60 Hz |
| Colour | 8 bits per component, RGB 4:4:4 |
| Pixels in parallel | 4 |
| Multi-stream transport | Not enabled |
| Audio | Not enabled |
| HDCP | Not enabled |
| Display Stream Compression and FEC | Not enabled |
The link rate and lane count above are the maximums the IP is built for. The firmware trains down to whatever the attached monitor supports.
NiosV Memory Map¶
These addresses are seen by the NiosV inside the subsystem. They are not visible on the HPS lightweight bridge, and no part of this subsystem can be reached from Linux.
| Block | Address | Notes |
|---|---|---|
| onchip_mem | 0x00000000 | 256 KB, holds the firmware |
| dp_source management interface | 0x00100000 | through dp_tx_mgmt_bridge |
| sysid | 0x00108000 | |
| sys_clock_timer | 0x00109000 | |
| jtag_uart | 0x0010A000 | |
| dp_core_pio_board | 0x0010C000 | not used in this example |
| cpu debug module | 0x00110000 |
Interrupts into the NiosV:
| IRQ | Source |
|---|---|
| 0 | jtag_uart |
| 1 | sys_clock_timer |
| 2 | dp_source transmit management |
Clocking and Reset¶
The subsystem takes two clocks from outside:
- mgmt_clock carries the 100 MHz HPS user0 clock, from hps_subsys.intel_agilex_5_soc_0_h2f_user0_clk. It clocks the NiosV, the on-chip memory, the console, the timer, and every management interface, and it is the reference for both IOPLLs.
- refclk_150 carries the 150 MHz DisplayPort reference clock from the DISPPORT_REF_CLK pin. It is the GTS transceiver's reference clock, supplied by the clock generator on the carrier board.
Because the management clock comes from the HPS, the HPS must be out of reset and clocking the fabric before any of this runs. The DisplayPort example is not a standalone fabric design.
The two IOPLLs generate:
| PLL | Output | Frequency | Used by |
|---|---|---|---|
| dp_iopll | outclk0 | 300 MHz | DisplayPort IP synchronisation clock |
| dp_iopll | outclk1 | 16 MHz | AUX channel clock |
| dp_pxl_iopll | outclk0 | 37.125 MHz | pixel clock for the video pipeline |
The pixel clock is a quarter of the 148.5 MHz pixel rate of 1080p60 because the video pipeline carries four pixels per clock.
Reset comes from fabric_reset_controller_0.reset_out at the top level and passes through reset_ctrl, which releases it in two stages: first the PLLs, then the rest of the subsystem once both PLLs report lock. Nothing in the subsystem leaves reset until the clocks are stable.
Board Interface Signals¶
| Signal | Direction | Purpose |
|---|---|---|
| DISPPORT_TX_P/N[3:0] | output | the four DisplayPort main link lanes |
| DISPPORT_REF_CLK | input | 150 MHz transceiver reference clock |
| AUX_TX_DRV_OUT | output | AUX channel transmit, to the external bidirectional buffer |
| AUX_TX_DRV_IN | input | AUX channel receive, from that buffer |
| AUX_TX_DRV_OE | output | direction control for that buffer |
| TX_HPD | input | hot plug detect from the connector |
| TX_CONFIG1 | output | tied low in the design |
TX_CONFIG1 is driven low because these designs are a plain DisplayPort source with no active cable or redriver to configure, and low is the correct deasserted state.
The reference clock's electrical standard follows the clock generator on each carrier:
| Platform | Reference clock I/O standard |
|---|---|
| MitySOM | CML |
| MitySOM-Mini | HCSL |
| MitySBC | CML |
Scope of This Example¶
The video source in this design is a test pattern generator, not a real image source. The pipeline in front of the DisplayPort IP is built from standard Video and Vision Processing suite components, so the test pattern generator can be replaced with another video source that produces the same stream format.
That makes it a good base for:
- driving a display from video generated or processed in the fabric
- bringing up and characterising a DisplayPort monitor or cable assembly
- measuring the DisplayPort transmit path on a new carrier design
Building the Example¶
Compile the FPGA design¶
Refer to Building the FPGA and Bootloader (MitySOM) or Building the FPGA and Bootloader (MitySBC) for building the FPGA design. Navigate into the mitysom-a5e-ref-dp, mitysom-a5e-mini-ref-dp or mitysbc-a5e-ref-dp example project before compiling the design.
- Ensure to flash the resulting a5e.hps.jic onto the hardware
- Ensure to replace the a5e.core.rbf on the SD card
Compiling this project also builds the NiosV firmware. The build runs the DisplayPort software build script, links the firmware against the DisplayPort IP's libraries, and turns the result into a memory initialisation file that Quartus loads into the on-chip RAM as part of the FPGA image. This happens automatically as part of the normal build, but it does mean the DisplayPort IP must be installed with Quartus, and that a compile of this project takes longer than the other examples.
Because the firmware ships inside the FPGA image, there is nothing to copy to the target and nothing to start. Configuring the FPGA starts the demo.
Using the Example¶
Hardware setup¶
- Program a design that includes this DisplayPort example.
- Connect the board's DisplayPort connector to a monitor with a DisplayPort cable.
- Boot Linux on the HPS. The subsystem's management clock comes from the HPS, so the demo does not run until the HPS is up.
The monitor can be connected before or after boot. The firmware watches hot plug detect and trains the link whenever a display appears.
What to expect¶
Once the link trains, the monitor shows a test pattern at 1920x1080 and 60 Hz. Nothing needs to be run on the target to make this happen.
Connecting to the demo console¶
The firmware's console is a JTAG UART inside the FPGA, not the board's serial console. Reach it over the same JTAG cable used to program the device, with the juart-terminal utility that ships with Quartus:
juart-terminal
On connecting, the firmware prints its banner:
Welcome to Altera DisplayPort Nios console... Press 'h' for help and UI menu, 's' for status
The console is interactive, so the keys below are typed into juart-terminal.
Console commands¶
Press h for the menu:
| Key | Action |
|---|---|
| h | print the menu |
| q | report how the DisplayPort IP is configured |
| s | link and video status |
| c | read the monitor's CRC through DPCD |
| t+ / t- | raise or lower the maximum link rate, then retrain |
| x+ / x- | raise or lower the maximum lane count, then retrain |
| y | retrain the link |
| Dr [N] [addr] | read N DPCD registers from the monitor, start address in hexadecimal |
| Dw [addr] [val] | write a DPCD register on the monitor, both in hexadecimal |
The menu also lists p, for sending a PHY test pattern. That command reports that test automation support is not enabled, since this build does not include it.
q reports what the IP was built for, which is the quickest way to confirm the image on the board is the one expected:
--- DP RX: disabled --- DP TX: enabled DP TX bps: 8 DP TX max link rate: 8.1 Gbps DP TX max lane count: 4 DP TX interface: Clocked Video DP TX 8b10b FEC support: disabled DP TX multi-stream support: disabled DP TX DSC support: disabled DP TX Aux channel monitoring: disabled DP TX test automation support: disabled
s reports the trained link and the video timing being transmitted. On a healthy link, MSA lock is 1 and the geometry matches the output resolution:
------ TX Main stream attributes ------ --- Channel Coding : 8b10b --- Stream 0 --- MSA lock : 1 Htotal : 2200 Vtotal : 1125 Hwidth : 1920 Vheight : 1080 ------------------------------------------ -------- TX Link configuration ------- Lane count : 4 Channel Coding : 8b10b Link rate : 5400 Mbps MST : off
The link rate reported here is the rate the link actually trained to, not the maximum the IP supports. The example above shows a monitor that trained at 5400 Mbps on four lanes, well inside the 8.1 Gbps the IP is built for.
The t+, t-, x+ and x- commands are the quickest way to check that a marginal cable or monitor works at a lower link rate: drop the rate or the lane count, retrain, and see whether the picture comes back.
Troubleshooting¶
The monitor stays blank and reports no signal¶
Confirm the HPS has booted, since the subsystem's management clock comes from the HPS and nothing in the subsystem runs before that. Then open the demo console and press s. An MSA lock of 0, or a link rate of 0, means the link never trained, so the problem is on the cable or at the monitor rather than in the video pipeline.
The demo console shows nothing¶
juart-terminal needs the JTAG cable connected and the FPGA configured with this design. Confirm the cable is visible to the Quartus tools first. A blank console with a working cable usually means the NiosV is still in reset, which happens when one of the subsystem PLLs has not locked.
The link trains but the picture is unstable or drops out¶
Try a shorter or better quality DisplayPort cable, then lower the maximum link rate with t- and retrain with y. A link that is stable at a lower rate points at the cable or the connector rather than the design.
The build fails saying the GTS bank is not bonded out¶
The selected module's FPGA is below the minimum density for DisplayPort on that platform, so the bank carrying the lanes is not brought out of the package. See the table in the overview for the smallest device on each platform.
References¶