Frame Buffer (sopc) Issues

[Altera_Forum]

Hi, 

 I am getting some issue for connecting an 1280X720P@50Hz camera to an cyclone III development board(starter kit). I am getting the torn video at the output. I have attached the images of the design(SOPC).  Thanks, Bhupesh

[Altera_Forum]

1 - Your DDR controller has a local interface width of 32 bits yet you've set your frame buffer to have a width of 256. Make your frame buffer 32 bits to match the DDR controller. 

 2 - You're running the DDR controller at a local interface width of 32 bits and a frequency of 133MHz. Just be aware that under this configuration you're consuming 69.3% of the available memory bandwidth. This is fine but your memory accesses have to be efficient for it to work.  Jake

[Altera_Forum]

Thanks jakobjones, 

 I tried with 32-bit frame buffer but no change in the output.  what r the other ways to increase the DDR controller efficiency?  i read some where in the post that if we increase the frame buffer width to 256 we could get better efficiency from frame buffer. as my input is RGB 24-bit 1280X720

[Altera_Forum]

Are you sure your video input is 50Hz. If it increases to 60Hz, the memory bandwidth usage increases to 83% which is cutting it close. Are you meeting timing requirements on everything? 

 Jake

[Altera_Forum]

yes i am sure it is 50Hz i have checked VSync of input video on scope. 

 how u have calculated that i am using 69% of the memory bandwidth?

[Altera_Forum]

I've got a nice little spreadsheet that I worked up some time ago specifically for calculating memory bandwidth of the video IP. Basically it's a function of: 

 - Memory width - Memory frequency - Video Input resolution - Video Input bits per pixel - Video Input frame rate  Basically for your case: Memory bandwidth = "Local Interface Frequency x Local Interface Width" So 133000000 x 32 = 4.256 Gbps  Now for the video rate calculation, you have to take into account the wasted memory bits per transfer. In your case this is easy. You've got a 32-bit memory bus and a 24-bit pixel. You'll waste 8 bits on each memory transfer. Now your input data rate to your frame buffer is: "Input frame width x Input frame Height X Frame per second x (bits per pixel + wasted bits per pixel)" so: 1280x720x50x32 = 1.47456Gbps  Now that data rate calculation applies both to the input and output of the frame buffer.  So (1.47456Gbps x 2) / 4.256Gbps = 0.69293 or 69.2%.  Now if your output frame rate is different from your input frame rate, you have to take that into account. So for example if your were converting 1280x720p50 to 1280x720p60 it would be : (1.47456 Gbps + 1.769472 Gbps) / 4.256 Gbps = 0.7622 or 76.22%  Jake

[Altera_Forum]

there is one interesting observation i came across 

 I have one HD camera which gives out 720X576P@50Hz (27MHz video clock), it gives out active high Vsync,Hsync & data enable. when i generate the system to display out in DVI it works fine. I was surprised because active high Vsync,Hsync should not have display any thing.  when i connect HD camera 1280X720P@50Hz (74.25MHz), it gives out active low Vsync,Hsnc and active high Data enable, and i get torn display.  tomorrow i will try to generate testpattern of 1280X720@50Hz (74.25Mhz) and connect it with the design......

[Altera_Forum]

i get some timing errors when i design system for 1280X720 resolution, may be this causing the problem........i shall see into the timing errors

[Altera_Forum]

Double check your video output timings. The numbers in your screen shot appear to be for 1280x720p60, not 1280x720p50. 

 For 1280x720p50, I believe the values should be:  H sync: 40 H front: 440 H back: 220 V sync: 5 V front: 5 V back: 20

[Altera_Forum]

Jake, 

 On the topic of frame buffer bandwidths, I have been trying to do some similar calculations myself recently.  Your method of calculating the bandwidth would be for the average bandwidth. However, peak bandwidths would be a bit higher. Now unless your FIFOs are ridiculously huge, won't the peak memory bus speed required also be higher? It seems to me that a more realistic figure to use would be the average bandwidth for one line of video. For example for 1280x720p50 the required bandwidth would be:  1280/1980*74.25*32 = 1.536 Gbps  Of course, this number is only 4% more than your figure, so maybe I am just being picky. On the other hand, if you are short on block RAM and you are trying to skimp on FIFO sizes, I suspect the required bandwidth would start to approach 74.25*32 = 2.376 Gbps. Multiply that by two for input and output to the frame buffer, and 133MHz x 32 wouldn't cut it at all anymore.  I have only started experimenting with VIP recently myself, so I may be way off in my thinking. I have successfully used the scaler and a few of the other components, but have not even tried a frame buffer yet. Unfortunately, my current board I am testing with doesn't have any external RAM, so it may be a while before I can try a frame buffer.

[Altera_Forum]

Kevin, 

You are correct. My calculations assume there is a line buffer before and after the frame buffer. This is typical of most designs but certainly not all.  Jake

[Altera_Forum]

Is there any way to add test pattern generator in quartus ii 8.0 version? 

 Is there any way to get source code for test pattern generator

[Altera_Forum]

--- Quote Start ---  Kevin,  You are correct. My calculations assume there is a line buffer before and after the frame buffer. This is typical of most designs but certainly not all.  --- Quote End ---   Maybe I am still just being picky, but my point was that with only a line buffer, you would need to have peak bandwidth available for the average bandwidth for one line. Your calculations were calculating the average bandwidth across entire frames. The difference isn't that big, but there is a difference. With only a line buffer, you can really only take full advantage of the horizontal blanking time, not the vertical blanking time.   bhupesh,  Have you tried running your system without the frame buffer? For example, you could try using just the clocked video input and clocked video output to make sure you have these set up correctly. As I pointed out yesterday, I think the timings in your screen shot for the output are wrong for 1280x720p50.  Once you have that working, you could try reducing your total sample size to 16 bits instead of 24 bits. This would reduce the required bandwidth for the frame buffer significantly. If the tearing goes away, this would point towards a memory bandwidth issue.  You could also try increasing the FIFO sizes for the video input and output. Version 9.0 of VIP also adds an additional option for the video output where you can set "Fifo level at which to start output" which may be an interesting setting to tweak.

[Altera_Forum]

--- Quote Start ---  Maybe I am still just being picky, but my point was that with only a line buffer, you would need to have peak bandwidth available for the average bandwidth for one line. Your calculations were calculating the average bandwidth across entire frames. The difference isn't that big, but there is a difference. With only a line buffer, you can really only take full advantage of the horizontal blanking time, not the vertical blanking time.   --- Quote End ---    Again, you are correct.   A worst case bandwidth calculation (assuming minimal buffering) in this case is easy. The parallel pixel clock rate is 74.25MHz x 32-bits per transfer (including wasted bits) = 2.376Gbps x 2 for read and write = 4.752Gbps. which would exceed the bandwidth of the memory.  Assuming line buffering (taking up slack during horizontal blanking) gives the number you calculated (1.536Gbps) x 2 for read and write gives you 3.072Gbps or 72% of total memory bandwidth.   In reality, the calculation is slightly more complex. During the horizontal blanking interval (and while pixels are coming in) the line buffers are being emptied. You would have to calculate exactly what rate would cause input pixels to start being dropped. In other words, you don't have to completely drain the line buffers before the next line of input begins. So the exact needed bandwidth would be that which drops no pixels but completely fills the line buffer when the last pixel of the frame comes in. I have performed this calculation for 1080p60 video but not for 1280p. It's the same calculation used to determine what the minimum clock frequency to run the video IP clock at.  Needless to say, the answer lies somewhere between 69% and 72% so it's not worth performing the calculation.  Jake

[Altera_Forum]

Hi,  

 I tried generating an test pattern of 1280X720@50Hz (testpattern ---> clocked video output) and connected to my frame buffer design.   I see an diagonally horizontal color bar pattern. Its look like vertical patterns are streched diagonally horizontal( more than one color bar patterns, 3 -4 color bar patterns).  i will try to convert this color bar into YUV422 and see the result

[Altera_Forum]

Hi, 

 Some intresting observation, test pattern (1280X720p@50Hz) running with external clock(camera clock 74.25MHz) works fine so from this test i concluded that there is no bandwidth issue with this resolution.   I looked at the camera DVI output data enable signal, there i found that the the TI DVI receiver was generating data enable for more than 1280 pixel value, which i fixed it by writing a samll code in FPGA and woooow the result was clear picture...:)   know i am trying to connect 1920X1080i to see wether cyclone III starter board has bandwidth to support this resolution