Negative Testing and Exception Scoreboarding

Mechanism and evidence

Guided verification lab

Expected failure still needs complete checking.

Register a CRC rejection before injection, verify its architectural effects, and make sure the expectation cannot leak into ID reuse.

STEP THROUGH

STATE & OBSERVATIONComplete rejection / 1 of 5

Checkpoint 1 · Register the expected exception.

TX OCCURRENCE: 50 / a
ERROR TOKEN: registered
PAYLOAD: clean
STATUS: 0

Compare all 5 checkpoints

1 · Register the expected exception.
TX OCCURRENCE
50 / a
ERROR TOKEN
registered
PAYLOAD
clean
STATUS
0
2 · Inject CRC corruption.
TX OCCURRENCE
50 / a
ERROR TOKEN
active
PAYLOAD
corrupt
STATUS
0
3 · Check every required error effect.
TX OCCURRENCE
50 / a
ERROR TOKEN
matched
PAYLOAD
dropped
STATUS
1
4 · Consume the expectation exactly once.
TX OCCURRENCE
50 / a
ERROR TOKEN
retired
PAYLOAD
—
STATUS
1
5 · Reuse ID 50 as a clean transaction.
TX OCCURRENCE
50 / b
ERROR TOKEN
none
PAYLOAD
clean
STATUS
cleared

Inspect the contract

Register the expected exception.

ID: 50
Token: Registered

Before corrupting transaction 50, register the exact outcome the checker must observe.

Evidence to inspect

Correlate the token to ID 50 and this transaction occurrence.

Checkpoint 1 / 5

Inspect the checker Selected checkpoint pseudocode

Conceptual checker / selected checkpoint

predicted_errors[{epoch, 50}] = CRC_REJECT;

Example contract & limitations

Example contract. This fixture requires corrupted ID 50 to be rejected with an error flag and status update. It is a CRC-rejection contract, not a universal claim about ECC. Expectations are correlated to a specific occurrence and consumed once. Checkpoints show selected state changes, not equally spaced simulation cycles.

Read the complete walkthrough

Complete rejection

Register the expected exception.. Before corrupting transaction 50, register the exact outcome the checker must observe. Evidence: Correlate the token to ID 50 and this transaction occurrence.
Inject CRC corruption.. Flip the selected CRC field while preserving the rest of the scenario. The expected outcome is now rejection, not successful data delivery. Evidence: Record injection location, ID, and pre-injection data.
Check every required error effect.. The checker correlates payload rejection, error flag, and status update. Merely suppressing a data mismatch would hide incomplete recovery. Evidence: Inspect all three outcomes against the registered error token.
Consume the expectation exactly once.. Delete the token after the complete matching rejection is handled. A failed side effect remains a failure even after cleanup. Evidence: Inspect the token lifetime and count of matching error events.
Reuse ID 50 as a clean transaction.. The new occurrence must follow normal data checking. A leftover error token must never waive its correctness. Evidence: Use occurrence identity and confirm the normal compare path is active.

Missing error status

Register the expected exception.. Before corrupting transaction 50, register the exact outcome the checker must observe. Evidence: Correlate the token to ID 50 and this transaction occurrence.
Inject CRC corruption.. Flip the selected CRC field while preserving the rest of the scenario. The expected outcome is now rejection, not successful data delivery. Evidence: Record injection location, ID, and pre-injection data.
Rejection without status is incomplete.. The payload is dropped and error flag is asserted, but the status register is unchanged. Detect this missing required side effect. Evidence: Inspect all three outcomes against the registered error token.
Consume the expectation exactly once.. Delete the token after the complete matching rejection is handled. A failed side effect remains a failure even after cleanup. Evidence: Inspect the token lifetime and count of matching error events.
Reuse ID 50 as a clean transaction.. The new occurrence must follow normal data checking. A leftover error token must never waive its correctness. Evidence: Use occurrence identity and confirm the normal compare path is active.

Leaked expectation

Register the expected exception.. Before corrupting transaction 50, register the exact outcome the checker must observe. Evidence: Correlate the token to ID 50 and this transaction occurrence.
Inject CRC corruption.. Flip the selected CRC field while preserving the rest of the scenario. The expected outcome is now rejection, not successful data delivery. Evidence: Record injection location, ID, and pre-injection data.
Check every required error effect.. The checker correlates payload rejection, error flag, and status update. Merely suppressing a data mismatch would hide incomplete recovery. Evidence: Inspect all three outcomes against the registered error token.
The token is accidentally retained.. The checker leaves the predicted-error entry active after handling the rejection. That stale permission can hide later defects. Evidence: Inspect the token lifetime and count of matching error events.
Reuse ID 50 as a clean transaction.. The new occurrence must follow normal data checking. A leftover error token must never waive its correctness. Evidence: Use occurrence identity and confirm the normal compare path is active.

Related implementation: Use an associative Predicted Error Set

// Associative-array membership is the set: key = transaction ID.
bit predicted_error_ids[int unsigned];

virtual function void write_error_notif(mac_item tr);
  predicted_error_ids[tr.id] = 1'b1;
endfunction

virtual function void check_data(mac_item act);
  if (predicted_error_ids.exists(act.id)) begin
    if (!act.error_flag)
      uvm_report_error("ERR", "DUT failed to detect injected error");

    check_payload_was_dropped(act.id);
    check_error_status_updated(act.id);
    predicted_error_ids.delete(act.id);
    return;
  end

  check_normal_data(act);
endfunction

The source mixes queue insertion with associative-array exists/delete calls. This corrected representation is an actual set keyed by transaction ID, so membership and one-time deletion are unambiguous.

Complete rejection, checkpoint 1: Register the expected exception.. Inspect the contract.

Understand the failure

Expected-failure ledgerInject one fault, predict every externally visible consequence.

The testbench records fault intent before injection, then checks payload suppression, error reporting, sticky status, interrupt behavior, and recovery as one correlated outcome.

01Intentcorrupt packet ID 4202Injectflip ECC bit at boundary03Observeerror response · no payload04Accountstatus + counter + IRQ05Recoverclear · retry · resume

PayloadsuppressedmatchResponseSLVERRmatchSticky statusECC_FATAL = 1matchRecoverynext clean packet passespending

injected fault token ↔ expected exception token ↔ observed response; unrelated traffic stays on the normal scoreboard path

Fault injection and exception checking

One virtual sequence coordinates the corrupted transfer and the checker expectation, while the DUT must produce both datapath and status evidence.

Error knobs: Select CRC, ECC, parity, poison type, and target transaction.
Virtual sequence: Owns injection timing and sends the stable ID expectation.
Injection proxy: Mangles the selected bits without changing the normal driver.
Predicted Error Set: Associative membership keyed by transaction ID.
DUT error path: Drops corrupted payload and asserts the required error signal.
Exception scoreboard: Checks the expected set, payload suppression, and one-time consumption.
Status evidence: RAL or monitor confirms error register and counter updates.

Error knobs -> Virtual sequence
Virtual sequence -> Injection proxy -> DUT error path
Virtual sequence -> Predicted Error Set
DUT error path + Predicted Error Set -> Exception scoreboard
DUT error path -> Status evidence -> Exception scoreboard

Why it matters

Server, automotive, and mobile silicon must fail safely when data is corrupted.
An unhandled ECC error or poisoned packet can cause silent data corruption or a permanent system hang.
The correct outcome of a corrupted transaction may be a dropped payload plus an error flag and status-counter update, not Correct In equals Correct Out.

What is difficult

Most ordinary scoreboards assume every input should produce valid output data.
The injection path and scoreboard expectation must identify the same transaction.
A predicted exception must be consumed exactly once so a later clean transaction with the same ID is not masked.
The checker must verify both the absence of corrupted payload and the presence of required error side effects.

Failure signatures

An expected CRC or ECC rejection appears as a false data mismatch.
The DUT forwards a poisoned payload instead of dropping it.
The DUT drops the payload but fails to assert its error flag.
Error-status registers or counters do not update.
The scoreboard suppresses an unexpected later mismatch because a predicted-error entry was not deleted.
A transaction is corrupted without a matching predicted-error notification.

Compare approaches

Two viable approaches—and their cost

Transaction poisoning

Flip parity, CRC, ECC, or response bits directly in the transaction or driver path.

Strengths

Simple to add for a single agent or packet type.
Makes directed corruption easy to understand.

Costs

Couples error behavior to the driver.
Makes expected-failure coordination with the scoreboard difficult.

Error-injection callback or proxy

Keep corruption policy in a reusable layer that can notify checking before the modified transfer reaches the DUT.

Strengths

Decouples fault logic from the normal driver.
Reusable across agents and corruption types.
Provides one place to coordinate injection and expected exception state.

Costs

Requires a clean uvm_callback or proxy ownership model.
Must define deterministic ordering between notification and observed DUT response.

Explain it in an interview

Interview answer, built from the mechanism

Treat errors as first-class transactions. An injection proxy can flip ECC or CRC bits, poison an AXI response, or otherwise mangle the transfer without contaminating the normal driver.
Before the corrupted transaction reaches the DUT, notify the scoreboard with the stable transaction ID, for example, expect a failure for ID 50.
The exception scoreboard checks the expected error set, proves that the DUT asserted its error indication, confirms the payload was dropped, and verifies error-status registers or counters.
Delete the predicted-error entry after the expected exception is consumed so later traffic with a reused ID receives ordinary checking.

Assign responsibilities

Component responsibility contract

Component responsibilities and required verification changes for Negative Testing and Exception Scoreboarding
Component	Responsibility	Required change
Agent config	Error knobs	Add enable_crc_err_injection and related fault controls for the driver or proxy.
Driver or proxy	Corruption logic	Mangle parity, CRC, ECC, or response bits on the selected transfer.
Virtual sequence	Expectation notification	Send the corrupted transaction ID to checking before the DUT result arrives.
Scoreboard	Exception handling	Maintain a Predicted Error Set and prevent false data mismatches.
RAL or status monitor	Side-effect proof	Check the required error flag, status field, and counter increment.

Build the checker

Implementation patterns

Use an associative Predicted Error Setsystemverilog

// Associative-array membership is the set: key = transaction ID.
bit predicted_error_ids[int unsigned];

virtual function void write_error_notif(mac_item tr);
  predicted_error_ids[tr.id] = 1'b1;
endfunction

virtual function void check_data(mac_item act);
  if (predicted_error_ids.exists(act.id)) begin
    if (!act.error_flag)
      uvm_report_error("ERR", "DUT failed to detect injected error");

    check_payload_was_dropped(act.id);
    check_error_status_updated(act.id);
    predicted_error_ids.delete(act.id);
    return;
  end

  check_normal_data(act);
endfunction

Coordinate an injection proxy and the scoreboardtext

select transaction ID 50
notify scoreboard: predicted_error_ids includes 50
corrupt CRC, ECC, parity, or AXI response
drive corrupted transfer
observe DUT result
require: payload dropped
require: error flag asserted
require: status register or counter updated
remove ID 50 from predicted_error_ids

The virtual sequence controls both sides of the experiment: the injected fault and the expected exception contract.

Stress the design

Stress recipe

Flip CRC, parity, or ECC bits on a selected transaction and register its ID in the predicted-error set before driving it.
Poison an AXI response and prove the receiver rejects it without a permanent channel hang.
Use the source example ID 50, then immediately reuse ID 50 for a clean transaction to prove the set entry was deleted.
Check payload suppression, error_flag, error-status registers, and counter increments together.
Inject an error without a notification and a notification without an error so the environment catches both coordination failures.

Follow-up questions

Why should errors be modeled as first-class transactions?

Because corruption changes the expected result. The checker needs the fault type and stable transaction identity to distinguish correct rejection from an ordinary mismatch.

Why use a callback or proxy instead of changing every driver?

A proxy separates reusable corruption policy from normal protocol driving and gives the environment one coordination point for injection plus predicted-error notification.

What must exception scoreboarding verify?

It must prove the corrupted payload was not accepted, the required error indication occurred, architectural status or counters updated, and the predicted exception was consumed exactly once.

Engineering qualifications