Problems with dvi2rgb at low resolutions

[mikeanthonywild]

I've got a HDMI link set up between two Zybos using Digilent's DVI cores (rgb2dvi and dvi2rgb). Having tested everything successfully using a 1080p pipeline, however upon switching to VGA resolutions (640x480) the sink part cannot successfully decode the stream. It never occurred to me that low resolutions would pose an issue - but I've been banging my head on a wall with this one!

As per the documentation, I've adjusted some constraints and multiplier / divider combinations for the MMCM in the dvi2rgb core and the clock recovery block is successfully recovering my 25.175 MHz pixel clock (although interestingly it is somehow still able to recover it when the MMCM is configured for 1080p - something I wasn't expecting as the VCO is operating way out of spec at 125 MHz). I'm not getting any activity on the pVDE or CTRL signals, so I think there's something up with the phase alignment or channel bonding.

Receiver block diagram is attached, but it's pretty standard.

Any clues?

 

EDIT:

I've just noticed that the documentation lists the lower limit for the pixel clock as 40 MHz. Initially I thought this was due to the VCO range, but I also just noticed that the 32-tap delay spans 2.5ns, which happens to be the period of a single bit at 40 Hz. Is my limitation down to the deskew implementation?

[AndrewHolzer]

Hi mikeanthonywild,

I've got a Zybo here on my desk configured with the hdmi_in demo project for the Zybo found on our site.  I've configured my computer to output 640x480 resolution video, which the Zybo was successful in capturing. I am a bit lost with this result, but I will do my best to help you. How are you feeding video to your Zybo system? If you are taking output from your computer, the issue might lie with your computer graphics and how it scales its output (I'm a bit fuzzy on this bit, but this was how it was described to me). Do you have any SDK code that you are using? If you are using code similar to that provided in the demo I mentioned, there is a vga_modes.h. It was suggested that you try messing with the values for the 640x480 setting, specifically the .freq variable. 

Let me know what kind of results you have, and we can  keep working through it,
Andrew

[elodg]

This is an old thread, but maybe it will help someone having the same issue.

The minimum limit of 40MHz for pixel clock comes from the phase alignment implementation on 7-series FPGA, as @mikeanthonywild noticed it. There are 32 steps available for delaying each data channel independently. Each step adds an additional delay of 78ps. The maximum amount of delay possible is roughly 2.5ns. For low pixel clock frequencies this does not span the whole bit period, so phase alignment might not be possible. That being said, back in Jan 2016 I changed the phase alignment algorithm to lock once a wide enough valid data eye is found, even if the whole bit period cannot be searched for the data eye boundaries. I believe pixel clock frequencies lower than 40MHz should work with the current core version. Anyone still having issues, please file a bug report.