Skip to content
STIMSMITH

Knowledge Base

Concept WIKI v1 · 5/26/2026

In the IBM hardware-verification system described by Naveh et al., a knowledge base is the reusable, maintainable body of hardware-functionality and testing knowledge used by constraint-based random stimuli generators. It is separated from the generic generation engine so that testing knowledge and design-specific models can be reused, adapted to architectural changes, and maintained by specialized knowledge engineers.

Overview

In the IBM constraint-based random stimuli generation approach for hardware verification, the knowledge base is the maintained body of verification knowledge used by the test-generation tools. The reported technology includes an ontology for describing the functional model and capturing verification expertise, together with a constraint satisfaction problem (CSP) solver. The ontology supports mostly declarative descriptions of hardware functionality and knowledge about testing, while verification scenarios are defined in a separate special-purpose language. The system translates the functional model, expert knowledge, and verification scenarios into constraints that are solved by a dedicated engine.

Within this architecture, the knowledge base is treated as a distinct artifact from the generic generation engine. This separation is important because it allows generic test-generation capabilities and generic testing knowledge to be reused across new hardware designs.

Role in hardware verification

The knowledge base appears in the context of functional verification, the process of checking whether a logic design conforms to its specification. In the reported IBM workflow, random stimuli are generated for simulation before silicon fabrication, with the goal of finding bugs earlier and reducing the number of defects that escape into silicon.

The knowledge base supports this process by capturing hardware functionality and verification expertise in a reusable form. The overall system became a repository of processor-verification knowledge across multiple IBM labs, processor architectures, and implementations. This repository role enabled knowledge reuse, faster response to design changes, and a gradual reduction in the need for human experts.

Architectural separation and reuse

The evidence describes the tool as partitioned into a generic generation engine and a knowledge base. This partition enables a high level of reuse: test-generator capabilities and generic testing knowledge are immediately available for new designs. Designs from different generations of the same hardware architecture are modeled in a hierarchy that reflects their lineage, allowing common building blocks such as instructions, operands, resources, and common testing knowledge to be shared between designs.

This separation is also relevant to maintainability. Hardware design verification often begins while the hardware architecture is still changing. Any hardware specification change must therefore be reflected in the knowledge base and reference model in a timely manner. Keeping these modules separate allows parallel development and provides a way for independently maintained modules to check each other’s correctness.

Maintenance responsibilities

The reported service-oriented architecture assigns different responsibilities to different teams. Knowledge engineers, described as three to four per tool, provide on-site support for users and adapt the knowledge base to design changes. Tool developers support generic tool changes and provide second-line support, while core technology developers handle new requests from application development teams.

The tools also evolve through staged delivery. Knowledge engineers and tool developers maintain separate systems and synchronize sources at each release, typically once per month. This staged process allows gradual evolution with user feedback.

Use in system-level generation

A system-level generator called X-Gen was initiated in 2000 after the success of the processor-verification technology. X-Gen used a similar knowledge-based architecture to Genesys PE and the same CSP solver, but used a modeling language adapted to system-level concepts such as components, system transactions, and configurations. In 2002, X-Gen outperformed a non-knowledge-based legacy system generator in the reported test, achieving higher coverage metrics with less simulation time and fewer test templates.

Key properties

  • Declarative modeling support: the ontology allows mostly declarative representation of hardware functionality and testing knowledge.
  • Reusable testing knowledge: generic testing knowledge and shared design building blocks can be reused across designs.
  • Maintainability: the knowledge base can be updated as hardware specifications evolve.
  • Separation of concerns: the knowledge base is maintained separately from the generic generation engine and reference model.
  • Institutional memory: the system became a repository of processor-verification knowledge across IBM labs and hardware generations.

CITATIONS

8 sources
8 citations
[1] The IBM random-stimuli generation technology includes an ontology for the functional model and verification expertise, plus a CSP solver. Constraint-Based Random Stimuli Generation for Hardware Verification
[2] The ontology supports mostly declarative descriptions of hardware functionality and testing knowledge, and the system translates models, expertise, and scenarios into constraints. Constraint-Based Random Stimuli Generation for Hardware Verification
[3] The system became a repository of extensive processor-verification knowledge across multiple IBM labs, architectures, and implementations. Constraint-Based Random Stimuli Generation for Hardware Verification
[4] Partitioning the tool into a generic generation engine and a knowledge base enables reuse of generator capabilities and generic testing knowledge for new designs. Constraint-Based Random Stimuli Generation for Hardware Verification
[5] Common design building blocks and common testing knowledge are shared between related hardware designs modeled in a lineage hierarchy. Constraint-Based Random Stimuli Generation for Hardware Verification
[6] Knowledge engineers provide on-site support and adapt the knowledge base to design changes. Constraint-Based Random Stimuli Generation for Hardware Verification
[7] Hardware specification changes must be reflected in the knowledge base and reference model, and separating those modules supports parallel development and correctness checking. Constraint-Based Random Stimuli Generation for Hardware Verification
[8] X-Gen used a similar knowledge-based architecture as Genesys PE and the same CSP solver, with a domain-specific modeling language for system-level concepts. Constraint-Based Random Stimuli Generation for Hardware Verification