Overview
The common instruction scenario base class is a reusable base class for processor verification scenarios. It exists because pure random instruction streams are unlikely to form useful processor programs, so user-defined scenarios need shared methods and constraints that make random instruction sequences legal, interesting, and controllable. In the cited constrained-random verification approach, operations, instructions, and instruction scenarios are modeled as classes as part of a bottom-up transaction-abstraction hierarchy.[C1]
Role in instruction-scenario modeling
The base class is intended to hold behavior common to user-defined instruction scenarios. Evidence explicitly identifies it as the place to encapsulate useful shared methods and to implement relationships between instruction objects as constraints.[C2]
A scenario is described as a list of instruction objects, commonly represented as a dynamic array. SystemVerilog array constraints, especially foreach, are used to express constraints across the items in the scenario.[C5]
Responsibilities
Shared constraints across instructions
The base class can define constraints that relate multiple instruction objects rather than only constraining a single instruction. A concrete example is the memory-alignment rule for load/store accesses. If load/store data-memory accesses are not aligned, the processor triggers an exception; the base class can model the alignment rule as a constraint.[C2]
Controlled exception generation
The memory-alignment constraint is not necessarily always enabled. As part of exception planning, the constraint can be turned off so that randomized scenarios sometimes produce misaligned memory addresses for load and store operations.[C2]
Directed-scenario loading
A typical common scenario class defines a method that loads a directed scenario from a file containing a pre-assembled program trace. This supports directed stimulus, including tests leveraged from a processor software team.[C4]
Scenario constraints and branch handling
Branch-heavy instruction generation requires constraints because random register values are unlikely to exercise branch behavior well. For forward branches, constraints can initialize comparing operands just before the branch, increasing the probability that the branch is taken. For backward branches, constraints can treat the branch as a loop, using an incrementing loop index and restrictions on destination registers to avoid endlessly long loops.[C3][C4]
These examples illustrate why a scenario-level class needs constraints over sequences of instructions, not just randomized individual instructions.
Use in stimulus generation
The broader stimulus-generation flow uses multiple scenario types:
- Constrained-random scenarios, such as constraining all operations in a long sequence to computational operations.
- Directed-random scenarios, such as preloading memory with special numerical values before arithmetic instruction streams.
- Directed scenarios, such as reading a pre-assembled program as a scenario.
A scenario generator can work with these scenario objects by selecting and randomizing scenarios until a user-specified stopping condition is reached.[C5]
Relationship to transaction abstraction
The base class participates in a transaction-abstraction approach in which operations, instructions, and instruction scenarios are all modeled as classes. Transactions are described with properties, constraints, and methods; instruction scenarios raise the abstraction level from individual operations and instructions to stimulus descriptions.[C1]