Bias Statements in Test Templates

Bias statements are constructs in a test-template language used to control how often expert-knowledge rules are activated during automated test generation. They allow verification engineers to steer generated tests toward scenarios believed to be more likely to expose bugs, while still leaving unspecified values to be chosen by the generator.^[1]^[2]

Context

In model-based stimuli generation, a test generator receives three main inputs: an architecture model, expert knowledge, and a test template. It then produces executable test programs for simulation.^[1] Test templates describe partially specified verification scenarios, while the generator fills in unspecified details, often randomly, subject to constraints and expert rules.^[2]

Expert knowledge rules encode verification experience about conditions that may be especially useful for exposing bugs. For example, a fixed-point-unit expert may suggest that bugs are likely when the result of an Add instruction is exactly zero.^[1] A typical architecture may define up to a few thousand validity and expert-knowledge rules.^[1]

Purpose

Bias statements let the template author influence the probability that selected expert-knowledge rules are applied during generation.^[2] This provides a way to “stress” a scenario toward cases that domain experts believe are bug-prone, without fully specifying every generated instruction or operand.^[1]

For example, a template can request that generated instructions prefer aligned memory addresses, resource dependencies, or arithmetic results satisfying an expert rule such as SumZero.^[1]

Syntax Example

The evidence includes the following table-walk test-template fragment:^[1]

1.  Var: addr=0x100, reg;
2.  Bias: resource_dependency(GPR)=30, alignment(4)=50;
3.  Instruction: load R5 ? ; with Bias: alignment(16)=100;
4.  Repeat(addr < 0x200) {
5.    Instruction: store reg addr;
6.    Select
7.      Instruction: Add ? reg , ? ; with Bias SumZero;
8.      Instruction: Sub;
9.    addr = addr + 0x10;
10. }

In this example:

Line 2 defines a general bias over the test, including resource_dependency(GPR)=30 and alignment(4)=50.^[2]
Line 3 applies a local bias to a load instruction, requesting alignment(16)=100.^[2]
Line 7 applies the SumZero bias to an Add instruction.^[2]

Scope Rules

Bias statements are scopal.^[2] A bias statement may apply broadly or locally depending on where it appears in the template.

In the table-walk example, the bias on line 2 applies throughout the test, while the bias annotations on lines 3 and 7 apply only to the individual instructions on those lines.^[2]

Interaction with Test Generation

Bias statements operate within a test-template language that includes several statement categories:^[2]

Statement type	Role
Transaction statements	Specify transactions to be generated and their properties, such as a processor instruction.
Control statements	Control the selection of sub-statements, such as choosing between an `Add` or `Sub` instruction.
Programming constructs	Include variables, assignments, expressions, and assertions.
Bias statements	Control the activation percentage of expert-knowledge rules.

During generation, the engine produces concrete tests that obey the template’s specifications. Values not specified in the template are selected by the generator, while expected results are computed using a functional reference model for later comparison with simulator results.^[2]

Role in Verification

Bias statements help bridge the gap between random generation and expert-directed testing. They allow a verification engineer to write a partially specified scenario and then bias the generator toward cases that are considered interesting or risky according to expert rules.^[1]^[2]

A mismatch between simulator results and expected results calculated by the reference model indicates a bug in the design.^[2] By increasing the frequency of expert-recommended corner cases, bias statements can make generated tests more likely to exercise bug-revealing behavior.^[1]