--- Quote Start ---
input rate = 148.5MHz * 3 bytes * 6 ports = 2.673 GBytes/sec
--- Quote End ---
Due to the horizontal blanking interval, you don't actually need to maintain a rate of 148.5MHz. The average rate for a line is actually 148.5*1920/2200. The average rate for the entire frame is even less due to vertical blanking, but you can't really take advantage of that as the FIFOs are not big enough to average out the demand over an entire frame.
As Vgs was mentioning, there is also some inefficiency in the way pixels get packed into a word. Therefore, simply multiplying the pixel rate by 3 bytes is not accurate.
I think a more accurate calculation would be:
bandwidth = 148.5M * 1920 / 2200 * 16 / 5 * 6 = 2.48 Gbytes/second.
The 16 / 5 factor is assuming 128 bit words. You can fit 5 pixels into each 128 bit (16 byte) word.
So it seems you should have enough bandwidth. Perhaps you need to adjust FIFO sizes and thresholds on the CVI, CVO and framebuffer blocks.
Some other random thoughts:
Do you even need to convert between clocked and avalon streaming video multiple times? Could your custom video IP be adapted to process the avalon stream directly? It would simplify your system a lot if you only had one CVI and one CVO to worry about. Do you even need all the frame buffers? Just based on your block diagram, I see no purpose for the first frame buffer. Unless the custom video IP needs to see the video from different delayed time points, I don't really see what the other frame buffers are for either.
As your video IP is running at 166MHz and your memory at 300MHz, are you doing anything to address potential clock domain crossing issues? The default clock domain crossing logic in SOPC builder can be quite inefficient. You may need to explicitly add a pipeline bridge.
Honored Contributor
