object-oriented verification methodology

Object-Oriented Verification Methodology

Concept

An object-oriented verification methodology structures constrained-random stimulus generators as a hierarchy of classes — a base class containing common data members, set/print/pack methods, and shared constraints, plus child classes for each opcode category that encapsulate category-specific constraints. Test layers control generation through knobs/weights, and a wrapper class is introduced when the test layer must reach into sub-class fields. Generator performance is monitored using a constraint profiler that reports cumulative, per-call, and per-partition CPU and memory statistics.

First seen 6/4/2026

Last seen 6/4/2026

Evidence 2 chunks

Wiki v1

WIKI

Overview

In an object-oriented verification methodology, constrained-random stimulus generators are decomposed into cooperating classes that mirror the natural taxonomy of the design under test. In the context of microcode stimulus generation, opcodes are partitioned into categories, and each category is represented by a child class that derives from a common base instruction class. This approach replaces a single, monolithic generator with a hierarchy of smaller, more focused randomize problems, which simplifies both the constraint model and the profiling/optimization loop.

Multi-Class Randomization

READ FULL ARTICLE →

NEIGHBORHOOD

No graph connections found for this entity yet. It may appear in future ingestion runs.

explore full graph →

RELATIONSHIPS

1 connections

Hierarchical Constrained-Random Test Generation ← implements 92% 1e

The hierarchical constrained-random test generation uses an object-oriented approach with base and sub-classes.

LINKED ENTITIES

1 links

Hierarchical Constrained-Random Test Generation IMPLEMENTS Extracted graph relationship

CITATIONS

8 sources

8 citations — click to expand

[1] Multi-class randomization splits the opcode class into multiple smaller classes organized as categories that map to the knobs/weights in the test interface. Generating AMD microcode stimuli using VCS constraint solver

[2] A base instruction class holds the data members common to all child classes and contains the set, print, and pack methods, along with constraints common to every opcode. Generating AMD microcode stimuli using VCS constraint solver

[3] Each opcode-category child class contains constraints specific to that set of opcodes, including a set of implication operators based on the opcode type. Generating AMD microcode stimuli using VCS constraint solver

[4] The test layer is controlled by knobs only, choosing the opcode category first so the correct sub-class object can be allocated and added to the sequence, with no test-layer constraints directly controlling sub-class items. Generating AMD microcode stimuli using VCS constraint solver

[5] If the test layer must directly control lower-level items, a wrapper class is required: it is randomized first to constrain the test-controlled variables, then the correct sub-class object is allocated and randomized in a second phase. Generating AMD microcode stimuli using VCS constraint solver

[6] The VCS constraint profiler reports runtime performance in three categories: cumulative randomize calls, per randomize call, and per partition, with analogous memory statistics. Generating AMD microcode stimuli using VCS constraint solver

[7] In the profiled workload, the call with the greatest cumulative CPU impact was at op_gen.sv line 4308, executed 7,104 times and consuming 44 seconds of CPU time, while the slowest individual call took 3.2 seconds but was invoked only twice. Generating AMD microcode stimuli using VCS constraint solver

[8] VCS partitions a randomize call into multiple partitions when random variables that are not related to each other occur in the same call, so the unrelated variables can be solved independently. Generating AMD microcode stimuli using VCS constraint solver