Definition

Bottom-Up Implementation is an implementation strategy for object-oriented constrained-random verification in which low-level transaction abstractions are created before higher-level stimulus descriptions. In the referenced microprocessor-verification approach, three transaction-abstraction levels—operations, instructions, and instruction scenarios—are modeled as SystemVerilog classes and implemented bottom-up because the lower-level building blocks must exist before the abstraction level can be raised to stimulus descriptions.

Verification context

The approach appears as part of a constrained-random verification strategy for microprocessors. The cited flow combines:

• Top-down stimulus planning, used to define useful processor stimulus and exception scenarios.
• Bottom-up implementation, used to build the SystemVerilog class infrastructure that represents transaction abstractions.

This is motivated by the limits of simple random instruction generation: pure random instructions are unlikely to adequately target processor features such as branches, jumps, and exceptions. A useful stimulus-generation infrastructure therefore needs knowledge of the processor instruction set architecture and state.

Transaction-abstraction layers

The implementation builds upward through transaction abstractions:

1. Operations — low-level operation objects, such as an ADD operation or a branch operation.
2. Instructions — higher-level instruction objects built from operation-level concepts.
3. Instruction scenarios — sequences or scenario-level objects that describe larger stimulus structures.

A generated processor program trace can be treated as a collection of one or more instruction scenarios. Example scenarios include boot code with an exception handler, instructions that program internal configuration registers, and instruction groups containing load/store, arithmetic, branch operations, nested branch loops, or randomly introduced exception conditions.

SystemVerilog transaction structure

In this methodology, a transaction is modeled as a SystemVerilog class with three main components:

• Properties — fields and supporting information describing the transaction, such as an ADD operation with source registers and a destination register.
• Constraints — relationships between the properties.
• Methods — functions or tasks that perform transaction-level actions, such as displaying assembly syntax or packing a transaction into binary representation.

For a MIPS-I example, the operation class can encapsulate the operation kind, operands, and other properties. A discriminant kind property identifies the represented operation, and an additional random property can describe the functional class, such as load/store or control. These properties support constraints and decisions across groups of related operations.

Why bottom-up matters

Bottom-up implementation is important because higher-level stimulus descriptions depend on lower-level transaction objects. For example, branch operations may require additional descriptive properties beyond raw encoding fields. In the cited MIPS-I branch-on-equal example, branch behavior can be represented by adding label-related and control-flow properties such as LABEL, label_suffix, from, and to; the immediate offset can then be calculated from these values. This kind of lower-level modeling enables more meaningful higher-level stimulus generation.