Skip to content
STIMSMITH

Exception Handling Verification

Concept WIKI v1 · 6/1/2026

Exception handling verification is the part of constrained-random microprocessor verification that plans, generates, and controls exception-causing conditions so the design under test can be checked for exception detection, priority, and handling behavior. In the cited methodology, this includes early stimulus planning for specific exception causes and their probabilities, support in the opcode/operation model for illegal instructions, and selectively enabled or disabled constraints to generate cases such as misaligned memory accesses or illegal slot placement of operations.

Overview

Exception handling verification is treated as an explicit part of constrained-random microprocessor verification rather than as an accidental by-product of random instruction generation. The cited methodology says exception conditions must be planned early, because the verification model must cover both individual exception causes and their occurrence probabilities, and it should also generate multiple exception conditions at the same time to test exception priority and handling.

Why it is needed

Pure random instruction streams are described as insufficient for processors, because they rarely create useful stimulus for important behaviors such as branches, jumps, and exceptions. Instead, the stimulus infrastructure is built with knowledge of the processor ISA and state so exception-related cases can be created deliberately but still randomized.

How exception cases are modeled

Opcode and operation modeling

The operation class is extended to support exception testing directly:

  • An ILLEGAL operation kind is added.
  • When randomized to ILLEGAL, the model uses a random unassigned opcode value to create an illegal instruction for exception testing.

The same source also notes that processors support exception types for conditions such as illegal opcodes and watchpoints.

Constraint-based exception generation

Processor rules are encoded as independent constraint blocks so test writers can selectively keep or disable them. The cited MIPS-oriented examples include:

  • Memory load/store operations must be in slot 0; otherwise an exception is to be detected.
  • 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 behavior is undefined.
  • Writing the same scalar register in both operations of the same instruction is disallowed; if attempted, behavior is undefined.

Because the rules are separated into multiple constraint blocks, a test can intentionally disable one rule to generate exception-producing cases. The article gives the example of disabling the slot0_only_good constraint so that a load/store operation may appear in slot 1, violating the rule and causing an exception.

Scenario-level exception injection

At the scenario level, exception conditions can be introduced randomly inside larger program traces. The source gives examples such as:

  • Boot code that includes an exception handler.
  • Scenarios that configure hardware watchpoints.
  • Randomly inserted exception conditions inside arithmetic, load/store, and branch scenarios.

A specific example is memory alignment. Load/store accesses to unaligned data memory addresses trigger an exception, so the common instruction scenario base class can normally enforce alignment with constraints and then deliberately turn that constraint off to inject misaligned accesses at random times.

Verification focus

From the cited methodology, exception handling verification is concerned with at least four things:

  1. Generating a specific exception cause.
  2. Controlling how often that cause appears.
  3. Generating multiple exception conditions together to test priority.
  4. Verifying the processor's handling behavior once the exception occurs.

Practical boundary

The source distinguishes exception-triggering cases from cases whose hardware behavior is undefined. That distinction matters when building reusable constraints: some rules are intentionally violated to provoke defined exceptions, while other violations are identified as undefined behavior and therefore represent a different verification category.

LINKED ENTITIES

2 links
Microprocessor Verification PART_OF
opcode class IMPLEMENTS

CITATIONS

8 sources
8 citations
[1] Exception conditions must be planned early, covering specific causes, occurrence probability, and simultaneous exceptions to test exception priority and handling. Applying Constrained-Random Verification to Microprocessors
[2] Pure random instructions rarely create useful stimulus for important processor behaviors such as exceptions, so constrained-random infrastructure with ISA/state knowledge is needed. Applying Constrained-Random Verification to Microprocessors
[3] Program traces can include an exception handler and can introduce exception conditions randomly inside instruction scenarios. Applying Constrained-Random Verification to Microprocessors
[4] The operation/opcode class supports exception testing by adding an ILLEGAL kind that uses a random unassigned opcode value to create an illegal instruction. Applying Constrained-Random Verification to Microprocessors
[5] Constraint rules can model exception-producing conditions, including load/store not in slot 0 and ERET not in slot 0. Applying Constrained-Random Verification to Microprocessors
[6] Constraint blocks are independently controllable; disabling the slot-0 rule can randomize load/store operations into slot 1 and cause an exception. Applying Constrained-Random Verification to Microprocessors
[7] Misaligned load/store accesses trigger an exception, and alignment constraints can be turned off in the scenario base class to inject such cases randomly. Applying Constrained-Random Verification to Microprocessors
[8] Some modeled rule violations are explicitly described as undefined behavior rather than exceptions, including ERET pairing and dual writes to the same scalar register in one instruction. Applying Constrained-Random Verification to Microprocessors