Avalon-MM master interface on Frame Buffer

Hello,

Write and read bursts to and from the memory cannot be interrupted and there is no guarantee that the data can be streamed as fast as it go or come back from the memory. Consequently, the write master is using a FIFO to buffer a sufficient amount of data before it issues a write burst and the read master is using a FIFO to store the data received during a read burst. The fifo depth parameters control the sizes of these two FIFOs. The burst target parameters define the typical size of a burst. The default values are appropriate for most video systems.

If you are using SOPC Builder, the tool will build the switch fabric for you and there is no need to use 16 for the memory port width. Using a larger number (eg, 128 or 256 bits) will probably improve things. You should also try to run the memory at a faster speed than the rest of the design to squeeze more bandwidth (tick the "use different clocks" checkbox in the two frame buffers) .

vgs

If you are not using DDR and your local memory interface width is truly 16 bits, then yes, set the memory width on the frame buffer to 16 bits.

With regards to the FIFO's, typically this is a performance issue. However, it makes no sense to make the FIFO depth smaller than the size of a RAM block. So if you are using a device with M4K blocks, make it 256 deep (resulting in a 256x16 memory). If you are using a device with M9K blocks, make it 512 deep (resulting in a 512x16 memory). I would recommend a burst of at least 32 but this is purely an efficiency issue. You wan't to make your bursts long enough to efficiently use the memory but you don't want to starve other components that need the memory.

Jake

Hi,

jakobjones is right when suggesting that you should typically use the same memory width as your local memory interface width but there could be cases where this is not the best thing to do because the frame buffer is not always efficient when packing pixels into words.

For instance, 16-bit words would be perfect for 8-bit RGB in sequence but the GUI should prevent you from using 16-bit words with 8-bit RGB in parallel. For 10-bit YCbCr in sequence, each 16-bit word would pack a single 10-bit sample and the rest would be lost. Using larger words can compensate for this behaviour.

vgs

Thanks for the great explanations and suggestions...

Originally I had my memory and SOPC components running on the same 133 MHz clock. I created a second clock to run the SOPC components at 100 MHz and kept the memory attached to the 133 MHz clock.

I tried to change the memory port width to 16 as suggested but the SOPC builder would not save the values. I did not get any errors or warnings, it just displayed the original values the next time I opened SOPC builder. VGS's post cleared up that mystery, I am running 8 bit RGB in parallel. I set the Port width to 32 and the fifo depths to 256 and left the burst targets at 32. Settings are saved but my video is torn across the display. When I set the port width to 256 and leave the fifo depths and targets at their defaults I get good video.

Since I appear to be approaching a memory bandwidth issue does it make sense to place my frame buffer directly after my CVI (8 bit 2 color plane in seq) and do the color space conversion downstream from the frame buffer?

I've never gotten a warm fuzzy about when a frame buffer is necessary. It is obvious to me that there would need to be one between my CVI and CVO due to the rate conversion but is it necessary between certain VIP components? On that note, I've also questioned the clock rate for the VIP components. I've read that it needs to be at least the rate of the input pixel clock but what if the stream is resequenced from sequential to parallel or vice-versa?

Sorry for the newbie questions... and thanks for all the help

Hi,

With 8-bit RGB in parallel and a port width of 32, the frame buffer will store one pixel (24 bits) per word and 25% and the bandwidth is wasted. If you increase the port width to 256 it goes to 10 pixels per word and "only" 6.25% of the bandwidth is wasted. This is probably enough to explain what you are seeing.

In many cases the position of the frame buffer does not really matter but there are exceptions which usually involve the clipper, the scaler, the color plane sequencer or the mixer. In your case, it probably does make sense to place the frame buffer directly after the CVI (8 bit 2 color plane in seq using 16-bit words) but we would need to see the full datapath to be sure of that.

vgs

Hi,

I am also facing the same problem what hyattbd was facing.

I am using an HD camera to connect it to Cyclone III starter board through an HSMC connector.

1280X720@50Hz (input clock rate 74.25MHz), the design path is

CVI ---- FRAME BUFFER -----CVO.

CVI input frequency is 74.25Mhz and CVO output frequency is 74.25MHz.

Rest of the design including DDR are running at 133MHz.

I set the Port width of frame buffer to 32 and the fifo depths to 256 and left the burst targets at 32. Settings are saved but my video is torn across the display. When I set the port width to 256 and leave the fifo depths and targets at their defaults then also i get torn video.

i made the above changes as "hyattbd" design worked when he made those changes.

It looks to me like some arbiration problem and seems data in the DDR is getting overwritten.

i would appriciate if any one can help me on this.