Definition

An architectural model is the architecture-specific model maintained separately from a generic test-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 in Genesys-Pro]

Role in model-based test generation (Genesys-Pro)

The architectural model is used together 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 Genesys-Pro 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. 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. VLIW architectures and complex address-translation mechanisms are cited 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 sub-operands. 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, and the base address is constrained to differ from the target address. [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. 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. Constraints originating from the architectural description are typically mandatory hard constraints, while testing-knowledge and test-template constraints may be set by users as mandatory or nonmandatory soft constraints. [Constraint hardness]

Role in post-silicon exercisers (Threadmill)

In Threadmill the architectural model is one of the inputs that, together with a test-template, testing knowledge, and the system topology, drives generation of test-cases on a post-silicon platform. [Threadmill inputs]

The Threadmill execution process starts with a builder application that runs off-line to create an executable exerciser image. The builder converts the data incorporated in the test-template and the architectural model into data structures that are embedded into the exerciser image, eliminating the need to access files or databases while the exerciser is running. [Builder conversion in Threadmill]

The exerciser image is composed of three major components: a thin OS-like layer of basic services required for Threadmill's bare-metal execution; a representation of the test-template, architectural model, and system configuration description as simple data structures; and fixed (test-template-independent) code that is responsible for the exercising. The image is loaded onto the silicon or accelerator platform, where the exerciser repeats the process of generating a random test-case based on the test-template, the configuration, and the architectural model, executing it, and checking its results. [Exerciser image composition]

Unlike Genesys-Pro, Threadmill does not use constraint-satisfaction techniques and is not supported by a reference model, neither to assist in test generation nor to support on-platform checking. [Threadmill avoidance of reference model]

Unifying pre- and post-silicon verification

The architectural model is part of a broader unified pre- and post-silicon verification methodology in which line-items of a verification plan are attached to one or more target platforms (simulation, acceleration, silicon) and converted into test-templates in the languages of the generators used by each platform. Using similar test-template languages and a common architectural model lets pre- and post-silicon tools produce similar (though not identical) test-cases from the same template, which simplifies adapting templates between platforms and assists root-cause analysis when bugs are detected on silicon and re-targeted on simulation. [Unified methodology role of architectural model]

In Threadmill specifically, several testing-knowledge constructs that are present in Genesys-Pro models (such as events that require long generation time) are intentionally omitted, and other constructs that demand a reference model are dropped to meet the simplicity and generation-speed requirements of the on-platform and acceleration environments. [Simplified Threadmill model relative to Genesys-Pro]