Skip to content
DenseChip
Learn
PracticeCode labInterview

DenseChip

Navigate

Menu

LearnPracticeCode labInterview

Tools

All toolsSV editorCode repoResume
DenseChip

Practice, courses, and chip-design tools in one focused workspace.

LearnPracticeCode labInterviewToolsLearning paths

© 2026 DenseChip

AboutContactPrivacyTerms
Skip to lesson

Course contents

  • RTL Foundations36
  • Combinational Design25
  • Sequential Design27
  • FSM & Control27
  • Timing & Clocking39
  • Reset & CDC34
  • Memory & Buses57
    • SRAM and ROM
    • Register Files
    • Valid/Ready Handshake
    • AXI-Lite
    • AXI-Stream
    • Bus Integration
    • Synchronous FIFO
      • Contract and Invariants
      • Pointers, Occupancy and Flags
      • Portable Registered-Output FIFO
      • Simultaneous Push and Pop
      • Standard vs Fall-Through Output
      • Almost Flags and Parameter Edges
      • Verification and Signoff
    • Register-Map and CSR RTL
    • Memory Reliability
    • Peripheral RTL Integration
    • Full AXI4: RTL Roadmap
  • Advanced RTL28
  • Senior & Interview76
  • Glossary and Notation
Loading lesson

‹Memory & Buses
  1. Topics
  2. RTL Design
  3. Memory & Buses
  4. Synchronous FIFO

Part 7 · Memory & Buses · Intermediate

Synchronous FIFO

A production-ready single-clock FIFO: interface contract, flags, boundary policy, fall-through behavior, parameter guards, and verification.

  • 7topics
  • 7lessons

Topics in this section

  1. 1Contract and Invariants1 lesson
  2. 2Pointers, Occupancy and Flags1 lesson
  3. 3Portable Registered-Output FIFO1 lesson
  4. 4Simultaneous Push and Pop1 lesson
  5. 5Standard vs Fall-Through Output1 lesson
  6. 6Almost Flags and Parameter Edges1 lesson
  7. 7Verification and Signoff1 lesson
On this page

    A synchronous FIFO stores an ordered stream when producer and consumer share one clock. It absorbs bursts, breaks timing paths, and converts short-term rate differences into occupancy.

    The memory array is the easy part. Correctness lives in the acceptance rules, pointer wrap, full and empty flags, simultaneous push/pop behavior, and the exact cycle in which output data becomes valid.

    A depth-five telemetry FIFO is the running design. Its non-power-of-two depth forces explicit pointer wrap, its registered output models a synchronous memory, and its conservative boundary policy remains unchanged from specification through scoreboard and assertions.

    Producer and consumer connected through a synchronous FIFO with occupancy-based status.
    One clock owns both sides. Accepted pushes add one ordered word; accepted pops remove the oldest word.

    Lessons in this topic

    7 lessons, about 28 min

    1. 1Contract and InvariantsYou can state the four FIFO invariants, define an accepted operation, and write the interface contract for the full and empty edges.4 min
    2. 2Pointers, Occupancy and FlagsYou can separate empty from full with a wrap bit or a counter, and wrap a non-power-of-two depth explicitly.4 min
    3. 3Portable Registered-Output FIFOYou can build a counter-based FIFO with a registered pop result, qualify the result with dout_valid_o, and reserve credit before issuing a pop.5 min
    4. 4Simultaneous Push and PopYou can state the conservative and the elastic rules for push and pop at the same edge, and say what each needs from the memory.4 min
    5. 5Standard vs Fall-Through OutputYou can compare registered-output and first-word fall-through FIFOs, and say what a prefetched fall-through design adds.3 min
    6. 6Almost Flags and Parameter EdgesYou can derive an almost-full margin from the producer's reaction time, and reject illegal margins at elaboration.4 min
    7. 7Verification and SignoffYou can build a self-checking FIFO test with a reference queue, and list the parameter sets and evidence needed for signoff.4 min
    Check yourself A FIFO has accepted 19 pushes and 12 pops since reset. What must its occupancy be?

    Seven. The central invariant is accepted pushes minus accepted pops. Requests refused at full or empty do not enter either count.

    Tip

    Begin FIFO design with acceptance and latency rules: push/pop guards, full/empty boundaries, simultaneous operations, output-valid meaning, and occupancy = accepted pushes - accepted pops.

    Revision sheet

    The whole topic on one page, taken from each lesson's Remember box. Read it before an interview, or print it.

    Contract and Invariants

    • Count accepted operations, not request levels. A push seen at full is rejected, even if a pop happens on the same edge.

    • Conservation, bounds, ordering and pointer discipline are the four invariants.

    • With push and pop together, occupancy holds but both pointers still advance.

    Rule of thumb: pointers and occupancy change on accepted operations only, never on raw requests.

    Pointers, Occupancy and Flags

    • An extra wrap bit makes equal pointers mean empty, and equal address bits with different wrap bits mean full.

    • A counter gives exact occupancy and any depth, at the cost of an adder and a register.

    • For non-power-of-two depth, wrap explicitly at DEPTH-1. Truncating the pointer reaches nonexistent entries.

    Portable Registered-Output FIFO

    • dout_valid_o marks the cycle of a newly removed word. The held bits afterwards mean nothing.

    • Never gate result-valid with !empty_o, because the final word is lost.

    • The memory array is never reset. Reset the pointers and the count, and empty hides the old contents.

    Rule of thumb: treat the pop as a result pulse: reserve capacity before you ask, and capture every result.

    Simultaneous Push and Pop

    • The conservative rule decides from the flags before the edge. It loses one opportunity at full and one at empty, and is portable.

    • The elastic rule accepts a push at full when a pop frees the slot. The memory must return the old word on a same-address collision.

    • Empty bypass is a different contract: it adds a combinational input-to-output path.

    Rule of thumb: the acceptance policy is visible behaviour, so change it in the RTL, the scoreboard and the assertions together.

    Standard vs Fall-Through Output

    • Direct fall-through reads the memory asynchronously. It suits a small flop-based queue, not a large synchronous SRAM.

    • A memory-friendly fall-through FIFO keeps an output register filled by a prefetch controller.

    • The consumer contract changes with the mode, so it is not a one-line output swap.

    Rule of thumb: name the output mode in the interface or the module name.

    Almost Flags and Parameter Edges

    • The margin must cover the cycles the producer needs to react, plus any register or crossing on the warning.

    • Test depths and margins at the limits: a one-bit width, depths of two and three, and a margin equal to the depth minus one.

    • Programmable watermarks are software policy. Almost flags are fixed hardware safety thresholds. Keep them separate.

    Rule of thumb: derive each threshold from a real reaction latency, never from a habit.

    Verification and Signoff

    • Compare every popped word with an independent ordered reference queue, and reach empty, full, simultaneous operations and several wraps.

    • Run the same top over a matrix of width, depth and margin. Illegal settings must fail at elaboration.

    • Reset discards queued words and any uncaptured result. A wrapper must account for them.

    Rule of thumb: signoff is a scoreboard, boundary assertions, wrap-around traffic, a parameter matrix and the memory-inference report.

    Practise it

    • Mini project: a two-master bus with decoder, default slave and timeout

    • Practice question: Synchronous FIFO RTL design, blocking on full and empty

    • Code lab: Synchronous FIFO, 4 entries

    • Practice question: Synchronous FIFO with full and empty flags

    • Code lab: Synchronous FIFO, 8 entries

    • Practice question: FWFT FIFO with almost flags and pointer-distance occupancy

    • Interview: run a mock interview on this topic

    PreviousNext: Contract and Invariants

    Up next

    Up nextContract and Invariants

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • SRAM and ROM
    • Register Files
    • Valid/Ready Handshake