DisplayPort TX IP Core Link Training Abort

[spte]

Hi All,

we are using the Intel DisplayPort TX IP core on Cyclone 10 GX FPGA and we see link training failures with a certain sink (monitor) of our customer.

Using a DP aux channel analyzer, we see that during the test of voltage levels and pre-emphasis, the DP TX core aborts the link training process instantly after about 60 ms.

This is caused due to a delay behavior of the sink: 

Each time, after the DP TX core writes training pattern sets (0x102) or training lane sets (0x103), the sink answers the next 8 source status reads each with AUX_DEFER, until finally providing the requested status. This results in a long duration of the whole link training process, which is aborted by the DP TX core after about 60 ms.

Tests of the monitor at a commercial GPUs shows that the link training process takes more than a second until finally succeeds.

We have no link training problems with other commercial monitors.

Questions:

• Why does the link training process not complete?
• We expect that there is some kind of  internal timeout within the DP TX core and ask of how we can change this value.
• We knew that within the sink (monitor) works a Xilinx DP RX IP core, so probably there are pre-known incompatibilities between Intel and Xilinx DisplayPort cores?

Note:

We use dp tx core version v20.0.1, config without support for DP 1.4

We use quartus pro version 22.3

I attached two aux channel analyzer logs, where the AUX-DEFER packets and the DP TX abort can be seen. I had to compress them to zip due to the forum upload restrictions.

Thank you in advance!

Stefan

[vgs]

Hello,

1) The Intel DPTX stopped the link training after failing the clock recovery phase. I may be wrong but I believe this may be because it reached a maximum number of attempts rather than a specific timeout. Per DP specs, I think a TX may give up on clock recovery after 10 failed attempts or after 5 attempts if the RX does not update values in the adjust request registers (voltage and preemphasis).

2) Apparently, the GPU DPTx gives the monitor a fair amount of time (15ms) between the write to voltage swing and preemphasis (h00103+) and checking the lane status (h00202+). The Intel DPTx  checks this after 200us. This may explain the difference but this is already more than what is mandated in the DP standards (100us). I haven't found a way to tweak this.

3) The Xilinx DP RX also took a while and multiple attempts/adjustments to establish CR with the GPU DPTx. Do you have a shorter/better DP cable available to give this a second try?

Kind regards,

Vgs

[ZH_Intel]

Hi there,

Thank you for reaching out.

Apologize for the delayed response as we encounter some technical difficulty.

Just to let you know that Intel has received your support request and currently we are confirming the details with our internal team.

I shall come back to you with findings.

Thank you for your patience.

Best Regards,

ZH_Intel

[spte]

Hi there,

Thank you for your answers. Concerning the remark 3 from user vgs above, our cables are of high quality and I tested several different ones. It rather seems to be a problem of the available patterns that are checked by the DPTX core.

I now have a second log with the same Intel FPGA DPTX core, but with a modified Xilinx DPRX design.

(please see the attached log, I had to zip it for upload reasons)

I short, the log contains the following:

* Try 5.4 Gbit/s up to voltage level 1 without reaching CR_DONE

* Try 2.7 Gbit/s up to voltage level 1, reach CR_DONE, try pre-amp to level 2, Intel DPTX core aborts 

* Try 1.6 Gbit/s up to voltage level 1, reach CR_DONE, try pre-amp to level 2, Intel DPTX core aborts 

Complete abort after about 110 ms.

So again, the Intel DPTX core aborts link training without trying voltage level 2. Reading the DP1.2 spec, I found in the description of address 0x0103: Bit 2 = MAX_SWING_REACHED
"The transmitter must support at least three levels of voltage swing, levels 0, 1 and 2. If only three levels of voltage swing are supported, then bit 2 must be set to 1 when bits 1:0 are set to 10b (level 2) and must be cleared in all other cases. ....."

During the test with speed 2.7 Gbit/s and 1.6 Gbit/s, MAX_SWING_REACHED is never set.

--> So why does the Intel DPTX core not test voltage level 2??

Thank you in advance!

Stefan

[ZH_Intel]

Hi Stefan,

Thank you for your reply.

Allow me to clarify with you some of the items below:

1) Could you share with us the design you are using? DPTX only design?

2) Is the design derived from Design Example or custom design? Link controller module from Design example?

3) Could you share with me the setup environment of your project? DPTX -->DP AUX analyzer --> Monitor? are you using DP certified cable?

(Connection setup, type of cable use, cable length, FMC daughter card revision, simple diagram of connection would be helpful)

4) May I know the specification of the sink device?

Hoping to hear back from you so that we can proceed for next step.

Thank you.

Best Regards,

ZH_Intel

[ZH_Intel]

Hi Stefan,

Good day.

I wish to follow up with you about this case.

I would like to get update on my previous reply.

1) Could you share with us the design you are using? DPTX only design?

2) Is the design derived from Design Example or custom design? Link controller module from Design example?

3) Could you share with me the setup environment of your project? DPTX -->DP AUX analyzer --> Monitor? are you using DP certified cable?

(Connection setup, type of cable use, cable length, FMC daughter card revision, simple diagram of connection would be helpful)

4) May I know the specification of the sink device?

Hoping to hear back from you so that we can proceed for next step.

Thank you.

Best Regards,

ZH_Intel

[spte]

Dear ZH-Intel,

Thank you for your response. To answer your questions:

1) unfortunately, the DPTX is embedded within a larger design I cannot share with you. We use dp tx core version v20.0.1, config without support for DP 1.4 and config without support for MST and without support for HDCP

2) The design is directly derived from the design example of the intel display port fpga ip core. We use the btc_xxx functions from the demo design, especially the function "btc_dptx_link_training"

3) Our setup is as you suggested: DPTX --> AUX analyzer --> monitor. I tested different types and length of cables including cables for 8K, but my design requires UHD only. 

4) The link device contains a Xilinx IP core as far as I know. Are there any known incompabilities?

One interesting thing I noticed, is that during link training, the Xilinx core of the monitor requests 5 times the same settings for voltage and pre emphasis. At the 5th adjust request, the dptx core aborts. The intel core manual writes:

The source checks for the Link Driver setting adjust request (0x00206 – 0x00207) and responds accordingly.

In the same Link Driver setting, if the source has already repeated Training Pattern Sequence 2 for 5 times, the source will lower the Link Bandwidth (from HBR2 to HBR to RBR) in offset 0x00100, aborts Training Pattern Sequence 2, and restarts Link Training Pattern Sequence 1.

But the 5th request is never processed, the core aborts instantly. It may be the cause of some misunderstandig between the xilinx sink core and the Intel source core, whether 5 requests of the same values for voltage and preamp are allowed or if the 5th request is already a reason for abort(!). So the next voltage setting level 2 is never tested. We observed, that other sources (GPU) achieved link training results with this level 2 setting.

So one question is, if it is reasonable concerning the link training function to abort at the 5th request instead of processing the 5th request and abort at the 6th...

It would really help us a lot - I would say solve our problem - if we would have the source code of the function "btc_dptx_link_training". Since all other btc_ functions are already provided in the tx_syslib library, we that will be able to modify the link training process and hopefully achieve successfull training.

Please, can you provide us the source code of the function "btc_dptx_link_training" of the intel FPGA display port demo design?

Thank you in advance,

Stefan

[ZH_Intel]

Hi Stefan,

Good day.

Thank you for your reply.

At the moment there is no known incompatibility issues.

Regarding to your question on source code of the function "btc_dptx_link_training", Unfortunately, I am unable to provide the source code as only engineering has access to it.

For source code request, you need to reach out to your FAE in your region to proceed request on the cleartext code.

Thank you.

Best Regards,

ZH_Intel

[ZH_Intel]

Hi Stefan,

Good day.

I wish to follow up with you about this case.

Do you still have further inquiries on this issue?

Is there anything else I can help you with regards to this case?

If there is no further inquiries, I will transition this thread to community support. 

Thank you.

Best Regards,

ZH_Intel

[ZH_Intel]

Hi Stefan,

Good day.

We do not receive any response from you to the previous reply that I have provided. 

Since there is no further inquiries, this thread will now be transitioned to community support. If you have a new question, feel free to open a new thread to get the support from Intel experts. Otherwise, the community users will continue to help you on this thread.

Stay safe, and I hope you have a great day.

Thank you.

Best Regards,

ZH_Intel

[spte]

Hi Forum,

Finally I would like to thank Intel!

We got a new pre-compiled DLL for our link-training, which changed/corrected two topics

* Link training abort time < 100 ms has been removed for DP 1.2 (valid only in higher versions)

* The sink (DP TX core) now allows the source (monitor) to request 5 times the same value before abort at 6th same request.

With these changes, all worked well.