Frame Buffer (sopc) Issues

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

--- 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.

--- 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

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

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