Bias Statements

Bias statements are constructs in a test-template language that let verification users control how often selected expert-knowledge rules are activated during model-based test generation. They are used to bias partially specified verification scenarios toward cases that are considered more likely to expose design bugs, while still allowing the generator to fill unspecified values randomly or through constraint solving.^[1][2]

Context

In the described model-based stimuli generation system, test templates are written by verification engineers and consumed by a generic generation engine together with an architecture model and an expert-knowledge repository.^[1] The knowledge base contains both the declarative architectural description of the design under test and expert knowledge maintained by knowledge engineers who are verification experts.^[1]

Expert knowledge rules encode hints about how a scenario should be biased or stressed so that bugs are more likely to be exposed.^[1] For example, a fixed-point-unit expert may state that bugs are expected when the result of an Add instruction is exactly zero; this can be represented as an expert rule such as SumZero and invoked through a bias statement in a test template.^[1]

Purpose

Bias statements provide a mechanism for controlling the activation percentage of expert-knowledge rules during test generation.^[2] This allows a verification engineer to guide random or constraint-based generation toward interesting cases without fully specifying every transaction in the test template.^[2]

Typical uses include:

• Increasing the likelihood of resource dependencies, such as dependencies involving general-purpose registers.^[1]
• Encouraging particular memory alignments, such as 4-byte or 16-byte alignment.^[1]
• Activating domain-specific rules, such as generating an Add instruction whose sum is zero.^[1]

Syntax Examples

The evidence shows bias statements in two forms: standalone bias statements and instruction-local bias annotations.

Standalone Bias Statement

Bias: resource_dependency(GPR)=30, alignment(4)=50;

This statement specifies biasing parameters for resource dependencies and alignment. In the example test template, this statement appears near the beginning of the template and applies throughout the test because bias statements are scopal.^[1][2]

Instruction-Local Bias Statement

Instruction: load R5 ? ; with Bias: alignment(16)=100;

This form attaches a bias directly to a transaction statement. In the example, the generated load instruction is biased toward 16-byte alignment with an activation value of 100.^[1]

Another instruction-local example is:

Instruction: Add ? reg , ? ; with Bias SumZero;

This applies the expert rule SumZero to an Add instruction, reflecting the expert claim that bugs may be expected when an add result is exactly zero.^[1]

Scope Rules

Bias statements are scopal.^[2] Their effect depends on where they are placed in the test template:

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

Relationship to Expert Knowledge Rules

Bias statements are tied to expert-knowledge rules in the verification knowledge base. The system may contain up to a few thousand validity and expert-knowledge rules for a typical architecture.^[1] These rules express design constraints, validity conditions, and expert beliefs about bug-prone scenarios.^[1]

The generation system uses AI techniques to model and satisfy complex rule sets written in a high-level language, including rules imposed by expert knowledge and belief systems.^[1] Bias statements are one way that a test template can influence which of these expert rules are activated during generation.^[2]

Example: Table-Walk Test Template

The provided table-walk scenario stores contents of randomly selected registers into memory addresses from 0x100 to 0x200 in increments of 16.^[2] A simplified excerpt is:

Var: addr=0x100, reg;
Bias: resource_dependency(GPR)=30, alignment(4)=50;

Instruction: load R5 ? ; with Bias: alignment(16)=100;

Repeat(addr < 0x200) {
  Instruction: store reg addr;
  Select
    Instruction: Add ? reg , ? ; with Bias SumZero;
    Instruction: Sub;
  addr = addr + 0x10;
}

In this template:

• resource_dependency(GPR)=30 biases generation toward general-purpose-register resource dependencies.^[1]
• alignment(4)=50 biases alignment behavior across the template scope.^[1][2]
• alignment(16)=100 applies only to the load instruction on that line.^[1][2]
• SumZero applies only to the Add instruction on that line.^[1][2]

Generation Behavior

During generation, the engine accepts the architecture model, expert knowledge, and test template, then generates a batch of tests.^[1] Each generated test contains hardware transactions that are sent to a design simulator.^[2] The generator also uses a functional reference model to calculate resource values after each generated transaction; these values are used both for generating subsequent transactions and for comparison with simulator results.^[2]

Bias statements affect this process by influencing the activation of expert rules while the generator fills in unspecified operands, addresses, registers, or instruction choices.^[2] The resulting tests obey the specifications in the template, while values not specified in the template may be chosen at random.^[2]

See Also

• Test Template Language — the language containing transaction statements, control statements, programming constructs, and bias statements.^[2]
• Expert Knowledge Rules — domain-specific rules used to bias or stress scenarios likely to expose bugs.^[1]
• Model-Based Stimuli Generation — the broader architecture in which test templates, architecture models, expert knowledge, and a generation engine produce executable verification tests.^[1]