Allowed R6 · Within policy
{
"slug": "fifo-depth-calculation",
"title": "Asynchronous FIFO Depth",
"difficulty": "medium",
"tags": [
"coding",
"embedded",
"technical",
"role-embedded"
],
"is_free": true,
"locked": false,
"frequency": 0.75,
"last_reported_at": "2026-03-22T19:15:33.348430Z",
"url": "https://www.mokabla.com/en/c/analog-devices/fifo-depth-calculation",
"agent": {
"page": "https://www.mokabla.com/agent/en/c/analog-devices/fifo-depth-calculation",
"question": "https://www.mokabla.com/agent/_call/get_question?company=analog-devices&question=fifo-depth-calculation"
},
"company": {
"slug": "analog-devices",
"name_en": "Analog Devices"
},
"body_md": "## Problem\nA write side pushes data at `w_rate` MHz, a read side pops it at `r_rate` MHz, and the two sit in different clock domains. The writer sends a burst of `burst` back to back items, then idles. The reader needs `idle_cycles` of its own clock between pops because of downstream backpressure.\n\nWork out the minimum FIFO depth that guarantees no overflow, then write the function that computes it for arbitrary numbers.\n\n## Examples\n**Example 1**, `w_rate = 100`, `r_rate = 100`, `burst = 120`, `idle_cycles = 1`\nThe reader consumes one item every 2 read clocks, so in the time the writer pushes 120 items the reader has drained 60. Depth = `120 - 60 = 60`.\n\n**Example 2**, `w_rate = 200`, `r_rate = 100`, `burst = 100`, `idle_cycles = 0`\nBurst duration is `100 / 200 MHz = 500 ns`. In 500 ns the reader pops `0.5 us * 100 MHz = 50`. Depth = `100 - 50 = 50`.\n\n**Example 3**, `w_rate = 100`, `r_rate = 250`, `burst = 40`, `idle_cycles = 0`\nThe reader is faster than the writer, so one entry is enough for the rate mismatch. Depth = `1`.\n\n## Constraints\n- Rates are positive, not necessarily integers.\n- Round the depth up, never down.\n- Then tell me the depth you would actually implement and why it is not the number you just computed.\n\n## What they look for\nThe arithmetic is the easy half. The second half is the design conversation that always follows:\n\n- Why the pointers are **gray coded** before they cross, and why binary pointers break even with two flop synchronisers.\n- Why full and empty are generated on **different sides** of the FIFO, and why each side is conservative in its own direction.\n- Where the synchroniser latency goes into your depth number, so that full asserts late and you overflow a FIFO that your spreadsheet said was fine.\n- What you do when the depth comes out at 4096 and nobody will give you that much memory.",
"follow_ups_md": "- Write the gray to binary and binary to gray conversion.\n- How do you prove full and empty are never both asserted?\n- Now the write side can be reset independently of the read side. What breaks?\n- Same question for a single clock FIFO. What changes and what does not?",
"access": "Question bodies are paid content: a person buys 30 days of access per company (200 EGP or 200 points) in the human app. Agents get titles, tags and difficulty; bodies only for free questions."
}