Skip to content
STIMSMITH

Constrained-Random Stimulus Generation

Technique WIKI v1 · 5/28/2026

Constrained-random stimulus generation is a verification technique for creating randomized but legally constrained test stimuli, such as microcode instruction sequences. In the provided AMD/Synopsys example, SystemVerilog constraints and the Synopsys VCS constraint solver are used to control instruction-field distributions, bias stimulus toward corner cases, and improve performance through hierarchical, multi-class generator architecture.

Overview

Constrained-random stimulus generation creates automated random test stimuli while applying constraints that keep generated items legal and useful for verification. In the provided microprocessor verification example, random generators create microcode test sequences and emphasize distribution across meaningful opcode values and other instruction attributes, replacing a diminishing reliance on hand-written directed tests as design complexity grows. [C1]

The technique contrasts with sequential randomization of instruction fields, which the source describes as producing verbose, redundant code and offering limited control over distributions. SystemVerilog constraint constructs provide a concise way to describe possible combinations of microcode-instruction attributes and to control the distribution of values for individual fields. [C2]

Architecture

The cited generator uses a two-layer architecture. The upper layer is implemented with a SystemVerilog random sequence construct and weighted knobs that control high-level item distribution. The lower layer is an opcode class randomized with additional constraints and weights supplied by the upper layer. Tests provide weighted values that direct the generator toward the required instruction mix, and the constraint solver applies these weights to control the distribution of generated opcode types. [C3]

Single-class approach

A simple implementation style places all opcodes in one class. This is flexible because constraints can be applied between any data members in the opcode class, but it can slow randomization because the constraint solver must handle many random variables and a large, complex set of constraints. In the cited prototype, the opcode class contained about 100 random variables and 800 constraint equations. [C4]

In that single-class implementation, the class contained random variables and implication constraints to ensure legal opcodes. Opcode type was a key data member that controlled which instruction type was generated. [C5]

Hierarchical multi-class approach

To reduce the randomization problem size, the opcode class was split into multiple smaller classes. Opcodes were divided into categories that mapped to the knobs or weights used by the test interface. A base instruction class held data members common to child classes, common constraints, and shared methods for setting, printing, and packing data. Each opcode-category child class contained constraints specific to its opcode set, including implication constraints based on opcode type. [C6]

The source reports that partitioning constraints hierarchically into smaller opcode groups reduced memory requirements and increased performance. [C7]

Test-layer control and wrapper considerations

In the cited architecture, the instruction generator was controlled by knobs or switches that let test writers generate constrained stimulus. The test layer did not directly constrain subclass items; instead, the upper-layer random sequence selected the opcode category first, allowing the correct object type to be allocated and added to the sequence. [C8]

If a test layer directly controls lower-level subclass items, the source notes that decisions about which subclass to randomize must be made first. In that case, a wrapper class may be required: the wrapper constrains variables controlled by tests, is randomized first, and then the correct subclass object is allocated and randomized in a second generation phase. [C9]

Profiling and optimization

The VCS constraint profiler is used in the source to analyze generator runtime and memory. It reports runtime performance by cumulative randomize calls, per-randomize call, and per partition. This allows engineers to distinguish between randomize calls that are individually slow and those that dominate total CPU time because they are called many times. [C10]

The profiler can also show solver partitions. VCS partitions a randomize call when possible, especially when unrelated random variables occur within the same randomize call, so independent parts of the problem can be solved separately. [C11]

Role in verification

Within the evidence, constrained-random stimulus generation is positioned as a way to cover stimulus space efficiently, control opcode and instruction-attribute distributions, and bias generation toward corner cases. Its effectiveness depends not only on constraints themselves but also on generator architecture: a single class maximizes cross-field flexibility, while hierarchical multi-class partitioning can reduce solver problem size and improve memory and runtime behavior. [C1] [C4] [C6] [C7]

LINKED ENTITIES

3 links
Constraint Solver USES
Instruction Field Distribution USES
Microcode Test Sequence USES

CITATIONS

11 sources
11 citations
[1] Automated random test generators create microcode test sequences and emphasize distribution across meaningful opcode and instruction-attribute values as directed tests become less dominant for complex microprocessor verification. Generating AMD microcode stimuli using VCS constraint solver
[2] Sequential randomization of instruction fields is described as verbose and redundant with limited distribution control, while SystemVerilog constraints provide concise descriptions of legal attribute combinations and control per-field value distributions. Generating AMD microcode stimuli using VCS constraint solver
[3] The cited generator has an upper random-sequence layer with weighted knobs and a lower opcode-class layer randomized with constraints and weights; the constraint solver applies weights to control opcode-type distribution. Generating AMD microcode stimuli using VCS constraint solver
[4] A single opcode class is flexible because constraints can span any data members, but may randomize slowly when the solver sees many random variables and complex constraints; the cited class had about 100 random variables and 800 constraint equations. Generating AMD microcode stimuli using VCS constraint solver
[5] The single-class implementation used random variables and implication constraints to ensure legal opcodes, with opcode type controlling which instruction type was generated. Generating AMD microcode stimuli using VCS constraint solver
[6] The multi-class approach reduces randomization problem size by splitting opcodes into categories mapped to test-interface knobs or weights, using a base instruction class for common members and constraints and child classes for category-specific constraints. Generating AMD microcode stimuli using VCS constraint solver
[7] Hierarchically partitioning constraints into smaller opcode groups reduced memory requirements and increased performance in the cited approach. Generating AMD microcode stimuli using VCS constraint solver
[8] The instruction generator was controlled by knobs or switches; the test layer did not directly constrain subclass items, and the upper-layer random sequence selected opcode category first so the correct object type could be allocated. Generating AMD microcode stimuli using VCS constraint solver
[9] When the test layer directly controls lower-level subclass items, subclass-selection decisions must be made first; a wrapper class may be randomized first, followed by allocation and randomization of the correct subclass object. Generating AMD microcode stimuli using VCS constraint solver
[10] The VCS constraint profiler analyzes generator runtime and memory and reports runtime by cumulative randomize calls, per-randomize call, and per partition. Generating AMD microcode stimuli using VCS constraint solver
[11] VCS can partition a randomize call when unrelated random variables occur in the same call, allowing independent variables to be solved separately. Generating AMD microcode stimuli using VCS constraint solver