Skip to content
STIMSMITH

fault model

Concept WIKI v1 · 5/26/2026

In the provided microprocessor-testing case study, a fault model is the class of faults that a testing technique is designed to represent or expose. At circuit level, stuck-at-fault analysis uses mutators to encode fabrication faults such as broken wires. At design-level model-based testing, the implicit fault model can become unclear when generated tests use coarse memory accesses, motivating denser tests or added constraints over generated addresses.

Overview

A fault model is discussed in the evidence as the fault assumptions incorporated into a testing method. In circuit-oriented testing, the paper describes stuck-at-fault analysis as modifying a circuit design with mutators that capture a fabrication fault model, such as one or more broken wires between gates. This is characterized as a white-box mutation technique because it relies on the structure of the implementation under test. [C1]

Role in test methodology

The case study contrasts implementation-based testing with specification-based testing. Stuck-at-fault techniques are said to use the structure of a circuit design to construct equivalence-class tests that directly incorporate a fault model. The authors report that such techniques are effective for medium-size circuits, but also state that this testing style will not reveal some design-level flaws, such as a write-read error influenced by byte alignments in memory. [C2]

Fault models in generated microprocessor tests

In the VAMP microprocessor case study, test data generation is performed by constraint solving and random instantiation. The authors observe that this can produce test sequences with coarsely grained memory access. Under those conditions, the underlying fault model is described as "somewhat arcane," with the example of interferences between operations in distant memory areas. If such faults are the target, the paper recommends choosing a denser test method. [C3]

Constraining the uniformity domain

The paper also describes ways to make generated tests more targeted. Additional constraints can reduce the uniformity domain, for example by bounding the address range used in generated sequences or by defining a predicate over input sequences that records the addresses written by store operations and constrains load operations to those addresses. The same kind of constraints can improve coverage by dividing the uniformity domain into interesting sub-domains. [C4]

Design-level refinement

Although the authors had access to a VAMP gate-level model, the study stayed at the design level of the VAMP machine. The paper notes that the equivalence classes underlying the tests could be refined further by making HOL-TestGen explore byte-level or bit-level representations of registers and memory cells, rather than relying on a coarse hypothesis such as one successful write-read of a memory cell standing for all write-reads in that cell. [C5]

CITATIONS

5 sources
5 citations
[1] Stuck-at-fault analysis uses mutators on a circuit design to capture a fabrication fault model, such as broken wires between gates, and is characterized as a white-box mutation technique. Test Program Generation for a Microprocessor: A Case Study
[2] Stuck-at-fault techniques use circuit structure to build equivalence-class tests that directly incorporate a fault model, are effective for medium-size circuits, but may miss design flaws such as memory byte-alignment write-read errors. Test Program Generation for a Microprocessor: A Case Study
[3] Constraint solving and random instantiation can generate test sequences with coarsely grained memory access, making the underlying fault model arcane and associated with distant-memory interferences; denser testing is recommended for such faults. Test Program Generation for a Microprocessor: A Case Study
[4] Additional constraints can reduce the uniformity domain by bounding address ranges or constraining loads to addresses written by stores, and can improve coverage by dividing the domain into interesting sub-domains. Test Program Generation for a Microprocessor: A Case Study
[5] The VAMP study stayed at the design level despite having a gate-level model, and test equivalence classes could be refined by using HOL-TestGen to explore byte-level or bit-level representations of registers and memory cells. Test Program Generation for a Microprocessor: A Case Study