DisplayPort Intel® FPGA IP User Guide

ID 683273
Date 11/12/2021

A newer version of this document is available. Customers should click here to go to the newest version.

Document Table of Contents
Give Feedback

9.1. Using the Library

The following figure describes a typical user application flow. The user application must initialize the library as its first operation. Next, the application should initialize the instantiated devices (sink and/or source), partly in the btc_dptx_syslib and btc_dprx_syslib data structures and partly in the user application. You must also implement interrupt service routines (ISRs) to handle interrupts generated by the DisplayPort core.

When initialization completes, the user application should periodically invoke the library monitoring function.

Figure 42. Typical User Application Flow

The following figure shows a more detailed view of these operations. For a sink application, the user application must initialize the DPCD content and the EDID. Additionally, for both source and sink applications, an interrupt ISR must be registered.

Figure 43. Typical Source and Sink User Application Library Calls

Sink instantiations issue an interrupt to the GPU when an AUX channel Request is received from the connected source. Source instantiations issue an interrupt to the GPU when a logic state change is detected on the HPD signal generated by the connected DisplayPort sink.

Because sources always act as AUX channel masters, they can manage AUX communication by initiating a transaction (by sending a request) and then polling the IP registers waiting to receive a reply. Optionally, source instantiations can also issue an interrupt to the GPU when an AUX channel reply is received from the connected DisplayPort sink, allowing the GPU to execute other tasks while waiting for AUX channel replies.

Enable or disable source and sink interrupts with the following library macros:


btc_dprx_syslib manages one to four sink instances by disabling all GPU interrupts when invoked and restoring them to their previous state on exiting. Therefore, most of the library public functions implement critical sections.

The GPU main program should minimize overhead when serving interrupts generated by sink instances (i.e., interrupts related to a connected source’s AUX channel requests).

Interrupts generated by source instances (i.e. interrupts related to a connected sink’s HPD activity) can be served with a lower priority. In designs where the same GPU handles both source and sink instances, the GPU must allow for nested interrupts originated by sinks. That is, a sink must be allowed to interrupt a source interrupt service routine (but not another sink interrupt service routine).

Typical Sink ISR Implementation

btc_dprx_aux_get_request (0,&cmd,&address,&length,data); 

Typical Source ISR Implementation

<Enable nested interrupt> 
if (HPD asserted) 
		 <read Sink EDID> 
		 <set video output resolution> 
else if (HPD deasserted)
		 btc_dptx_video_enable(..., 0); 
else if (IRQ_HPD)
		 <check link status> 
		 if (Test Automation request) 
<Disable nested interrupt>