cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Adventurer
Adventurer
3,468 Views
Registered: ‎01-08-2018

Video Phy Controller: DRP won't return DRP ready

Jump to solution

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

 

0 Kudos
33 Replies
Highlighted
Adventurer
Adventurer
1,101 Views
Registered: ‎01-08-2018

Hi @florentw

 

Please find attached updated log files. I wasn't sure about "implementation log (or full vivado.log)" as I can't find this one so have included the runme.log from the impl folder. I have also added some screen shots of the video we get on the FMC using the south clock - it is a 1920x1080p60 format - screen shots of black, red, green, blue and white flat fields - the line patterns seem to repeat every 128 pixels.

 

When we added the ILAs this was by marking signals for "debug" in the bd and then specifying the specific signals in the synthesized design. I am concluding at the moment that adding ILAs seem to improve the problem but it has not totally cured it - still get corrupt video (as per screen shot) on the south clock FMC project and unreliable software on both FMC's projects - so could it be the ILA's are a bit of a red herring? I have reviewed the timing margins with and without the ILAs and as best as I can tell they are similar, also to note the only timing warnings are with the ILA's added there is an interclock timing failure related to the ILA's.

 

I have also gone back to Inrevium's Quattro DDR4 demo project to see if I can see any relevant differences.

  • The DDR4 demo worked reliably and reported DDR4 was OK.
  • Reviewing the DDR4 I/O port parameters implemented for DDR4 demo and DP projects there were no differences. 
  • Reviewing the cal margins reported by the MIG for both projects they were not significantly different. Worst case complex margins for DDR4 project were 125ps read/131ps write, for the DP project 124ps read/129ps write. - Do these seem reasonable? In both cases DDR4 CAL has always passed without any problems.
  • The DDR4 project used a set_system_jitter of 0.005, the DP project didn't specify this. I experimented with adding a figure of 0.005 and 0.1 in the DP project it didn't fix the issues.

Currently we are out of ideas on how to fix this issue or where to investigate next - so would welcome your thoughts.

 

Best regards

John

 

0 Kudos
Highlighted
Moderator
Moderator
1,083 Views
Registered: ‎11-09-2015

HI @johnhd,

 

In SDK, could you check were the memory of the (MicroBlaze) MB is implemented in the linker script. You should try to have the instruction and data mapped to the internal BRAM.

 

Might be that both the VDMA and the MB are reading in the same memory space of the DDR.

 

Regards,


Florent
Product Application Engineer - Xilinx Technical Support EMEA
**~ Don't forget to reply, give kudos, and accept as solution.~**
0 Kudos
Highlighted
Adventurer
Adventurer
1,067 Views
Registered: ‎01-08-2018

Hi @florentw

 

The Microblaze code is too big to fit in the BRAM it is using DDR from its base address 0x80000000.

Video from the VDMA is being loaded into DDR from 0x81000000.

 

We can run the same software in the SDK on a working and non-working FW load so have concluded the address allocations are OK. However it could be that if the DDR and interface (either within or external to the FPGA) was faulty this would cause problems for both the SW running in the SDK and the video.

 

Rgds

John

0 Kudos
Highlighted
Adventurer
Adventurer
3,994 Views
Registered: ‎01-08-2018

Hi @florentw

 

The Quattro dev board has 2 DDR4 banks each of 4 devices / 64 bits. Retargeting the DisplayPort example design at the other DDR4 bank seems to have resolved some or all of the issues.

 

Status then is as follows when operating the DP example design in Rx (via DDR4) to Tx mode…

 

DDR4 Bank #

Changes to example design project

FMC1
(uses GTREFCLK)

FMC3
(uses GTSOUTHREFCLK)

0

No

S/W crashes

Video corrupt and frozen

S/W crashes

Video corrupt and frozen

0

ILAs added for debug

OK

Some S/W crashes

Video has vertical lines

1

No

OK

OK

 

Other notes…

  • In all cases the DP example design works in TX only mode (in this case video is not using DDR4).
  • The Quattro board (both DDR4 banks) passes the tests of Inrevium DDR4 Reference Design.
  • In all cases the example design passes the DDR4 cal process and similar timing margins are reported.
  • The DP example design implementation meets timing requirements with the exception of a few interclock paths relating to ILAs in the version with the ILAs.
  • The DP example design DDR constraints are based on those from the Inrevium DDR4 Reference Design.

 

View solution in original post

0 Kudos