Skip to content
STIMSMITH

Constraint-Based Randomization

Technique WIKI v1 · 5/28/2026

Constraint-Based Randomization is an object-oriented stimulus-generation technique used in constrained-random processor verification. Instead of relying on purely procedural random sequence generation, it models operations, instructions, and instruction scenarios as SystemVerilog classes whose random properties are governed by constraints. This lets verification environments generate random but useful instruction streams, control exception and legality rules, and make branch scenarios more likely to exercise taken, not-taken, and loop-exit behavior.

Overview

Constraint-Based Randomization is a stimulus-generation technique in which transaction objects expose random properties and use constraints to describe legal, illegal, or otherwise interesting relationships among those properties. In the cited microprocessor-verification flow, it is presented as part of a constrained-random verification approach that uses object-based randomization with constraints rather than relying only on procedural random sequence generation.

The technique is especially useful for processor verification because pure random instructions rarely form useful program traces. Important behaviors such as branches, jumps, exceptions, memory alignment cases, and instruction-pairing rules often require knowledge of the processor instruction set architecture and state.

Object model

The described implementation models three levels of transaction abstraction as SystemVerilog classes:

  • Operations
  • Instructions
  • Instruction scenarios

These classes are built bottom-up: lower-level operations are created before higher-level instruction and scenario descriptions. A transaction class has three main parts:

  1. Properties — fields and supporting information that describe the transaction, such as opcode kind, operands, source registers, destination registers, labels, or branch metadata.
  2. Constraints — rules that describe relationships between properties.
  3. Methods — functions or tasks that act on the transaction, such as displaying an instruction in assembly syntax or packing it into binary form.

Constraint use cases

Constraints encode processor rules and stimulus intent. Examples from the evidence include:

  • Restricting memory load/store operations to slot 0.
  • Requiring Return from Exception (ERET) to be in slot 0.
  • Pairing ERET in slot 0 with NOP in slot 1.
  • Disallowing writes to the same scalar register in both operations of the same instruction.
  • Enforcing memory-alignment rules for load/store accesses.

A useful implementation pattern is to place rules in separate constraint blocks. When constraint blocks are enabled, generated transactions obey the rules. When a block is disabled, the randomizer can intentionally create rule violations, such as putting a load/store operation in the wrong slot or generating misaligned memory accesses, to test exception behavior.

Branch scenario generation

Branches are a major motivation for constraint-based stimulus. With purely random register values, a forward branch condition such as equality is unlikely to be true, while a backward branch may create an excessively long or effectively endless loop. Constraint-based scenarios can shape the instruction sequence around the branch to make behavior useful.

Forward branches

For a forward branch, the evidence describes increasing the taken probability by initializing the compared registers just before the branch. One example uses an ADDI instruction to assign R1 = R2 + {-2:2}. This makes R1 == R2 occur with a stated probability of 20%. In constraint terms, the operation before the forward branch is constrained to be an ADDI using the same operands and a small immediate value.

Backward branches

Backward branches can be treated as loop scenarios. The evidence describes constraining the operation before a backward branch to be an ADDI with the same operands and a small negative value, then incrementing the loop-index operand by 1 inside the loop just before the branch. The compared registers must not be modified elsewhere inside the loop. This produces loops ranging from immediate fall-through to several iterations while avoiding absurdly long loops.

Relationship to random sequence generation

SystemVerilog random sequence generation can create random instruction sequences from structured rules and scenarios, but the cited source characterizes such schemes as procedural. Constraint-Based Randomization differs by using object-based randomization: properties are part of class objects, and constraints declare relationships that the randomizer solves when creating transactions and scenarios.

Scenario-level control

At the scenario level, instruction objects can be stored in dynamic arrays, and SystemVerilog foreach array constraints can express relationships across the list. The evidence identifies three useful scenario styles:

  • Constrained-random scenarios, such as constraining all operations in a long sequence to the computational kind.
  • Directed-random scenarios, such as preloading memory with special arithmetic values and then generating arithmetic streams that consume them.
  • Directed scenarios, such as loading a pre-assembled program trace from a file.

A scenario generator can select from a set of scenario objects, randomize one, and repeat until a user-specified stopping condition is reached.

Practical role

Constraint-Based Randomization provides a way to make random stimulus both variable and meaningful. It can generate legal instruction streams, selectively generate illegal or exceptional cases, and focus stimulus on hard-to-hit behaviors such as branch taken/not-taken outcomes, nested loops, exception priority, and boundary conditions.

CITATIONS

8 sources
8 citations
[1] Constraint-Based Randomization is used in CRV as object-based randomization with constraints, contrasting with procedural random sequence generation. Applying Constrained-Random Verification to Microprocessors
[2] Processor verification needs more than pure random instructions because important behaviors such as branches, jumps, and exceptions require planned, ISA-aware stimulus. Applying Constrained-Random Verification to Microprocessors
[3] Operations, instructions, and instruction scenarios are modeled as SystemVerilog classes with properties, constraints, and methods. Applying Constrained-Random Verification to Microprocessors
[4] Constraints can encode processor rules such as slot restrictions, ERET/NOP pairing, scalar-register write restrictions, and exception-triggering violations. Applying Constrained-Random Verification to Microprocessors
[5] Common instruction scenario base classes can implement relationships between instruction objects as constraints and can allow constraints such as memory alignment to be disabled for exception testing. Applying Constrained-Random Verification to Microprocessors
[6] Forward branch probability can be increased by constraining the instruction before the branch to initialize compared operands using ADDI with a small immediate value. Applying Constrained-Random Verification to Microprocessors
[7] Backward branch loops can be controlled by constraining setup and loop-index update operations and preventing other loop instructions from modifying the compared registers. Applying Constrained-Random Verification to Microprocessors
[8] Scenario-level stimulus can use dynamic arrays of instruction objects and SystemVerilog foreach array constraints, with constrained-random, directed-random, and directed scenarios supported by a scenario generator. Applying Constrained-Random Verification to Microprocessors