AMBA AXI · Module 16

Negative & Error-Injection Testing

Deliberately drive error and illegal scenarios to verify an AXI DUT's error handling — provoking SLVERR/DECERR with bad addresses and read-only writes, injecting errors from an error-capable slave model, and (carefully) probing illegal traffic — then checking the DUT responds and recovers correctly rather than hanging or corrupting state.

Constrained-random testing (16.6) deliberately stays inside the legal space. Negative and error-injection testing does the opposite: it intentionally drives the error scenarios — accesses that should return SLVERR/DECERR, slaves that fault, and (carefully) malformed traffic — to verify the DUT handles them correctly rather than hanging, corrupting state, or silently swallowing the fault. Error paths are the least-exercised and most-fragile part of any design (normal stimulus almost never triggers them), so they need deliberate provocation. This chapter shows how to provoke error responses, inject faults from an error-capable slave model, probe illegal traffic safely, and — crucially — check the recovery: that the DUT returns the right error code, stays consistent, and continues serving subsequent legal traffic.

1. Why Negative Testing Is Separate and Essential

Positive testing (random or directed) confirms the DUT does the right thing on good input. Negative testing confirms it does the right thing on bad input — a distinct, equally important question that positive testing structurally cannot answer, because legal traffic rarely produces errors. The error-handling logic (decode-error paths, SLVERR generation, recovery) is real RTL that must be exercised, and it's where bugs hide precisely because it's rarely hit.

Figure 1 — positive vs. negative testing as complementary halves. Positive testing (legal traffic) verifies correct behavior on good input and exercises the main datapath. Negative/error testing (error-provoking and illegal scenarios) verifies correct behavior on bad input and exercises the error-handling paths. Both are needed: a DUT can pass all positive tests and still hang or corrupt on the first error, because positive traffic never reaches the error logic.

2. Provoking Error Responses

The first class of negative test provokes the error responses the protocol defines — these are legal transactions that the slave is supposed to error on. Drive them deliberately and confirm the correct code comes back:

DECERR — access an unmapped address (no slave at that decode). The interconnect's default slave should return DECERR.
SLVERR — write to a read-only register, access a reserved offset, or hit a slave-defined error condition. The slave should return SLVERR and not change state.
EXOKAY / exclusive failures — attempt an exclusive access that fails its monitor; confirm OKAY (not EXOKAY) is returned to signal failure.

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

// Directed negative sequence: provoke each error response
task provoke_errors();
  axi_txn t = axi_txn::type_id::create("t");
 
  // DECERR: write to an address with no slave mapped
  start_item(t); assert(t.randomize() with { addr == UNMAPPED_ADDR; });
  finish_item(t);                       // expect BRESP == DECERR
 
  // SLVERR: write to a read-only register
  start_item(t); assert(t.randomize() with { addr == RO_REG_ADDR; });
  finish_item(t);                       // expect BRESP == SLVERR, reg unchanged
 
  // Reserved offset read
  start_item(t); assert(t.randomize() with { addr == RESERVED_ADDR; });
  finish_item(t);                       // expect RRESP == SLVERR
endtask

The scoreboard's reference model (16.4) must predict these error responses — it knows the address map, so it expects DECERR for unmapped and SLVERR for read-only — and verify the DUT both returns the right code and leaves state unchanged (a read-only write must not modify the register).

3. Error Injection from a Faulting Slave Model

The second class injects faults that don't originate from the manager's request but from the slave side — an error-capable slave model (or VIP) configured to return errors on demand, drop responses, stall indefinitely, or corrupt data, so you can verify how the manager and interconnect react. This tests the error-propagation and recovery paths the slave's own legal behavior wouldn't trigger.

Figure 2 — error injection from a configurable slave model. A normal slave returns OKAY; an error-injection slave model is configured to return SLVERR/DECERR, delay or drop responses, or corrupt data on selected transactions. This drives the manager's and interconnect's error-handling and recovery logic — how they propagate an error response, time out a missing one, or flag corruption — which the slave's normal behavior never exercises.

The injected error then propagates, and the test verifies the response and the subsequent recovery on the bus:

Injected SLVERR then recovery

10 cycles

Figure 3 — an injected SLVERR and recovery on the write channel. A normal write to a good address returns BRESP=OKAY. The next write targets an error region; the error-injection slave returns BRESP=SLVERR. The test confirms the manager receives and reports the error, then issues a following legal write that completes normally (OKAY) — proving the DUT propagated the error without hanging and recovered to serve subsequent traffic.

4. Probing Illegal Traffic — Carefully

The third, most delicate class drives protocol-illegal traffic to test a checker, an interconnect's robustness, or a slave's defensive behavior. This is the deliberate inverse of 16.6's legality constraints: temporarily relax a constraint to emit, say, a 4 KB-crossing burst or a reserved encoding. It must be done carefully and in isolation, because the result is often undefined by the spec — the goal is usually to confirm a protocol checker fires (an illegal_bins hit or assertion) or that the DUT degrades gracefully, not to assert a particular functional outcome.

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

// Illegal-traffic sequence: relax a legality constraint deliberately.
// Used to confirm a CHECKER fires, not to assert functional behavior.
class axi_illegal_seq extends axi_rand_seq;
  task body();
    axi_txn t = axi_txn::type_id::create("t");
    start_item(t);
    // Disable the 4 KB constraint for this item, force a crossing burst
    t.c_no_4k_cross.constraint_mode(0);
    assert(t.randomize() with { burst == 1;           // INCR
                                (addr % 4096) > 4000;  // near page end
                                len > 8; });           // span crosses 4 KB
    finish_item(t);   // EXPECT: protocol checker/assertion fires
  endtask
endclass

The key discipline: illegal-traffic tests verify the checker, not the DUT's functional response — since the spec doesn't define behavior for illegal input, asserting a specific functional result would be wrong. Keep them isolated so they can't pollute the legal-traffic scoreboard.

Figure 4 — the illegal-traffic testing discipline. Relax one legality constraint to emit a specific malformed transaction, in an isolated sequence. The success criterion is that a protocol checker (assertion or illegal_bins) fires — not a particular functional outcome, since the spec doesn't define one. Isolation keeps the illegal traffic out of the functional scoreboard and coverage. The finding is about the checker's completeness, not the DUT's data behavior.

5. Common Misconceptions

Myths to unlearn

"If positive tests pass, the DUT is verified." Positive tests never exercise the error paths — a DUT can pass every legal-traffic test and still hang or corrupt on the first DECERR. Error handling is real logic that needs deliberate negative testing.
"Error responses are edge cases you can skip." DECERR/SLVERR paths are common bug sites (unmapped accesses, read-only writes, faulting slaves) and are often the least tested. They're high-value, not optional.
"Returning the error code is all that matters." Equally important is that the DUT doesn't change state wrongly (a read-only write must leave the register untouched) and recovers — it must keep serving subsequent legal traffic, not hang. Negative testing checks the response and the aftermath.
"Illegal-traffic tests check the DUT's functional response." No — the spec doesn't define behavior for illegal input, so there's no correct functional result to assert. Illegal-traffic tests verify that a checker fires (or the DUT degrades gracefully), and must be isolated from the functional scoreboard.
"You can mix illegal traffic into the random regression." Illegal traffic pollutes the legal-traffic checks and coverage and can wedge the scoreboard. Keep negative/illegal tests in dedicated, isolated sequences, not the main constrained-random stream.
"The reference model doesn't need to predict errors." It must — the scoreboard has to expect DECERR for an unmapped address and SLVERR for a read-only write (and expect no state change), or it can't tell a correct error response from a bug.

6. Debugging Insight

🔍 Debugging insight — error-test failures separate 'wrong code' from 'wrong recovery'

Negative-test failures fall into clear classes:

Wrong response code (expected DECERR, got OKAY). The decode/error logic didn't recognize the bad access — an unmapped address fell through to a default that returns OKAY, or a read-only write wasn't rejected. Check the address decode and the access-type enforcement.
Correct code but state changed. The slave returned SLVERR for a read-only write but also modified the register — the error path doesn't suppress the write. The error must block the side effect, not just the response.
DUT hangs after an injected error/dropped response. The recovery path is broken — the manager waits forever for a response that won't come (no timeout), or the error wedged a state machine. This is the most serious class; check the timeout and the post-error state.
Error response but no recovery (subsequent legal traffic fails). The error left the DUT in a bad state — outstanding counters not cleared, a FIFO stuck. The follow-up legal transaction failing is the symptom; inspect the post-error internal state.
A protocol checker didn't fire on injected illegal traffic. The checker has a gap — the illegal scenario you injected isn't covered by an assertion/illegal_bins. This is a finding about the checker (16.2), valuable in itself.
Illegal traffic polluted the functional scoreboard. The negative test wasn't isolated; move it to a dedicated sequence/test.

The diagnostic split is response vs. aftermath: first confirm the right code came back, then confirm state was preserved/blocked correctly and the DUT recovered. Many error bugs pass the first check and fail the second — the code is right but the recovery or state handling is wrong.

7. Verification Insight

✅ Verification insight — provoke every error, inject from the slave side, isolate illegal traffic, and always check recovery

Negative testing completes the verification picture by deliberately exercising what positive testing structurally cannot. Four disciplines. (1) Provoke every defined error — drive DECERR (unmapped addresses), SLVERR (read-only writes, reserved offsets, slave faults), and exclusive-access failures, with the scoreboard's reference model predicting each error and confirming both the right code and no wrongful state change; an empty error-response coverage bin (16.5) is the signal that an error path is untested. (2) Inject from the slave side — use an error-capable slave model/VIP to return errors, drop/delay responses, and corrupt data on selected transactions, exercising the manager's and interconnect's error-propagation, timeout, and detection logic that the slave's normal behavior never triggers. (3) Isolate illegal traffic — drive protocol-illegal scenarios (by relaxing a legality constraint) only in dedicated sequences whose purpose is to confirm a checker fires (assertion/illegal_bins), never to assert a functional outcome the spec doesn't define, and keep them out of the functional regression so they can't pollute the scoreboard. (4) Always check recovery, not just the response — the decisive question is rarely "did the right code come back?" but "did the DUT stay consistent and keep serving traffic?" — so every negative test must follow the error with subsequent legal traffic and confirm it completes, and must check that error side effects are suppressed (read-only write changes nothing) and resources freed (outstanding counters/FIFOs cleared). The highest-value, easiest-to-miss failures are the hang-after-error (broken recovery/timeout) and state-change-despite-error (side effect not suppressed) — both pass a naive "got the error code" check and fail the aftermath check. Coverage must include the error responses, the injection scenarios, and the recovery sequences, so a closed coverage report demonstrates the error paths were genuinely exercised. Negative testing, with these disciplines, turns "the DUT works when everything goes right" into "the DUT works and fails safely when things go wrong" — the property real systems actually require, and the one positive testing alone can never establish. With assertions, monitors, scoreboards, coverage, constrained-random, and negative testing all in place, the next step packages them into the reusable UVM agent.

8. Interview Questions

9. Summary

Negative and error-injection testing deliberately exercises what positive testing structurally cannot: the DUT's behavior on bad input. It has three classes. Provoking error responses drives the protocol's defined errors — DECERR (unmapped addresses), SLVERR (read-only writes, reserved offsets, slave faults), exclusive-access failures — with the scoreboard's reference model predicting each and confirming both the right code and no wrongful state change. Slave-side error injection uses a configurable faulting slave model to return errors, drop/delay responses, or corrupt data, exercising the manager's and interconnect's error-propagation, timeout, and recovery logic. Illegal-traffic probing (relaxing a legality constraint) drives undefined scenarios in isolated sequences solely to confirm a checker fires — never to assert a functional outcome the spec doesn't define.

The decisive discipline is to check recovery, not just the response: the right error code is necessary but insufficient — the DUT must also suppress error side effects (a read-only write changes nothing), free resources (outstanding counters/FIFOs cleared), and keep serving subsequent legal traffic without hanging. The highest-severity, easiest-to-miss failures are hang-after-error (broken recovery/liveness) and state-change-despite-error (side effect not suppressed) — both pass a naive error-code check. Recovery is verified rigorously by following every error with legal traffic, checking resource accounting, using timeout watchdogs, and stressing errors under concurrency. With negative testing alongside assertions, monitors, scoreboards, coverage, and constrained-random, verification establishes not just "works when right" but "fails safely when wrong." Next, we package the whole environment into the reusable UVM AXI agent.

10. What Comes Next

You've completed the stimulus/checking toolkit; next we package it for reuse:

16.8 — UVM AXI Agent Overview (coming next) — assembling the driver, sequencer, and monitor into a reusable UVM agent, the standard packaging that bundles an interface's verification into one drop-in unit.

Previous: 16.6 — Constrained-Random AXI Traffic. Related: 6.8 — RRESP, BRESP & RLAST for the response codes provoked here, 12.3 — Decode & Address Map for the unmapped-address DECERR path, and 16.4 — AXI Scoreboards for the reference model that predicts errors.