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:

1. Properties — fields that describe the transaction (for example, the two source registers and one destination register of an ADD operation).
2. Constraints — code that describes relationships between properties.
3. Methods — functions and tasks defining how transaction-level actions are performed. A task can be used to display a transaction in its assembly syntax (for example, ADD R10, R3, R5), and a function can be used to pack the same transaction into its binary representation (for example, 000000_00011_00101_01010_00000_100000).

Functional classes

The cited source states that the MIPS-I instruction set has four functional classes:

• No operation
• Load and store
• Computational
• Control

In the object-oriented stimulus model, an operation class encapsulates the operation kind, the list of operands, and other properties. The kind property is an enumerated type that contains a full listing of the supported opcodes defined by the instruction set architecture. A separate random property is also defined to describe the operation's functional class (for example, the load/store and control/branch classes), so that constraints can be applied to a group of operations or decisions can be made across operations of the same functional class.

Encoding and methods

SystemVerilog constraints can be used to implement the encoding rules for operations that use a function field, which the article notes some MIPS operations do. As an example of the methods layer, the article references two opcode-class methods — opcode::psdisplay() and opcode::byte_pack() — for displaying and packing an instruction, respectively. The standard vmm_data methods are implemented in the Instruction class.

Branch modeling (BEQ)

The article uses the MIPS branch-on-equal (BEQ) operation as an example of why raw instruction fields may not be descriptive enough for stimulus generation. BEQ is defined as: "If the contents of general register rs and rt are equal, the branch is taken and the program execution jumps to a branch label; the jump address is computed to the program counter (PC) calculated as the current PC plus a sign-extended immediate value, or PC = PC + sext(imm)." The imm field is described as nothing more than a computed program counter offset.

To make branches easier to describe, the model adds the following to the opcode class:

• A LABEL value is added to the enumerated operation type kind_e.
• A label_suffix property is added to the opcode class.
• from and to properties are added.

Each branch label takes the form LABEL_<suffix>. The label_suffix is an integer that can be treated as the line number in a program-trace listing (for example, LABEL_005 is the 5th line in the sample program-trace listing). Using line numbers meets the requirement that labels used in a legal program trace shall be unique. Given a sample program trace, the from and to properties take the values 3 and 5 for a BEQ that branches from line 3 to line 5 when the branch is taken. The relative program-counter offset (the imm field of the operation encoding) can then be calculated from these two integers.

Exception-oriented stimulus

The article emphasizes that exception behavior must be planned early in processor verification. From a stimulus-generation perspective, planning for a processor's exception conditions must cover the occurrence of any specific exception cause, the probability of its occurrence, and the ability to apply multiple exception conditions simultaneously to test the DUT's exception priority and handling. Exception causes discussed in the source include illegal opcodes and watchpoints, as well as misaligned load/store accesses to data memory, which are legal program traces that nevertheless trigger well-defined processor behaviors that need to be verified at the hardware level.

For opcode-related exception testing, an ILLEGAL operation kind is added to the enumerated kind property. When the operation kind is randomized to ILLEGAL, a random and unassigned opcode value is used to make the operation illegal for exception testing.

Instruction-level constraints in the cited model

The cited model expresses processor rules as SystemVerilog constraints over the two opcode objects inside an instruction transaction. Example rules translated from the MIPS specification include:

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

These rules are implemented in separate SystemVerilog constraint blocks so that each can be independently modified or turned off by the test writer. For example, disabling the slot0_only_good block allows op[1].kind to be randomized to a memory load or store operation (for example, LW, SB), which violates Rule 1 and exercises the corresponding exception path. (The cited article's rule numbering jumps from R3 to R5, consistent with the source text.)

Scope of this article

The above material is drawn from a single verification-engineering article that uses a MIPS-I processor as its DUT and is presented here as it appears in that source. These rules and properties are presented as examples of how MIPS-I semantics are translated into a constrained-random verification model, rather than as a complete or standalone specification of the MIPS-I architecture.