Skip to content
STIMSMITH

Program Trace

Concept

In the cited microprocessor constrained-random verification approach, a program trace is the main stimulus for the design under test. It is defined as a collection of one or more instruction scenarios and is used to organize more useful, processor-aware stimulus than pure random instruction streams typically provide.

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

WIKI

Definition

In the cited constrained-random verification (CRV) approach for microprocessors, a program trace is the main stimulus for the design under test (DUT). The source describes it as a collection of one or more instruction scenarios, with program traces built from operations, instructions, and scenarios.

Purpose in verification

READ FULL ARTICLE →

NEIGHBORHOOD

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

explore full graph →

RELATIONSHIPS

7 connections
Instruction Scenario ← part of 98% 4e
A program trace is composed of one or more instruction scenarios.
Constrained-Random Verification (CRV) ← uses 95% 1e
CRV generates program traces as the main stimulus for the processor design under test.
Design Under Test (DUT) ← uses 95% 1e
The program trace is the main stimulus applied to the DUT.
Constrained-Random Verification (CRV) ← uses 93% 1e
CRV uses the program trace as the main stimulus for the DUT.
Instruction Scenario Generation ← uses 90% 1e
Instruction scenario generation builds program traces as collections of instruction scenarios.
Top-Down Stimulus Planning ← uses 90% 1e
Top-down stimulus planning produces program traces as the main stimulus.
Directed Stimulus ← uses 92% 1e
Directed stimulus involves loading a pre-assembled program trace from a file.

CITATIONS

8 sources
8 citations — click to expand
[1] Program trace is the main stimulus for the DUT and is a collection of one or more instruction scenarios. Applying constrained-random verification to microprocessors
[2] Pure random instructions rarely create useful stimulus for branches, jumps, and exceptions, motivating structured program traces. Applying constrained-random verification to microprocessors
[3] Example contents of a program trace include boot code, configuration-register programming, mixed load/store-arithmetic-branch instruction groups, nested branch loops, and randomly introduced exception conditions. Applying constrained-random verification to microprocessors
[4] A sample program trace contains a forward BEQ branch and a backward BNE branch, showing why unconstrained random register values are ineffective. Applying constrained-random verification to microprocessors
[5] Forward branch scenarios can be improved by constraining the preceding operation to be an ADDI with the same operands and a small immediate value. Applying constrained-random verification to microprocessors
[6] Backward branch scenarios can be constrained as loop scenarios by using a preceding ADDI with a small negative value, incrementing the loop index inside the loop, and preventing other loop instructions from modifying the compared registers. Applying constrained-random verification to microprocessors
[7] Exception planning should cover both occurrence and probability of specific exception causes and include simultaneous exception conditions to test priority and handling. Applying constrained-random verification to microprocessors
[8] A directed scenario can be loaded from a file containing a pre-assembled program trace for directed stimulus. Applying constrained-random verification to microprocessors