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