Intel DisplayPort IP - DPCD Register Access

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

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

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

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?

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

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

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

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