Ontology for Hardware Modeling

Overview

The Ontology for Hardware Modeling is an ontology-based approach to describing hardware functionality and verification expertise for simulation-based functional verification. It represents architectural knowledge, functional behavior, validity rules, and expert testing knowledge in a mostly declarative form, and translates these models into constraint satisfaction problems (CSPs) for automated stimuli generation.^[1]

The ontology is used within a hardware test-generation system that combines three main inputs: a functional model of the hardware, verification expert knowledge, and verification scenarios written in a separate special-purpose language. These inputs are converted into constraints and solved by a dedicated engine adapted to the needs of hardware stimuli generation.^[1]

Verification Context

The ontology was developed for simulation-based functional verification, the dominant industrial practice for verifying hardware designs compared with formal methods. In this process, an HDL description of the design is simulated, stimuli are driven into the simulation, and the actual behavior is compared against the expected behavior implied by the specification.^[1]

A typical verification process begins with a verification plan that identifies behaviors to check and risk areas to target. Verification engineers then translate abstract functional scenarios into concrete tests. This translation is difficult because generated tests must satisfy architectural validity, user-specified scenarios, and expert knowledge about bug-prone cases.^[1]

Sources of Rules

The ontology supports rules from three major sources:

1. User requests — scenario-specific requirements, such as generating an Add instruction with at least one operand larger than a specified value, or generating a sequence of Load instructions to consecutive addresses in a multiprocessor system.^[1]
2. Architectural validity — rules required by the hardware architecture, such as computing a memory address from a base register and offset, treating aligned load-word operations as atomic, or raising an exception for privileged instructions executed in user mode.^[1]
3. Expert knowledge — probabilistic or biased testing rules intended to stress likely bug-prone conditions, such as preferring some Add instructions to produce zero, encouraging load/store instructions to cross page boundaries, or creating contention on a shared bus.^[1]

Modeling Approach

Hardware information and expert knowledge are modeled using an in-house modeling tool that combines object-oriented and constraint-based modeling. The tool provides native support for constraints between objects and between object subcomponents, enabling hardware relationships to be represented directly in the ontology.^[2]

The ontology supports a type hierarchy for creating and classifying taxonomies commonly found in hardware transactions. It also includes a type refinement mechanism that extends beyond classical inheritance, packages for controlled redefinition of types in follow-on designs, and extended data types such as collections, meta-types, and bitstreams for arbitrary-sized address and data values.^[2]

Modeling is performed through a graphical studio that supports navigation through the object hierarchy, searches, and queries.^[2]

Example: Load-Word Instruction Model

A modeled instruction can be represented as a structured object whose operands and attributes form a tree. For a partial Load-Word instruction model, the source memory, base register, offset, and target register may each have attributes such as address and data fields with legal value ranges.^[2]

An architectural validity rule for such an instruction can be expressed declaratively as a constraint:

SourceMemory.Address = BaseRegister.Data + Offset.Data

This rule states that the source memory address for the load operation is computed from the base register value plus the offset data value.^[2]

Expert Knowledge Representation

The ontology allows verification experts to encode testing expertise as rules. These rules are generic and can apply across a wide range of designs, capturing expert beliefs about bug-prone situations and important hardware behaviors.^[2]

For example, an expert rule for an addition instruction may be modeled as a constraint over instruction operands:

op1.data + op2.data = 0

where op1 and op2 are modeled operands of an Add instruction. Such a rule expresses a testing bias toward cases where the operation produces zero.^[2]

Once expert knowledge is modeled, it is applied by default to all tests generated by the application. Verification engineers can override this default behavior for a specific test template by increasing or decreasing rule biases or by prioritizing among the rules.^[3]

Test Generation Process

Test program generation occurs at two levels. Stream generation is controlled recursively by statements in the test template. Individual transaction generation, at the leaves of the control hierarchy, occurs in three stages.^[2]

First, the transaction is formulated as a CSP. CSP variables and domains are taken directly from the transaction model, while hard and soft constraints are constructed from the relevant user requests, architectural validity rules, and expert knowledge.^[2]

Second, the CSP is solved. The solver assigns values to all properties of the transaction so that all hard constraints and a subset of the soft constraints are satisfied.^[2]

Third, the generated transaction is applied to the reference model, and the generator updates its internal reflection of resource states accordingly.^[2]

Role of Constraint Satisfaction

CSP is used as the core solution technology for two main reasons. First, it is declarative: modelers can state rules directly and rely on the underlying CSP algorithm to enforce them. This avoids the need to write procedural code that handles all possible rule interactions.^[3]

Second, CSP supports prioritization of expert-knowledge rules. A generic Soft-CSP algorithm can use these priorities when deciding which soft constraints to satisfy, while still respecting hard architectural constraints.^[3]

The system uses a specialized constraint solver because stimuli generation has distinctive requirements. It must handle many soft constraints arranged in deep hierarchies, while also supporting test diversity. A strict constraint-hierarchy approach could repeatedly return the same assignment if it maximizes the number of satisfied soft constraints. To avoid this, the system uses a local metric: if a partial solution can be extended to satisfy additional soft constraints, it must be extended, but the solver does not require global maximization of all soft constraints.^[3]

Production Rules and Events

The test-template language also supports production rules called events. An event consists of a condition and a response template. After each transaction is generated, the system checks the conditions of all defined events. If an event condition is satisfied, its response template is generated.^[3]

A response template typically inserts additional transactions into the test and may trigger other events. Event conditions can refer to processor state, such as a register value, or to generation state, such as the number and types of transactions generated so far.^[3]

AI Components

The hardware modeling ontology is part of a broader AI-based verification application. The application uses AI in several ways:

• architectural and expert knowledge are represented and maintained as an ontology;
• expert knowledge is applied as a hierarchical set of rules reflecting relative importance;
• production rules monitor generation and insert transactions when conditions hold;
• CSP is used as the core solution technology.^[3]

Significance

The ontology provides a declarative framework for capturing hardware functionality and verification expertise in a reusable form. By separating architectural knowledge, expert bias, and test scenarios from the solving mechanism, it enables automated generation of valid and targeted simulation stimuli. Its combination of ontology modeling, rule prioritization, production rules, and CSP solving addresses the practical difficulty of translating verification plans into concrete tests for complex hardware designs.^[1][3]