Skip to content
STIMSMITH

MIPS-I Instruction Set

Concept

The MIPS-I Instruction Set is presented in the cited verification article as an example instruction set architecture (ISA) used as the design under test (DUT) for an object-oriented, constrained-random microprocessor verification methodology written in SystemVerilog. Its operations are organized into four functional classes — no operation, load and store, computational, and control — and are modeled as transaction classes with properties, constraints, and methods (including assembly display and binary packing).

First seen 5/28/2026
Last seen 6/5/2026
Evidence 8 chunks
Wiki v2

WIKI

Overview

The MIPS-I Instruction Set is used in the cited verification article as the instruction set architecture of an example processor design under test (DUT). The article describes an object-oriented constrained-random verification (CRV) methodology implemented in SystemVerilog, and uses the MIPS-I instruction set to illustrate how operations, instructions, and instruction scenarios can be modeled as transaction classes that capture ISA-level properties, constraints, and methods.

The verification model represents processor stimulus at three transaction abstraction levels: operations, instructions, and instruction scenarios. These are modeled as SystemVerilog classes so that instruction-set properties, constraints, and methods can be reused when generating program traces. A transaction object has 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

3 connections
Instruction Set Architecture (ISA) part of → 95% 2e
MIPS-I is used as the example ISA for the design under test in this verification methodology.
opcode class ← implements 92% 1e
The opcode class encodes MIPS-I specific operations and their properties.
Object-Oriented Stimulus Generation ← uses 92% 1e
The solution uses a MIPS-I processor as the example DUT.

LINKED ENTITIES

1 links
Constrained Random Verification context The cited article frames MIPS-I within a constrained-random verification methodology; CRV is the surrounding methodology.

CITATIONS

9 sources
9 citations — click to expand
[1] MIPS-I is used as the example instruction set architecture (ISA) of a design under test (DUT) for an object-oriented constrained-random verification methodology in SystemVerilog. Applying constrained-random verification to microprocessors
[2] MIPS-I is described as having four functional classes: no operation, load and store, computational, and control. Applying constrained-random verification to microprocessors
[3] Operations are modeled as SystemVerilog classes with three components — properties, constraints, and methods — and methods are used to display operations in assembly syntax and pack them into binary. Applying constrained-random verification to microprocessors
[4] The MIPS BEQ operation is defined as branching to a label when `rs == rt`, with target address `PC = PC + sext(imm)`. Applying constrained-random verification to microprocessors
[5] Branch modeling adds a `LABEL` kind, a `label_suffix` property, and `from`/`to` properties, with `label_suffix` treated as a program-trace line number (e.g., `LABEL_005` is the 5th line). Applying constrained-random verification to microprocessors
[6] An `ILLEGAL` operation kind is added to the enumerated `kind` property, and when randomized selects a random unassigned opcode value to exercise exception handling. Applying constrained-random verification to microprocessors
[7] Constraint rules cited from MIPS specifications: R1 — memory load/store in slot 0 only (else exception); R2 — ERET must be in slot 0 (else exception); R3 — ERET in slot 0 must be paired with NOP in slot 1 (else undefined); R5 — writing the same scalar register in both operations of the same instruction is disallowed (else undefined). Applying constrained-random verification to microprocessors
[8] Exception planning must cover specific causes, occurrence probability, and multiple simultaneous conditions to test priority and handling; cited exception causes include illegal opcodes, watchpoints, and misaligned data-memory accesses. Applying constrained-random verification to microprocessors
[9] Three transaction abstraction levels are used — operations, instructions, and instruction scenarios — implemented in a bottom-up manner with class-based randomization. Applying constrained-random verification to microprocessors