Difficulty: Medium · Puzzle 1 of 6 · Topic: Scoreboard Puzzles: Mismatch or Ordering Bug?
Burst test shows intermittent mismatches, but waveform indicates DUT data is valid. Protocol allows response reordering by txn_id.
class my_scoreboard extends uvm_component;
uvm_tlm_analysis_fifo #(txn) exp_fifo;
uvm_tlm_analysis_fifo #(txn) got_fifo;
virtual task run_phase(uvm_phase phase);
txn exp, got;
forever begin
exp_fifo.get(exp);
got_fifo.get(got);
if (!exp.compare(got))
\`uvm_error("SB", $sformatf("Mismatch exp=%s got=%s", exp.sprint(), got.sprint()));
end
endtask
endclassFIFO-to-FIFO compare assumes strict in-order protocol.
1) Confirm protocol ordering guarantees for response channel.
2) Add txn_id to mismatch logs and show IDs are permuted, not corrupted.
3) Replace strict queue compare with associative matching by stable key (txn_id).
4) Keep timeout tracking for missing counterpart transactions.
5) Add directed out-of-order test to lock behavior.Answer: Bug: scoreboard assumes in-order compare while DUT legally reorders by txn_id. Fix: match expected/actual by transaction identity instead of queue position.
Checked by running the code in Verilator 5; the printed output supports the answer above. Plain-SV model of the compare policy: positional compare flags legal reordering, id-keyed matching does not.
A data mismatch message can be a checker policy bug, not a DUT functional bug.
What should the scoreboard do if two actual transactions arrive with the same txn_id? Model answer: If the protocol allows several outstanding transactions per id, keep a queue per id and match in order per id. If it does not, report a protocol/checker error ('duplicate outstanding id') at the second arrival, because it means a monitor or DUT bug, not a mismatch.
First I check whether the mismatching data is actually the right data arriving in a different order. The root cause is that the scoreboard assumes in-order comparison while the DUT legally reorders responses by transaction id, so this is a checker policy bug, not corruption. I confirm it by seeing that every actual item matches some expected item with the same id. The fix is to match expected and actual by transaction identity instead of queue position.