Bias Statements for Expert Rule Activation

Bias statements are constructs in a model-based verification test-template language that let verification engineers control how often selected expert knowledge rules are activated during test generation. They are used to steer generated scenarios toward conditions believed to expose hardware bugs, while still allowing many distinct tests to be produced from the same partially specified template.^[1][2]

Context

In the described model-based stimuli-generation architecture, test generation is driven by three main inputs:

• an architecture model of the design under test,
• an expert knowledge repository, and
• a test template written by verification engineers.^[1]

The generation engine combines these inputs with a constraint solver and a functional reference model to generate executable test programs. The reference model is used during generation to calculate resource values after each generated transaction, and those calculated values are later compared with simulator results to detect design mismatches.^[2]

Expert knowledge is represented as a large pool of rules. These rules encode verification expertise about scenarios that may be more likely to expose bugs. For example, an expert for a fixed-point unit may state that bugs are expected when the sum of an Add instruction is exactly zero.^[1]

For a typical architecture, the rule base may contain up to a few thousand validity and expert knowledge rules.^[1]

Purpose

Bias statements provide a way to influence the activation percentage of expert knowledge rules during generation.^[2] Instead of fully specifying every instruction operand or state value, the test writer can give the generator probabilistic guidance such as:

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

or attach a bias directly to a transaction:

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

The intent is to make generated tests more likely to include bug-prone conditions identified by expert rules, without eliminating randomness or variability.

Use in Test Templates

The test-template language supports four broad classes of statements:

1. Transaction statements — specify hardware transactions to generate, such as processor instructions.
2. Control statements — control selection among sub-statements, such as choosing between an Add or Sub instruction.
3. Programming constructs — variables, assignments, expressions, and assertions.
4. Bias statements — control activation percentages of expert knowledge rules.^[2]

A simplified example based on the provided table-walk template 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 example:

• resource_dependency(GPR)=30 biases generation toward general-purpose-register dependency scenarios.
• alignment(4)=50 biases address alignment-related rule activation.
• alignment(16)=100 applies specifically to the load instruction.
• SumZero applies specifically to the Add instruction, reflecting an expert rule where an addition result of zero is considered interesting.^[1][2]

Scoping Rules

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

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

Relationship to Expert Rules

Bias statements do not themselves define expert knowledge. Instead, they control the likelihood that existing expert knowledge rules are used during generation.^[2]

For example, an expert rule may state that an Add instruction is interesting when its sum is zero. A template can then request that this rule be favored for a particular instruction:

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

The generator uses the expert knowledge repository and constraint-solving techniques to satisfy such high-level rule constraints while still producing legal test programs.^[1]

Role in Test Diversity

A key challenge for the generator is producing many significantly different tests from the same template while still targeting interesting bug-prone scenarios.^[1] Bias statements help address this by guiding probabilities rather than fully specifying all generated values.

As a result:

• template-specified constraints are obeyed,
• unspecified values may still be chosen randomly,
• expert-guided scenarios occur more frequently, and
• different generated tests can still vary substantially.^[2]

The evidence describes a generated table-walk test in which the template constraints are followed, while values not specified in the template are selected randomly.^[2]

Example: Table-Walk Scenario

The example test template describes a table-walk scenario that stores contents of randomly selected registers into memory addresses from 0x100 to 0x200 in increments of 16.^[2]

Biases in the template affect both global and instruction-local generation:

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

This global bias applies throughout the test.

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

This local bias applies only to the load instruction.

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

This local bias applies only to the Add instruction selected inside the control statement.

The resulting generated test includes initialization sections for registers and memory, an instruction sequence to execute, and expected results calculated by the reference model.^[2]

Implementation Setting

The described generation application is implemented as a service-oriented architecture. Knowledge engineers maintain the architecture model and expert knowledge base, verification engineers write test templates, and a generic C++ generation engine produces batches of tests.^[1][2]

Bias statements are therefore part of the interface between verification intent and the generator’s expert-rule machinery: they let the test author express which classes of expert scenarios should be emphasized, without hard-coding a single concrete test.

See Also

• Model-based stimuli generation
• Constraint-based test generation
• Expert knowledge rules
• Functional reference models
• Processor verification test templates

References

^[1]: Evidence 9627d0fc-78e1-47fa-a4aa-94b08d433baa. ^[2]: Evidence 4c8e1005-e6b5-4969-b088-83b092cefbf1.