Service-Oriented Architecture
Overview
In the cited hardware-verification application, the test generation system is explicitly described as a service-oriented architecture (SOA). The SOA is said to be derived from the separation of inputs that is central to model-based systems. The application separates the knowledge base, test templates, generic generation engine, functional reference model, and simulator-facing test execution flow into distinct parts with different responsibilities. [SOA application architecture]
Architecture in the model-based stimuli generator
The application’s knowledge base contains both the declarative architectural description of the design under test and an expert-knowledge repository. This knowledge base is developed and maintained by knowledge engineers who are verification experts. Test templates are written by verification engineers implementing the test plan. The generic engine, developed by software engineers, accepts the architecture model, expert knowledge, and test template, then generates a batch of tests. [Component responsibilities]
Each generated test contains a series of hardware transactions that are sent to execute on the design simulator. During generation, the system uses a functional reference model to calculate resource values after each generated transaction. Those values are used both for subsequent transaction generation and for comparison with the simulator results; a mismatch indicates a design bug. [Generation and validation flow]
Relationship to model-based generation
The SOA appears within a broader model-based stimuli-generation approach. In that approach, the generator is partitioned into a generic engine that can generate tests for any hardware architecture and an input model describing the hardware architecture and expert knowledge. The evidence identifies this partitioning as a response to challenges such as modeling complex objects and rules, migrating information to new designs, satisfying validity and user rules, generating varied tests from the same template, and doing so efficiently. [Model-based partitioning]
Maintainability properties
The evidence reports that the application’s SOA addressed maintainability concerns arising from simultaneously verified designs and unstable hardware specifications. The listed maintainability concerns are defining responsibilities, knowledge reuse, adapting to change, and ongoing upgrades. [Maintainability role]
Defining responsibilities
The architecture supports a clear separation of responsibility and source-code ownership. Knowledge engineers provide on-site user support and adapt the knowledge base to design changes. Tool developers support generic tool changes and provide second-line user support. Core technology developers provide solutions to requests coming from application development teams. [Responsibility separation]
Knowledge reuse
The partition between the generic generation engine and the knowledge base allows reuse. The test generator’s capabilities and generic testing knowledge are available for new designs. Designs from different generations of the same hardware architecture are modeled in a hierarchy reflecting their lineage, allowing common building blocks such as instructions, operands, resources, and common testing knowledge to be shared. [Knowledge reuse]
Adapting to change
Hardware design verification may begin while the hardware architecture is still evolving. The evidence states that changes to the hardware specification must be reflected in the knowledge base and reference model in a timely manner. Separating those modules allows parallel development, and having different teams maintain different modules helps check one module’s correctness relative to the other. [Adaptation to change]
Ongoing upgrades
The test generation tools evolve through staged delivery, allowing gradual tool evolution with user feedback. Knowledge engineers and tool developers maintain separate systems and synchronize sources during each release, typically monthly. Communication across geographic areas and time zones is supported through a unified defects database and regular weekly phone conferences. [Ongoing upgrades]
Example system context
The evidence also describes X-Gen, a system-level stimuli generator initiated in 2000 after successful processor-verification use of the technology. X-Gen used a knowledge-based architecture similar to Genesys PE and the same CSP solver, while using a modeling language adapted to system-level domains where components, system transactions, and configurations are first-class language members. [X-Gen architecture]
In a 2002 comparison against a legacy non-knowledge-based system stimuli generator, X-Gen achieved higher coverage metrics in one-fifth of the simulation time and with one-tenth of the test templates. It then became the primary stimuli generator for IBM high-end systems and was used in verification of most high-end system designs, including p-Series server and Cell-processor-based systems. [X-Gen results]