Browse Prior Art Database

Hybrid (Simulator - S/W Processor) Fault Simulation System

IP.com Disclosure Number: IPCOM000112661D
Original Publication Date: 1994-Jun-01
Included in the Prior Art Database: 2005-Mar-27
Document File: 4 page(s) / 124K

Publishing Venue

IBM

Related People

Lapihuska, C: AUTHOR [+2]

Abstract

The process of developing complex electronic hardware designs calls for the utilization of various simulation techniques to assure the correctness of the design before it is committed to hardware. One such technique, called fault simulation, is used to verify that diagnostic and test vectors for the proposed design are sufficiently rigorous to thoroughly test the design. The approach used is to systematically "insert" faults into the design simulation and determine whether the test pattern set under observation will cause an observable change in any monitored signals and thereby verify that the pattern set will detect the specific faults.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

Hybrid (Simulator - S/W Processor) Fault Simulation System

      The process of developing complex electronic hardware designs
calls for the utilization of various simulation techniques to assure
the correctness of the design before it is committed to hardware.
One such technique, called fault simulation, is used to verify that
diagnostic and test vectors for the proposed design are sufficiently
rigorous to thoroughly test the design.  The approach used is to
systematically "insert" faults into the design simulation and
determine whether the test pattern set under observation will cause
an observable change in any monitored signals and thereby verify that
the pattern set will detect the specific faults.

      Both design verification simulation and fault simulation
require basic descriptions, or models, of the hardware being
simulated.  In traditional applications of fault simulation, modeling
format restrictions or changes are often required to accommodate
differences between the design verification simulator and the fault
simulator environments.  These restrictions or changes are often very
subtle but can result in significant, and sometimes extreme, extra
expense and schedule delay.

      The run-time performance of fault simulators, which depend on
rather complex software algorithms in an attempt to contain run time
and resource demands, is also very sensitive to specific fault
selection and  can be very unpredictable depending on factors such as
how much of the design is affected by each given fault.  In many
instances, the algorithms simply fail to perform their intended
mission and numerous reruns and special handling of fault list
entries can result from these limitations.

      In addition, the degree of visibility to specific fault
simulation output information is completely controlled by the fault
simulation creator.  It is invariably less than that provided by the
design verification simulator and can be severely limiting for any
desired postprocessing activity.

      Fig. 1 shows the relationship of the required two simulation
environments and highlights the burdensome areas outlined above.

      The...