Day 81: Async FIFO depth: computing it on paper
Async FIFO depth: computing it on paper
A classic interview question: given a write rate, a read rate, and a burst length, what's the minimum FIFO depth so it never overflows? The method: over the burst, compute how many items arrive vs how many can leave, and size the FIFO for the worst-case backlog. The subtlety is accounting for the read side draining *during* the burst and for synchronizer latency.
Given: write 1 item every wr_clk; a burst of B items written back-to-back.
read side drains 1 item every M write-clock periods (slower reader).
Items written during the burst: B
Items read during the burst: floor(B / M)
Worst-case backlog (min depth): B - floor(B / M)
Example: B = 120 items, reader takes M = 4 write-clocks per read
read during burst = 120/4 = 30
min depth = 120 - 30 = 90 -> round up to a power of two (128) for gray pointers
Add a couple of slots for 2-FF synchronizer latency margin.Round up, and add margin
Gray-coded pointers want a power-of-two depth, so round the computed minimum up (90 → 128). Then add a slot or two for the synchronizer latency (the pointers you compare against are a couple of cycles stale). Being able to *derive* this on a whiteboard — not just recite a formula — is a named Stage-2 exit criterion.
Before moving on, you should be able to
A burst writes 100 items back-to-back; the reader removes 1 item per 5 write-clocks. Roughly what minimum FIFO depth avoids overflow (before rounding)?
