|
Constrained-random verification (CRV) offers a highly effective way to deal with the challenges of microprocessor verification. These verification challenges are overwhelming for many reasons: complex instruction sets, multiple pipeline stages, in-order or out-of-order execution strategies, instruction parallelism, fixed- and floating-point scalar/vector operations, and other features that create a seemly never-ending list of corner cases to exercise. The time required to create traditional directed tests has become unreasonable.
Language features such as the SystemVerilog random sequence generator allow you to create instruction sequences randomly to improve stimulus quality based on a structured set of rules and scenarios. Such random-sequence generation schemes are procedural, however, and do not take full advantage of object-based randomization using constraints.
This article proposes an object-oriented solution for processor verification challenges. The solution covers both a top-down stimulus planning process and a bottom-up implementation solution using SystemVerilog and commercially available base classes (such as those in Synopsys's Verification Methodology Manual, VMM). The description that follows covers the most important parts of this solution and uses a processor supporting the MIPS-I instruction set as an example design under test (DUT).
Stimulus strategy
As with most designs, simple random stimulus is not sufficient to verify a processor fully. Pure random instructions rarely create useful stimulus for the processor to target important design functionalities such as branches/jumps and exceptions. The CRV approach provides the ability to create useful stimulus but can only do so when the stimulus-generation infrastructure is built with enough intelligence about the processor instruction set architecture and state. Top-down planning is needed to create this infrastructure.
The main stimulus for the DUT is a program trace that can be considered as a collection of one or more instruction scenarios. In Figure 1, for example, Scenario 0 can be generic boot code for the processor with an exception handler. Scenario 1 can be a set of instructions to program the processor's internal configuration registers with dynamic contents to set up hardware watchpoints. The other scenarios can consist of one or more instructions with load/store, arithmetic, and branch operations, possibly including nested branch loops. Exception conditions can be introduced at random inside these scenarios.
Click here for Fig. 1
1. Building blocks of a program trace from operations, instructions and scenarios.
Error conditions or exceptions must be planned for early. From a stimulus-generation perspective, planning for a processor's exception conditions must cover the occurrence of any one specific exception cause as well as the exception's occurrence probability. Moreover, the test plan should provide multiple exception conditions simultaneously to test the DUT's exception priority and handling. Because these considerations can affect the modeling of the properties and constraints between transaction objects, planning must begin early.
Objected-oriented stimulus design
SystemVerilog supports object-oriented-based data abstraction. Class objects contain information (properties) and actions (methods) that work on the properties. SystemVerilog's randomization is also built in an object framework. For processor verification, three levels of transaction abstraction — operations, instructions, and instruction scenarios — are modeled as classes. These classes are implemented in a bottom-up manner because it is essential to create the lower-level building blocks before you can raise the level of abstraction to stimulus descriptions (as verification engineers typically deal with stimulus).
A transaction is modeled as a SystemVerilog class with three major components:
- Properties—typically fields of a transaction and other supporting information that describe what the transaction is. For example, a transaction might be an ADD operation with two source registers, and the result is placed into a destination register.
- Constraints—code describing the relationships between properties.
- Methods—functions and tasks defining how transaction-level actions are performed. You can use a task to display a transaction in its assembly syntax (ADD R10, R3, R5), for example, and you can use a function to pack the same transaction into its binary representation (000000_00011_00101_01010_00000_100000).
Properties
The MIPS-I instruction set has four functional classes: no operation, load and store, computational and control. The operation class encapsulates the operation kind, the list of operands, and other properties. A "kind" property distinguishes the operation this object represents. It is an enumerated type that has a full listing of the supported opcodes as defined by the instruction set architecture (Figure 2).
2. Instruction set architecture.
In addition to the discriminant property "kind," it is useful to create another random property to describe the functional class of the operation, such as the load/store and control (branch/jump) classes. You can use this property when you need constraints for a group of operations or certain decisions are to be made across operations of the same functional class.
Similarly, you can use SystemVerilog constraints to implement the encoding rules for operations that make use of a function field (as some MIPS operations do). Sometimes, however, the transaction fields alone are not descriptive enough. Consider, for example, the MIPS branch-on-equal operation (BEQ): "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 nothing more than a computed program counter offset.
Properties can be added to the opcode class to build good descriptions of branch operations:
- "LABEL" 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_. You can think of the label_suffix property, an integer, as the line number in the program trace listing. For example, LABEL_005 is the 5th line in the sample program trace listing in Figure 3.
Click here for Fig. 3
3. Sampling Program Trace Listing with Line Numbers.
Using line numbers meets the requirement that labels used in a legal program trace shall be unique. With the sample program trace listing in Figure 3, the "from" and "to" properties take on the values of 3 and 5, respectively, for the BEQ operation jumps from line 3 (from=3) to line 5 (to=5), if the branch is taken in program execution. The relative program counter offset (the "imm" field of the operation encoding) can be calculated from these two integral numbers. Figure 4 shows the opcode class with the added properties.
Click here for Fig. 4
4. Additional "LABEL" kind and other operation class properties to support branches.
Today's processors support different types of exceptions to enable software to handle conditions such as illegal opcodes and watchpoints. As a requirement derived from top-down stimulus planning, the operation class supports the ability to introduce illegal opcodes. Like the LABEL kind, an operation kind called ILLEGAL is added to the enumerated property, kind. When the operation kind is randomized to ILLEGAL, a random and unassigned opcode value is then used to cause an operation to be illegal for exception testing.
Constraints
The second component of the transaction class is the constraints, which describe relationships between the properties—specifically, the two opcode objects. As an example, you need to translate processor rules such as the following MIPS specifications into SystemVerilog constraints:
- [R1] Memory load and store operations are in slot 0 only. If not, an exception is to be detected.
- [R2] Return from Exception (ERET) must be in slot 0. If not, an exception is to be detected.
- [R3] Return from Exception (ERET) is in slot 0 and must be paired with NOP in slot 1. If not, the hardware behavior is undefined.
- [R5] Writing to the same scalar register in both operations of the same instruction is disallowed. If it is attempted, the hardware behavior is undefined.
Figure 5 shows an implementation. Keep in mind that you can independently modify each SystemVerilog constraint block. For a finer resolution of control by test writers, consider implementing these rules in multiple constraint blocks.
Click here for Fig. 5
5. Constraints describing relationships between Instruction properties.
If the constraint blocks in Figure 5 are left modified, Rules 1, 2, 3 and 5 will always be obeyed. Because these rules are implemented in separate constraint blocks, they can be individually controlled, if needed. For example, if you modify (turn off) the constraint block "slot0_only_good", after a few randomize calls, the op[1].kind value will likely get randomized to one of the memory load and store operations (e.g., LW, SB, ). In this case, Rule 1 is violated and the condition causes an exception.
|
