Browse Prior Art Database

Post Test Functionality Check Program

IP.com Disclosure Number: IPCOM000099577D
Original Publication Date: 1990-Feb-01
Included in the Prior Art Database: 2005-Mar-15
Document File: 6 page(s) / 185K

Publishing Venue

IBM

Related People

Hoffmann, RJ: AUTHOR [+2]

Abstract

Disclosed is a diagnostic program that when used on bare board opens and shorts test systems, checks out the error detection capabilities of the test system. This check guarantees that the test system was completely functional at the time that product was tested.

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

Post Test Functionality Check Program

       Disclosed is a diagnostic program that when used on bare
board opens and shorts test systems, checks out the error detection
capabilities of the test system.  This check guarantees that the test
system was completely functional at the time that product was tested.

      Bare board opens and shorts test systems of the bed of nails
type usually consist of:
 1)  A product handler with test heads or fixtures, used to contact
test nodes of the product under test.
           2)  A switch matrix with a Pass/Fail comparator or
analyzer to perform the shorts and opens testing.
           3)  A local system controller (computer) used to store and
retrieve test data, man/machine input or output, and machine control.

      The Post Test Functionality Check is a program that is stored
and executed by the local system's controller.  This program uses the
test data or net list information of the particular product being
tested as its input and outputs several additional commands or tests
to the Matrix/Analyzer to guarantee the integrity of the shorts and
opens test performed.

      In most cases, test systems of this type are considered to be
"open loop" systems.  This is to say, that you tell the system to
perform a test and the system reports back the results.  You have no
feed back to guarantee that the test system actually did what you
told it to do or if it gave you the correct results.  You can only
hope that it did.  When a test system reports that a product panel
has defects on it and you offline verify that those defects are on
the panel, you feel fairly confident that your tester is functioning
properly.  It found defects and that is what it is supposed to do.
It is when a test system gives you consistently good results and the
product is found to have defects that you know that you have real
problems, such as:
           1)  How long has this problem existed?
           2)  How many product panels did we test with this
               problem?
           3)  Did any defects get by the tester?

      The problem may only exist in certain portions of the switch
matrix, and in these address areas product defects will not be found.
This problem could exist for a long time, and you could have a lot of
product go by the tester with real defects. Product with defects
should never get by a test system.  The Post Test Functionality Check
program was implemented to detect problems like this.

      In most test matrixes/analyzers there are several areas of
logic, drivers and switches where this type of problem could go
undetected by normal diagnostics or product testing.  They are:
           1)  Matrix and Analyzer control logic
                A.  Dwell Circuits
                B.  Scanning Circuits
                C.  Error Detection Circuits (B...