Overview
A testing knowledge database is described in the Genesys-Pro model as a collection of architecture- or design-specific testing-knowledge constraints. These constraints are part of the processor-specific architectural model and are used by the generator to create higher-quality pseudorandom test programs by steering random choices toward verification-interesting cases. [Testing knowledge database role]
In Genesys-Pro, the overall test-generation flow separates three kinds of knowledge: a generic generation engine, an architecture-specific model, and test templates. The architecture-specific model includes both a declarative processor-architecture description and a database of testing knowledge relevant to that processor. [Architecture-specific model placement]
Function in test generation
During test generation, Genesys-Pro formulates and solves a separate constraint problem for each test instruction. The constraint problem is based on constraints from both the architectural description and the testing knowledge, and the tool annotates those constraints according to directives in the test template. [Constraint-problem inputs]
Testing-knowledge constraints are used to influence the quality of generated tests by biasing pseudorandom decisions toward interesting areas. Users can activate or deactivate constraints, and can mark them as mandatory or as prioritized nonmandatory constraints. [Constraint activation and priority]
Relationship to generic constraints
Genesys-Pro distinguishes between constraints that come from a design-specific testing-knowledge database and generic biasing constraints supplied by the generic generation engine. The generic constraints are applicable to any processor, while the testing-knowledge database captures design-specific knowledge in the model. [Design-specific versus generic constraints]
Examples of generic biasing constraints include:
- Alignment bias, which causes generated addresses to be aligned at, near, or across boundaries such as word, cache-line, or page boundaries.
- Cache bias, which causes memory-access patterns that lead to cache events such as hits, misses, and line replacements. [Generic constraint examples]
Mandatory and nonmandatory use
Genesys-Pro constraints can be hard or soft. Architectural-description constraints are typically mandatory, while nonmandatory constraints are attempted by the CSP engine but may be abandoned if no solution is found. Users can set testing-knowledge constraints, as well as constraints originating from the test template, as mandatory or nonmandatory. [Mandatory and nonmandatory constraints]
Examples of captured testing knowledge
The evidence describes testing-knowledge relations between instruction attributes. For example, verification engineers may decide that a specific relationship between data attributes should occur with higher probability in generated tests and can model a corresponding testing-knowledge relation. Another example is a PageCross testing-knowledge constraint that constrains an address attribute to cross a page boundary. [Testing-knowledge relation examples]
Reuse across designs
Genesys-Pro experience indicates that users often accumulate testing knowledge during design verification and pass it on to models of follow-on designs. This makes the testing knowledge database a reusable verification asset when later designs share relevant architectural or verification characteristics. [Reuse across follow-on designs]
Floating-point testing knowledge
For designs that comply with the IEEE floating-point standard, the evidence states that a testing-knowledge database based on FPgen can be used. This database focuses on verifying the data path of floating-point designs, and Genesys-Pro uses it to generate a rich variety of floating-point events. [FPgen-based testing knowledge]