Transaction Abstraction

Concept

Transaction abstraction models microprocessor verification stimulus at progressively higher levels—operations, instructions, and instruction scenarios—using SystemVerilog classes. Each transaction class is described by properties, constraints, and methods, and the classes are built bottom-up so lower-level operation models can support higher-level stimulus descriptions.

First seen 5/28/2026

Last seen 6/1/2026

Evidence 3 chunks

Wiki v1

WIKI

Overview

In constrained-random microprocessor verification, transaction abstraction represents stimulus using class-based models at multiple levels: operations, instructions, and instruction scenarios. These levels are implemented in a bottom-up manner because lower-level building blocks must exist before higher-level stimulus descriptions can be constructed.

A transaction is modeled as a SystemVerilog class with three major components:

READ FULL ARTICLE →

NEIGHBORHOOD

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

explore full graph →

RELATIONSHIPS

8 connections

opcode class ← part of 92% 1e

The opcode class is a key building block of the transaction abstraction hierarchy.

instruction class ← part of 92% 1e

The instruction class is a key building block of the transaction abstraction hierarchy.

common instruction scenario base class ← part of 90% 1e

The common instruction scenario base class represents the scenario level of the transaction abstraction hierarchy.

Bottom-Up Implementation ← uses 93% 1e

The bottom-up implementation builds transaction abstractions starting from lower-level building blocks.

Object-Oriented Stimulus Generation ← uses 95% 1e

Object-oriented stimulus generation models operations, instructions, and scenarios as transaction classes at multiple levels of abstraction.

opcode class ← implements 90% 1e

The opcode class is a transaction modeled as a SystemVerilog class.

instruction class ← implements 90% 1e

The instruction class is a transaction modeled as a SystemVerilog class.

Object-Oriented Verification ← uses 92% 1e

The object-oriented verification approach models stimuli using transaction abstraction.

LINKED ENTITIES

4 links

opcode class PART_OF Extracted graph relationship

instruction class PART_OF Extracted graph relationship

common instruction scenario base class PART_OF Extracted graph relationship

Bottom-Up Implementation USES Extracted graph relationship

CITATIONS

6 sources

6 citations — click to expand

[1] Transaction abstraction models operations, instructions, and instruction scenarios as classes and implements them bottom-up. Applying constrained-random verification to microprocessors

[2] A transaction class has properties, constraints, and methods; methods may display assembly syntax or pack a binary representation. Applying constrained-random verification to microprocessors

[3] The MIPS-I example groups operations into no-operation, load/store, computational, and control functional classes. Applying constrained-random verification to microprocessors

[4] The operation class encapsulates operation kind, operands, and other properties, with kind implemented as an enumerated opcode listing. Applying constrained-random verification to microprocessors

[5] A random functional-class property can support constraints or decisions applied across groups of operations. Applying constrained-random verification to microprocessors

[6] Branch operations can be modeled with LABEL, label_suffix, from, and to properties, allowing the encoded immediate offset to be calculated from source and target line numbers. Applying constrained-random verification to microprocessors