Debug case: stale IDs after reset

What the scoreboard state stands for

Each entry in the scoreboard's expected-data map stands for a read the DUT still owes a response to. That is a claim about the DUT, and it stays true only while the DUT agrees.

Reset breaks the agreement. The DUT drops every outstanding read, so after reset it owes nothing. Any entry that survives reset describes a read that no longer exists, and the next response with the same ID is compared against it.

Finding the stale entry

At the failure, print the whole queue for the ID, not only the front entry. Here exp_q[3] holds two entries, 0x10 and 0x20, although only one read with ID 3 is outstanding.

To tell old from new, store the request time with each expectation. Comparing it with the time of the last reset settles the question at once. Storing the data and the time together as a packed struct keeps the lookup unchanged and makes every later failure easier to read.

The stale entry is not a DUT bug. The DUT dropped the read exactly as the reset spec says; the scoreboard simply never heard about it.

The repair: clear the state on reset

When the monitor sees reset asserted, clear everything that describes outstanding work. For this scoreboard that is a single call, exp_q.delete();, which removes every ID and its queue.

Clear the state when reset starts, not when it ends. No response can arrive while reset is held, so the moment rst_n falls is a clean point to drop the old work.

// monitor
@(negedge rst_n);
// nothing happens to exp_q

// monitor
@(negedge rst_n);
exp_q.delete();       // every ID, every entry
outstanding = 0;

Clear by deleting keys, not by emptying each queue. If every key stays behind with an empty queue, num() still reports outstanding IDs, and the end-of-test check fails for reads that were never issued.

Other state that reset must clear

Clearing the map is the most visible step, but not the only one. A monitor that was halfway through collecting a burst must drop the beats it already has, or the first burst after reset starts with stale data.

A driver must discard requests that were queued but not yet sent, and every counter of outstanding work must return to 0.

Do the clearing in one place, for example a task that waits for negedge rst_n and then calls a reset function on each component. Scattered clears are easy to forget when someone adds new state later.

When a response can outlive reset

Some bridges can deliver a response from before reset after reset has ended. On such a system, a reused ID alone cannot tell an old response from a new one, and clearing the map turns the late response into an "unexpected response" error.

If your protocol allows that, the response needs extra identity, or the test must wait until old responses can no longer arrive before it reuses an ID. Write the rule down, because the scoreboard must follow the protocol and not your expectations.

A regression for the reset path

One test can cover every case here. Issue ID 3, reset before it completes, issue ID 3 again, and answer it: that must pass. Then send a second response for ID 3, which must be reported as unexpected.

Finish with the end-of-test check: exp_q.num() must be 0. Without the clear on reset, the first step already fails, and with the clear, every step behaves as specified.

Run the reset at several points: before any read, with one read outstanding, and in the middle of a burst. Each placement leaves different state behind.

Try it

Without the clear, the response for the new read is compared with the stale 0x10, and the new 0x20 is left behind as a read that seems never to complete. With the clear, the response matches and nothing is left over.

The last line shows the duplicate check still works after the fix. In run, move the second request above the clear, as if reset arrived after the new read was issued, and predict the first two lines.

Check yourself

module tb;
  int m [int][$];
  initial begin
    m[3].push_back(10);
    m[3].push_back(20);
    m.delete();
    m[3].push_back(30);
    $display("%0d %0d %0d", m.num(), m[3].size(), m[3][0]);
  end
endmodule

exp_q.delete();

foreach (exp_q[id]) exp_q[id].delete();

int k;
while (exp_q.num() > 0) begin
  void'(exp_q.first(k));
  exp_q.delete(k);
end

int ids [$];
foreach (exp_q[id]) ids.push_back(id);
foreach (ids[i]) exp_q.delete(ids[i]);

Practice

• Flush pending requests Implement · Easy
• The stale expectation Debug · Medium