Expert Knowledge Rules

Expert Knowledge Rules are reusable, declarative rules used in model-based hardware stimuli generation to encode verification expertise about bug-prone or otherwise important scenarios. They supplement architectural validity rules and user-requested test constraints by biasing generated tests toward scenarios that verification experts believe are valuable to exercise.^[1]^[2]

Purpose

In model-based stimuli generation, tests must satisfy multiple kinds of rules:

User requests, such as generating an Add instruction with an operand larger than 9999, or issuing multiple consecutive Load instructions from the same processor.^[1]
Architectural validity rules, such as address calculation rules, alignment-dependent atomicity, and exception behavior for privileged instructions in user mode.^[1]
Expert knowledge rules, which express general verification beliefs about interesting or risky behavior, such as contention, boundary crossing, or special arithmetic outcomes.^[1]

Expert knowledge rules help the generator reach diverse scenarios that satisfy the same input constraints, supporting a form of uniform sampling over possible valid scenarios.^[1]

Examples

Representative expert knowledge rules include:

Arithmetic-result bias
30% of all Add instructions of the form a + b = c should result in c = 0.^[1]
Memory-page boundary bias
20% of all Load and Store instructions should cross page boundaries.^[1]
Page-alignment bias
Another 20% of all Load and Store instructions should be exactly aligned to page boundaries.^[1]
Bus-contention bias
70% of all transactions in a system should contend on the same bus.^[1]

These rules are generic and can apply across a wide range of hardware designs, rather than being limited to one specific processor or system implementation.^[2]

Role in Model-Based Stimuli Generation

Model-based stimuli generators separate a generic generation engine from an input model that describes the target hardware architecture and expert knowledge.^[1] In this architecture, the knowledge base contains both:

the declarative architectural description of the design under test, and
the expert knowledge repository.^[1]

Verification experts, acting as knowledge engineers, develop and maintain this knowledge base. Verification engineers then write test templates that implement the verification plan, while the generic engine consumes the model, expert rules, and templates to generate tests.^[1]

Representation as Ontology Rules

Expert knowledge is modeled as part of a hardware ontology. The modeling environment supports object-oriented and constraint-based modeling features, including constraints between objects, type hierarchies, type refinement, controlled type redefinition for follow-on designs, and extended data types such as collections, meta-types, and bitstreams.^[2]

Within this ontology, verification experts encode their expertise as rules. These rules realize the experts’ belief system about conditions that are likely to expose hardware bugs or represent important behavioral cases.^[2]

Biasing and Prioritization

Once modeled, expert knowledge is applied by default to all tests generated by the application.^[2] However, verification engineers can override the default behavior for a specific test template by:

increasing a bias implied by an expert rule,
decreasing a bias implied by an expert rule, or
prioritizing among competing expert rules.^[2]

This allows broad reuse of generic expert knowledge while still supporting test-specific intent.

Interaction with Constraint Solving

Single-transaction generation is formulated as a constraint satisfaction problem. The transaction model supplies the CSP variables and domains, while hard and soft constraints are constructed from the applicable rule sources.^[2] The solver assigns values to transaction properties so that all hard constraints and a subset of soft constraints are satisfied.^[2]

Expert knowledge rules therefore function as part of the constraint-driven generation process. They guide the generator toward desirable verification scenarios while coexisting with mandatory architectural validity constraints and user-specified test requirements.^[1]^[2]

Relationship to Production Rules

The test-template language also supports production rules, called events. An event consists of a condition and a response template. After each generated transaction, event conditions are checked; when a condition is satisfied, the response template is generated, usually inserting additional transactions into the test.^[2]

While expert knowledge rules encode general verification biases, production rules monitor the generation process and react dynamically to processor state or generation state, such as register values or the number and types of transactions already generated.^[2]

Benefits

Expert knowledge rules provide several benefits in hardware verification:

Reuse across designs: Generic rules can apply to many hardware architectures.^[2]
Declarative modeling: Experts state desired conditions without writing procedural generation code.^[2]
Bug-prone scenario targeting: Rules encode beliefs about scenarios likely to reveal bugs, such as contention or boundary conditions.^[2]
Configurable biasing: Verification engineers can adjust or prioritize expert-rule biases for specific templates.^[2]
Integration with CSP solving: Expert rules are handled within the same constraint-based generation flow as architectural and user-defined rules.^[2]