Video Phy Controller: DRP won't return DRP ready

[johnhd]

This post follows on from post: Video Phy Controller channel id confusion

I am trying to debug a DisplayPort design based on Xapp1271 on an ultrascale device, using Vivado 2016.4.

The project works ok on an input FMC where the GTREFCLK inputs are used.

I am now using an FMC position that requires the refclks to be routed in on the southrefclk inputs.  So I have I have ONBOARD_REF_CLK=5 and DP159_FORWARDED_CLK=6. 

Debugging the software, the DRP does not return a DRPRDY signal and prevents further DRP transactions - i.e. once in this state it doesn't seem to recover.

This occurs after XVphy_ResetGtPLL and XVPhy_BufGtReset for Tx and Rx. 

Looking at UG576 it seems to describe the issue I'm having in the section on "DRP Ports of GTHE3/4_CHANNEL"

Port: PCSRSVDIN[2] Dir: In Clock: Async

Description: UltraScale FPGAs only:DRP reset. Reading read-only registers while the XCLK is not toggling (e.g., during reset or change of reference clocks) causes the DRP to not return a DRPRDY signal and prevent further DRP transactions. In such an event, PCSRSVDIN[2] must be pulsed to reset the DRP interface before initiating further DRP transactions.

However a response to this on the previous post indicates "The video phy will take care of controlling the DRP. You shouldn't have to take care of it."

If I am unable to use the reset detailed in the user guide for this situation I am unsure how to proceed - any thoughts?

- Are there any other resets too use instead (e.g. vid_phy_axi4lite_aresetn?)

- Any other ways to recover when the DRP does not respond?

- Any ways to prevent this occurring in the 1st place?

- Anything that could be causing this?

- Any other thoughts on how to debug this further?

Thanks, regards

John

[florentw]

Hi @johnhd,

I still think you shouldn't have to care about the interface.

The only thing I see that could be wrong is that you have no clock on the GT. Did you try to check in your design if you could get the clock? You can divide a clock and display it on a LED.

Regards,

[johnhd]

Hi @florentw

The message "TX GT CONFIG ENCOUNTERED ERROR" is displayed at the point the DRP ready signal problem occurs. 

If the Tx only option is selected the demo does successfully work with the default 2.7Gbps 4 lane interface. So I'm presuming that the (Tx) GT does have a clock.

If you then go on to request the link to operate at the slower 1.62Gbs rate the link fails and nothing is displayed.

The DRP ready signal problem is the 1st error the demo encounters - that is why I'm focusing on trying to get that fixed.

If I want to test if the GT does have a clock, using a LED, am I best to monitor the txoutclk from the video PHY controller?

The other option I have been exploring is your comment about trying the latest ref design in Vivado 2017.4. So I have downloaded this version. It is seeing the licenses in licence manager (Same as version 2016.4 - A full license for Vivado and Eval license for the dp_rx&tx_subsystems etc) - However when I add the dp_tx_subsystem IP it says IP license not found (e.g. in Report IP status). It then doesn't allow me to open the IP Example design - I get...

" [Common 17-69] Command failed: * IP 'design_1_dp_tx_subsystem_0_0' requires one or more mandatory licenses but no valid licenses were found. However license checkpoints may prevent use of this IP in some tool flows. Please select 'Report IP Status' from the 'Tools/Report' menu or run Tcl command 'report_ip_status' for more information."

Do I now need a new eval licence? Or something else ? Any clues - can't see how licence Manager says I have a licence but then doesn't allow me to use it!

Regards

John

[florentw]

Hi @johnhd,

Yes you should be able to check txoutclk.

Could you share a screenshot of your vivado license manager?

If you are using a  license server, you might need to update the version of Flex 11.14.1.

Regards,

[johnhd]

Hi @florentw

Thanks for your reply.

Attached are screenshots of license manager and warning message when I try to load the example project.

We are using flexlm_v11.13.1.3.

Regards

john

[florentw]

Hi @johnhd,

Then you need to upgrade Flex LM on your server.

You might want to generate the evaluation license locally to be quicker

[watari]

Hi @johnhd

> I am trying to debug a DisplayPort design based on Xapp1271 on an ultrascale device, using Vivado 2016.4.

I strongly suggest to use new flow (use Display Port Rx Subsystem IP and Display Port Tx Subsystem IP) instead of Xapp1271.

Because of example design on Xapp1271 (DisplayPort Rx IP) has a problem about video card on PC.

Would you try new flow after closing your license issue ?

Best regards,

[johnhd]

Hi @florentw

I still can't get the licensing sorted out to try the latest version of the ip and associated example design.

I am now just using a node locked local license (so assume this has nothing to do with flex lm on the server) - but can't get license to be found in Vivado although it appears OK in license manager.

Attached is the screen shot from vivado license manager - please can you confirm the DP licenses I have highlighted are the ones I need for this (the IP I have instantiated is called DisplayPort TX Subsystem).

When I try to open the IP Example Design I get...

[Common 17-69] Command failed: * IP 'design_1_dp_tx_subsystem_0_2' requires one or more mandatory licenses but no valid licenses were found. However license checkpoints may prevent use of this IP in some tool flows.
Please select 'Report IP Status' from the 'Tools/Report' menu or run Tcl command 'report_ip_status' for more information.

Report IP Status also report that "IP License not found" for the instantiated IP.

[florentw]

Hi @johnhd,

When using node locked license, the colum "Host ID matches" is important. Could you make sure it says yes?

[johnhd]

Hi @florentw

Thanks. yes "Host IDs Match" is "Yes" for all entries

Regards

John

[florentw]

HI John,

Let me try the flow with an HW evaluation license tomorrow.

Regards,

[johnhd]

thanks

[florentw]

Hi @johnhd,

It is working for me with a HW eval license

Could you make sure you have Hardware Evaluation license available in the GUI?

EDIT:

For you local license, could you try to point to the specific location in XILINXD field in Vivado License Manager:

It is mainly if you are using the .Xilinx folder (default). For some reason, vivado is not able to detect the licenses in this folder when they are IP licenses

Thanks,

Regards,

[johnhd]

Hi @florentw

Unfortunately I still can't get Vivado to see the licence properly. Please see attached.

Best regards

John

[florentw]

HI @johnhd,

Is you license also located in C:\Licenses\HW_Eval? Else make sure you are pointing to the correct location

If yes could you try to close vivado and start a new project?

Thanks,

[johnhd]

Hi @florentw

Yes the license file is in C:\Licenses\HW_Eval - see screen shot

License manager can read the file OK - see screen shot

I've just tried a new project after restarting PC & reopening Vivado - still no valid licence when adding DP IP.

Rgds

John

[florentw]

HI @johnhd,

Could you use the "report_environment -file ./report.txt" command and send me the file generated?

Thanks,

[florentw]

Hi @johnhd,

Could you regenerate your evaluation license. It seems that there is something missing inside.

You should see dp_rx_subsystem and dp_tx_subsystem with evaluation license but you cannot see it (only with the floating license but you need to update flexLM to use it).

Note sure what happened

Thanks,

Regards

[johnhd]

Hi @florentw

Thanks for the reply.

We have updated flexlm and are using the licence on the server.

This is working and I can generate the example IP - so some progress.

Unfortunately the example IP is generating long path names so am getting some errors...

ERROR: [Common 17-680] Path length exceeds 260-Byte maximum allowed by Windows: c:/xilinx/User/174test/dp_tx_subsystem_0_ex/dp_tx_subsystem_0_ex.srcs/sources_1/bd/dp_tx_subsystem_0_design_synth/ip/dp_tx_subsystem_0_design_synth_axis_clock_converter_0_0/dp_tx_subsystem_0_design_synth_axis_clock_converter_0_0/dp_tx_subsystem_0_design_synth_axis_clock_converter_0_0.xdc

Anyway it looks like I should be able to fiddle around a bit to get past this problem. I note of the 260 characters available, the example project is using 250 of them, leaving the user 10 for their project path.

I'll re-target the example project at my demo board (which isn't the KCU105) and let you know how I get on.

Best regards

John

[johnhd]

Hi @florentw

I think I've been beaten by the extraordinarily long path names created by Vivado when creating the example IP design for displayport.

The path I'm creating the example project in is f:/x/ - so could only loose a couple of characters of this if I created the project in the root folder.

The rest of the path length seems to be under control of Vivado and I can't see anyway of making it shorter.

The error message I get is....

[Common 17-680] Path length exceeds 260-Byte maximum allowed by Windows: f:/X/dp_tx_subsystem_0_ex/dp_tx_subsystem_0_ex.srcs/sources_1/bd/dp_tx_subsystem_0_design_synth/ip/dp_tx_subsystem_0_design_synth_axis_clock_converter_0_0/dp_tx_subsystem_0_design_synth_axis_clock_converter_0_0/dp_tx_subsystem_0_design_synth_axis_clock_converter_0_0.xdc
Please consider using the OS subst command to shorten the path length by mapping part of the path to a virtual drive letter. See Answer Record AR52787 for more information.
Resolution: In Windows 7 or later, the mklink command can also be used to create a symbolic link and shorten the path.

So the total path length is 271 characters (including .xdc) - I need to save 11 characters - I can't do that with any of the suggestions given - As I believe 266 characters are in the control of Vivado without any means for the user to modify them.

Hopefully I'm wrong and there's a way forward. Any thoughts on solving this gratefully received.

Best regards

John

[johnhd]

Hi @florentw

I've found a way forward on the long path names.

From the example project I used "save project as", within the block design I used "Save Block Design As" - I probably only needed to to 1 of these - in each case I used a shorter name than that generated automatically by Vivado.

The design is now compiling.

Regards John

[florentw]

Hi @johnhd,

Unfortunately this is a tool issue which creates long path. I am trying to have this fixed.

This is good the you found a solution.

Regards

[florentw]

Hi @johnhd,

Do you have any updates on this. Did the example design on ZCU102 help you to use the north clock?

Thanks and Regards,

[johnhd]

Hi @florentw

I have made some progress - I am using the design example for KCU105.

I have made 2 versions, one for the FMC position that uses the standard clock and one for the FMC position that uses the south clock.

Good news is that the south clock version performs the same as the other - neither report any errors when initialising the transmitter - The options within the transmitter only menu all seem to work OK.

However (Bad News) both versions do not work correctly in the Rx-Tx menu : They both display a frozen/corrupt image on the screen, when trying to investigate through the menus the software locks up and I haven't been able to debug via the software.

I have established via LEDs that the Phy has Rx, Tx and DRP clks. I was starting to debug further with some ILA's - I'll let you know any updates.

If you have any thoughts on what might be going wrong or how to debug further then please advise.

Also to note that XAPP1271 version was working correctly for both Tx only and Rx-Tx versions for the standard clock version on my development system.

Best regards

John.

[florentw]

Hi @johnhd,

I wouldn't expect many differences between the xapp1271 and the exdes from vivado. The exdes should have some improvement in the software.

As TX is working properly, could you make sure you are using the latest driver for you source?

Regards,

[johnhd]

Hi @florentw

To update you on the current status with the latest design example. I have generated the example design twice based on the KCU105 design but targeted at an Inrevium Quattro dev board (xkcu115-flva1517-2-e). I have made 2 versions, one for the FMC position that uses the standard clock and one for an FMC position that uses the south clock.

Neither report any errors when initialising the transmitter - The options within the transmitter only menu all seem to work OK.

In the Rx-Tx menu :

Initial compile : Both design examples display a frozen/corrupt image on the screen, when trying to investigate through the menus the software locks up and we haven't been able to debug via the SDK (encounter corrupt values etc). Note: Looking again at the timing results there are in fact no timing errors.

Later compile with a few changes including the addition of some debug ILA's - Both design examples are now fixed the software doesn't crash, we can debug the S/W via the SDK and RX->Tx is displaying live video (On the version using the South clock there is actually some issue with the video to be investigated - vertical lines on screen - but the video is live and generally OK). 

I'm now going to recompile one of the original faulty designs with just adding some ILA's to see if this fixes it (to confirm if it was that or one of the other changes that fixed it).

Rgds John

[johnhd]

Hi @florentw

A few more updates from our investigations today.

When I added debug ILA's onto the non-working version it did seem to fix the problem - The Rx->Tx worked and the SW didn't crash.

On the version using the South clock there was actually some issue with the video - vertical lines on screen - but the video is live and generally OK - So we used the ILA's we had already added to investigate this further - The ILAs are on the video stream data in 4 places...

- Out of the Rx block into the vdma

- Out of the vdma into the clock converter

- Out of the clock converter into the pat_gen

- Out of the pat_gen into the Tx block

We found the video was clean out of the Rx but had picked up corrupt pixels (presumably vertical lines) on leaving the vdma.

So adding ILAs in these places seems to help or "fix" the problems we are facing, but could it be that there is an issue with the vdma/ddr4 interfacing that is causing corruption  of the video and causing the microblaze to crash? Could it be the ILAs are altering timing in this area enough to affect the performance?

As always we'd be grateful for any thoughts you may have.

Best regards

John

[florentw]

Hi @johnhd,

On the test case you send me, I get critical warnings related to the constraint of the DDR. Do you have the same critical warnings with the ILAs?

Do you still have both design? Could you share the log file for both projects?

Thanks and Regards,

[johnhd]

HI @florentw

Attached what I believe to be the log files related to these projects.

The critical warnings related to the constraints of the ddr are as the Quattro board has 2 lots of memory (twice as much as needed for this project) I am declaring the pins for both in the constraints file, but only have one used in the design. I should have removed 1 lot of memory from the constraints hence the warning, I assumed this was not relevant.

Not sure what you mean "Do you have the same critical warnings with the ILAs"

Regards

John

[florentw]

Hi @johnhd,

Thank you for the reports. However they did not give me any more information...

When I was asking for the log, I was thinking about the synthesis (runme.log in synth folder) and implementation log (or full vivado.log). Could you attached them?

Did you do any progress on your side?

By "Do you have the same critical warnings with the ILAs" I was asking if you add the same critical warning in the project with the ILA. But I do not see why you would not have them so forget this point.

Just a question: when do you add the ILAs? Is it in the BD or in the synthesized design?

Regards,