Skip to content
STIMSMITH

object-oriented verification

Concept

In the provided sources, object-oriented verification refers to using object-oriented structure in verification workflows. The clearest example is SystemVerilog-based constrained-random stimulus generation built from base classes, subclasses, and layered control of constraints and weights; the supplied public context also shows the term used for verifiers of object-oriented programs such as Gobra, KeY, and Dafny.

First seen 5/28/2026
Last seen 5/31/2026
Evidence 4 chunks
Wiki v2

WIKI

Overview

In the provided evidence, object-oriented verification refers to applying object-oriented structuring to verification tasks. In the hardware-stimulus example, SystemVerilog classes are used to describe instructions and their constraints, with a base class holding common behavior and derived classes specializing groups of related opcodes. The cited article says that partitioning constraints hierarchically into smaller opcode groups reduced memory requirements and improved performance. [C1]

Role in constrained-random stimulus generation

READ FULL ARTICLE →

NEIGHBORHOOD

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

explore full graph →

RELATIONSHIPS

4 connections
SystemVerilog uses → 97% 2e
The object-oriented verification solution is implemented using SystemVerilog.
Multi-Class Randomization ← uses 2e
Multi-class randomization uses object-oriented verification by organizing opcodes into a class hierarchy.
Verification Methodology Manual (VMM) uses → 95% 1e
The object-oriented verification solution uses VMM base classes from Synopsys.
Hierarchical Constrained-Random Test Generation ← implements 1e
Hierarchical constrained-random test generation implements object-oriented verification principles through class hierarchies.

LINKED ENTITIES

2 links
Hierarchical Constrained-Random Test Generation IMPLEMENTS Extracted graph relationship
Multi-Class Randomization USES Extracted graph relationship

CITATIONS

7 sources
7 citations — click to expand
[1] C1: In the hardware example, object-oriented verification uses a SystemVerilog base class with global constraints and derived classes for related opcode groups; hierarchical partitioning reduced memory requirements and increased performance. Generating AMD microcode stimuli using VCS constraint solver
[2] C2: The generator architecture has an upper SystemVerilog random sequence with weighted knobs and a lower opcode class randomized with additional constraints and weights from the upper layer. Generating AMD microcode stimuli using VCS constraint solver
[3] C3: Multi-class randomization splits the opcode class into smaller classes; a base instruction class holds common data, constraints, and methods, while child classes add opcode-category-specific constraints. Generating AMD microcode stimuli using VCS constraint solver
[4] C4: Single-class randomization is flexible but can be slow because the solver faces many variables and constraints; the cited opcode class had about 100 random variables and 800 constraint equations. Generating AMD microcode stimuli using VCS constraint solver
[5] C5: If tests do not directly constrain subclass items, the upper layer can choose the opcode category first and allocate the correct subclass; otherwise a wrapper class would likely be randomized first and the subclass allocated in a second phase. Generating AMD microcode stimuli using VCS constraint solver
[6] C6: The VCS constraint profiler reports cumulative, per-randomize, and per-partition performance, and the solver can partition unrelated variables so they are solved independently. Generating AMD microcode stimuli using VCS constraint solver
[7] C7: In program-verification research, Gobra, KeY, and Dafny were reported to be vulnerable to proving false through a combination of ghost-variable declaration and non-terminating code, suggesting possible unsoundness in object-oriented verifiers. Proving False in Object-Oriented Verification Programs by Exploiting Non-Termination