Directed Random Stimuli Generation

Directed random stimuli generation is a hardware verification technique in which tests are generated from partially specified scenarios plus constraints, architectural validity rules, and expert knowledge. The approach aims to create many different tests that satisfy the same input rules while exploring different valid scenarios, providing a form of uniform sampling over the space of scenarios satisfying those rules.^[1]

Overview

In directed random generation, the verification engineer does not necessarily write a fully concrete test. Instead, they describe a test template or set of rules that may be partly specific and partly random. A generator then produces executable tests made of hardware transactions, while ensuring that required constraints are met.^[1]

The generated tests may be directed by several kinds of inputs:

• User requests, such as requiring at least one operand of an Add instruction to be larger than 9999, or requiring the same processor in a multiprocessor system to issue ten subsequent Load instructions to consecutive addresses.^[1]
• Architectural validity rules, such as computing a memory address as base-register data + offset, treating a 4-byte-aligned Load-Word instruction as atomic, or raising an exception when a privileged instruction is executed while the user-mode bit is on.^[1]
• Expert knowledge, such as statistical goals: 30% of Add instructions should produce result c = 0, 20% of Load and Store instructions should cross page boundaries, another 20% should be exactly page-boundary aligned, and 70% of transactions should contend on the same bus.^[1]

Model-Based Generation

A common implementation style is model-based stimuli generation. In this approach, the generator is divided into two main parts:

1. A generic engine capable of generating tests for different hardware architectures.
2. An input model that describes the specific hardware architecture and associated expert knowledge.^[1]

IBM advocated this model-based approach, separating the reusable generation engine from architecture-specific descriptions and verification knowledge.^[1]

Architecture

A model-based stimuli generation application can be organized as a service-oriented architecture. Its main components include:

The cited implementation was written in C++, with graphical interfaces using the QT library.^[1]

Generation Workflow

A typical directed random generation flow is:

1. Model the design
   Architectural rules and expert knowledge are encoded in a knowledge base.^[1]

2. Write a test template
   Verification engineers define a partially specified scenario, which may range from highly specific to highly random.^[1]

3. Generate tests
   The generic engine combines the architecture model, expert knowledge, and template to produce a batch of tests.^[1]

4. Track state with a reference model
   During generation, the functional reference model calculates the values of resources after each transaction so that subsequent transactions can be generated consistently.^[1]

5. Execute and compare
   Generated transactions are run on the design simulator, and the simulator’s results are compared against the reference model; a mismatch indicates a design bug.^[1]

Rule Categories

User-Directed Constraints

User constraints express specific verification intent. Examples include:

At least one Add operand > 9999

or:

Processor P issues 10 consecutive Load instructions
to consecutive memory addresses

These constraints direct the random generator toward scenarios of interest while leaving other aspects open to variation.^[1]

Architectural Validity Rules

Architectural constraints ensure that generated tests are valid for the target design. Examples include:

memory_address = base_register_data + offset

if memory_address is 4-byte aligned:
    Load-Word is atomic

if privileged_instruction and user_mode_bit == on:
    raise exception

Such rules prevent the generator from producing tests that violate architectural semantics unless such violations are explicitly part of the intended scenario.^[1]

Expert Knowledge Rules

Expert knowledge may encode distributional or coverage-oriented goals. Examples include:

30% of Add instructions should result in c = 0
20% of Load/Store instructions should cross page boundaries
20% of Load/Store instructions should be exactly page-boundary aligned
70% of transactions should contend on the same bus

The generator attempts to satisfy all user-defined and validity rules, and as many expert-knowledge rules as possible.^[1]

Technical Challenges

Model-based directed random generation raises several technical challenges:

• Modeling complex hardware objects and rules imposed by architecture and expert knowledge.^[1]
• Migrating knowledge and models to new designs.^[1]
• Describing test templates that bridge abstract verification-plan scenarios and concrete generated tests.^[1]
• Ensuring that generated tests satisfy user-defined rules, validity rules, and as many expert-knowledge rules as possible.^[1]
• Producing many significantly different tests from the same test template.^[1]
• Performing generation efficiently enough that it does not obstruct the verification process.^[1]

The source characterizes these challenges as naturally suited to AI-based techniques, especially for modeling and satisfying complex high-level rule sets derived from expert knowledge and belief systems.^[1]

Purpose in Verification

Directed random stimuli generation is used to generate batches of hardware tests that are both constrained and varied. The same template can produce multiple different tests that satisfy the same rules but reach different scenarios, helping verification explore the scenario space more broadly than a single hand-written directed test.^[1]

Because generated transactions are executed on a design simulator and checked against a functional reference model, the method supports both stimulus creation and result checking. If the simulator’s resource values differ from those computed by the reference model, the mismatch indicates a bug in the design.^[1]

References

^[1]: Evidence excerpt c19716ac-d440-4e7a-9df4-14d6adcc779a.