HDMI In to VGA out on Zybo

[cgarry]

I'm trying create a PL subsystem that takes a HDMI video in and outputs it on the VGA. I got the digilent IP from this github https://github.com/Digilent/ZYBO.git and I created a HDMI in to VGA out loop in Vivado as shown below

 

I have set the clock wizard up to provide 200MHz to the dvi2rgb block and the clock wizard block has an input clock 125MHz. I programmed the dvi2rgb block with the following config

 

 

After trying to generate the bitstream for this I'm getting critical errors at the implementation stage saying it can't meet timing. It managed to generate the bitstream but its output an video from the VGA. Any ideas what is causing these timing errors? or where I am going wrong with the implementation?

 

 

 

ZYBO_Master.xdc.txt

[JColvin]

HI @cgarry,

Which version of Vivado are you using? Based on the tutorial for the Zybo HDMI demo on our Wiki (link), the project is only compatible with Vivado 2016.4 and Xilinx SDK 2016.4, though it does use a processor and not all PL. I imagine you might have seen this already, but we have some documentation on the rgb2vga and dvi2rgb IP cores here and here, respectively.

Thanks,
JColvin

[cgarry]

The system shown above was generated with Vivado 2017.2. I have seem the tutorial you provided as well and this was generated with Vivado 2016.4 and I see the same timing issue when generating the bit stream for this. I reviewed the documents you pointed to but they don't say anything about timing issues. They also don't give a clear indication what the parameters of the two IP should be in order to get a certain video format in or out.

 

Is there any simple example available for the zybo where it is just dvi2rgb connected to rgb2vga?

[jpeyron]

Hi @cgarry,

We currently do not have a basic project with these ip cores that does not have a processor involved. I have reached out to more experience engineers about your thread to see if they have any other input. Could you please attach your time errors?

thank you,

Jon

[cgarry]

Hi Jon,

 

I managed to fix the timing errors by disable "add BUFG to PixelClk" and I can now input video on the HDMI and output it on the VGA. What is this feature used for? It would also be usual if the document for these IP contained a recommended setting for typical use cases, I wasn't ever 100% clear on what should be set in the parameter IP settings.  

 

One side affect of using the DVI and VGA IP is that my zynq processing system no longer seems to work correctly. I used to be able to boot Linux on it and since adding these IPs to the PL it fails to boot, any ideas what might be causing this? The project I'm working on requires Linux running along with some form of video processing in the PL.

 

Thanks,

Cathal

[BogdanVanca]

Hello @cgarry,

If you check the ip documentation, you will found out this paragraph :

"The parallel pixel clock (PixelClk) is recovered by the use of a BUFR buffer. Since BUFR is restricted to a single clock region and the video data output from the core is synchronous to PixelClk, any downstream logic consuming video data is also restricted to this clock region. The option to re-buffer PixelClk introduces a BUFG after the BUFR and re-registers video data into the BUFG-domain. This will allow downstream logic to be placed anywhere on the device."

With other words this feature is more related with logic consuming, and normally should not introduce any kind of timing errors. For a better analyze, can you please attach a screen shot, or a document with the errors that you receive?

thank you,

Bogdan

[cgarry]

Sorry for the delay, here is a screen shot of the critical warning I get

 

 

and here is the summary of the timing report

 

Do you know if there a way to dump out the timing report to a log file in Vivado?

[elodg]

@cgarry,

I recommend ug949 chapter 5 for instructions on how to achieve timing closure.

You have to click on each failing category in the timing summary and see the failing paths on the right. For example, if you check the Pulse Width constraint, it is due to driving the BUFR primitive with a frequency too high for an Artix-7 FPGA. You may ignore this warning, or specify a larger period constraint for the HDMI input clock (hdmi_clk_p) and using a lower resolution.

The rest of the timing categories have to be analyzed path-by-path. Solve Inter-Clock first, which are most of the time due to incorrect clock-domain crossings. Intra-Clock should be solved by reducing congestion, trying different implementation strategies or lowering clock frequencies.