Error injection in verification

In short: Error injection in verification is the deliberate forcing of illegal values, protocol violations and fault conditions into a DUT so you can prove its error-detection, reporting and recovery logic actually works — the paths that normal constrained-random stimulus almost never reaches.

Most of a verification plan is spent proving the design does the right thing when the inputs are legal. But silicon fails in the field precisely on the paths that legal stimulus never touches: an ECC double-bit flip, a dropped handshake, a CRC mismatch, a timeout, an X propagating through a FIFO. Error injection (sometimes called fault injection or negative testing) is the discipline of forcing those conditions on purpose and checking that the DUT detects, flags and recovers from them. If you only verify the happy path, your error-handling RTL ships untested — and it is almost always the buggiest code in the design because nobody exercises it.

Why happy-path stimulus never finds these bugs

A constrained-random environment generates legal transactions by construction. A good AXI generator will never emit a write that violates burst boundaries, because the constraint solver forbids it. That is exactly the problem: the recovery FSM that is supposed to respond to a protocol violation sees zero stimulus for its entire regression. Coverage looks green because the functional covergroups were written around legal behaviour. You need a separate, intentional mechanism to break the rules.

Rule of thumb: on a typical SoC block, error-handling logic is 15–25% of the RTL but attracts under 5% of random-generated activity. Error injection is how you close that gap.

The three places you can inject

Errors enter a verification environment at one of three levels, each with a different tool and blast radius:

Stimulus-level is the cleanest and most reusable. You add an error_kind field to the transaction and a knob in the sequence so the driver emits a malformed packet — a bad CRC, an out-of-range opcode, a truncated burst. This is the UVM-idiomatic approach and it keeps the error inside the normal transaction/scoreboard flow so the checker can predict the expected error response.

Signal-level uses SystemVerilog force/release (or a VPI/`uvm_hdl_force` call) to override an internal net regardless of what the RTL drives it to. This is how you simulate a stuck-at fault, a glitch, or a parity bit flipping on a bus the testbench cannot otherwise reach. It is powerful but fragile: a force on a hierarchical path breaks the moment someone renames a module, so quarantine these into a small, well-commented injector class.

Model-level injection corrupts a reference model or a memory backdoor — the classic example being an ECC verification where you flip one or two bits in the RAM model and confirm the controller corrects the single-bit error and flags the double-bit error as uncorrectable.

A worked example: ECC double-bit detection

Consider a SECDED (single-error-correct, double-error-detect) memory controller. The negative test plan must hit four cases: no error, single-bit (corrected, no flag), double-bit (detected, uncorrectable interrupt raised), and — the one teams forget — an error on the check bits themselves. The animation below shows a single bit flipping in a stored word and the syndrome logic reacting.

The scoreboard here does not just check data integrity — it predicts the control-plane response: which status register bit sets, whether the interrupt fires, and how many cycles the correction takes. A frequent silicon escape is a controller that corrects the data correctly but forgets to log the corrected-error counter, so field diagnostics are blind.

Negative testing vs. error injection

The terms overlap but are not identical. Negative testing feeds illegal inputs at the interface and checks the response (reject, NAK, clamp). Error injection is broader — it includes internal faults the interface cannot create, such as an SEU (single-event upset) flipping a state-machine register mid-flight. Both share one golden rule: an injected error must have a predicted, checked outcome. Injecting faults without a checker that knows what should happen is just noise that inflates your toggle coverage.

Tool support

All three big simulators handle stimulus- and signal-level injection natively through SystemVerilog and UVM. Synopsys VCS and Cadence Xcelium both expose uvm_hdl_force/uvm_hdl_deposit for backdoor pokes and ship X-propagation modes (VCS Xprop, Xcelium xprop) that let you prove the DUT does not launder an X into a clean logic value. For systematic fault campaigns — flipping every flop one at a time and measuring whether a safety mechanism catches it — functional-safety flows such as Synopsys Z01X and Siemens Questa fault simulation automate the injection and compute diagnostic coverage for ISO 26262 metrics. Build the manual UVM hooks first; reach for the fault simulator when you need a certified coverage number.

For ISO 26262 ASIL-D, you may need to demonstrate >99% single-point-fault diagnostic coverage. That number comes from an automated fault-injection campaign, not from hand-written tests — but hand-written error tests prove the recovery logic is correct in the first place.

Building it cleanly in UVM

Keep error injection out of your driver's main path. The maintainable pattern is an error_kind enum in the sequence item, a corruption step in the driver guarded by that enum, and a mirror flag in the scoreboard so the predictor expects the error response. Drive the mix through sequences — a good_seq for the bulk of regression and dedicated err_* sequences that raise each fault — and add covergroups on error_kind so you can prove every negative case was actually exercised. This layering ties directly into a well-built constrained-random verification environment, and the predictor discipline is the same one you use for scoreboard architecture. If you want hands-on labs that wire this together end to end, our verification courses walk through a complete error-injection testbench.

Ready to build error-injection testbenches that catch the bugs happy-path stimulus never will? The CourseTron Functional Verification track takes you from UVM fundamentals to full negative-test campaigns — explore the curriculum. For custom IP verification services, our design partner Avecas design services runs industrial-grade fault campaigns.

Frequently asked questions

Is error injection the same as fault injection?

Largely yes in day-to-day use. "Fault injection" is the term of art in functional-safety (ISO 26262) work, where you systematically flip registers to measure diagnostic coverage. "Error injection" and "negative testing" are the general verification terms. All three mean forcing abnormal conditions and checking the response.

Should injected errors count toward functional coverage?

Yes — add covergroups on the error-kind field and on the DUT's error-status signals. If you cannot point to a covergroup bin showing each fault was hit, you have not actually verified the error path, no matter how many tests you wrote.

When should I use force instead of an illegal transaction?

Use an illegal transaction whenever the fault can be created from the interface, because it stays inside the normal transaction/scoreboard flow. Reserve force/release for internal faults the interface cannot reach — stuck-at nodes, parity flips on internal buses, or injected X values.

Do I still need a fault simulator if I write manual error tests?

For a certified ASIL coverage number, yes — a tool like Z01X or Questa fault sim exhaustively flips flops and computes diagnostic coverage. Manual tests prove the recovery logic is functionally correct; the fault simulator proves the safety mechanism's coverage is high enough.