Skip to content
STIMSMITH

Hardware Ontology

Concept WIKI v1 · 5/23/2026

**Hardware Ontology** is an ontology-based modeling approach for simulation-based functional verification of hardware designs. It represents architectural knowledge, hardware functionality, and verification expertise in a declarative model that can be translated into constraint satisfaction problems (CSPs) for automated stimuli/test generation.[92cfac92-32e5-4b82-8274-31d3fd0342ef][b35d5537-147a-4ddc-a2b9-24f3aa0debbb]

Hardware Ontology

Hardware Ontology is an ontology-based modeling approach for simulation-based functional verification of hardware designs. It represents architectural knowledge, hardware functionality, and verification expertise in a declarative model that can be translated into constraint satisfaction problems (CSPs) for automated stimuli/test generation.[1][2]

Context

In industrial hardware development, simulation-based functional verification is a dominant technique. A hardware design described in HDL is simulated, test stimuli are driven into the simulation, and the observed behavior is compared with expected behavior derived from the specification.[1]

A typical verification process begins with a verification plan that identifies behaviors to check and major risk areas. Verification engineers then convert plan scenarios into concrete tests. This mapping is difficult because scenarios must obey architectural rules while also targeting bug-prone cases and coverage goals.[1]

The hardware ontology addresses this by capturing:

  • the functional model of the hardware,
  • architectural validity rules,
  • expert verification knowledge,
  • user-requested verification scenarios,
  • and constraints used by a solver to generate legal and useful test stimuli.[1][3]

Purpose

The ontology is used to describe hardware functionality and testing knowledge largely in a declarative form. A separate special-purpose language defines verification scenarios. The system translates the functional model, expert knowledge, and scenario requests into constraints solved by a dedicated engine.[1]

Its main role is to support automated generation of simulation stimuli that are:

  1. architecturally valid,
  2. aligned with user verification goals, and
  3. biased toward expert-identified bug-prone cases.[1][3]

Rule Sources

The system combines rules from several sources. Examples in the evidence include:

Rule source Example
User requests Generate an Add instruction where at least one operand is larger than 9999; generate 10 subsequent Load instructions to consecutive addresses from the same processor.[1]
Architectural validity Memory address equals base-register data plus offset; a privileged instruction in user mode results in an exception.[1]
Expert knowledge Bias a percentage of Add instructions to produce zero; bias Load/Store instructions to cross or align with page boundaries; bias transactions to contend on the same bus.[1]

These rule types are later converted into constraints used during test generation.[3]

Modeling Approach

Hardware information and expert knowledge are modeled using an in-house modeling tool that combines object-oriented and constraint-based features.[3]

The modeling environment supports:

  • constraints between objects and subcomponents,
  • type hierarchies for hardware transaction taxonomies,
  • type refinement beyond classical inheritance,
  • packages for controlled redefinition of types in follow-on designs,
  • extended data types such as collections, meta-types, and bitstreams,
  • arbitrary-sized address and data values.[3]

Modeling is performed through a graphical studio that supports navigation, search, and queries over the object hierarchy.[3]

Example: Load-Word Instruction Model

A partial model of a Load-Word instruction includes operands such as source memory, target register, base register, and offset. Each operand has attributes such as address and data, with legal value ranges.[3]

An example architectural constraint is:

SourceMemory.Address = BaseRegister.Data + Offset.Data

This expresses the rule that the memory address used by the instruction is computed from the base register and offset.[3]

Expert Knowledge Representation

Verification experts can encode their knowledge as rules inside the ontology. These rules express beliefs about bug-prone or important hardware behaviors and are intended to be generic across a range of designs.[3][2]

For example, an expert rule for an Add instruction may constrain operands so that the result is zero:

op1.data + op2.data = 0

where op1 and op2 are modeled operands of the Add instruction.[3]

Once modeled, expert knowledge is applied by default to generated tests. A verification engineer can override this behavior in a specific test template by increasing or decreasing rule biases, or by prioritizing among rules.[2]

Test Generation Process

Test program generation occurs at two levels:

  1. Stream generation, driven recursively by control statements in a test template.
  2. Single transaction generation, performed at the leaves of the control hierarchy.[3]

Single transaction generation has three stages:

  1. CSP formulation
    Variables and domains are taken from the transaction model. Hard and soft constraints are built from user requests, architectural rules, and expert knowledge.[3]

  2. CSP solving
    The solver assigns values to transaction properties so that all hard constraints and some soft constraints are satisfied.[3]

  3. State update
    The generated transaction is applied to a reference model, and the generator updates its internal reflection of resource states.[3][2]

Use of AI Techniques

The system uses several AI-related techniques:

  • Ontology modeling for architectural knowledge and expert verification knowledge.
  • Hierarchical expert rules to represent relative importance among rules.
  • Production rules, called events, that observe generation and insert special transactions when conditions are met.
  • Constraint satisfaction problems as the core solving technology.[2]

Production Rules

The test-template language includes production rules known as events. An event contains:

  • a condition, and
  • a response template.[2]

After each transaction is generated, the system checks the conditions of all defined events. When an event condition is satisfied, the response template is generated, usually inserting additional transactions into the test. Events may also trigger other events.[2]

Event conditions may refer to:

  • processor state, such as the current value of a register, or
  • generation state, such as the number and types of transactions generated so far.[2]

Constraint Satisfaction

CSP is used as the core solution technology for two main reasons:

  1. Declarative rule enforcement
    CSP allows engineers to state rules and rely on the solver to enforce them, rather than manually implementing procedural logic for every possible case.[2]

  2. Rule prioritization
    CSP supports prioritization of expert-knowledge rules through a Soft-CSP approach, allowing different rules to have different importance levels.[2]

The evidence also notes that stimuli generation poses special solver requirements because the system may contain many soft constraints and deep constraint hierarchies, while still needing diverse, uniformly distributed solutions rather than repeatedly returning only the single solution that satisfies the maximum number of soft constraints.[2]

Significance

The Hardware Ontology provides a structured way to combine hardware architectural models, validity constraints, expert testing knowledge, and scenario requests into a unified test-generation framework. By translating these elements into CSPs, it enables automated generation of legal and strategically biased simulation stimuli for functional verification.[1][3][2]