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.
Role in constrained-random processor verification
The main stimulus for the device under test is a program trace, modeled as a collection of one or more instruction scenarios. Example scenarios include:
- generic boot code with an exception handler,
- instructions that program internal configuration registers with dynamic contents,
- setup of hardware watchpoints,
- load/store, arithmetic, and branch-operation scenarios,
- nested branch loops, and
- random insertion of exception conditions inside scenarios.
This planning level helps define which scenario types are needed before lower-level randomization is implemented.
Exception planning
Exception and error conditions are called out as items that must be planned early. From the stimulus-generation perspective, planning must cover both:
- the occurrence of a specific exception cause, and
- the probability of that exception occurring.
The test plan should also allow multiple exception conditions to occur simultaneously so that exception priority and handling can be tested. These requirements can affect the modeled properties and constraints between transaction objects, which is why the planning is expected to begin early.
Effect on object-oriented stimulus design
The implementation described in the evidence models processor-verification stimulus using three transaction-abstraction levels:
- operations,
- instructions, and
- instruction scenarios.
These are implemented as SystemVerilog classes. Although the implementation is bottom-up, because lower-level building blocks must exist before higher-level stimulus descriptions can be built, top-down planning determines what those building blocks need to support.
One example is support for illegal opcodes. As a requirement derived from top-down stimulus planning, the operation class adds an ILLEGAL operation kind. When randomized to ILLEGAL, a random unassigned opcode value is used to make the operation illegal for exception testing.
Constraint implications
Top-down planning also affects constraint structure. Processor rules such as slot restrictions for memory operations or ERET, valid pairing requirements, and disallowed same-register writes can be represented as separate SystemVerilog constraint blocks. Keeping these constraints separate allows test writers to selectively disable a rule and thereby create a rule violation that should trigger an exception or exercise undefined hardware behavior, depending on the rule.
For example, disabling a constraint that restricts memory load/store operations to slot 0 can allow a load/store operation to appear in slot 1; the cited flow describes this as violating the rule and causing an exception.
Relationship to stimulus generation
Top-down stimulus planning is not itself the random generator. Instead, it defines the scenario structure, exception coverage needs, and constraint capabilities that the stimulus-generation infrastructure must implement. In this role it supports constrained-random stimulus generation by making generated program traces more likely to exercise meaningful processor behaviors.