Skip to content
STIMSMITH

Top-Down Stimulus Planning

Concept

Top-down stimulus planning is an early processor-verification activity used to define the intelligence needed in constrained-random stimulus generation. It identifies useful program-trace scenarios, plans exception and error conditions, and influences the properties and constraints modeled in transaction objects such as operations, instructions, and instruction scenarios.

First seen 5/28/2026
Last seen 5/31/2026
Evidence 4 chunks
Wiki v1

WIKI

Overview

Top-down stimulus planning is a planning approach for constrained-random processor verification. It is used before or alongside implementation of the stimulus infrastructure to determine what kinds of instruction scenarios, processor states, and exception conditions must be represented so that random stimulus is useful rather than merely syntactically random.

In the cited microprocessor-verification flow, simple random instructions are described as insufficient because they rarely target important processor functionality such as branches, jumps, and exceptions. Constrained-random verification can create more useful stimulus, but only when the stimulus-generation infrastructure contains enough knowledge of the processor instruction set architecture and state. Top-down planning is identified as the activity needed to create that infrastructure.

READ FULL ARTICLE →

NEIGHBORHOOD

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

explore full graph →

RELATIONSHIPS

4 connections
Top-down stimulus planning includes planning for exception conditions early in the stimulus strategy.
Stimulus Generation ← uses 95% 1e
Top-down stimulus planning is needed to guide the stimulus generation process.
Exception handling verification is planned for early as a requirement from top-down stimulus planning.
Constrained-Random Verification (CRV) ← uses 93% 1e
CRV requires top-down stimulus planning to build the stimulus-generation infrastructure.

CITATIONS

6 sources
6 citations — click to expand
[1] Simple random instructions are insufficient for full processor verification because they rarely target important functionality such as branches, jumps, and exceptions; constrained-random stimulus requires infrastructure with processor ISA and state knowledge, and top-down planning is needed to create that infrastructure. Applying constrained-random verification to microprocessors
[2] A processor program trace can be considered a collection of instruction scenarios, including boot code with an exception handler, configuration-register programming, watchpoint setup, load/store, arithmetic, branch operations, nested branch loops, and randomly inserted exception conditions. Applying constrained-random verification to microprocessors
[3] Exception planning should begin early and should cover specific exception causes, exception occurrence probability, and simultaneous exception conditions to test exception priority and handling. Applying constrained-random verification to microprocessors
[4] The object-oriented stimulus design models processor-verification transactions at three levels: operations, instructions, and instruction scenarios, implemented as SystemVerilog classes. Applying constrained-random verification to microprocessors
[5] A requirement derived from top-down stimulus planning is support for illegal opcodes: the operation class adds an ILLEGAL kind, and when randomized to ILLEGAL it uses a random unassigned opcode value for exception testing. Applying constrained-random verification to microprocessors
[6] Processor rules can be implemented as independently controllable SystemVerilog constraint blocks, allowing test writers to disable a specific rule and create violations such as a load/store operation in the wrong slot, which causes an exception. Applying constrained-random verification to microprocessors