Overview

The BDD Solver is a constraint-solving mode described in the context of VCS constrained-random stimulus generation. In this mode, the solver elaborates the entire solution space of a randomize call before selecting a solution. This up-front solution-space elaboration can take significant time and memory, but the solution space is cached to accelerate later randomization calls of the same form.

Performance characteristics

The BDD Solver is most attractive when:

• the randomization problem does not require excessive memory;
• the same randomize call occurs many times; and
• the verification architecture can benefit from reusing the cached solution space.

The cited AMD microcode-stimulus generation study identifies CPU opcode generation as a case where repeated randomization calls are common and where the BDD Solver can work well if memory use remains manageable.

Relationship to solution-space elaboration

BDD solving depends directly on solution-space elaboration: the solver builds the complete solution space for a randomize call before choosing a result. This makes memory profiling especially important, because elaborating the full space can require large amounts of memory before any individual solution is selected.

Comparison with the RACE Solver

In the AMD x86 opcode-generation study, runtime was compared across two testbench architectures and two solvers: the default RACE Solver and the BDD Solver. A multiple-class architecture, which reduced the active variables and constraints for each opcode category, improved runtime with both solvers. The reported speedup was about 4x with the default RACE Solver and about 2x with the BDD Solver.

Memory measurements in the study focused on the BDD Solver because RACE memory consumption was described as typically smaller and not a limiting factor. The multiple-class architecture also reduced memory requirements for BDD solving.

Design implications

For workloads using the BDD Solver, the key design lever is reducing the size of each randomization problem. In the opcode-generation case, randomizing instructions by first selecting an opcode category reduced the set of relevant variables and constraints. The study reports that the revised implementation had 7x fewer constraints than the original, enabling more efficient solution calculation and reducing both runtime and memory pressure.

Practical guidance from the evidence:

1. Use constraint profiling to identify high-cost randomize calls and memory-heavy partitions.
2. Keep each BDD-randomized problem small enough that full solution-space elaboration is practical.
3. Prefer architectures that repeatedly invoke the same manageable randomize call, so cached solution spaces can be reused.
4. Reduce inactive or irrelevant constraints, for example by partitioning generation by opcode category.