ASIC Point Explore

← Design Verification Interviews

Interview Question · Project Defence

Walking Through a FIFO Test Plan

L2 Mid-LevelL3 Senioruvmtest planproject defence

The interviewer asks

Walk me through your test plan for a synchronous FIFO with a configurable depth.

Reveal the Model Answer

I start from the spec and list every feature: ordering, full, empty, the almost-full flag, and reset. For each feature I say how it is checked: a scoreboard for order and data, assertions for flag timing and illegal pushes. Then I say how it is driven: random push and pop rates, plus directed fill-to-full and drain-to-empty. Each feature gets coverage, such as fill level crossed with push and pop. I finish with exit criteria: tests passing on many seeds, coverage closed, and no open serious bugs.

REQ-7 from the Specification to a TestEach arrow is a document or code reference. The row cites the requirement, the bin and the check cite the row, and the row names the test that hits it.
REQ-7 from the specification to a testEach arrow is a document or code reference. The row cites the requirement, the bin and the check cite the row, and the row names the test that hits it. document Specification REQ-7: withCTRL.burst = 1 awrite burst isaccepted document Test plan row REQ-7: bin, check,test, closure rule coverage mon_cov binREQ-7 write, len > 1,ctrl_burst = 1, ok =1 checker Scoreboard rule ok must equal !(wr&& len > 1 &&!ctrl_burst) test burst_test(repaired) Intended: CTRL = 11,then 3 write bursts decision Closure Hit in a complete,checked run ofburst_test becomes a rowmeasured byjudged byhit byno mismatchhits counted
  1. A testable sentence

    The specification sentence names the condition (CTRL.burst = 1), the stimulus (a write burst) and the result (accepted).

    Follow the calls, values and waits
    1. data REQ-7 sentence: Specification → Test plan row
  2. A bin and a check

    The row points to one coverage bin and one checker rule. The bin proves the case happened; the rule proves the result was right.

    Follow the calls, values and waits
    1. data row REQ-7: bin: Test plan row → mon_cov bin REQ-7
    2. data row REQ-7: check: Test plan row → Scoreboard rule
  3. A test that owns it

    The row names burst_test as the test expected to hit REQ-7. In one run, its CTRL write was wrong, so the bin stayed at 0.

    Follow the calls, values and waits
    1. data REQ-7 hits = 0: mon_cov bin REQ-7 → burst_test (repaired)
    2. Waiting: burst_test (repaired) — REQ-7 not hit: CTRL written as 01
  4. Closed only when both agree

    REQ-7 closes when a run of burst_test hits the bin, answers and checks all ten planned requests, and reports no mismatch. A hit in a failing or incomplete run does not count.

    Follow the calls, values and waits
    1. data REQ-7 hits = 3: mon_cov bin REQ-7 → burst_test (repaired)
    2. data REQ-7 hits = 3: burst_test (repaired) → Closure
    3. data 10 checked, 0 mismatches: Scoreboard rule → Closure
    4. Released: burst_test (repaired)
Read the diagram as text
  • Specification: REQ-7: with CTRL.burst = 1 a write burst is accepted
  • Test plan row: REQ-7: bin, check, test, closure rule
  • mon_cov bin REQ-7: write, len > 1, ctrl_burst = 1, ok = 1
  • Scoreboard rule: ok must equal !(wr && len > 1 && !ctrl_burst)
  • burst_test (repaired): Intended: CTRL = 11, then 3 write bursts
  • Closure: Hit in a complete, checked run of burst_test
  • Specification → Test plan row: becomes a row
  • Test plan row → mon_cov bin REQ-7: measured by
  • Test plan row → Scoreboard rule: judged by
  • mon_cov bin REQ-7 → burst_test (repaired): hit by
  • Scoreboard rule → Closure: no mismatch
  • burst_test (repaired) → Closure: hits counted

A requirement is closed by a hit in a complete, checked run, both traceable to one plan row.

FeatureCheckStimulusCoverage
Order and dataScoreboard (queue model)Random push/pop ratesItems through each slot
Full and empty flagsAssertions on flag timingDirected fill and drainFlag set and clear seen
Push when full, pop when emptyAssertion: no state changeWeighted illegal requestsEach illegal case hit
Push and pop together at full or emptyScoreboard and assertionsDirected, then weightedCross of level with push and pop
Reset with data insideScoreboard flush, flags resetReset at random fill levelsReset at each fill level band

One row per feature: how it is checked, driven and shown to be covered.

Self-Check

Tick each key point you covered in your answer.

What Interviewers Listen For (Mid-Level)

A good mid-level answer organises the plan by feature. Each feature gets a check, a stimulus and a coverage item before any test is named.

Cross-Questions

Where the interviewer goes next. Open a node to practise that follow-up.

WhyWhat IfProve ItCompareScale It

  1. Walking Through a FIFO Test Plan
  2. WhyWhy the Plan Lists Features Before TestsL2 Mid-Level

    Why list features before tests?

    Reveal the Model Answer

    Designers and architects can review a feature list against the spec. Each feature then maps to checks and coverage you can measure. A list of tests cannot show what is missing. Features also stay stable when tests are renamed or merged.

    Self-Check

    Tick each key point you covered in your answer.

  3. What IfA Feature Row with No CheckL2 Mid-Level

    What if a feature in the plan has no check and no coverage item mapped to it?

    Reveal the Model Answer

    Then the plan shows a hole, which is the point of the format. Either add a check and a cover for it, or record why it is out of scope, approved by the architect. At sign-off, every feature row needs a check, a cover and a result.

    Self-Check

    Tick each key point you covered in your answer.

    Half-Truth

    "The regression passes, so every feature is covered."

    A passing test can skip a feature completely. Only a mapped check and cover show it was exercised and checked.

  4. What IfPlanning for a Parameterised DepthL2 Mid-Level

    What if the depth is a parameter that can be anything from 2 to 1024?

    Reveal the Model Answer

    Pick configurations that stress different logic. Use the smallest depth, a power of two, a depth that is not a power of two, and the largest. Run the full plan on a few and a smoke set on the rest. Collect coverage per configuration, because "full" at depth 2 says nothing about depth 1000.

    Self-Check

    Tick each key point you covered in your answer.

    Missed Corner

    "Test the default depth; the others are the same logic."

    Pointer wrap and count widths change with the depth. A depth that is not a power of two often breaks wrap logic that works at 16.

    Source Problem 7.2.2, Arbitrary-Depth FIFO with a Fill Level (graded on several depths)

  5. CompareFIFO Rules: Assertions or ScoreboardL2 Mid-Level

    Which FIFO rules go in assertions, and which in the scoreboard?

    Reveal the Model Answer

    Cycle rules go in assertions: full rises in the cycle the last slot fills, and no push is accepted while full. Data rules go in the scoreboard: every popped value matches the oldest pushed value. Some rules need both, such as the count after reset. Formal tools can then prove the assertion side on its own.

    The Model and the FIFO Watch the Same PortsA FIFO and a small model watch the same ports. Arrows show data: the stimulus reaches the FIFO and, through a bound checker, the model. A failing rule adds one to its counter.
    The model and the FIFO watch the same portsA FIFO and a small model watch the same ports. Arrows show data: the stimulus reaches the FIFO and, through a bound checker, the model. A failing rule adds one to its counter. testbench Stimulus one operation perclock component hardware_fifo DEPTH 3 model Auxiliary model n, q, exp_data assertions Rules flags_match,answered, in_order,... component Fail counters one per rule drivessame portsoutputsn, take_r, exp_dataelse f_x++
    1. Fill

      Writes of 10, 11 and 12 are accepted. The model's queue holds 10, 11, 12, and n is 3, equal to DEPTH.

      Follow the calls, values and waits
      1. data write 10, 11, 12: Stimulus → hardware_fifo
      2. data write 10, 11, 12: Stimulus → Auxiliary model
    2. A write at full

      The write of 13 meets n == DEPTH, so take_w is 0 and the model skips it. flags_match compares the FIFO's full with n == DEPTH.

      Follow the calls, values and waits
      1. data write 13: refused: Stimulus → Auxiliary model
      2. data full = 1: hardware_fifo → Rules
      3. data n = 3: Auxiliary model → Rules
    3. A read is accepted

      A read and the write of 14 arrive together. The read is accepted and the write refused, both decided at full. The model pops 10 into exp_data.

      Follow the calls, values and waits
      1. data read, write 14: Stimulus → hardware_fifo
      2. data read, write 14: Stimulus → Auxiliary model
    4. The answer, one edge later

      answered sees read_valid, and in_order compares read_data with the sampled exp_data, 10. On the correct FIFO both hold.

      Follow the calls, values and waits
      1. data read_data = 10: hardware_fifo → Rules
      2. data exp_data = 10: Auxiliary model → Rules
    5. Fault 6, same traffic

      This variant stores its fourth accepted write, 15, in a spare slot. The read of 15 returns the stale 10, and in_order fails once.

      Follow the calls, values and waits
      1. data read_data = 10: hardware_fifo → Rules
      2. data exp_data = 15: Auxiliary model → Rules
      3. data in_order + 1: Rules → Fail counters
    Read the diagram as text
    • Stimulus: one operation per clock
    • hardware_fifo: DEPTH 3
    • Auxiliary model: n, q, exp_data
    • Rules: flags_match, answered, in_order, ...
    • Fail counters: one per rule
    • Stimulus → hardware_fifo: drives
    • Stimulus → Auxiliary model: same ports
    • hardware_fifo → Rules: outputs
    • Auxiliary model → Rules: n, take_r, exp_data
    • Rules → Fail counters: else f_x++

    The model decides acceptance from its own count, never from the FIFO's internals.

    Self-Check

    Tick each key point you covered in your answer.

  6. Scale ItGetting a Test Plan Signed OffL3 Senior

    Scale it: how do you get the plan signed off, and how do you keep it alive?

    Reveal the Model Answer

    Review it with the designer and the architect, row by row, and record who agreed. Link each row to its checks and coverage items, so the plan shows live status. Review it again whenever the spec changes. At sign-off, every row is closed or formally waived with a reason.

    Self-Check

    Tick each key point you covered in your answer.

    What Interviewers Listen For (Senior)

    A good senior answer treats the plan as a live document linked to results, with an owner for each row. It is not a file written once and forgotten.

  7. Prove ItSolve 7.6.6: Catch the FIFOs That Break at Wrap and ResetSimulator-graded

    Show it, don't just say it: this Silicon Lab problem is graded by the simulator.

    Open Problem 7.6.6

What People Get Wrong

Common wrong answers and why they fail.

Delivery

Lists test names: "fifo_full_test, fifo_empty_test, random_test".

Tests come last. The interviewer wants the features, how each is checked, and how you know each was exercised.

Half-Truth

"Random push and pop will cover the corners."

Random rates rarely hold the FIFO full while pushing and popping in the same cycle. Corners need directed or weighted stimulus, and a coverage bin that proves they ran.

Wrong Altitude

Starts with the UVM class diagram.

The bench follows from the plan. Leading with classes shows tool knowledge, not what you would check.

Learn It, Then Prove It