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:

• Properties: fields and supporting information that describe what the transaction is. For example, an ADD operation can be described by two source registers and a destination register.
• Constraints: code that describes relationships between transaction properties.
• Methods: functions and tasks that perform transaction-level actions, such as displaying an instruction in assembly syntax or packing it into a binary representation.

Transaction levels

The cited source identifies three transaction-abstraction levels used for microprocessor stimulus modeling:

1. Operations
2. Instructions
3. Instruction scenarios

These levels are modeled as classes. The approach starts with the lower-level operation classes and then builds upward toward the stimulus descriptions that verification engineers typically manipulate.

Operation and opcode modeling

For the MIPS-I example in the source, the instruction set is grouped into four functional classes:

• No operation
• Load and store
• Computational
• Control

The operation class encapsulates the operation kind, operands, and other properties. Its kind property acts as a discriminant that identifies which operation the object represents, and it is implemented as an enumerated type containing the supported opcodes defined by the instruction set architecture.

A separate random property can also describe the operation's functional class, such as load/store or control. This property is useful when constraints apply to a group of operations or when decisions must be made across operations in the same functional class.

Constraints and encoding rules

SystemVerilog constraints can encode relationships among transaction fields. In the operation model, constraints can also implement instruction-encoding rules, including rules for operations that use a function field.

However, transaction fields alone may not always describe an operation at the desired abstraction level. The source gives the MIPS branch-on-equal operation, BEQ, as an example: the immediate field is a computed program-counter offset rather than a direct high-level description of the branch target.

Branch-operation properties

To better describe branch operations, additional properties can be added to the opcode class:

• Add LABEL to the enumerated operation type kind_e.
• Add a label_suffix property.
• Add from and to properties.

Branch labels take the form LABEL_<suffix>. The label_suffix can be treated as a line number in a program trace listing, which helps ensure labels in a legal program trace are unique. For example, if a BEQ operation jumps from line 3 to line 5, the from and to properties hold values 3 and 5, and the relative program-counter offset for the encoded immediate field can be calculated from those numbers.