Frame Buffer (sopc) Issues

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

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

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

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?

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

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

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

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.

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