Data Checking

Scoreboards · Module 18 · Page 18.4

The Engineering Problem

The predictor produces the expected (Module 18.2) from a faithful reference model (18.3), and the scoreboard receives the observed from the monitor. Now comes the comparison itself — data checking: given a paired observed and expected transaction, decide if they match. This sounds trivial — "are they equal?" — but it carries two real decisions that make or break the check. First: which fields to compare. Not all fields matter — a transaction often carries fields the spec leaves unspecified (reserved bits, a randomized tag, a timestamp) that the predictor can't predict; comparing those produces false mismatches (the DUT is fine, but a don't-care field differs). Second: how to report a mismatch — a vague "mismatch" message turns every failure into an investigation, while a precise one (which field, got vs expected) makes debugging instant. The problem this chapter solves is the comparison done right: comparing only the meaningful fields and reporting precisely.

Data checking is the scoreboard's field-by-field comparison of a paired observed and expected transaction. It compares the meaningful fields — the ones the spec defines and that matter for correctness — and masks the don't-cares (unspecified or irrelevant fields the predictor can't predict). On a match (all meaningful fields equal), it passes; on a mismatch (some meaningful field differs), it flags a bug with a precise report: which field differed, the got (observed) value, the expected value, and the transaction context. The two decisions are symmetric dangers: comparing too many fields (including a don't-care) → false mismatches (noise, wasted debug, eroded trust); comparing too few (masking a meaningful field) → missed bugs (a silent hole, like a reference-model gap, Module 18.3). Data checking is grading the answer: compare the DUT's answer against the key, field by field, grading only the parts that count, and marking precisely what's wrong. This chapter is the comparison: which fields to compare, the masking of don't-cares, precise mismatch reporting, and the false-mismatch bug.

How does the scoreboard compare a paired observed and expected transaction — comparing only the meaningful fields (masking don't-cares the predictor can't predict) and reporting a precise mismatch (which field, got vs expected) — and why is comparing the wrong set of fields the central data-checking hazard?

Motivation — why comparison is more than "are they equal?"

The comparison seems like a == b, but the which-fields and how-to-report decisions determine whether the check is correct and usable. The reasons:

• Not all fields matter for correctness. A transaction carries meaningful fields (the spec defines them — address, data, response) and don't-cares (reserved bits, a tracking tag, a timestamp the spec leaves unspecified). Only the meaningful ones should be compared.
• The predictor can't predict a don't-care. For an unspecified field, the spec doesn't say what the value should be — so the reference model has no basis to predict it. Comparing it pits the DUT's arbitrary value against the predictor's default → a false mismatch.
• Comparing too many fields is noise. A false mismatch on every transaction with a don't-care difference floods the log, wastes debug time chasing a non-bug, and erodes trust in the scoreboard (the "boy who cried wolf").
• Comparing too few fields is a blind spot. Masking a meaningful field (one that does matter) means a bug in that field is never caught — a silent hole, exactly like a reference-model gap (Module 18.3's blind spot).
• The report determines debug speed. A mismatch is a signal — but a vague one ("mismatch occurred") forces a fresh investigation, while a precise one (field, got, expected, context) points straight at the problem. The report is part of the check's value.

The motivation, in one line: the comparison is more than a == b because which fields you compare determines correctness (compare only the meaningful ones — don't-cares the predictor can't predict produce false mismatches, masking meaningful ones produces missed bugs) and how you report determines debug speed (a precise mismatch — field, got, expected — is instant to debug; a vague one is an investigation).

Mental Model

Hold data checking as grading the answer — comparing against the key field by field, grading only what counts, marking precisely what's wrong:

Data checking is grading an answer against the key: you compare the student's answer field by field, but you grade only the parts that count — not the handwriting, the margin doodles, or the scratch work — and you mark precisely what's wrong, so the student knows exactly where they erred. Grade a doodle as 'wrong' and the grade is unfair; skip a real answer and you miss a mistake; write 'wrong' with no detail and the feedback is useless. Picture grading a filled-in answer sheet (the observed transaction) against the answer key (the expected). You go field by field — question by question — comparing each. But you grade only the parts that count: the answers the exam tests, not the handwriting, the margin doodles, the scratch work in the corner (the don't-cares — fields irrelevant to whether the answer is right). Three things must be right. First, grade only what counts: if you mark a margin doodle as "wrong" (compare a don't-care), the grade is unfair — you've failed a correct student over something that doesn't matter (a false mismatch). Second, don't skip a real answer: if you skip grading question 3 (mask a meaningful field), you miss a real mistake (a missed bug). Third, mark precisely: writing "wrong" with no detail leaves the student guessing; writing "question 3: you put 24, the answer is 42" (the field, the got, the expected) tells them exactly where they erred — useful feedback. So good grading is comparing the right things (the answers, not the doodles) and marking precisely (which question, what you wrote, what's correct) — so the grade is fair and the feedback is actionable.

So data checking is grading the answer against the key: compare field by field, grade only the parts that count (the meaningful fields — not the don't-care doodles), and mark precisely what's wrong (which field, got vs expected, context). The two grading errors are symmetric: grading a doodle (comparing a don't-care) → unfair fail (false mismatch); skipping a real answer (masking a meaningful field) → missed mistake (missed bug). And vague marks (no detail) make the feedback useless. Grade only what counts, don't skip what matters, and mark exactly what's wrong.

Visual Explanation — the field-by-field comparison

The defining picture is the comparison: the scoreboard compares the meaningful fields of the observed and expected, masks the don't-cares, and on a mismatch reports precisely.

The figure shows the field-by-field comparison with its two key behaviors: comparing only the meaningful fields and reporting precisely. The observed and expected transactions each have meaningful fields (address, data, response) and don't-care fields (a reserved field, a timestamp). The scoreboard compares the meaningful fields field by field, and masks the don't-cares (they are not compared). If all meaningful fields match, it passes. If a meaningful field differs, it produces a precise mismatch report: which field, the got (observed) value, the expected value, and the transaction context. The crucial reading is the two design choices made visible. First, the warning-colored don't-cares are masked — routed away from the comparison — so their differences (which are legitimate, since the spec doesn't define them) don't cause false mismatches. Second, the success-colored report is precise — it names the field and shows both values — so a real mismatch is immediately actionable. This is the anatomy of a correct, usable comparison: compare what matters (meaningful fields), ignore what doesn't (don't-cares), and report what's wrong (field, got, expected). The separation of the meaningful fields (compared) from the don't-cares (masked) is the correctness decision; the precision of the report is the usability decision. The diagram is the comparison done right: a focused check (only the meaningful fields) with a clear verdict (a precise mismatch) — fair (no false marks for don't-cares) and useful (exactly which field, and what each value is).

RTL / Simulation Perspective — comparing with field masking and precise reporting

In code, the scoreboard compares the transactions — masking don't-cares (via field-automation flags or a custom compare) and reporting the precise mismatch. The code shows both.

class bus_txn extends uvm_sequence_item;
  rand bit [31:0] addr;                            // MEANINGFUL — compare
  rand bit [31:0] data;                            // MEANINGFUL — compare
  rand bit [1:0]  resp;                            // MEANINGFUL — compare
  bit  [7:0]      tag;                             // DON'T-CARE — tracking only, do NOT compare
  time            timestamp;                        // DON'T-CARE — unspecified, do NOT compare
  `uvm_object_utils_begin(bus_txn)
    `uvm_field_int(addr, UVM_ALL_ON)               // included in compare
    `uvm_field_int(data, UVM_ALL_ON)
    `uvm_field_int(resp, UVM_ALL_ON)
    `uvm_field_int(tag,  UVM_NOCOMPARE)            // ← masked: excluded from compare (don't-care)
    // timestamp: not registered for compare at all
  `uvm_object_utils_end
endclass
 
// === SCOREBOARD: compare paired observed vs expected; report PRECISELY on mismatch ===
function void my_scoreboard::check(bus_txn observed, bus_txn expected);
  if (observed.compare(expected)) `uvm_info("SB", "MATCH", UVM_HIGH)   // compares only meaningful fields
  else `uvm_error("SB", $sformatf("MISMATCH addr=%0h: data got=%0h exp=%0h, resp got=%0h exp=%0h",
                                   observed.addr, observed.data, expected.data, observed.resp, expected.resp))
endfunction
// ✗ comparing a DON'T-CARE (e.g., tag/timestamp) → false mismatches (DebugLab)
// ✗ masking a MEANINGFUL field → missed bugs (silent hole)

The code shows field masking and precise reporting. The transaction declares meaningful fields (addr, data, resp — compared) and don't-care fields (tag — tracking only; timestamp — unspecified). The field automation controls the comparison: uvm_field_int(addr, UVM_ALL_ON) includes a field in compare, while uvm_field_int(tag, UVM_NOCOMPARE) masks it (excluded from compare), and timestamp is not registered (so never compared). So observed.compare(expected) compares only the meaningful fields. The scoreboard's check calls compare — and on a mismatch, reports precisely: the uvm_error names the address context, and shows data got=... exp=..., resp got=... exp=... — which fields, got vs expected. The two ✗ comments mark the symmetric dangers: comparing a don't-care (tag/timestamp) → false mismatches (the DebugLab); masking a meaningful field → missed bugs (a silent hole). The shape to carry: control which fields are compared (via field-automation flags — UVM_NOCOMPARE to mask don't-cares, or a custom do_compare), comparing only the meaningful fields, and report the mismatch precisely (which field, got, expected, context — via $sformatf). The field flags are where the which-fields decision lives; the $sformatf report is where the debuggability lives. Getting both right — mask the don't-cares, report precisely — is what makes the comparison correct (no false mismatches, no missed bugs) and usable (fast to debug).

Verification Perspective — the two failure modes of field selection

The which-fields decision has two symmetric failure modes — comparing too many (false mismatches) and comparing too few (missed bugs) — and the right set is exactly the meaningful fields. Seeing both frames the decision.

The figure shows the two failure modes of field selection and the correct middle. Compare too many — including a don't-care field the predictor can't predict — → false mismatches (a correct DUT flagged, noise, wasted debug). Compare too few — masking a meaningful field that matters — → missed bugs (a real bug in that field never caught, a silent hole). The correct set is exactly the meaningful fields: every field the spec defines and that matters for correctness, and no don't-cares → a correct check (no noise, no blindness). The verification insight is that field selection is a balance between noise and blindness, and the two errors are opposite with opposite symptoms. Comparing too many (false mismatches) is loud (the scoreboard flags — you notice), annoying (wasted debug), and trust-eroding (the "boy who cried wolf" — engineers start ignoring mismatches, which is dangerous). Comparing too few (missed bugs) is silent (the scoreboard passes — you don't notice), and dangerous (a real bug escapes). So the two errors pull in opposite directions: err toward more fields and you get false mismatches (loud noise); err toward fewer fields and you get missed bugs (silent holes). The right answer is neither extreme but exactly the meaningful fields — which requires knowing the spec: which fields the spec defines (compare them) and which it leaves unspecified or irrelevant (mask them). The brand-colored "meaningful fields" is the target; the warning-colored extremes are the failures. The figure is the field-selection decision: it's not "compare everything" (false mismatches) nor "compare little" (missed bugs) but compare exactly what the spec makes meaningful — and the don't-care must be masked (it can't be predicted), while the meaningful must be compared (or its bugs escape). Compare the spec's meaningful fields — no more (noise), no less (blindness).

Runtime / Execution Flow — the comparison per transaction

At run time, the scoreboard runs a per-pair comparison: pair the observed with its expected, compare the meaningful fields, and on a mismatch report precisely. The flow shows it.

The flow shows the per-pair comparison. Pair (step 1): pair the observed transaction with its expected (the matching one — which expected goes with which observed is the ordering logic's job, in-order or out-of-order, Modules 18.5–18.6). Compare (step 2): compare the meaningful fields field by field, masking the don't-cares the predictor can't predict. Pass (step 3): if all match, pass — the DUT was correct for this transaction. Report (step 4): if any meaningful field differs, report precisely — which field, got vs expected, the context — an instantly actionable bug report. The runtime insight is the division of labor: data checking (this chapter) is the comparison once paired; the pairing (which expected matches which observed) is separate — handled by the ordering logic (in-order pairs sequentially, out-of-order pairs by ID/key, Modules 18.5–18.6). So data checking assumes a pair and focuses on the field comparison and the report. This separation is clean: the ordering logic answers "which two transactions go together?", and data checking answers "do these two match, and if not, how?". The per-transaction loop produces, for every observed transaction, either a pass (silent or low-verbosity) or a precise bug report — a stream of verdicts, each with enough detail to debug if it's a bug. The flow is the comparison engine: pair → compare meaningful fields → pass or report precisely — the focused, usable check that, given a good expected (18.3) and a correct pairing (18.5–18.6), decides correctness per transaction and reports it actionably. Compare the right fields, report precisely — for every paired transaction.

Waveform Perspective — comparing fields, reporting which one differs

The comparison is visible on a timeline: for each transaction, the meaningful fields of observed and expected are compared, and on a mismatch, the report names which field differs. The waveform shows a match and a precise mismatch.

The waveform shows the field comparison — masking the don't-care, reporting precisely. For transaction 1, the meaningful fields match: obs_data=A4 equals exp_data=A4; and the don't-care tag differs (obs_tag=11 vs exp_tag=00) but is masked, so sb_match fires (a pass) — the tag difference does NOT cause a mismatch. For transaction 2, the data field differs (obs_data=B0 vs exp_data=C1): sb_mismatch fires, and the report names the field — "data: got B0, expected C1". The crucial reading is the two behaviors visible together: (1) the don't-care tag differs in both transactions but never causes a mismatch (it's masked — not compared), so the correct transaction 1 passes despite the tag difference; and (2) the meaningful data is compared, so transaction 2's real difference is caught, with a precise report (which field, got, expected). The picture to carry is the selectivity and precision: the scoreboard compares the meaningful fields (data) and masks the don't-cares (tag), so it neither false-flags (transaction 1's tag) nor misses (transaction 2's data), and when it does flag, the report is precise (data: got B0, expected C1). The counterfactual (the DebugLab): if tag were compared, transaction 1 would false-mismatch (tag 11 ≠ 00) — noise on a correct DUT. Reading this waveform — do the meaningful fields match? is the don't-care masked? does the mismatch report name the field and both values? — confirms the comparison is correct and usable. The meaningful field compared, don't-care masked, mismatch reported precisely is the signature of data checking done right: fair (the tag difference doesn't fail a correct DUT) and useful (the data mismatch is named exactly).

DebugLab — the scoreboard that flagged a correct DUT on a don't-care field

✗ COMPARE a don't-care field the predictor can't predict → false mismatch every time:
  `uvm_field_int(tag, UVM_ALL_ON)   // ✗ tag is UNSPECIFIED by the spec → included in compare
  // the DUT sets tag to arbitrary values (legal — the spec doesn't define it)
  // the predictor sets tag to its default (0x00) — it has NO basis to predict an unspecified field
  // → tag always differs → false mismatch on EVERY transaction (DUT is actually correct)
 
✓ MASK the don't-care → compare only the meaningful fields:
  `uvm_field_int(tag, UVM_NOCOMPARE)   // ✓ tag excluded from compare (don't-care)
  // now compare only addr/data/resp (spec-defined, meaningful) → correct DUT passes, real bugs caught

Common Mistakes

• Comparing a don't-care field. An unspecified or irrelevant field the predictor can't predict floods false mismatches; mask it (UVM_NOCOMPARE).
• Masking a meaningful field. Excluding a spec-defined, correctness-relevant field hides real bugs there — a silent hole; compare every meaningful field.
• Vague mismatch reports. A bare "mismatch" turns every failure into an investigation; report which field, got vs expected, and the context.
• Comparing everything by default. Don't blindly compare all fields; decide compare-or-mask per field from the spec.
• Not knowing which fields the spec defines. The compare/mask decision requires knowing what the spec specifies; an unspecified field is a don't-care.
• Ignoring repeated same-field mismatches. The same field mismatching every time is the signature of a don't-care being compared, not a DUT bug.

Senior Design Review Notes

Interview Insights

Exercises

1. Classify the fields. For a bus transaction with address, data, response, a reserved field, and a timestamp, decide which to compare and which to mask, and why.
2. Write the report. Write a precise mismatch message for a data-field difference, including the fields a debugger needs.
3. Diagnose the flood. The same field mismatches on every transaction while others match. Name the cause and the fix.
4. Avoid both errors. Explain the two failure modes of field selection and how to choose the right set.

Summary

• Data checking is the scoreboard's field-by-field comparison of a paired observed and expected transaction: compare the meaningful fields, mask the don't-cares, pass on a full match, and on a mismatch report precisely.
• Compare only the meaningful fields — the ones the spec defines and that matter for correctness — and mask the don't-cares (unspecified or irrelevant fields the predictor can't predict), via field-automation flags (UVM_NOCOMPARE) or a custom compare.
• The two failure modes are symmetric: comparing too many (a don't-care) → false mismatches (loud noise, eroded trust); comparing too few (masking a meaningful field) → missed bugs (a silent hole) — the right set is exactly the meaningful fields.
• Report precisely — which field, got vs expected, context — because a precise report makes debugging instant and lets you instantly recognize a don't-care false mismatch (same field every time) versus a real bug.
• The durable rule of thumb: compare exactly the meaningful fields (spec-defined, correctness-relevant) and mask the don't-cares the predictor can't predict — comparing a don't-care floods false mismatches, masking a meaningful field hides real bugs — and report every mismatch precisely (which field, got vs expected, context), which makes real bugs instant to debug and don't-care false mismatches obvious.

Next — In-Order Checking: the simplest pairing — in-order checking: when the DUT's outputs arrive in the same order as the inputs, the scoreboard pairs each observed transaction with the next expected from a queue, the FIFO pattern that implements it, and the cases (drops, duplicates, reordering) it catches and the ones it can't.