Definition

A scenario generator is a testbench stimulus-generation component that operates on a set of scenario objects. In the described processor verification approach, the generator randomly selects and randomizes one scenario from the available set, then repeats that process until a user-specified condition is reached.[1]

Role in stimulus generation

The scenario generator is part of a controllable stimulus-generation strategy. Both the test scenarios and the generator itself should be controllable so that verification engineers can generate stimuli with varying levels of randomness.[2]

The evidence describes scenario contents using SystemVerilog: an instruction scenario can be represented as a dynamic array of instruction objects, and SystemVerilog foreach array constraints can be used to express scenario-level constraints.[2]

Supported scenario styles

The cited flow describes three scenario styles that a scenario generator can work with:

• Constrained-random scenarios: scenarios constrained to focus the generated instruction stream. For example, a long arithmetic-focused sequence can constrain operations to the computational kind, excluding branches, loads, and stores.[3]
• Directed-random scenarios: scenarios that combine directed setup with randomized execution. For processor arithmetic testing, the cited example preloads data memory with special values such as walking 0/1 patterns and values near zero or near minimum and maximum numbers, then reads those values before executing an arithmetic instruction stream.[4]
• Directed scenarios: scenarios used to cover specific functionality. The cited example implements a scenario class that reads a pre-assembled program as a directed scenario; a common scenario class method can load a directed scenario from a file containing a pre-assembled program trace.[5]

Use in processor verification

In processor constrained-random verification, scenario generation must account for architectural and boundary-condition constraints. The evidence gives an example involving backward branches: the testbench must prevent invalid or unhelpful cases such as a branch that is always taken because an operand has the smallest possible number, and must ensure loop-related registers are not modified elsewhere in the loop.[6]

The overall approach combines constrained-random stimulus with support for directed-random and directed stimulus. This helps address limitations of traditional directed tests while still allowing reuse of directed stimuli, such as tests leveraged from a processor software team.[5][7]