Interview Question · Debug

The Scoreboard That Remembered Before Reset

L1 JuniorL2 Mid-Levelsystemverilogscoreboardsresetdebug

The interviewer asks

A test applies reset in the middle of traffic. After reset, the first response for ID 3 fails although the waveform shows the DUT returned the right data for the new request. Here is the log. What is wrong?

log

@1200 req  id=3 data=a0
@1250 RESET asserted (2 requests outstanding)
@1400 RESET released
@1450 req  id=3 data=b1
@1520 resp id=3 data=b1
@1520 SCOREBOARD ERROR: ID 3: expected a0 got b1

Reveal the Model Answer

The scoreboard still holds the expected data of the request that was in flight at reset. So it compares the new response with a0. The DUT legitimately dropped that request; the testbench did not. On reset, flush every expected-data structure, and decide whether a dropped request should be logged or counted.

An Expectation That Survives Reset

Cycle 1
Read ID 3 is issued, and the scoreboard pushes its expected data, 0x10, onto exp_q[3].
Cycle 2
Reset is asserted. The DUT drops the outstanding read, as the spec requires, but the scoreboard keeps 0x10.
Cycle 5
A new read reuses ID 3. Its expected data, 0x20, queues behind the stale 0x10.
Cycle 7
The DUT returns 0x20. The scoreboard pops the stale 0x10 and reports ID 3: expected 10 got 20.

The same bug on a waveform, with data 10 and 20. The DUT forgot the first read at reset; the scoreboard did not.

Self-Check

Tick each key point you covered in your answer.

Key point 1 The scoreboard still holds the expected data of the request that was in flight at reset. Key point 2 So it compares the new response with a0. Key point 3 The DUT legitimately dropped that request; the testbench did not. Key point 4 On reset, flush every expected-data structure, and decide whether a dropped request should be logged or counted.

What Interviewers Listen For (Junior)

A good junior answer reads the log and sees that the expected value belongs to the request from before reset. It adds a flush of the scoreboard on reset.

Cross-Questions

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

WhyWhat IfProve ItCompareScale It

The Scoreboard That Remembered Before Reset
WhyWhy a Reset Drops Outstanding RequestsL1 Junior
Why is it legal for the DUT to forget requests at reset instead of finishing them?

Reveal the Model Answer

Reset returns the design's state to its defined initial values, and the queues holding outstanding requests are part of that state. Most protocols say transactions in progress at reset are abandoned and that nothing may be signalled until reset is released. The testbench must model the same loss.

Self-Check
Tick each key point you covered in your answer.
Key point 1 Reset returns the design's state to its defined initial values, and the queues holding outstanding requests are part of that state. Key point 2 Most protocols say transactions in progress at reset are abandoned and that nothing may be signalled until reset is released. Key point 3 The testbench must model the same loss.

Half-Truth

"A good design should complete in-flight requests before resetting."

That is a graceful-shutdown feature some designs add, not what reset means. Check the spec rather than assuming it.
- Lesson 2.7Debug Case: Stale IDs After Reset
- Lesson P1.3Handshakes: Request and Acknowledge, Valid and Ready
What IfA Response That Outlives ResetL1 JuniorL2 Mid-Level
What if responses can outlive reset, and the next request reuses the same ID?

Reveal the Model Answer

Then a late response for the old request can match the new request with the same ID. The scoreboard may pass wrong data, or flag correct data. Give each expected entry extra identity, or wait a quiet period after reset before reusing IDs. Test it with a reused ID and a duplicate response.

Self-Check
Tick each key point you covered in your answer.
Key point 1 Then a late response for the old request can match the new request with the same ID. Key point 2 The scoreboard may pass wrong data, or flag correct data. Key point 3 Give each expected entry extra identity, or wait a quiet period after reset before reusing IDs. Key point 4 Test it with a reused ID and a duplicate response.

Missed Corner

"Clearing the queue at reset fixes stale IDs for good."

It removes old expectations, but not responses still in flight. A late one can match a new request with the same ID.

Source Lesson 2.7 key points
- Lesson 2.7Debug Case: Stale IDs After Reset
- Problem 2.7.1Flush Pending Requests
CompareFlushing the Scoreboard vs Tagging EpochsL2 Mid-Level
Compare flushing the scoreboard on reset with tagging each expectation with a reset epoch number.
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

Flushing is simple and correct when the monitors also stop at reset. Tagging every entry with the epoch it was created in lets the checker recognise a late response from before the reset. It can then report that case as its own error instead of mismatching it. Use the epoch scheme when responses can still emerge from pipelines around the reset edge.

A Stale Entry, Then the Clear on ResetThe scoreboard state for ID 3, first without and then with a clear on reset. Arrows show data, except exp_q.delete(), which is a call.

Before reset
A read with ID 3 is issued before reset, and its expected data, 0x10, is pushed onto exp_q[3].
Follow the calls, values and waits
data 10: Request monitor → exp_q[3]
Reset, no clear
Reset is asserted and the DUT drops that read. Without a clear, 0x10 stays in the queue and describes a read that no longer exists.
ID 3 is reused
After reset a new read reuses ID 3. Its expected data, 0x20, lands behind the stale 0x10.
Follow the calls, values and waits
data 20: Request monitor → exp_q[3]
A false failure
The DUT returns 0x20, but pop_front hands the checker the stale 0x10. It reports expected 10 got 20, and 0x20 is left behind.
Follow the calls, values and waits
data 20: DUT → response()
data 10: exp_q[3] → response()
With the repair
Run it again with the repair. When rst_n falls, exp_q.delete() removes every ID and every entry, so 0x10 is gone.
Follow the calls, values and waits
data 10: Request monitor → exp_q[3]
call exp_q.delete(): Reset monitor → exp_q[3]
Only new reads remain
The new read pushes 0x20, and the response pops 0x20 and matches. exp_q.num() is 0 at the end.
Follow the calls, values and waits
data 20: Request monitor → exp_q[3]
data 20: DUT → response()
data 20: exp_q[3] → response()

Read the diagram as text
Request monitor: pushes expected data per ID
Reset monitor: waits for negedge rst_n
exp_q[3]: expected data for ID 3
response(): pops the front for the ID
DUT: returns ID 3 with data 20
Request monitor → exp_q[3]: push_back
Reset monitor → exp_q[3]: exp_q.delete()
exp_q[3] → response(): pop_front
DUT → response(): response

Each entry stands for a read the DUT still owes; reset cancels them all, so the scoreboard must drop them too.

Self-Check
Tick each key point you covered in your answer.
Key point 1 Flushing is simple and correct when the monitors also stop at reset. Key point 2 Tagging every entry with the epoch it was created in lets the checker recognise a late response from before the reset. Key point 3 It can then report that case as its own error instead of mismatching it. Key point 4 Use the epoch scheme when responses can still emerge from pipelines around the reset edge.
Missed Corner

"Flushing is always enough."

A response already on the wires at the reset edge arrives after the flush. It has no matching entry, or it matches a reused ID by accident.

Source Lesson 2.7 (debug case: stale IDs after reset)
- Lesson 2.7Debug Case: Stale IDs After Reset
Prove ItSolve 2.7.1: Flush Pending RequestsSimulator-graded

Show it, don't just say it: this Silicon Lab problem is graded by the simulator.
Open Problem 2.7.1
Scale ItReset in the Middle of a Test Across a Whole EnvironmentL3 Senior
How do you make mid-test reset work across a whole environment with several agents, scoreboards and running sequences?

Reveal the Model Answer

Give reset one owner that broadcasts it, and make every stateful component handle it. Drivers drop their current item and idle the bus, monitors abandon partial transactions, scoreboards flush or bump an epoch, and sequences restart. Then cover reset at each interesting point, such as mid-burst or with a full FIFO. Each component's reset code runs only in those cases.

Self-Check
Tick each key point you covered in your answer.
Key point 1 Give reset one owner that broadcasts it, and make every stateful component handle it. Key point 2 Drivers drop their current item and idle the bus, monitors abandon partial transactions, scoreboards flush or bump an epoch, and sequences restart. Key point 3 Then cover reset at each interesting point, such as mid-burst or with a full FIFO. Key point 4 Each component's reset code runs only in those cases.

What Interviewers Listen For (Senior)
A good senior answer puts mid-test reset in the test plan with its own coverage. It names the failure that happens when one component ignores reset.

Wrong Altitude

"End the test at reset and start a new one."

It avoids the problem in the bench but never tests the DUT's own reset-in-traffic behaviour, which is where real bugs hide.

What People Get Wrong

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

Misconception

"Reset only matters to the DUT; the testbench just waits for it."

Every stateful testbench component holds expectations about the DUT. The twin keeps one stale entry and fails a correct response.

Run It

An ID-keyed scoreboard across a reset that drops one outstanding request.

RUNVerilator · simulator service

Edit the code, then run it

Expected: ID 3: expected a0 got b1 mismatches=1 FAIL: the scoreboard kept the pre-reset expectation and compared the new response against it

module tb;
  // Scoreboard: expected data queued per transaction ID.
  logic [7:0] exp [int][$];
  int mismatches = 0;
  task automatic expect_req(int id, logic [7:0] d); exp[id].push_back(d); endtask
  task automatic got_resp(int id, logic [7:0] d);
    logic [7:0] e = exp[id].pop_front();
    if (e !== d) begin mismatches++; $display("ID %0d: expected %h got %h", id, e, d); end
  endtask
  initial begin
    expect_req(3, 8'hA0);       // request in flight ...
    // ... reset: the DUT drops every outstanding request
    // the belief: a reset only matters to the DUT
    expect_req(3, 8'hB1);       // ID 3 reused after reset
    got_resp(3, 8'hB1);         // the DUT answers the new request correctly
    $display("mismatches=%0d", mismatches);
    if (mismatches) $display("FAIL: the scoreboard kept the pre-reset expectation and compared the new response against it");
    else $display("PASS: the response matched the post-reset request");
  end
endmodule

See the Fix

module tb;
  // Scoreboard: expected data queued per transaction ID.
  logic [7:0] exp [int][$];
  int mismatches = 0;
  task automatic expect_req(int id, logic [7:0] d); exp[id].push_back(d); endtask
  task automatic got_resp(int id, logic [7:0] d);
    logic [7:0] e = exp[id].pop_front();
    if (e !== d) begin mismatches++; $display("ID %0d: expected %h got %h", id, e, d); end
  endtask
  initial begin
    expect_req(3, 8'hA0);       // request in flight ...
    // ... reset: the DUT drops every outstanding request
    exp.delete();               // the fix: the scoreboard forgets them too
    expect_req(3, 8'hB1);       // ID 3 reused after reset
    got_resp(3, 8'hB1);         // the DUT answers the new request correctly
    $display("mismatches=%0d", mismatches);
    if (mismatches) $display("FAIL: the scoreboard kept the pre-reset expectation and compared the new response against it");
    else $display("PASS: the response matched the post-reset request");
  end
endmodule

Prints: mismatches=0 PASS: the response matched the post-reset request

Delivery

"The DUT must be wrong; the scoreboard says so."

The log shows the response matching the post-reset request. Debug starts by asking which side holds old state, not by trusting the checker.

Wrong Altitude

"Avoid reusing IDs after reset in the test."

That hides the bug instead of fixing it, and real software reuses IDs freely after a reset.

Find Your Next Track

Put Your Skills to Work

Prepare to Explain Your Thinking

An Idea to Try? Pick a Tool.

The Scoreboard That Remembered Before Reset

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)

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)

What People Get Wrong

Learn It, Then Prove It