Skip to content
STIMSMITH

Synopsys VCS Constraint Solver

Tool WIKI v1 · 5/25/2026

Synopsys VCS Constraint Solver is described in the provided evidence as a SystemVerilog constrained-random solving technology used to generate AMD x86 microcode stimuli with controllable distributions, profiling support, and alternative solver behavior such as default RACE and BDD modes.

Overview

The Synopsys VCS Constraint Solver was used in an AMD/Synopsys case study to generate microcode test sequences for x86 instruction verification. The approach used SystemVerilog constraint-language constructs to describe legal combinations of opcode attributes and to control value distributions for individual fields. The motivation was to replace sequential field randomization, which the authors reported produced verbose code, redundant code, and limited distribution control. [C1]

Generator architecture

The described opcode generator used two layers. The upper layer used a SystemVerilog random sequence construct with weighted knobs to control high-level distribution. The lower layer randomized an opcode class with additional constraints and weights supplied by the upper layer. Test inputs consisted of weighted values that directed the generator toward the required instruction mix, and the constraint solver applied those weights to control opcode-type distribution. [C2]

Single-class and multi-class constraint models

The initial generator prototype used a single class containing constraints for all opcodes. This coding style was flexible because constraints could be applied between any data members in the opcode class, but it also presented the solver with many random variables and a large constraint set. In the reported implementation, the opcode class had approximately 100 random variables and 800 constraint equations. [C3]

To reduce randomization problem size, the authors then used an object-oriented hierarchy with a base class for global opcode constraints and subclasses for groups of related opcodes with similar constraints. Partitioning constraints into smaller opcode groups reduced memory requirements and improved performance. [C4]

Solver behavior and profiling

The evidence distinguishes the default RACE solver from the BDD solver. For the BDD solver, the solver elaborates the entire solution space of a randomize call before choosing a solution. This can require significant memory and elaboration time, but the computed solution space is cached to accelerate subsequent randomization calls. The authors reported that BDD works well for architectures where the randomization problem does not consume excessive memory and the same randomize call is repeated many times, such as CPU opcode generation. [C5]

VCS profiling data was used to inspect randomize CPU runtime and memory usage. The VCS 2009.12 release also provided a testcase extraction feature that could automatically extract the slowest partition from each randomize call. [C6]

Reported performance characteristics

In the reported comparison, the multi-class architecture ran faster than the single-class architecture with both solvers and for both tested opcodes. The default RACE solver showed a 4x speedup, while the BDD solver showed a 2x speedup. Memory requirements were also reported to be significantly better for the multi-class architecture; memory results were measured for BDD because RACE memory consumption was typically smaller and not the limiting factor. [C7]

The authors attributed the runtime and memory improvements mainly to reducing the number of variables and constraints in the randomized problem. Their profile data showed that the new implementation had 7x fewer constraints than the original, allowing the solver to compute solutions more efficiently. [C8]

Practical implication

The case study concludes that serial randomization met speed and memory goals but caused distribution problems, while a simple constrained-random approach improved distribution but became too slow and memory-intensive for the complex x86 instruction set. Randomizing instructions by first choosing the opcode category simplified the solver problem because only category-specific constraints were present, improving memory and speed while preserving distribution and test-level control. [C9]

CITATIONS

9 sources
9 citations
[1] C1: The Synopsys VCS Constraint Solver was used for constrained-random AMD x86 microcode stimulus generation with SystemVerilog constraints and distribution control, addressing limitations of sequential randomization. Generating AMD microcode stimuli using VCS constraint solver
[2] C2: The generator architecture used an upper SystemVerilog random sequence layer with weighted knobs and a lower opcode-class randomization layer, with tests supplying weighted values for instruction mix control. Generating AMD microcode stimuli using VCS constraint solver
[3] C3: The single-class opcode model was flexible but could be slow because it presented the solver with many random variables and constraints; the reported class had about 100 random variables and 800 constraint equations. Generating AMD microcode stimuli using VCS constraint solver
[4] C4: The multi-class architecture used a base class for global constraints and subclasses for related opcode groups, reducing memory requirements and improving performance by partitioning constraints hierarchically. Generating AMD microcode stimuli using VCS constraint solver
[5] C5: In BDD mode, the solver elaborates the entire solution space before selecting a solution, can consume significant memory and time, caches the solution space, and is useful when repeated randomize calls occur and memory is not excessive. Generating AMD microcode stimuli using VCS constraint solver
[6] C6: VCS provided constraint profile data for runtime and memory, and VCS 2009.12 included testcase extraction to automatically extract the slowest partition from each randomize call. Generating AMD microcode stimuli using VCS constraint solver
[7] C7: The multi-class architecture was faster than the single-class architecture for both solvers and tested opcodes, with a 4x speedup for default RACE and 2x for BDD; BDD memory use was significantly improved and RACE memory was typically smaller. Generating AMD microcode stimuli using VCS constraint solver
[8] C8: The reported acceleration and memory reduction were mainly due to a smaller set of variables and constraints; the new implementation had 7x fewer constraints than the original. Generating AMD microcode stimuli using VCS constraint solver
[9] C9: The article concludes that choosing an opcode category before randomizing simplified the constraint problem and improved memory and speed without sacrificing distribution or test-level control. Generating AMD microcode stimuli using VCS constraint solver