Bottom-Up Implementation

Concept

Bottom-Up Implementation is an object-oriented constrained-random verification approach in which lower-level transaction building blocks are implemented before higher-level stimulus descriptions. In the cited microprocessor-verification flow, SystemVerilog classes model operations, instructions, and instruction scenarios, and the implementation proceeds bottom-up so stimulus generation can be built on well-defined transaction abstractions.

First seen 5/28/2026

Last seen 5/28/2026

Evidence 2 chunks

Wiki v1

WIKI

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

READ FULL ARTICLE →

NEIGHBORHOOD

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

explore full graph →

RELATIONSHIPS

2 connections

Stimulus Generation ← uses 93% 2e

Stimulus generation is implemented bottom-up, starting from low-level transaction building blocks.

Transaction Abstraction uses → 93% 1e

The bottom-up implementation builds transaction abstractions starting from lower-level building blocks.

LINKED ENTITIES

2 links

Stimulus Generation USES Extracted graph relationship

Transaction Abstraction USES Extracted graph relationship

CITATIONS

6 sources

6 citations — click to expand

[1] Bottom-Up Implementation is used in an object-oriented constrained-random microprocessor-verification solution alongside top-down stimulus planning. Applying constrained-random verification to microprocessors

[2] Operations, instructions, and instruction scenarios are modeled as SystemVerilog classes and implemented bottom-up because lower-level building blocks are needed before raising abstraction to stimulus descriptions. Applying constrained-random verification to microprocessors

[3] A transaction class contains properties, constraints, and methods; examples include assembly display and binary packing methods for an ADD operation. Applying constrained-random verification to microprocessors

[4] Simple random stimulus is insufficient for full processor verification because it rarely targets important functionality such as branches, jumps, and exceptions; useful stimulus generation needs processor ISA and state knowledge. Applying constrained-random verification to microprocessors

[5] A processor program trace can be considered a collection of one or more instruction scenarios, including boot code, configuration-register programming, load/store and arithmetic instructions, branch operations, nested loops, and random exception conditions. Applying constrained-random verification to microprocessors

[6] In the MIPS-I example, operation modeling includes operation kind, operands, functional class properties, and additional branch properties such as LABEL, label_suffix, from, and to for representing branch behavior and computing offsets. Applying constrained-random verification to microprocessors