Video Phy Controller: DRP won't return DRP ready

[johnhd]

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

[florentw]

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,

[johnhd]

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

[johnhd · Accepted solution]

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.