UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
637 Views
Registered: ‎03-03-2017

DisplayPort TX DPCD State Machine bug?

I am using the DisplayPort TX block example design in Vivado/SDK 2018.1 which I am plugging into a custom DP Receiver chip which our company designs and I am monitoring the DPCD communication using a Unigraf DPA-400 auxiliary channel analyzer.

It seems the training sequence which is controlled by the Xilinx DPCD master (DP Source) doesn't follow the protocol mentioned in the VESA DisplayPort Standard documentation.   The KC-705 DP Source seems to start the clock-recovery phase of training just fine, and then reads back from the DP Rx if CR_DONE=1 which our chip does respond just fine, but the KC-705 DP source never stops that portion of the training and moves on the the EQ portion of the training (TPS2/3/4).

Is there possibly a bug in the current implementation?

If you would like more details we can take this into a private conversation.   But I am suspecting there is a bug in the current implementation of the DP Tx DPCD state machine.

Vivado/SDK Version used: 2018.1

dp_tx_subsystem (in block design): 2.1 (rev. 2)

dp_v7_0 used in BSP

dptxss_v6_0 used in BSP

Thanks.

Tim

0 Kudos
10 Replies
627 Views
Registered: ‎03-03-2017

Re: DisplayPort TX DPCD State Machine bug?

DPCD Sequence experienced with (KC-705 -> DP Tx -> our Custom DP rx chip):

KC705: Sets 4 lanes 5.4Gbps

KC705: Initiates training using TRAINING_PATTERN_SET=1

KC705: Request training status

   Custom DP RX: Reports LANEX_CR_DONE=1 for all lanes

KC705: keeps doing this 5 times

KC705: Stops training by setting TRAINING_PATTERN_SET=0

KC705: Sets 4 lanes 2.7Gbps

KC705: Initiates training using TRAINING_PATTERN_SET=1

KC705: Request training status

   Custom DP RX: Reports LANEX_CR_DONE=1 for all lanes

KC705: keeps doing this 5 times

KC705: Stops training by setting TRAINING_PATTERN_SET=0

....

Wheras when I plug the KC705 DP Tx into a Lilliput DP monitor:

KC705: Initiates training using TRAINING_PATTERN_SET=1

As soon as the monitor returns LANEX_CR_DONE=1 the KC705 DP TX changes TRAINING_PATTERN_SET to 3.

 

Why would this not occur on the custom DP Rx?   Would it be some kind of a timing problem?   Any insight here would be very helpful.

 

Thanks.

Tim

0 Kudos
Scholar watari
Scholar
617 Views
Registered: ‎06-16-2013

Re: DisplayPort TX DPCD State Machine bug?

Hi @tim_severance

 

According to your DP sequence information, it seems signal integlity issue between two chips or clock recovery issue which include reference clock jitter.

 

Would you make sure them ?

Also I recommend to check PLL lock status and symbol and disparity errors in the Sink through DPCD registers.

Would you refer the following document on page 114 and 115, if you need more detail ?

 

https://www.xilinx.com/support/documentation/ip_documentation/dp_tx_subsystem/v2_1/pg199-displayport-tx-subsystem.pdf

 

Best regards,

 

0 Kudos
611 Views
Registered: ‎03-03-2017

Re: DisplayPort TX DPCD State Machine bug?

@watari,

   Thanks for the response.

   I do not believe it to be a signal integrity issue due to the fact that if I unplug the DP cable from the KC705 DP Tx source and plug instead into our own DP Tx solution then everything works and if I watch the AUX analyzer it works correctly where the DP RX gets clock recovery and then the DP TX moves on the further training.

   Also, if I use the same DP cable and plug the KC705 DP TX into a monitor and watch the DP AUX, then that seems to work fine as well.

   So it seems to be some interaction between the KC705 DP TX and our custom DP RX and our DP RX reports clock recovery success, so why doesn't the DP TX stop the training at that point and move forward with starting TPS2 or TPS3?   That is simple logic and should have nothing to do with signal integrity as far as I can tell.

   So I guess what I am looking for is for somebody to look through the DP TX AUX state machine and see if there is any way it can get clock recovery success and *not* move forward with further training.

 

Thanks.

Tim

0 Kudos
574 Views
Registered: ‎03-03-2017

Re: DisplayPort TX DPCD State Machine bug?

If somebody takes this offline I can share my AUX analyzer logs.  

Tim

0 Kudos
Moderator
Moderator
560 Views
Registered: ‎11-09-2015

Re: DisplayPort TX DPCD State Machine bug?

Hi @tim_severance,

Please share your AUX log via email. I will have a look next week.

Regards,


Florent
Product Application Engineer - Xilinx Technical Support EMEA
**~ Don't forget to reply, give kudos, and accept as solution.~**
543 Views
Registered: ‎03-03-2017

Re: DisplayPort TX DPCD State Machine bug?

@florentw, Thank you, I just sent you an email with all the details.

Tim

0 Kudos
Moderator
Moderator
489 Views
Registered: ‎11-09-2015

Re: DisplayPort TX DPCD State Machine bug?

Hi @tim_severance,

Do you have any updates on this.

Just for some detail of our offline chat.

I agree that there is something wrong in the training. I suggested to try with a GPU to see what you get. It could also be a good reference if the training succeed with it.

Thanks and Regards,


Florent
Product Application Engineer - Xilinx Technical Support EMEA
**~ Don't forget to reply, give kudos, and accept as solution.~**
0 Kudos
Moderator
Moderator
436 Views
Registered: ‎11-09-2015

Re: DisplayPort TX DPCD State Machine bug?

HI @tim_severance ,

Did you make any progress on this?

From our discussion, your RX device was also not able to train with another source. So I suspected something wrong with your RX device.


Florent
Product Application Engineer - Xilinx Technical Support EMEA
**~ Don't forget to reply, give kudos, and accept as solution.~**
0 Kudos
420 Views
Registered: ‎03-03-2017

Re: DisplayPort TX DPCD State Machine bug?

 



@florentw ,

   Sorry, my priorities have not been on this project for a while so I do not have an update.   If you want we can close this and I can reopen a new forum post should it become an issue where I have verified that GPU video sources work but the Xilinx video source does not.  

Tim

0 Kudos
Moderator
Moderator
417 Views
Registered: ‎11-09-2015

Re: DisplayPort TX DPCD State Machine bug?

Hi @tim_severance ,

No need to close this. Just reply to this topic if you are back working on this. I wads just checking you didn't need any further assistance for the moment ;)


Florent
Product Application Engineer - Xilinx Technical Support EMEA
**~ Don't forget to reply, give kudos, and accept as solution.~**
0 Kudos