rgb2dvi IP Customization

[dgottesm]

This question came up on a previous thread and I wanted to ask it separately

According to the Digilent rgb2dvi IP specs, "Resolutions supported: 1920x1080/60Hz down to 800x600/60Hz (148.5 MHz – 40 MHz)"

My video is 720x576, with a 27 Mhz pixel clock, which is not supported as is In the previous thread, 

@hamster said that it is possible to customize the IP by changing the divide-by values in the clkgen. Can someone help me with this? Has anyone ever had a similar problem? Also, how will I deal with the lower pixel resolution?

[hamster]

Hi again - sorry, busy weekend!

I had a look at the IP in Digilent's GitHub (https://github.com/Digilent/vivado-library). It looks like it can be configured to support slow pixel clocks:

From CLKGEN.VHD:

      kClkRange : natural := 1;  -- MULT_F = kClkRange*5 (choose >=120MHz=1, >=60MHz=2, >=40MHz=3, >=30MHz=4, >=25MHz=5

SO to support a 27MHz Pixel clock you will need to set kCLkRange to  However....

I also had a look at the standards for the video format you mentioned. It seems to have a "data" clock of 27MHz, but each Pixel has "Y" and "C" values, so the actual Pixel clock is 13MHz.

It is also an interlaced format (with odd and even fields to each frame). This format is structurally incompatible, so simple direct translation is not possible. It will really need a complex project to receive this video into memory, de-interlace it, then send it out as progressive video.

The timing of "standard definition" broadcast formats (PAL, NTSC...) are not compatible with DVI or HDMI...

 

 

 

[dgottesm]

@hamster

I know that that is how it seems. However, my video source is actually coming through its own de-interlacer through pixel interpolation (link at the bottom). Meaning, when lines 1 and 3 are received, line 2 is created with some algorithm. I don't understand exactly how it does it, but what it does is double the pixel clock from 27 MHz to 54 MHz. This is to keep the original frame rate. As you mentioned, only half of the values are Y, so I actually have Y at 27 Mhz, in a progressive format. I am writing a decoder for the de-interlaced video, but I also need to make it work for the rgb2dvi IP. I am taking your idea and insertin Y into the RGB values to get a black and white image. (I know the project seems like overkill, but just bear with me here)

http://www.analog.com/media/en/technical-documentation/user-guides/EVAL-ADV7282AEBZ-UG-1174.pdf

Also, some questions I had for Analog devices about the I2P output

https://ez.analog.com/message/339021-re-general-question-about-itu-r-bt656

Either way, are you saying that all I need to do to have it accept a slower clock is to change that value to 5? 

How do I get the 720x576 resolution? (Sorry, I was mistaken before about the 640x480. Turns out I am working with a PAL video source)

Thanks for working with me!

[hamster]

On some random web post I found this:

  Timing recommendation #3.... 720x576 at 50Hz
      Modeline................ "720x576" 27,000 720 732 796 864 576 581 586 625 -hsync -vsync
...
  Timing recommendation #5.... 720x576 at 50Hz
      Modeline................ "720x576" 27,000 720 732 796 864 576 581 586 625 -hsync -vsync

Because it is larger than 640x480 it should work with standard HDMI.

How to interpret the numbers

27,000 is the pixel clock

Horizontal

720 active pixels

732 start horizontal blanking

796 end horizontal blanking

864 total length of line.

Vertical:

576 active lines

581 Start vertical blanking

586 stop vertical blanking

625 total lines.

How to generate a hsync signals out of nothing

The easiest way is to ....

- Convert the input into three signals Y, C and a one-bit Active_Pixel (aka 'data enable')

- Add a horizontal pixel counter that counts 0 to 863 when when you see the first active pixel - i.e. reset it when you see the first active pixel, otherwise leave it free-running. 

- You can then generate hsync when the horizontal counter is between 732 and 795

How to generate the vsync signals

- detect when you have more than 144 cycles without active data (144 = 564 clocks per line - 520 active pixels per line). This lets you know when you are in the vertical blanking interval (as the horizontal blanking is 144 cycles)

- then reset the line counter when you see the next active pixel, as this will be the first visible line.

- increment the line counter, whenever the horizontal counter wraps from 863 back to 0/

- Generate the vsync pulse when the line counter is between 581 and 585.