Intel DisplayPort IP - DPCD Register Access

[DZuck1]

For the Intel DisplayPort IP, is there anyway to access the DPCD register without using the btc_dprx_dpcd_gpu_access() function in the NIOS code?

I do not plan on using a NIOS to set up the core and some of the functions in the sample code are precompiled and do not provide source code.

[Deshi_Intel]

Hi,

short answer is YES.

You can use the DisplayPort Intel FPGA IP core to instantiate sources and sinks.

• Source instantiations require an embedded controller (Nios II processor or another controller) to act as the policy maker.
• Sink instantiations greatly benefit from and may optionally use a controller (GPU).

I presume you just want to use DP IP sink interface only. There is setting option in the IP to enable/disable GPU support.

• After that, you can refer to DP IP user guide table 198 (page 235) for DP sink DPCD register mapping location for both with GPU or without GPU option.
• https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/ug_displayport.pdf#page=235&zoom=100,0,0

Thanks.

Regards,

dlim

[DZuck1]

My goal is to replace the NIOS II processor in the sample design with the HPS in a Stratix 10 (RX & TX with PCR). The current software library has commands to set the EDID and DPCD using GPU access. I cannot use this software as it is precompiled for NIOS and not ARM (uses functions like ALTR_READ() ). Is there an Avalon alternative way to set the DPCD and EDID? Looking through the documentation in your post it shows the offsets within DPCD but the offset of the DPCD register region itself. These offsets are not the register addresses because there are already registers defined with those addresses. [cid:image003.png@01D5F211.9FE8FD30] [cid:image006.png@01D5F211.9FE8FD30] [cid:image007.png@01D5F211.9FE8FD30] May the DPCD registers are defined in the separate EDID interface to the core shown here? [cid:image001.png@01D5F210.06750AF0] My concern is that Platform Designer only shows this interface when Enable GPU Control is turned off. However, turning off GPU control also removes the rx_mgmt interface. See below: [cid:image002.png@01D5F210.BD38C330] [cid:image004.png@01D5F210.BD38C330]

[DZuck1]

My goal is to replace the NIOS II processor in the sample design with the HPS in a Stratix 10 (RX & TX with PCR). The current software library has commands to set the EDID and DPCD using GPU access. I cannot use this software as it is precompiled for NIOS and not ARM (uses functions like ALTR_READ() ).

Is there an Avalon alternative way to set the DPCD and EDID? Looking through the documentation in your post it shows the offsets within DPCD but the offset of the DPCD register region itself. These offsets are not the register addresses because there are already registers defined with those addresses.

May the DPCD registers are defined in the separate EDID interface to the core shown here?

My concern is that Platform Designer only shows this interface when Enable GPU Control is turned off. However, turning off GPU control also removes the rx_mgmt interface. See below:

[DZuck1]

Looking through the sample C code, it looks like if I am not in GPU mode then there is no software setup required for the RX side. This will get me around not being able to call the RX functions from the pre-compiled library.

The only issue is that I need to perform link training on the TX side which is a function I cannot use from the HPS.

[Deshi_Intel]

HI,

Sorry if I have mis-lead you earlier. 

I have consulted internal team further and below is updated feedback.

First of all, I am sorry to clarify that DP Rx DPCD register location (from doc chapter 11.9) can only be access via NIOS II software API as it's like virtual register build with c-code in software, not build as RTL register in DP Rx IP.

We always recommend customer to use our DP example design NIOS II software design and API or else customer is expected to design whole DP link policy maker using another external CPU (for instance : HPS in your case)

Let me explain from DP Tx and DP Rx point of view for your use case here

For DP Tx :

• Ideally you want to leverage the NIOS II software design available in DP example design but unfortunately you mentioned NIOS II function is not compatible with HPS
• That means you are left with option to design your whole link policy maker software design using HPS if you insist of using HPS only. HPS should be connected to DP Tx IP via tx_mgmt bus interface

For DP Rx (with GPU mode enabled) :

• Again, we have NIOS II software design available in DP example design accessible via DP Rx IP rx_mgmt bus interface
• What you can do is to connect DP Rx IP rx_mgmt interface to HPS and build your own software design

For DP Rx (with GPU mode disabled) :

• I find out that DP Rx removed rx_mgmt interface due to DPCD value is hard coded and can't be changed anymore

However, do take note of the caveat that Intel won't be able to support customer in developing their own DP link policy maker design

I hope I have explained all option and clear your doubt.

Thanks.

Regards,

dlim

[DZuck1]

For DP Rx with GPU mode disabled, since the DPCD is fixed, I should be able to plug it into a DP master device (like a PC) and it will be discovered with no configuration at all? The sample project for the non-gpu mode Sink core has an on chip EDID ROM which is pre-loaded with all of the configuration details it looks like nothing would need to be done on my part.

[Deshi_Intel]

HI,

If you use DP Rx with GPU mode disabled - yes.

There is default RTL hardcoded setting in IP code while the sink EDID ROM is now pre-stored with default EDID image.

You can overwrite the EDID image with your own EDID image.

Thanks.

Regards,

dlim

[DZuck1]

I changed my design to use the non-GPU mode DP sink with an external EDID memory (same setup as the non-gpu mode sample project). When I plug in the DP RX connection to a PC I can see the "Bitec MOnitor" show up in the PC's display settings but then the PC stops responding and the other screens plugged into the PC show a distorted screen. I have tried this on both Windows and Ubuntu PCs.

I used the edid_memory.hex file provided with the sample design to fill my EDID memory.

The picture below shows the traffic on the RX AUX channel. Does everything look correct?

[Deshi_Intel]

Hi,

Honestly speaking, we don't look at raw data transaction for debug.

Typically we rely on debug software to help decode meaning data transfer to aid in debug process.

For instance :

1. using external test tool like Unigraph DPA400 to monitor and decode Aux transaction traffic to debug DP link training process

• https://www.unigraf.fi/products/r-d-debug-tools/for-displayport/dpa-400

1. or internally Intel DP IP also included its own debug tool to print out log file that contains useful debug data like MSA lock, Hwidth and Vheight info, MISC0, BER and etc

• Debug tool is only available in "GPU mode enabled" as it's build with software design

I would suggest you to build own your own debug software tool if you prefer to use "GPU disable" mode or consider some available DP test tool from the market.

Alternatively, you can also consider to lower down refresh rate, bit per colour or video resolution to see if it helps

Thanks.

Regards,

dlim

[Deshi_Intel]

HI,

I don't hear back from you after my feedback suggestion.

Hopefully you are able to make good progress with your project development

For now, I am setting this case to closure.

Thanks.

Regards,

dlim

[DZuck1]

I was able to move to the non-gpu mode which bypassed the problem (RX). I am still not able to transmit out DisplayPort.

[Deshi_Intel]

I suspect there could be some issue with your link policy maker design. Well, IP core solution development itself is tough.

Perhaps it's time for you to consider to use NIOS II as shown in DisplayPort Example design ?

Regards,

dlim

[Deshi_Intel]

HI,

I hope you will be considering to use NIOS II as I suggested earlier. Hopefully everything goes smooth with your project development as well.

For now, I am setting this case to closure.

Thanks.

Regards,

dlim