Skip to content
STIMSMITH

instruction class

CodeArtifact WIKI v1 · 5/28/2026

The instruction class is a SystemVerilog transaction-level code artifact used in constrained-random microprocessor verification. It models an instruction using transaction properties, constraints over two opcode/operation objects, and standard methods for display and binary packing, and it participates in a hierarchy of transaction abstractions from operations to instructions to instruction scenarios.

Overview

The instruction class is a transaction-level SystemVerilog class used in constrained-random verification of microprocessors. In the described methodology, transaction abstraction is built in levels—operations, instructions, and instruction scenarios—and these levels are modeled as classes. The lower-level operation objects are created first so that higher-level stimulus descriptions can be built on top of them. [1]

Like other transaction classes in this methodology, the instruction class follows a three-part structure:

  • Properties: fields and supporting information that describe the transaction.
  • Constraints: relationships among those properties.
  • Methods: functions or tasks used to perform transaction-level actions, such as displaying assembly syntax or packing a transaction into a binary representation. [1]

Role in transaction abstraction

The instruction class sits above operation/opcode modeling and below instruction-scenario modeling. Operations encapsulate details such as operation kind, operands, and supporting properties. Instructions then constrain relationships between operation objects, while instruction scenarios define higher-level sequences of instructions for stimulus generation. [1]

Properties

The evidence describes the instruction-level constraint component as operating over “the two opcode objects,” indicating that an instruction instance contains or references two opcode/operation objects whose relationship must be constrained. [2]

The lower-level opcode/operation class provides the descriptive fields used by instruction-level constraints. For a MIPS-I example, an operation includes a kind property representing the opcode and may include additional properties for functional class grouping, branch labels, label_suffix, and branch from/to line numbers. These opcode properties allow higher-level instruction constraints and methods to reason about operation legality and encoding. [1]

Constraints

The instruction class uses SystemVerilog constraint blocks to encode processor rules relating the two opcode objects in an instruction. The cited example translates MIPS rules such as:

  • Memory load and store operations are allowed in slot 0 only; otherwise, an exception is expected.
  • Return from Exception (ERET) must be in slot 0; otherwise, an exception is expected.
  • ERET in slot 0 must be paired with NOP in slot 1; otherwise, hardware behavior is undefined.
  • Writing to the same scalar register in both operations of the same instruction is disallowed; if attempted, hardware behavior is undefined. [2]

The rules are implemented as separate constraint blocks, which lets test writers control them independently. If the relevant constraint blocks remain enabled, the listed rules are always obeyed. If a constraint block such as slot0_only_good is disabled, randomized instructions can intentionally violate the rule—for example by placing a load/store operation in slot 1—to test exception behavior. [2]

Methods

The instruction class includes methods for transaction-level behavior. The source identifies display and packing as representative class methods: a display method can present an instruction in assembly-like syntax, while a packing method can produce the binary representation. The cited implementation is described as providing standard vmm_data methods in the instruction class. [1] [2]

Relationship to vmm_data

The instruction class is associated with standard vmm_data behavior: the evidence explicitly describes an implementation of standard vmm_data methods in the instruction class. This supports modeling the instruction as a reusable transaction object with conventional transaction methods such as display and packing. [2]

LINKED ENTITIES

2 links
vmm_data EXTENDS
Transaction Abstraction PART_OF

CITATIONS

6 sources
6 citations
[1] Operations, instructions, and instruction scenarios are modeled as class-based levels of transaction abstraction. Applying constrained-random verification to microprocessors
[2] A transaction class is structured around properties, constraints, and methods. Applying constrained-random verification to microprocessors
[3] Instruction-level constraints describe relationships between two opcode objects. Applying constrained-random verification to microprocessors
[4] The instruction class example encodes rules for load/store slot placement, ERET placement and pairing, and disallowing duplicate scalar-register writes within an instruction. Applying constrained-random verification to microprocessors
[5] Separate constraint blocks allow individual processor rules to be enabled or disabled, enabling legal generation or intentional rule violation for exception testing. Applying constrained-random verification to microprocessors
[6] The instruction class implements standard vmm_data methods, including methods associated with displaying and packing instructions. Applying constrained-random verification to microprocessors