Skip to content
STIMSMITH

opcode class

CodeArtifact

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.

First seen 5/28/2026
Last seen 6/1/2026
Evidence 4 chunks
Wiki v1

WIKI

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

READ FULL ARTICLE →

NEIGHBORHOOD

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

explore full graph →

RELATIONSHIPS

10 connections
instruction class ← uses 88% 2e
The instruction class builds on and uses the opcode class as a building block.
MIPS-I Instruction Set implements → 92% 1e
The opcode class encodes MIPS-I specific operations and their properties.
Illegal Opcode Injection implements → 95% 1e
The opcode class supports an ILLEGAL kind to inject illegal opcodes for exception testing.
opcode::psdisplay() ← part of 97% 1e
psdisplay() is a method belonging to the opcode class for displaying instructions.
opcode::byte_pack() ← part of 97% 1e
byte_pack() is a method belonging to the opcode class for packing instructions into binary.
Transaction Abstraction part of → 92% 1e
The opcode class is a key building block of the transaction abstraction hierarchy.
MIPS-I Instruction Set Architecture implements → 93% 1e
The opcode class encapsulates operation kinds from the MIPS-I instruction set.
Transaction Abstraction implements → 90% 1e
The opcode class is a transaction modeled as a SystemVerilog class.
Instruction Set Architecture (ISA) implements → 93% 1e
The opcode class encapsulates operation kinds as defined by the ISA.
Exception Handling Verification implements → 88% 1e
The opcode class supports illegal opcode generation for exception testing.

LINKED ENTITIES

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

CITATIONS

8 sources
8 citations — click to expand
[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