Browse Prior Art Database

Increased Testability for an Intelligent Adapter Having an External Interface

IP.com Disclosure Number: IPCOM000102010D
Original Publication Date: 1990-Oct-01
Included in the Prior Art Database: 2005-Mar-17
Document File: 4 page(s) / 145K

Publishing Venue

IBM

Related People

Gyllenhammer, CR: AUTHOR

Abstract

Generally, adapter self-tests can functionally test all the internal areas of the adapter. The self-test, however, cannot always test interfaces to other devices. The adapter is, therefore, made dependent on some other mechanism to fully test its function.

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

Increased Testability for an Intelligent Adapter Having an External Interface

       Generally, adapter self-tests can functionally test all
the internal areas of the adapter.  The self-test, however, cannot
always test interfaces to other devices.  The adapter is, therefore,
made dependent on some other mechanism to fully test its function.

      Another problem that is generated from an inability to fully
test the adapter is that associated with "hot plugging" a new
adapter; that is, plugging a new adapter into a system that is
already up and running.

      The problem is that the adapter's interface to the bus needs to
be tested prior to the adapter being brought "on-line".  If the
interface is bad, the entire system could be brought down by the new
adapter.

      Assume that the system in question is an adapter with an
external bus interface and that the adapter's interface to that bus
is a single module or other isolatable logic entity (see Fig. 1).

      The external bus consists of address lines, data lines, and
control lines.  The address, data and control signals are
bidirectional so that the adapter has the ability to send or receive
information over the bus.  For simplicity, let us assume that there
are only two control signals (select and acknowledge).

      The bus interface logic will ordinarily have an internal state
machine that will scan these signals, latch the information at the
proper time and produce the proper response signals.  This is the
hardware that needs to be tested and verified prior to going
"on-line" and using the external bus.

      The following is a general overview of the bus interface
logic's internal structure.  The first thing to note is that although
the signals are bidirectional external to the chip, the signals are
split into two single directional paths inside the module itself.
These single directional signals are fed into sequential circuits
that will product the desired outputs (see Fig. 2).

      The solution to the above problem is to place programmable
hardware in the path of the external bus's signals to increase
testability.  This hardware has the following features:
 o    A set of test latches and selection mechanism with programmable
control.  The selection mechanism (a multiplexer, for example)
selects between two inputs.  The two selector inputs are (1) the
functional input signal from the adapter logic and (2) the output of
a 'stimulus' test latch loaded by the adapter's microprocessor or
other programmable mechanism.  A 'sample' test latch is attached to
the output of the selector which can be read to determine the state
of its output (see Fig. 3).
      o    Programmable means for disabling timeout checks done on
the interface signals.
      o    The 'stimulus out' latch is used to force a desired
response out of the sequential logic.
      o    The 'sample out' latch is used to determine the value of
an ou...