Browse Prior Art Database

Hardware Failure Simulator

IP.com Disclosure Number: IPCOM000113011D
Original Publication Date: 1994-Jun-01
Included in the Prior Art Database: 2005-Mar-27

Publishing Venue

IBM

Related People

Beaton, CB: AUTHOR [+5]

Abstract

Disclosed is a Hardware Failure Simulator (HFS) for testing the Power-On Self Test and Diagnostics programs within a computing system by placing simulated failures, or "bugs" at various places within the system, and by letting the POST and Diagnostics programs run to see whether these known failures are properly detected.

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

Hardware Failure Simulator

      Disclosed is a Hardware Failure Simulator (HFS) for testing the
Power-On Self Test and Diagnostics programs within a computing system
by placing simulated failures, or "bugs" at various places within the
system, and by letting the POST and Diagnostics programs run to see
whether these known failures are properly detected.

      The HFS may be operated in an automated mode or in a
menu-driven manual mode.  Simulated faults may be placed with bitwise
granularity in memory, I/O ports, CMOS/NVRAM, Programmable Option
Select (POS) registers, and indirect ports, even when these targets
are embedded in Very Large Scale Integration (VLSI) circuits.  In the
automated mode, hardware faults are simulated through a pre-written
disk file known as a Bug File, which can in turn invoke another
pre-written disk file known as a Matches File to simulate human
keyboard input while the Target System is running the Diagnostics
program.  The HFS stores information displayed on the monitor of the
Target System in a disk file known as a Screens File, and more
technical information is stored in yet another disk file known as a
Log File.

      Fig. 1 shows the basic components used in the operation of the
HFS.  A Host System 10 controls and monitors operations of a Target
System 12, on which POST and Diagnostics programs are running.
Dedicated hardware, called the Bug Analysis Research Tool (BART) 14,
is controlled by software resident on Host System 10, producing
simulated faults in Target System 12.  The Host System 10 includes a
bi-directional parallel port which is connected to BART tool 14 by
means of a cable 16.  The BART tool 14 is attached to Target System
12 by means of a cable 18 extending to a pod (not shown), which
either replaces the processor of the Target System or which plugs
into the co-processor socket of the Target System.  In either of
these cases, the BART Pod becomes the processor of the Target System
when it is plugged in.  This method includes a cycle control and
acquisition system controlling the processor at speeds of up to 50MHz
with zero wait states.

      BART tool 14 provides a number of features for use by the HFS
program, including processor or system reset, processor hold, single
cycle execution of the processor, Non-Maskable Interrupt (NMI)
masking and generation, emulation of all processor transfer cycles,
processor trace buffer, processor cycle break point registers, and
control of all resources accessible through the system bus.

      While testing the Target System POST and Diagnostics routines
and a error recovery programs, the HFS simulates errors, monitoring
and controlling the Target System with BART tool 14.  In simulating a
failure at a selected memory address or I/O port, the HFS first waits
for the program executing in the Target System to write to the
selected memory address or I/O port.  Following this write operation,
the HFS stops, or holds, the process...