Skip to content
STIMSMITH

Object-Oriented Constraint Partitioning

Technique WIKI v1 · 5/25/2026

Object-Oriented Constraint Partitioning is a constrained-random verification technique that splits a large single-class constraint problem into a base class plus opcode-category subclasses. In the AMD/Synopsys microcode stimulus generator example, this hierarchy reduced memory requirements and improved performance while preserving weighted control over generated instruction distributions.

Overview

Object-Oriented Constraint Partitioning is a technique for structuring constrained-random generators by moving global constraints into a base class and placing category-specific constraints into derived subclasses. In the AMD/Synopsys microcode stimulus generator example, the original generator used one opcode class containing constraints for all opcodes; the later object-oriented version used a base instruction class plus child classes for groups of related opcodes. This hierarchical partitioning reduced the size of each randomization problem, drastically reduced memory requirements, and increased performance.

Motivation

A single-class constrained-random generator is flexible because constraints can be applied across any data members in the class. However, the evidence describes a single opcode class with approximately 100 random variables and 800 constraint equations, which made the randomization problem large and potentially slow for the constraint solver.

The partitioned approach addresses this by splitting the opcode class into multiple smaller classes. Opcode categories were chosen to map well to the knobs or weights exposed through the test interface, allowing tests to continue controlling high-level instruction distributions while reducing the complexity of each solve.

Architecture

The referenced generator used two layers:

  1. Upper layer: a SystemVerilog random sequence with weighted knobs controlling the distribution of high-level items.
  2. Lower layer: an opcode class or subclass randomized with additional constraints and weights supplied by the upper layer.

In the object-oriented partitioned design:

  • A base instruction class contains data members common to all child classes.
  • The base class also contains common methods, such as methods used to set, print, and pack data.
  • Data members and constraints that apply to every opcode are placed in the base class.
  • Each opcode-category subclass contains constraints specific to that opcode group.
  • Each subclass can retain the same general implication-constraint style as the original single-class generator, but only for its own opcode category.

Randomization flow

The upper-layer random sequence chooses an opcode category first using knobs or weights. Once the category is known, the generator can allocate the correct subclass object and randomize that smaller object. This design works cleanly when tests control only high-level knobs and do not directly constrain fields inside lower-level subclasses.

If test-layer constraints directly control lower-level subclass fields, the evidence notes that subclass selection decisions must be made before randomizing the subclass. In that situation, a wrapper class may be required. The wrapper class constrains the variables controlled by the tests, is randomized first, and then the correct subclass object is allocated and randomized in a second generation phase.

Relationship to solver-level partitioning

The evidence also describes Synopsys VCS constraint solver profiling. VCS can partition a randomize call into independent partitions when unrelated random variables appear in the same randomize call. This solver-level partitioning allows unrelated variables to be solved independently and can be analyzed using profiler views such as cumulative randomize calls, per-randomize-call data, and per-partition data.

Object-Oriented Constraint Partitioning is complementary to this solver behavior: it reduces the problem size at the generator architecture level, while the solver may further partition unrelated variables within a randomize call.

Benefits

Reported benefits in the evidence include:

  • smaller randomization problems by splitting one large opcode class into multiple category-specific classes;
  • reduced memory requirements through hierarchical partitioning;
  • increased performance compared with the large single-class formulation;
  • continued use of weighted knobs to control opcode-category distributions; and
  • better profiling visibility through VCS constraint profiler reports for runtime and memory.

Implementation considerations

Use this technique when a constrained-random class has grown into a large monolithic solve problem with many random variables and constraints. A practical implementation pattern is:

  1. Identify fields, methods, and constraints common to all generated items.
  2. Move those shared members into a base class.
  3. Divide generated items into categories aligned with test-level knobs or weights.
  4. Implement one subclass per category, containing only category-specific constraints.
  5. Randomize the category first, allocate the matching subclass, and then randomize the subclass object.
  6. If tests directly constrain subclass internals, introduce a wrapper randomization phase to choose the subclass consistently before solving subclass-specific constraints.

LINKED ENTITIES

1 links
Synopsys VCS Constraint Solver used_with

CITATIONS

7 sources
7 citations
[1] The technique uses an object-oriented hierarchy with a base class for global opcode constraints and subclasses for groups of related opcodes. Generating AMD microcode stimuli using VCS constraint solver
[2] Hierarchical partitioning of constraints into smaller opcode groups reduced memory requirements and increased performance. Generating AMD microcode stimuli using VCS constraint solver
[3] The original single-class opcode generator had approximately 100 random variables and 800 constraint equations, making the solver problem large and potentially slow. Generating AMD microcode stimuli using VCS constraint solver
[4] The generator architecture used an upper SystemVerilog random sequence layer with weighted knobs and a lower opcode class layer randomized with constraints and weights. Generating AMD microcode stimuli using VCS constraint solver
[5] In the multi-class design, opcode categories mapped to test-interface knobs or weights, the base class held common data and methods, and each child class held opcode-category-specific constraints. Generating AMD microcode stimuli using VCS constraint solver
[6] When tests directly control lower-level subclass items, the evidence recommends making subclass-selection decisions first, potentially by randomizing a wrapper class before allocating and randomizing the subclass. Generating AMD microcode stimuli using VCS constraint solver
[7] The VCS constraint profiler reports runtime performance by cumulative randomize calls, per-randomize call, and per partition, and VCS can partition unrelated random variables within a randomize call for independent solving. Generating AMD microcode stimuli using VCS constraint solver