Skip to content
STIMSMITH

Constrained-Random Stimulus Generation

Technique

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.

First seen 5/28/2026
Last seen 7/6/2026
Evidence 13 chunks
Wiki v1

WIKI

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]

READ FULL ARTICLE →

NEIGHBORHOOD

1 nodes · 0 edges
graph · Constrained-Random Stimulus Generation · depth=1

RELATIONSHIPS

12 connections
Synopsys STING ← implements 95% 2e
Synopsys STING produces constrained-random system-level stimulus.
RISC-V evaluates → 95% 2e
Constrained-random stimulus generation is used to verify RISC-V core blocks.
UVM Sequence ← uses 95% 2e
UVM sequences implement constrained-random RISC-V instruction generation.
System-Level Testing ← uses 90% 2e
System-level testing uses constrained-random stimulus generation.
Corner Case Coverage implements → 93% 1e
The constrained-random approach provides biasing to hit corner cases.
hardware fuzzing ← uses 80% 1e
Traditional hardware fuzzing approaches use constrained-random stimulus generation.
riscv-dv ← implements 95% 1e
RISCV-DV is used for generating random instruction binaries for RISC-V verification.
Constraint Solver uses → 90% 1e
Constrained-random stimulus generation relies on a constraint solver to generate valid stimuli.
Coverage-Driven Verification ← uses 94% 1e
Coverage-driven verification uses constrained-random stimulus generation to exercise the DUT.
Instruction Field Distribution uses → 90% 1e
Constrained-random stimulus generation emphasizes distribution of stimuli across all meaningful values for instruction attributes.
Microcode Test Sequence uses → 90% 1e
Constrained-random stimulus generation creates microcode test sequences.
opcode distribution and biasing implements → 92% 1e
Constrained-random stimulus generation provides optimal distribution and biasing over opcodes.

CITATIONS

11 sources
11 citations — click to expand
[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