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

  • Start Here6
  • SystemVerilog Language Foundations28
  • Object-Oriented SystemVerilog for Verification30
  • Constraint Randomization — Interview-Critical Deep Dive36
  • SystemVerilog Assertions — Interview-Critical Deep Dive40
  • Functional Coverage in SystemVerilog22
  • Testbench Architecture in SystemVerilog23
  • Advanced Language & Integration25
  • Senior & Interview Preparation21
    • Senior Debug Playbook
    • Reviewing Verification Code
    • Verification Strategy: Spec to Sign-Off
    • SystemVerilog Interview Q&A Bank
    • Capstone: Verify a Parameterized FIFO
      • Spec Analysis and Verification Plan
      • Harness and Stimulus
      • Monitor, Scoreboard and Model
      • Assertions, Coverage and Closure
  • Principal-Level Verification28
Loading lesson

‹Capstone: Verify a Parameterized FIFO
  1. Topics
  2. SystemVerilog
  3. Senior & Interview Preparation
  4. Capstone: Verify a Parameterized FIFO
  5. Spec Analysis and Verification Plan

Part 8 · Senior & Interview Prep · Intermediate

Spec Analysis and Verification Plan

The FIFO spec, ambiguity log, feature list, verification plan table and corner inventory.

On this page

    The specification

    Every plan row traces to this spec. Each numbered behavior becomes at least one feature, and each silence becomes a logged question.

    Diagram
    FIFO SPECIFICATION (v1.2)
    
      Parameters
        WIDTH  : data width in bits        (default 8,  range 1-64)
        DEPTH  : number of entries         (default 16, power of 2, >= 2)
    
      Interface (all synchronous to clk, async active-low rst_n)
        write side:  in_valid  (in)   in_ready  (out)   in_data[WIDTH]  (in)
        read  side:  out_valid (out)  out_ready (in)    out_data[WIDTH] (out)
        status:      full (out)       empty (out)
    
      Behavior
        1. A push occurs when in_valid && in_ready on a clk edge.
        2. A pop  occurs when out_valid && out_ready on a clk edge.
        3. in_ready  == !full;  out_valid == !empty.
        4. full  asserts when count == DEPTH; empty when count == 0.
        5. Data emerges in push order (strict FIFO), unmodified.
        6. Push at full is ignored (in_ready low blocks the handshake).
        7. Simultaneous push+pop is legal whenever both handshakes can
           occur (0 < count < DEPTH). At full, in_ready is low: the pop
           proceeds and an offered push is not taken until in_ready
           rises (spec v1.2 clarification Q-003).
        8. rst_n clears the FIFO to empty within 1 cycle; in-flight
           data is discarded.

    Questions for the architect

    Three ambiguities needed answers before any code. Guessing from RTL is not verification.

    • Q-003: push and pop in the same cycle at full, allowed? Answer (architect, spec updated to v1.2): no. in_ready stays !full, so the pop proceeds and the offered push is not taken that cycle; it must wait for in_ready. A push accepted at full is a bug, even when a pop fires.

    • Q-004: out_data validity when empty, defined? Answer: undefined when out_valid is low. Checkers must not compare it.

    • Q-005: behavior if rst_n asserts mid-handshake? Answer: transaction discarded, no partial state. Flags valid 1 cycle after deassert.

    Features and the plan

    One spec sentence can hide several features. Rule 7 becomes two rows because each needs different stimulus and a different check.

    1. F-01 Data integrity: every pushed word pops exactly once, unmodified, in push order.

    2. F-02 full asserts exactly at count == DEPTH, deasserts on the next pop.

    3. F-03 empty asserts exactly at count == 0, deasserts on the next push.

    4. F-04 in_ready mirrors !full; out_valid mirrors !empty (combinational, same cycle).

    5. F-05 Push at full is blocked: no data loss, no corruption, count unchanged.

    6. F-06 Pop at empty is blocked: no spurious data, count unchanged.

    7. F-07 Simultaneous push+pop at intermediate fill: count unchanged, order preserved.

    8. F-08 Push offered with a pop at full: pop proceeds, push blocked (in_ready low) until a slot is free, per Q-003.

    9. F-09 Reset mid-traffic: empty within 1 cycle, in-flight data discarded, clean restart.

    10. F-10 Backpressure: sustained out_ready == 0 fills the FIFO, release drains in order.

    11. F-11 Parameter sweep: behavior holds at DEPTH 2 (minimum) and WIDTH 1 (degenerate).

    Diagram
    VERIFICATION PLAN — fifo v1.2
    
      ID   │ Feature             │ Approach              │ Coverage / Check        │ Owner
      ─────┼─────────────────────┼───────────────────────┼─────────────────────────┼──────
      F-01 │ data integrity,     │ random, all tests     │ scoreboard in-order     │  SB
           │ in-order            │                       │ compare; a_data_integ   │
      F-02 │ full @ count=DEPTH  │ burst-fill directed   │ a_full_def;             │  SB
           │                     │ + random              │ cp_count.full bin       │
      F-03 │ empty @ count=0     │ drain directed        │ a_empty_def;            │  SB
           │                     │ + random              │ cp_count.empty bin      │
      F-04 │ ready/valid mirror  │ assertion, always on  │ a_ready_def, a_valid_def│  SB
      F-05 │ push @ full blocked │ stress + error test   │ a_no_push_full;         │  RK
           │                     │                       │ cp_backpressure bin     │
      F-06 │ pop @ empty blocked │ stress + error test   │ a_no_pop_empty;         │  RK
           │                     │                       │ x_op_state empty bin    │
      F-07 │ push+pop mid-level  │ random mixed-rate     │ x_op_state.both_mid     │  SB
      F-08 │ push offered @ full │ directed corner test  │ cp_offer_at_full bin;   │  SB
           │ with a pop          │                       │ a_no_push_full          │
      F-09 │ reset mid-traffic   │ reset-storm test      │ cp_reset_busy bin;      │  RK
           │                     │                       │ post-reset SB restart   │
      F-10 │ backpressure drain  │ burst/drain scenario  │ cp_backpressure bins    │  SB
      F-11 │ param corners       │ regression configs    │ DEPTH=2 + WIDTH=1 runs  │  RK
    
      Status column omitted here — all rows start "open".

    Corners that find bugs

    The corner inventory is the FIFO bug map. Boundaries, simultaneity, reset, wrap-around and backpressure find the bugs that flat randomness misses.

    • Exact boundaries: the cycle full asserts, the cycle empty asserts. Off-by-one errors live at count == DEPTH-1 versus DEPTH.

    • Simultaneous push and pop at empty+1 and at full-1 (F-07), and a push offered during a pop at full (F-08). Pointer-update ordering bugs live here.

    • Reset mid-traffic, mid-burst, and reset released directly into a push (F-09).

    • Wrap-around: pointers crossing DEPTH back to 0 repeatedly. Tests that push fewer than DEPTH total items never exercise it.

    • Sustained backpressure, then sudden drain at full rate (F-10).

    Common pitfall

    Two habits hide bugs: pushing fewer than DEPTH total items, which never wraps the pointers, and comparing out_data while out_valid is low, which checks data the spec leaves undefined.

    Interview

    Likely question: “How do you turn a spec into a plan?”

    • Extract until each row has one stimulus and one check.

    • Log ambiguities for the architect instead of guessing from RTL.

    • Keep a corner inventory so each bug class has a named test.

    Check yourself Rule 7 covers simultaneous push and pop. Why does it become two features?

    Each case needs different stimulus and a different check. Mid-level: both handshakes happen and count holds. Full: only the pop happens and the offered push is blocked per Q-003. Each closes a different coverage bin.

    Check yourself A test pushes 10 words into a depth-16 FIFO and passes. What did it never test?

    Wrap-around, the full boundary and the almost-full bins. The pointers never crossed back to zero.

    Related topics

    • Rules That Keep Flow Control Safe

    Previous

    228 / 259

    Next: Harness and Stimulus

    Up next

    Up nextHarness and Stimulus

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • Monitor, Scoreboard and Model
    • Assertions, Coverage and Closure