Constrained-Random Stimulus Generation

Concept

Constrained-random stimulus generation is a directed-random verification technique in which a solver automatically selects values for randomized fields of a data object subject to a set of Boolean constraints, producing legal stimuli with controlled distributions. In SystemVerilog, the technique is built on rand class members, the `constraint` keyword, the implicit `randomize()` method, and the optional `with` clause for inline constraints; in industrial practice (e.g. the AMD/Synopsys microcode generator) it is implemented as a hierarchical, knob-driven opcode generator profiled with tools such as the VCS constraint profiler.[^2119d9e0][^6fa7d584][^5204399e][^4de14aa6][^78097f25]

First seen 5/24/2026

Last seen 6/9/2026

Evidence 5 chunks

Wiki v2

WIKI

Constrained-Random Stimulus Generation

Constrained-random stimulus generation is a directed-random verification technique in which a constraint solver automatically selects values for randomized fields of a data object subject to a set of Boolean constraints, producing legal stimuli with controlled distributions. In SystemVerilog it is the central mechanism of the directed-random verification methodology, and in industrial practice (such as the AMD/Synopsys microcode work) it is realized as a hierarchical, knob-driven opcode generator.^[1]^[2]^[3]

Directed-random verification context

READ FULL ARTICLE →

NEIGHBORHOOD

3 nodes · 2 edges

graph · Constrained-Random Stimulus Generation · depth=1

RELATIONSHIPS

2 connections

Class-Based Testbench ← uses 93% 2e

Class-Based Testbench uses constrained-random stimulus generation to produce test data.

Pseudo-Random Stimulus Generation ← implements 92% 1e

Pseudo-Random Stimulus Generation implements constrained-random stimulus generation by using constraints to direct random values.

LINKED ENTITIES

2 links

Pseudo-Random Stimulus Generation IMPLEMENTS Extracted graph relationship

Class-Based Testbench USES Extracted graph relationship

CITATIONS

11 sources

11 citations — click to expand

[1] Constrained-random stimulus generation is a directed-random verification technique in which a solver selects values for randomized fields under Boolean constraints, producing legal stimuli with controlled distributions, and is the central mechanism of the directed-random verification methodology. Testbench Automation and Constraints Tutorial - Doulos

[2] Most practical verification problems involve transactions best modeled by a class that wraps a rand struct, with rand fields marked accordingly; classes also allow methods and built-in pre_randomize()/post_randomize() callbacks. Testbench Automation and Constraints Tutorial - Doulos

[3] A constraint is a Boolean expression that directs the random generator to choose values satisfying the constraint; the process is called solving and the tool is called the solver. Testbench Automation and Constraints Tutorial - Doulos

[4] Constraints are class members and may be written in the original class or in derived classes; the `inside` range-membership operator and dynamic-array `size()` can be used inside constraints; conflicting constraints cause the generator to fail. Testbench Automation and Constraints Tutorial - Doulos

[5] Testbenches call `randomize()` on class objects, optionally using the `with` clause to add inline constraints; this is equivalent to writing a new constraint in the class, and class inheritance can be used to override a default constraint in a derived class. Testbench Automation and Constraints Tutorial - Doulos

[6] Class methods can maintain invariants (e.g. clearing the payload and zeroing DLC when RTR is set) and can serialize randomized data onto a serial DUT input via a `ref` argument and a delay that models the bit period. Testbench Automation and Constraints Tutorial - Doulos

[7] The AMD/Synopsys microcode generator uses a two-layer hierarchical architecture: a SystemVerilog random sequence upper layer with weighted knobs selects the opcode category, and a lower opcode layer randomizes the chosen category with category-specific constraints; SystemVerilog constraint constructs and the VCS solver are used to improve generation speed, reduce memory, and bias generation toward corner cases. Generating AMD microcode stimuli using VCS constraint solver

[8] The single-class implementation contained approximately 100 random variables and 800 constraint equations, used random variables and implication constraints to ensure only legal opcodes were generated, and traded flexibility for a large constraint-solving problem with high memory and slow runtime. Generating AMD microcode stimuli using VCS constraint solver

[9] In the multi-class architecture, a base instruction class holds common data members, shared methods, and global constraints, while each child class adds only the constraints specific to its opcode category; implication operators based on opcode type structure each child class; splitting constraints into smaller opcode groups drastically reduced memory requirements and improved performance. Generating AMD microcode stimuli using VCS constraint solver

[10] If the test layer needs to directly control items in the lower-level sub-classes, a wrapper class must constrain all test-controlled variables, be randomized first, and then allocate and randomize the correct sub-class object in a second phase. Generating AMD microcode stimuli using VCS constraint solver

[11] The VCS constraint profiler reports runtime in three views (cumulative randomize calls, per randomize call, and per partition); the randomize call at op_gen.sv line 4308 had the largest cumulative CPU impact at 44 s across 7,104 calls, while a 3.2 s call that ran only twice was a poor optimization target; VCS partitions unrelated variables into independent subproblems and the partition profile correlates with the individual and cumulative tables. Generating AMD microcode stimuli using VCS constraint solver