Skip to content
STIMSMITH

Exception Handling in Processor Verification

Concept WIKI v1 · 5/28/2026

Exception handling in processor verification is planned stimulus and checking for processor exception causes such as illegal opcodes, watchpoints, misaligned memory accesses, and instruction-slot rule violations. In constrained-random verification, exception conditions should be planned early, modeled in transaction properties and constraints, and injected through instruction scenarios with controlled occurrence probabilities and combinations.

Overview

In constrained-random processor verification, exception handling refers to planning and generating instruction streams that exercise the processor hardware's exception behavior. Pure random instruction streams are usually insufficient for this purpose because they rarely create useful stimulus for important functions such as branches, jumps, and exceptions. A constrained-random verification infrastructure therefore needs knowledge of the processor instruction-set architecture and state, and it should be driven by top-down stimulus planning. [C1]

A program trace can be modeled as a collection of one or more instruction scenarios. For example, one scenario may provide boot code with an exception handler, another may program internal configuration registers for hardware watchpoints, and later scenarios may contain load/store, arithmetic, and branch operations. Exception conditions can be introduced randomly inside these scenarios. [C2]

Planning exception stimulus

Exception conditions should be planned early in the verification strategy. From the stimulus-generation perspective, the plan should cover both which exception cause occurs and the probability that it occurs. The test plan should also allow multiple exception conditions at the same time so that the design under test can be checked for exception priority and handling behavior. These requirements can affect how transaction properties and constraints are modeled. [C3]

Modeling with constrained-random transactions

A processor-verification stimulus model can use several abstraction levels: operations, instructions, and instruction scenarios. SystemVerilog object-oriented classes can represent these transactions with properties, constraints, and methods. Constraints describe legal relationships between transaction properties, while test writers can selectively disable some constraints to create exception-producing cases. [C4]

Examples of processor rules that can be encoded as constraints include:

  • Memory load and store operations must be in slot 0; otherwise, an exception is to be detected.
  • Return from Exception (ERET) must be in slot 0; otherwise, an exception is to be detected.
  • ERET in slot 0 must be paired with NOP in slot 1; otherwise, hardware behavior is undefined.
  • Writing to the same scalar register in both operations of the same instruction is disallowed; if attempted, hardware behavior is undefined. [C5]

Because such rules can be implemented in separate constraint blocks, they can be independently controlled. For instance, disabling a constraint that requires load/store operations to appear only in slot 0 can allow randomization to place a load/store operation in slot 1, violating the rule and causing an exception condition. [C6]

Illegal opcode injection

Illegal opcode testing can be built into the operation model. As part of top-down stimulus planning, the operation class can support an ILLEGAL operation kind. When randomized to ILLEGAL, the generator uses a random unassigned opcode value so that the operation is illegal and can trigger exception testing. [C7]

Memory-alignment exceptions

Some instruction sequences may be legal program traces but still trigger defined processor behavior at the hardware level. For example, unaligned load/store accesses to data memory trigger an exception. The memory-alignment rule can be encoded as a constraint in a common instruction-scenario base class. For exception planning, that constraint can be disabled so that misaligned memory addresses are generated randomly with memory load and store operations. [C8]

Role of instruction scenarios

A common instruction-scenario base class can encapsulate reusable methods and constraints shared by user-defined scenarios. This is useful because verification must include both legal instruction sequences and sequences that software tools might not generate but that the hardware must still handle correctly. By controlling constraints at the scenario level, the verification environment can generate random but targeted exception cases instead of relying on pure random programs. [C9]

LINKED ENTITIES

4 links
Illegal Opcode Injection USES
Memory Alignment Constraint USES
Instruction Scenario MENTIONS
Top-Down Stimulus Planning USES

CITATIONS

9 sources
9 citations
[1] Pure random instruction streams are insufficient for fully verifying processor functions such as branches, jumps, and exceptions; constrained-random infrastructure needs ISA and state knowledge guided by top-down planning. Applying constrained-random verification to microprocessors
[2] A program trace can be modeled as instruction scenarios, including boot code with an exception handler, watchpoint setup, and scenarios where exception conditions are introduced randomly. Applying constrained-random verification to microprocessors
[3] Exception planning should cover specific causes, occurrence probabilities, and simultaneous exception conditions to test exception priority and handling. Applying constrained-random verification to microprocessors
[4] Processor-verification transactions can be modeled as operation, instruction, and instruction-scenario classes with constraints that describe relationships between properties. Applying constrained-random verification to microprocessors
[5] Example constrained rules include load/store and ERET slot requirements, ERET pairing with NOP, and disallowing same-register writes in both operations of an instruction. Applying constrained-random verification to microprocessors
[6] Separate constraint blocks can be disabled to violate rules intentionally, such as allowing a load/store operation in slot 1 to cause an exception. Applying constrained-random verification to microprocessors
[7] Illegal opcode injection can be modeled with an ILLEGAL operation kind that selects a random unassigned opcode value for exception testing. Applying constrained-random verification to microprocessors
[8] Unaligned load/store accesses trigger exceptions, and memory-alignment constraints can be disabled so misaligned addresses are generated for exception testing. Applying constrained-random verification to microprocessors
[9] A common instruction-scenario base class can encapsulate reusable methods and constraints, supporting targeted random exception cases beyond pure random instruction generation. Applying constrained-random verification to microprocessors