Jump to content

Fault coverage

From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by 72.197.254.138 (talk) at 06:21, 17 February 2010 (spelling fix). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Fault coverage refers to the percentage of some type of fault that can be detected during the test of an electronic system, usually an integrated circuit. High fault coverage is particularly valuable during manufacturing test, and techniques such as Design For Test (DFT) and automatic test pattern generation are used to increase it.

For example, stuck-at fault coverage is measured by sticking each pin of the hardware model at logic '0' and logic '1', respectively, and running the test vectors. If at least one of the outputs differs from the fault-free model, the fault is said to be detected.

Conceptually, the total number of simulation runs is twice the number of pins (since each pin is stuck in one of two ways, and both faults should be detected). However, there are many optimizations that can reduce the needed computation. In particular, often many non-interacting faults can be simulated in one run, and each simulation can be terminated as soon as a fault is detected.

A fault coverage test passes when at least a specified percentage of all possible faults can be detected. If it does not pass, at least three options are possible. First, the designer can augment or otherwise improve the vector set, perhaps by using a more effective automatic test pattern generation tool. Second, the circuit may be re-defined for better fault detectibility (improved controllability and observability). Third, the designer may simply accept the lower coverage.

Test coverage (computing)

The term Test Coverage used in the context of programming / software engineering, refers to measuring how much a software program has been exercised by tests. For example,

  • has a particular statement ever been executed?
  • how many times has a statement been executed?
  • have all the statements in a program been executed, at least onece?
  • has the last optimization reduced the instruction path length significantly?

See also