Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
16 years ago

FIFO Depth

Hi All,

I have a design issue. I want to knwo the efficient fifo depth.

My write speed is 50 Mhz@16 bits, and read speed is 1bit@500 Mhz.

Current;y i am validating in Altera FPGA and later i will move to ASIC.

I want to know the efficient fifo depth for this scenario.

Plz help.

regards,

freak

8 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    50MHz * 16 bit gives a write bandwidth of 800MBit/s

    500MHz * 1 bit gives a read bandwidth of 500Mbit/s

    So it looks like your write bandwidth is greater than your read bandwidth? No FIFO can help here :)

    I assume your input rate is not constant i.e. 16 bits of data are not written on every 500MHz clock.

    This is the key to sizing FIFOs. What is the profile of your input data? i.e. how bursty is it?

    (Short bursts of data can be absorbed by small FIFOs. longer bursts by larger FIFOs)

    If you could define your input and output data in a bit more detail then forum uses may be able to offer sizing advice

    Hope this helps
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Presumably you're writing a burst of data @ 50MHz then pausing for a while. If so the depth of your fifo will be related to the length of the burst.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Hi vernmid,

    Thanks for your reply. The spec also says that the average writing speed is 500 mbit/s..

    Please help me to find the FIFO depth.

    Suppose the average rate is not given. How actually you concluded a FIFO cannot help. This is where FIFO comes to picture. right ?

    Please share your thoughts,

    regards,

    freak
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    In all cases of using storage to cushion the data flow, the average data rate on either side of storage must tend to equality over time. Otherwise your fifos will either overflow or underflow soon. This is common space physics.

    The idea is just cushioning the flow i.e. absorp the burstiness into the fifo level just like a water tank that receives irregular supply of water from the government but can provide the household anytime...never empty or overflowing on their heads.

    The depth of buffering is implementation dependant and there are no rules of thumb either. You will need to have an input model or the actual input and then watch for fifo state. Moreover you will need to consider cases when you process entire packets or blocks of data that these are not broken inside fifos which therefore must accomodate them as they arrive. You may also have info from your fellows who deal with same degree of burstiness.

    One other issue about data flow here is that at start up or other stressful moments your fifos may get stuffed and close to fill-level - accidentally -and then you are likely to stay there having limited cushioning. You will need to clear them in these cases to make full use of them.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    You effectively didn't specify your application. Thus it's impossible to give specific suggestions.

    Missing points are e.g.: available methods of dataflow control for both interfaces, transfer sizes in block transfer, which side is initiating the transfer. It may be the case, that you aren't yet aware of these questions to exist. But we can't give the answer.

    As another point, the 500 MBit/s interface apparently involves a serializer.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Hi vernmid,

    With full respect I don't quite see how this math is going to be practically useful. It depends entirely on (B) defined as number of bits per burst(worst case). It ignores the spacing between bursts. It may suit a well spaced case.

    But for a truely bursty input, I see no substitute for in-system sizing. I don't know of any reliable method to quantify burstiness
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Hi Kaz,

    Agreed. I referenced the document purely for info (and to be honest I didn't read it in that much detail!)

    the doc does mention

    --- Quote Start ---

    In order to know the data rate of write operation, we need to know Number of data in a Burst which we have assumed to be B.

    --- Quote End ---

    So you're right, what is the magic number B?

    In System sizing is definitely the way to go. Make an over estimate and monitor the fill level in a real situation.

    Apologies if I have caused confusion