Skip to content
STIMSMITH

opcode class

CodeArtifact WIKI v1 · 5/28/2026

The opcode class is a SystemVerilog constrained-random verification model for individual processor operations/opcodes. In the cited MIPS-I-oriented example, it captures opcode kind, operands, functional class metadata, branch-label metadata, illegal-opcode generation support, cross-opcode constraints, and utility methods such as display and binary packing.

Overview

The opcode class models a processor operation/opcode as a SystemVerilog transaction building block in a constrained-random microprocessor verification environment. The evidence describes transaction classes as having three major components: properties, constraints, and methods. At the operation level, the class encapsulates the operation kind, operand list, and other operation-specific properties. [C1]

Instruction-set role

For the MIPS-I example, the instruction set is grouped into four functional classes: no operation, load/store, computational, and control. The kind property distinguishes which operation an object represents and is an enumerated type containing the supported opcodes defined by the instruction set architecture. [C2]

A separate random property can describe the functional class of an operation, such as load/store or control. This allows constraints and decisions to be written for groups of operations rather than only for individual opcodes. [C3]

Branch support properties

The class can be extended with additional properties to describe branches more directly than raw instruction fields alone. For branch-oriented modeling, the evidence adds:

  • LABEL to the enumerated operation type kind_e;
  • a label_suffix property;
  • from and to properties. [C4]

Branch labels are described as taking a LABEL_ form, with label_suffix used like a line number in a program trace. The from and to properties identify the source and destination trace lines of a branch, and the relative program-counter offset used in the encoded immediate field can be calculated from those two integer values. [C4]

Illegal opcode generation

The class also supports exception-oriented stimulus by adding an ILLEGAL operation kind. When the randomized operation kind is ILLEGAL, the model selects a random unassigned opcode value so that the generated operation is illegal and can be used for exception testing. [C5]

Constraints involving opcode objects

At the instruction-transaction level, constraints describe relationships between properties, including relationships between two opcode objects. The cited MIPS rules include slot-placement and pairing requirements such as load/store operations being allowed only in slot 0, ERET being required in slot 0, ERET in slot 0 being paired with NOP in slot 1, and disallowing writes to the same scalar register by both operations of one instruction. [C6]

The evidence notes that these rules can be implemented as separate constraint blocks so they can be controlled independently. For example, turning off a slot-0-only constraint can allow a memory load/store operation to appear in slot 1, violating the rule and causing an exception condition. [C7]

Methods

The class includes methods for transaction-level actions. The evidence names opcode::psdisplay() and opcode::byte_pack() as examples: one displays an instruction in assembly-style syntax, while the other packs the operation or instruction into its binary representation. [C8]

Related artifacts

  • opcode::psdisplay() is a display method associated with the opcode class. [C8]
  • opcode::byte_pack() is a packing method associated with the opcode class. [C8]
  • The class participates in a transaction-abstraction hierarchy where operations, instructions, and instruction scenarios are modeled as classes. [C1]

LINKED ENTITIES

6 links
Instruction Set Architecture (ISA) IMPLEMENTS
MIPS-I Instruction Set IMPLEMENTS
Illegal Opcode Injection IMPLEMENTS
opcode::psdisplay() PART_OF
opcode::byte_pack() PART_OF
Transaction Abstraction PART_OF

CITATIONS

8 sources
8 citations
[1] C1: Transaction classes are modeled with properties, constraints, and methods; operations, instructions, and instruction scenarios are modeled as classes, and the operation class encapsulates kind, operands, and other properties. Applying constrained-random verification to microprocessors
[2] C2: In the MIPS-I example, the instruction set has four functional classes, and the operation kind is an enumerated property listing supported opcodes defined by the ISA. Applying constrained-random verification to microprocessors
[3] C3: A random functional-class property can be added for grouping operations such as load/store and control operations for constraints or decisions. Applying constrained-random verification to microprocessors
[4] C4: Branch support adds LABEL to kind_e plus label_suffix, from, and to properties; labels use line-number-like suffixes and the branch immediate offset can be calculated from from/to values. Applying constrained-random verification to microprocessors
[5] C5: Illegal opcode testing is supported by adding an ILLEGAL operation kind that causes a random unassigned opcode value to be used. Applying constrained-random verification to microprocessors
[6] C6: Instruction constraints describe relationships between two opcode objects and implement MIPS rules such as slot restrictions, ERET/NOP pairing, and disallowed duplicate scalar-register writes. Applying constrained-random verification to microprocessors
[7] C7: Separate constraint blocks can be independently controlled; disabling slot0_only_good can allow a load/store operation in slot 1 and cause an exception. Applying constrained-random verification to microprocessors
[8] C8: opcode::psdisplay() and opcode::byte_pack() are cited as opcode-class method examples for displaying and packing an instruction. Applying constrained-random verification to microprocessors