Definition

In the Genesys-Pro model-based test-generation approach, an architectural model is the architecture-specific model that remains separate from the generic generation engine. It contains processor-specific information, principally a declarative description of a particular processor architecture and a database of testing knowledge relevant to that processor. [Architectural model contents]

Role in model-based test generation

The architectural model is used with a test template and a generic engine to generate processor verification tests. A verification engineer supplies a test template describing the desired scenario, while the generation engine formulates and solves a separate constraint problem for each test instruction. These constraint problems are based on constraints originating from the architectural description, testing knowledge, and directives in the test template. [Model use in test generation]

This separation supports a model-based workflow: architecture-generic information resides in the engine, while architecture-specific information is included in the model. The evidence states that separating the model from the engine helps users maintain tool versions for different designs and follow-ons, and supports ongoing design changes without depending on tool developers. [Model-engine separation]

Contents

The model's architecture-dependent knowledge includes:

• a declarative processor description, including instructions, design resources such as registers and caches, and high-level mechanisms such as address translation; and
• design-specific testing knowledge intended to increase coverage of verification events that randomly generated tests are likely to miss. [Architecture-dependent knowledge]

Genesys-Pro's modeling framework provides high-level building blocks designed specifically for modeling processors, and uses a constraint-based representation to model many different and complex architectures. The evidence identifies VLIW architectures and complex address-translation mechanisms as examples where this modeling capability is especially useful. [Modeling framework capabilities]

Instruction representation

Instructions form the bulk of the Genesys-Pro model and are described as constraint problems made of attributes and relations. Instruction attributes include an opcode and attributes for resources used by the instruction, such as data, resource family, address, and number of units. [Instruction model structure]

A Load-Word example illustrates the structure: the instruction loads four bytes from memory, has a source memory operand and a target register operand, and the source memory operand has base-register and displacement suboperands. Relations between attributes are represented as constraints; for example, the source memory address is constrained to equal the sum of the base-register data and displacement data. [Load-Word example]

Relations expressible as equations with arithmetic and Boolean operators can be stated directly in the model. Relations with more complex semantics can refer to an external C++ implementation supplied by the modeling engineer. [Relation implementation]

Testing knowledge

The architectural model can also include instruction-specific testing knowledge. For example, for an Add instruction Rt <- Ra + Rb, the model can encode a testing-knowledge relation that increases the probability of generating cases where data(Ra) + data(Rb) = 0, a combination that would otherwise be unlikely under random generation. [Instruction-specific testing knowledge]

Testing knowledge can also include constraints such as PageCross, which constrains an address attribute to cross a page boundary. The evidence notes that users often accumulate such testing knowledge during design verification and pass it on to models of follow-on designs. [Reusable testing knowledge]

Constraint hardness

Constraints derived from the architectural model can participate in the constraint satisfaction problem solved for each instruction. The evidence distinguishes mandatory hard constraints from nonmandatory soft constraints. Constraints originating from the architectural description are typically mandatory, while testing-knowledge and test-template constraints may be set by users as mandatory or nonmandatory. [Constraint hardness]