Skip to content
STIMSMITH

Single-Class Randomization

Technique WIKI v1 · 5/26/2026

Single-Class Randomization is a constrained-random verification technique in which one instruction or opcode class contains the random variables and constraints for all supported opcodes. It provides high modeling flexibility and direct constraint interactions across fields, but can become slow and memory-intensive when the instruction space is large because the constraint solver must handle many variables and a large constraint set in one randomization problem.

Overview

Single-Class Randomization is a constrained-random instruction-generation style in which a single class contains all opcodes and their associated constraints. In the AMD/Synopsys microcode stimulus generator described in the evidence, the initial prototype used one class with constraints for all opcodes, relying on SystemVerilog constraint constructs to describe legal instruction attribute combinations and control value distributions. [C1]

Architecture

In the documented generator architecture, tests provided weighted values that directed the required mix of instructions. These weights were applied through the generator layer to control the distribution of opcode types. The lower layer consisted of an opcode class randomized with additional constraints and weights from the upper layer. [C2]

Within the single-class approach, the opcode class contained the random variables and implication constraints needed to ensure that only legal opcodes were generated. The opcode type was a key data member because it controlled which type of instruction was generated. [C3]

Technical Characteristics

The main advantage of the single-class style is flexibility: because all opcode data members are in the same class, constraints can be applied between any of them. This makes it straightforward to express relationships across instruction fields. [C4]

The main drawback is solver complexity. In the documented implementation, the single opcode class contained approximately 100 random variables and 800 constraint equations. Presenting this large, complex problem to the constraint solver could make randomization slow. [C4]

Relationship to Sequential Randomization

The single-class constrained-random prototype was introduced after traditional sequential field randomization methods, which were described as producing verbose, redundant code and offering limited control over distributions. The single-class constrained-random design overcame those sequential-randomization flaws by using SystemVerilog constraints to describe combinations and distributions more directly. [C1]

Performance Implications

Although the single-class constrained-random approach improved distribution control relative to sequential generation, the evidence reports that a simple constrained-random approach reached speed and memory limits for complex x86 instruction generation, reducing simulation performance. [C5]

The performance comparison in the evidence shows that a later multiple-class architecture was faster than the single-class architecture with both tested solvers: the default RACE solver showed a 4x speedup, and the BDD solver showed a 2x speedup. The memory requirements were also significantly better for the multiple-class architecture in the BDD measurements. [C6]

The stated reason for the acceleration and memory reduction was that the newer multiple-class implementation exposed a smaller set of variables and constraints to the solver. The evidence reports that the new implementation had 7x fewer constraints than the original single-class implementation, allowing solutions to be calculated more efficiently. [C7]

When It Fits

Single-Class Randomization is most suitable when maximum cross-field constraint flexibility is important and the size of the randomized problem remains manageable. It becomes less attractive when the instruction set or opcode space creates a very large constraint problem, because solver runtime and memory use can become limiting factors. [C4][C5]

Contrast With Multiple-Class Randomization

The documented alternative was to split the opcode class into multiple smaller classes by opcode category. A base instruction class held data members and constraints common to all opcodes, while each child class held constraints specific to a category. This reduced the size of each randomization problem and improved speed and memory without sacrificing distribution or test-level control. [C8]

CITATIONS

8 sources
8 citations
[1] C1: The initial constrained-random microcode generator used a single class containing constraints for all opcodes, and SystemVerilog constraint constructs were used to describe instruction attribute combinations and value distributions; this addressed flaws of sequential randomization. Generating AMD microcode stimuli using VCS constraint solver
[2] C2: The generator architecture used an upper layer with weighted knobs and a lower opcode class randomized with additional constraints and weights to control opcode-type distribution. Generating AMD microcode stimuli using VCS constraint solver
[3] C3: The single-class implementation used random variables and implication constraints to generate legal opcodes, with opcode type as a key data member controlling instruction type. Generating AMD microcode stimuli using VCS constraint solver
[4] C4: Single-class randomization is flexible because constraints can be applied between any opcode-class data members, but may be slow because the solver sees many random variables and complex constraints; the documented class had about 100 random variables and 800 constraint equations. Generating AMD microcode stimuli using VCS constraint solver
[5] C5: A simple constrained-random approach solved distribution issues but reached speed and memory limits for the complex x86 instruction set, reducing simulation performance. Generating AMD microcode stimuli using VCS constraint solver
[6] C6: In the reported comparison, the multiple-class architecture was faster than the single-class architecture with both solvers; RACE showed a 4x speedup and BDD showed a 2x speedup, and BDD memory requirements were significantly better for the multiple-class architecture. Generating AMD microcode stimuli using VCS constraint solver
[7] C7: The performance and memory improvement of the newer implementation was attributed to a smaller set of variables and constraints; it had 7x fewer constraints than the original implementation. Generating AMD microcode stimuli using VCS constraint solver
[8] C8: The multiple-class alternative split opcodes into categories, used a base class for common data and constraints, placed category-specific constraints in child classes, and simplified the solver problem by first choosing the opcode category. Generating AMD microcode stimuli using VCS constraint solver