Interview Question · Debug

Full Coverage, No Errors, and a Dropped Packet

L1 JuniorL2 Mid-LevelL3 Seniorfunctional coveragedebugmethodology

The interviewer asks

Silicon drops CONFIG packets. Here is the end of the block regression log, which passed. What went wrong in the bench?

log

[gen] sent 30 packets: READ=10 WRITE=10 CONFIG=10
[cov] kind coverage = 100.00% (sampled in the generator)
[sb] compared 20, mismatches 0
[test] TEST PASSED: 0 errors

Reveal the Model Answer

Two things. The covergroup was sampled in the generator, so it measured what was sent, not what the design produced. And the scoreboard compared only the packets that came out: 30 went in, 20 were compared, and nobody checked the count. Sample coverage at the output monitor, from what the design accepted or produced. Add an end-of-test check that every sent packet was compared.

Where the Covergroup Was SampledThe twin and its fix. Arrows show packets moving through the bench, and where each covergroup takes its samples.

Read the diagram as text

Generator: 30 packets, 10 of each kind
Covergroup in the generator: 100%: counts what was sent
Design: Drops every CONFIG packet
Output monitor: 20 packets come out
Covergroup at the monitor: 66.67%: CONFIG is missing
Scoreboard: Compared 20, never checked the count

Generator → Covergroup in the generator: sample
Generator → Design: 30 in
Design → Output monitor: 20 out
Output monitor → Covergroup at the monitor: sample
Output monitor → Scoreboard

Measured: the twin reads 100.00% in the generator. The fixed version samples at the output monitor and reads 66.67%.

Self-Check

Tick each key point you covered in your answer.

Key point 1 Two things. Key point 2 The covergroup was sampled in the generator, so it measured what was sent, not what the design produced. Key point 3 And the scoreboard compared only the packets that came out: 30 went in, 20 were compared, and nobody checked the count. Key point 4 Sample coverage at the output monitor, from what the design accepted or produced. Key point 5 Add an end-of-test check that every sent packet was compared.

What Interviewers Listen For (Junior)

A good junior answer notices 30 sent against 20 compared in the log. It says this before talking about coverage at all.

Cross-Questions

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

WhyWhat IfProve ItBreak ItCompareScale It

Full Coverage, No Errors, and a Dropped Packet
WhyWhy Coverage Belongs on What the Design DidL1 Junior
Why should coverage be sampled from what the design accepted, and not from what the generator produced?
2:30

You have two and a half minutes. Speak or type, then press Get Feedback under your answer. No credits needed.

Speech-to-text runs in your browser. Chrome and Edge may send audio to their own speech service.
Reveal the Model Answer

Coverage claims that the design was exercised in a situation. A generated item proves only that the bench made it. The design may never have accepted it, because of back-pressure, a reset or a driver bug. Sampling at the monitor ties each bin to something the design actually did.

Observe the Accepted Input and the Actual OutputThe monitor reads both sides of the design. It does not use the driver’s item as evidence that a transfer happened.

Read the diagram as text
Input pins: valid, ready and x at the edge
Incrementer: Accepts 16; later produces 17
Output pins: out_valid and y at the edge
Input observation: A fresh item with x = 16
Checking path: Predict from input; compare output
Output observation: A fresh result with y = 17
Input pins → Incrementer: accepted x
Incrementer → Output pins: result pins
Input pins → Input observation: sample input
Input observation → Checking path: input item
Output pins → Output observation: sample output
Output observation → Checking path: result item

Coverage taken from these observations counts what the design accepted and produced, not what the driver offered.

Self-Check
Tick each key point you covered in your answer.
Key point 1 Coverage claims that the design was exercised in a situation. Key point 2 A generated item proves only that the bench made it. Key point 3 The design may never have accepted it, because of back-pressure, a reset or a driver bug. Key point 4 Sampling at the monitor ties each bin to something the design actually did.
Half-Truth

"If the driver sends it, the design gets it; it is the same thing."

Drivers drop, delay or reorder items under back-pressure and reset. The monitor is the only place that sees what crossed the interface.

Source Mehta, SystemVerilog Assertions and Functional Coverage (3rd ed.), §26.19 guidelines (PDF p476)
- Lesson C1What Coverage Measures
- Lesson U7.1Monitor the Event the DUT Accepts
Break ItWhat Output-Side Coverage Still MissesL2 Mid-Level
How could coverage sampled at the output monitor still mislead you?

Reveal the Model Answer

It sees only what came out. A packet the design corrupts into another kind is counted under the wrong bin. A packet that comes out with the wrong data still covers its bin. Coverage says a case happened; only the checker says it was right. That is why coverage is only trusted from passing tests.

Self-Check
Tick each key point you covered in your answer.
Key point 1 It sees only what came out. Key point 2 A packet the design corrupts into another kind is counted under the wrong bin. Key point 3 A packet that comes out with the wrong data still covers its bin. Key point 4 Coverage says a case happened; only the checker says it was right. Key point 5 That is why coverage is only trusted from passing tests.

Half-Truth

"Coverage from failing tests still counts; the case did happen."

If the design was wrong in that test, the covered case was not verified. Teams discard coverage from failing runs before merging.

Source Spear & Tumbush, SystemVerilog for Verification (3rd ed.), §9.1 (PDF p362)
- Lesson C1What Coverage Measures
- Lesson C7Closing Holes
Prove ItThe Count Check That Was MissingL1 JuniorL2 Mid-Level
Prove it: write the end-of-test check that would have caught the 10 missing CONFIG packets.

Reveal the Model Answer

At the end of the test, after the design has drained, compare the counts and the expected queue. Fail if compared != sent, or if any expected item is still waiting, and print what is left. In a UVM bench this goes in check_phase, after the run phase has ended. In the log above it would have reported 10 packets that never came out.

Self-Check
Tick each key point you covered in your answer.
Key point 1 At the end of the test, after the design has drained, compare the counts and the expected queue. Key point 2 Fail if compared != sent, or if any expected item is still waiting, and print what is left. Key point 3 In a UVM bench this goes in check_phase, after the run phase has ended. Key point 4 In the log above it would have reported 10 packets that never came out.

Missed Corner

"Check the queue is empty right after the last packet is sent."

The design still holds packets in flight then, so the check fails early or, if skipped, misses real losses. Wait for the drain, then check.

Source Verification Academy, UVM Cookbook, Analysis Reporting (PDF p155)

CompareStimulus Coverage vs Response CoverageL2 Mid-LevelL3 Senior

Compare input-side and output-side coverage. Is input-side coverage ever useful?

Reveal the Model Answer

Input-side coverage, taken at the input monitor after the design accepted the item, shows which requests the design saw. Output-side coverage shows which results it produced, such as error responses or interrupts. You usually need both, and a cross of them, such as request kind against response status. Coverage taken in the generator is useful only to tune the generator, never for sign-off.

Sampled at	Shows	Counts for sign-off?
Generator	What the bench made	No: only for tuning the generator
Input monitor	Requests the design accepted	Yes
Output monitor	Results the design produced	Yes
Cross of input and output	Request kind against response status	Yes

Self-Check

Tick each key point you covered in your answer.

Key point 1 Input-side coverage, taken at the input monitor after the design accepted the item, shows which requests the design saw. Key point 2 Output-side coverage shows which results it produced, such as error responses or interrupts. Key point 3 You usually need both, and a cross of them, such as request kind against response status. Key point 4 Coverage taken in the generator is useful only to tune the generator, never for sign-off.

What Interviewers Listen For (Senior)

A good senior answer names which covergroups count toward sign-off. It labels the generator covergroups as tuning aids only.

Missed Corner

"Output coverage is enough; inputs are the bench's business."

Some important cases leave no trace on the output, such as a request the design correctly rejects. Only input-side coverage shows it was tried.

Source Mehta, SystemVerilog Assertions and Functional Coverage (3rd ed.), §25.1.2 (PDF p443)

Prove ItSolve 7.4.6: The Scoreboard That Checks Too EarlySimulator-graded

Show it, don't just say it: this Silicon Lab problem is graded by the simulator.
Open Problem 7.4.6
What IfA Driver That Drops Items Under Back-PressureL2 Mid-Level
Asked if they ask whether the bench could drop items too

What if the design is fine, but the driver drops items? It gives up after a few cycles of back-pressure and moves on.

Reveal the Model Answer

Generator-side coverage is just as blind to this; the item was generated, so its bin counts. The scoreboard may never expect it, so nothing fails. An input monitor, sampling what crossed the interface, shows the missing items. Treat a driver that silently discards items as a bench bug: it must report an error or retry.

Self-Check
Tick each key point you covered in your answer.
Key point 1 Generator-side coverage is just as blind to this; the item was generated, so its bin counts. Key point 2 The scoreboard may never expect it, so nothing fails. Key point 3 An input monitor, sampling what crossed the interface, shows the missing items. Key point 4 Treat a driver that silently discards items as a bench bug: it must report an error or retry.

Missed Corner

"Drivers are simple; only the design can lose data."

Timeouts, reset handling and early test ends in drivers lose items too. Only a monitor on the pins shows what really happened.

Source Mehta, SystemVerilog Assertions and Functional Coverage (3rd ed.), §26.19 guidelines (PDF p476)
- Lesson 6.5Ready/valid Drivers and Backpressure
- Lesson U7.1Monitor the Event the DUT Accepts
Scale ItQuestions for a Coverage Model ReviewL3 Senior
You review other teams' coverage models. Which questions catch mistakes like this one before tape-out?

Reveal the Model Answer

Ask where each covergroup samples, and from which monitor. Ask which plan row each coverpoint serves, and why each bin edge sits where it does. Ask which exclusions exist and what spec text supports them, and whether reset is guarded. Ask which checker verifies each covered case. A model that cannot answer these is not ready to count toward sign-off.

Self-Check
Tick each key point you covered in your answer.
Key point 1 Ask where each covergroup samples, and from which monitor. Key point 2 Ask which plan row each coverpoint serves, and why each bin edge sits where it does. Key point 3 Ask which exclusions exist and what spec text supports them, and whether reset is guarded. Key point 4 Ask which checker verifies each covered case. Key point 5 A model that cannot answer these is not ready to count toward sign-off.

What Interviewers Listen For (Senior)
A good senior answer runs the review from a fixed checklist. It asks for evidence, such as the monitor connection, not just the covergroup code.

Wrong Altitude

"Review the coverage numbers; the code is the owner's business."

The numbers are only as good as the model. Every mistake in this tree reads as a healthy percentage.

Source Mehta, SystemVerilog Assertions and Functional Coverage (3rd ed.), §26.19 guidelines (PDF p477)
- Lesson C7Closing Holes
- Lesson U15.1Coverage Architecture and Planning

What People Get Wrong

Common wrong answers and why they fail. Run It shows the wrong belief failing on a real simulator.

Misconception

"Coverage was 100%, so CONFIG was tested."

It shows CONFIG was generated. The twin samples in the generator and reads 100% while the design drops every CONFIG packet.

Run It

The bench behind the log: a design that drops CONFIG, and coverage sampled in the generator.

RUNVerilator (coverage build) · simulator service

Edit the code, then run it

Expected: [cov] kind coverage = 100.00% (sampled in the generator) [sb] compared 20, mismatches 0 FAIL: the covergroup counted what was sent, not what the design produced; 10 CONFIG packets vanished

module tb;
  typedef enum bit [1:0] {READ, WRITE, CONFIG} kind_t;
  covergroup kind_cg with function sample(kind_t k);
    cp: coverpoint k;
  endgroup
  kind_cg cov = new();
  int sent = 0, compared = 0, mismatches = 0;
  // The design forwards each packet to its output, but drops CONFIG packets (the bug).
  function automatic bit dut_forwards(kind_t k); return k != CONFIG; endfunction
  initial begin
    for (int i = 0; i < 30; i++) begin
      kind_t k;
      k = kind_t'(i % 3);
      sent++;
      cov.sample(k);                        // the belief: cover what the generator sent
      if (dut_forwards(k)) compared++;      // the scoreboard compares what comes out
    end
    $display("[gen] sent %0d packets: READ=10 WRITE=10 CONFIG=10", sent);
    $display("[cov] kind coverage = %0.2f%% (sampled in the generator)", cov.get_coverage());
    $display("[sb] compared %0d, mismatches %0d", compared, mismatches);
    $display("[test] TEST PASSED: 0 errors");
    if (cov.get_coverage() == 100.0 && compared < sent) $display("FAIL: the covergroup counted what was sent, not what the design produced; 10 CONFIG packets vanished");
  end
endmodule

See the Fix

module tb;
  typedef enum bit [1:0] {READ, WRITE, CONFIG} kind_t;
  covergroup kind_cg with function sample(kind_t k);
    cp: coverpoint k;
  endgroup
  kind_cg cov = new();
  int sent = 0, compared = 0, mismatches = 0;
  // The design forwards each packet to its output, but drops CONFIG packets (the bug).
  function automatic bit dut_forwards(kind_t k); return k != CONFIG; endfunction
  initial begin
    for (int i = 0; i < 30; i++) begin
      kind_t k;
      k = kind_t'(i % 3);
      sent++;
      if (dut_forwards(k)) begin compared++; cov.sample(k); end   // the fix: sample at the output monitor
    end
    $display("[gen] sent %0d packets: READ=10 WRITE=10 CONFIG=10", sent);
    $display("[cov] kind coverage = %0.2f%% (sampled in the output monitor)", cov.get_coverage());
    $display("[sb] compared %0d, mismatches %0d", compared, mismatches);
    $display("[test] TEST PASSED: 0 errors");
    if (cov.get_coverage() < 100.0) $display("PASS: output-side coverage shows CONFIG never came out of the design");
  end
endmodule

Prints: [cov] kind coverage = 66.67% (sampled in the output monitor) PASS: output-side coverage shows CONFIG never came out of the design

Missed Corner

"No mismatches means the scoreboard saw nothing wrong, so the design is right."

A scoreboard that only compares what arrives cannot see a packet that never arrives. It needs an end-of-test check that nothing is still expected.

Source Spear & Tumbush, SystemVerilog for Verification (3rd ed.), §9.2.2 (PDF p364)

Delivery

Starts by proposing more random seeds.

The log already shows the clue: 30 sent, 20 compared. More seeds repeat the same blind spot.

Find Your Next Track

Put Your Skills to Work

Prepare to Explain Your Thinking

An Idea to Try? Pick a Tool.

Full Coverage, No Errors, and a Dropped Packet

Your Answer

Self-Check

What Interviewers Listen For (Junior)

What Interviewers Listen For (Mid-Level)

What Interviewers Listen For (Senior)

Cross-Questions

Your Answer

Self-Check

Your Answer

Self-Check

Your Answer

Self-Check

Your Answer

Self-Check

What Interviewers Listen For (Senior)

Your Answer

Self-Check

Your Answer

Self-Check

What Interviewers Listen For (Senior)

What People Get Wrong

Learn It, Then Prove It

The Question

Your Answer

Self-Check

What Interviewers Listen For (Junior)

What Interviewers Listen For (Mid-Level)

What Interviewers Listen For (Senior)

Cross-Questions

Your Answer

Self-Check

Your Answer

Self-Check

Your Answer

Self-Check

Your Answer

Self-Check

What Interviewers Listen For (Senior)

Your Answer

Self-Check

Your Answer

Self-Check

What Interviewers Listen For (Senior)

What People Get Wrong

Learn It, Then Prove It