GB2260414A - Circuit tester with scanner path assignment - Google Patents

Abstract

An automatic circuit tester (10) contains in its memory (29) a test program (60 Figure 3) that specifies connections to be made between tester instruments (16, 18) and a device under test (12) in terms of instrument terminals and device-under-test test points without specifying the scanner state that is to implement those connections. A system program (62) inspects the current configuration of the scanner (20) and other tester parts and determines the identities and positions of components of which the scanner is comprised. Then, by consulting a low-level description (66) of each of the scanner components, it searches for paths that will result in the instrument-to-test point connections specified by the test program. The test program (60) can thus dictate a scanner-state change without "knowing" the configuration of the particular scanner employed. <IMAGE>

Description

1 -)) n41 4 APPARATUS FOR SCANNER PATH ASSIGNMENT

BACKGROUND OF THE INVENTION

The present invention is directed to automatic test equipment and in particular to determining scanner states for such equipment.

A typical automatic circuit tester typically employs a "bed of nails" fixture, which includes a large number of spring-loaded probes ("nails") that contact test points on the device under test (11DUT11), typically a circuit board, at a large number of test points. These nails are in turn connected to "system pins" that lead to terminals of instruments that drive or sense signals at the test points.

Although complete testing of a particular circuit board may require that connections be made between test instruments and a large number of test points on the board, the number of test instruments can be much smaller than the number of possible board test points, since only a fraction of the test points are typically in use in any given part of the test. The test instruments can therefore be multiplexed. In an automatic circuit tester, the apparatus for performing this multiplexing and related switching is called a scanner, which makes the connection between the instruments and the system pins.

The scanner is typically embodied in a plurality of circuit boards, each of which plugs into the fixture along one of its edges. Some types of scanner boards additionally contain instruments that scanner switches are to connect to the system pins, but other arrangements employ separate cards for the instruments. The latter approach is often preferred because the former approach tends to "lock the buyer in" to the use of instruments made by one tester manufacturer. The automatic-test-equipment industry has accordingly responded by moving toward "open architecture," in which different testequipment manufacturers implement a common instrument-control protocol. They provide sockets that can be used by instruments manufactured by other suppliers so long as those instruments conform to the common protocol.

To perform a circuit-board test, a circuit tester follows a test program, which includes a list of test instructions. Each instruction specifies a set of signals (a "vector") that are to be applied andlor are expected to be sensed at a plurality of test points during one clock cycle. In accordance with the test program, the tester applies a signal-set sequence (sometimes called a "burst") specified by a group of instructions with the scanner in one state, which results in one set of connections between instruments and test points. The tester then typically changes the scanner state, thereby making a different set of connections, before it applies further signal sequences. The test program additionally contains connection specifications that set forth the intended sets of connections.

At some point in the generation of a test program, the program is written at a level in which it specifies the types of instruments that are to apply respective vector components and the respective test points to which those vector components are to be applied; that is, it specifies ultimate connections between instrument terminals and DUT test points without specifying the scanner connections by which those connections are to be made. The program at this level must then be compiled by software written specifically for the particular tester configuration so as to convert the higher-level connection specification to one that specifies the scanner states required to achieve those ultimate connections.

The configuration-specific nature of this conversion operation, however, adds a significant burden. Specifically, the compiler must be rewritten or greatly enhanced for each new tester configuration. Part of the advantage of open systems, namely, their enhanced reconfigurability, is thus compromised.

SUMMARY OF THE INVENTION

We have recognized that this additional burden can be eliminated-and the benefits of reconfigurability thus more readily obtained-if the tester is provided with a scanner driver that is able to operate the scanner in response to test programs that specify the instrument-to-test-point connections at a non-scanner-specific level and that could operate a wide variety of scanner-system configurations. Of course, such a scanner would need to have access to a library of information concerning the various possible scanner-system configurations that it might encounter so that it can put the scanner system in the appropriate state. Such a library could potentially occupy too much memory to be practical. We have further recognized, however, that the required memory size can be kept manageable if the library is provided in a particular form.

Specifically, rather than list each possible configuration and, for each configuration, the connections made in each of its states, we store the information at a lower level, i.e., as a list of possible scanner components (e.g., scanner boards) and for each component the switches that it contains and the nodes that the switches connect. Storage at this level takes orders of magnitude less memory.

When the scanner driver operates with a given scannersystem configuration, it is apprised of the scanner system in terms of, e.g., its component scanner boards and their locations. In response to a test-program specification of instrument-to-test-point connections, then, the scanner driver searches through the thus-identified scanner components for paths that will provide the desired connections.

By providing the scanner-system-configuration information as a combination of scanner-specific low-level component information and scanner-independent searching capability for deriving the ultimate scanner-system configuration from this low-level information, we have achieved a scanner-independent driver that makes it possible to take full advantage of the reconfigurability that open systems provide.

BRIEF DESCRIPTION OF THE DRAWINGS

These and further features and advantages of the present invention are described below, by way of example, and in connection with the accompanying drawings, in which:

Figure 1 is a block diagram of an automatic circuit tester of a type in which the present invention can be employed; Figure 2 is a perspective view, with parts broken away, of such a tester; Figure 3 is a diagram that depicts selective contents of the tester memory; Figure 4 is a block diagram of exemplary scanner and instrument cards that the tester might use; and Figures SA and 5B together form a flow chart of a routine of the type that a tester employing the present invention can use to determine scanner states for tester signal bursts.

DETAILED DESCRIPTION OF AN ILLUSTRATIVE EMBODIMENT

Fig. 1 represents in block-diagram form one of the many types of automatic circuit testers in which the teachings of the present invention can be employed. The tester 10 tests a DUT 12 by using digital test instruments in the form of driver/sensors 14 to apply signals to the DUT and observe the resulting signals that the DUT produces. In addition to the digital instruments 14, a tester may also use analog instruments, such as a waveform generator 16 or a digital voltmeter 18.

To connect the test instruments to the DUT 12, typical automatic test equipment employs a scanner 20 and a fixture 22. The scanner 20 provides a large number of fixed-position system pins 24, and these pins carry signals to and from the DUT. However, they are not physically positioned to line up with test points on any particular circuit board, and signals on the system pins 24 have to be directed to different physical positions for every board type or family. This is the purpose of the fixture 22, which provides connections between the system pins 24 and fixture pins ("nails") 26 specifically positioned for the desired test points on the DUT 12.

For many DUTs, the number of necessary nails 26 is very large, but only a small number of them are employed at any one time. For instance, a DUT may have a large number of components, which in total require a large number of test points, but the test program may test only one individual component or circuit on the DUT at any one time. The test may therefore involve only the test points that electrically communicate with the particular terminals of that component or circuit and a few others, whose operation must be affected in order to isolate that component or circuit. In testing that particular component or circuit, the tester leaves all other test points idle. Subsequently, when the system tests other components or circuits on the board, it uses other small subsets of the test points.

Since each part of the test requires only a small subset of all of the nails 26, only a small subset of the system pins 24 are typically employed in any part of the test. In many cases it would therefore be wasteful to provide a separate test instrument dedicated to each system pin 24. This is particularly true of analog instruments, such as digital voltmeters 18 and waveform generators 16, since the number of such instruments used at a time is usually much smaller than that of the driverlsensors 14. The tester therefore includes the scanner 20, which is a matrix of switches and other circuitry that switches the connections between instruments and system pins 24 between bursts so that individual instruments can be used for different nails for different parts of a test.

The control circuitry for the tester may be embodied in a computer 28, its memory 29, a sequencer 30, and a scanner driver 34. To set th e tester up for a burst, the computer 28 communicates with the scanner driver 34 by means of, for instance, industry-standard MXI and V= buses 36 and 38 to specify the connections that the scanner 20 is to make between the instruments and the system pins 24. The scanner driver 34 responds by applying scanner- control signals to the scanner by means of a separate scanner bus to be described below. The V= bus also serves as an instrument bus, carrying instrumentcontrol signals such as those by which the computer 28 loads a pin memory 32 with values representing the signals that the individual test points are to receive or are expected to produce during the burst. The computer 28 may similarly program an analog instrument such as the digital voltmeter 18 if such an instrument is included as a standard part of the tester. Alternatively, an analog instrument such as the waveform generator 16, which may not be an ordinary part of the system and is not plugged into the V= bus, may be connected to the scanner 20 and programmed separately, possibly by the computer 28.

For real-time control during the actual burst, the computer 28 turns control over to the high-speed sequencer 30, which clocks the driverlsensors 14 and the pin memory 32 and may control other instruments as well.

When the burst has been completed, the computer 28 reads the results from the pin memories 32 and, for instance, the digital voltmeter 18 and changes the sensor state for the next burst. It also uses appropriate equipment such as a display 40 to produce an indication of the results, either then or after further bursts.

Fig. 2 shows the physical arrangement that certain of the elements of Fig. 1 might assume in an embodiment of the present invention. Fig. 2 shows that the VXI bus 38 is provided, in the conventional manner, as a backplane bus lying in a horizontal plane near the bottom of a tester chassis 42. The driverlsensors 14 and digital voltmeter 18 of Fig. 1 are provided by a number of circuit boards plugged into the V= backplane 38 to receive the instrument-control signals that program and otherwise control their operation. Fig. 2 depicts only one of those boards 44, but a typical tester will employ many such boards arrayed physically in parallel. Fig. 2 omits the connectors into which such further boards would be plugged.

The circuit tester provides the scanner 20 in a plurality of circuit boards. Only two scanner boards 46 and 47 appear in Fig. 2, but the typical arrangement will employ a larger number. In the illustrated embodiment, the scanner 20 of Fig. 1 further includes a scanner backplane bus 50, which is separate from the VXI instrument bus 38 but physically more or less parallel to it. Scanner board 46 plugs into connectors 48 at the upper edge of board 44, where board 44 provides the ports at which the analog instruments or driver/sensors drive and/or sense signals. Scanner boards 46 and 47 also plug into connectors such as connector 51 on the scanner bus 50, from which they receive scanner-control signals. They also send and receive instrument and DUT signals over bus 50.

For the sake of simplicity, Fig. 2 omits the largely conventional connection of the VXI backplane 38 to the MXI bus by which the computer 28 communicates with the scanner 20. As was explained above, however, the computer does send signals to the VXI backplane 38, and some of those signals, appropriately decoded, are forwarded to the scanner 20 by the scanner driver 34, which is shown in Fig. 2 as being embodied in a circuit board 34 oriented parallel to scanner boards 46 and 47. A "slot zero" board 52 makes the connections between the VXI backplane 38 and the scanner driver 34.

The upper edges of the scanner boards 46 and 47 provide connectors 54 and 56, which, together with corresponding connectors on other scanner boards not shown, contain part of the system pins 24 of Fig. 1. Also included on the upper edges of scanner boards 46 and 47 are connectors 58 for attaching coaxial cables from, for instance, the external waveform generator 16 of Fig. 1. (Of course, the waveform generator could be provided as the driver/sensors and the voltmeter are; i.e., it could be connected between a scanner board and the V= bus.) To test the DUT 12, the tester 10 follows a test program 60 written for the DUT and residing in the memory 29, part of whose contents Fig. 3 depicts. According to the present invention, however, the test program 60 is not specific to the particular tester architecture that the test system 10 employs. In particular, it is not based on any assumptions concerning the locations of various types of instrument and scanner boards 44 and 46 within the tester. In specifying a connection arrangement for a particular burst, therefore, it does not explicitly give a scanner state. Instead, it specifies that, say, a first driver/sensor should be connected to a first test point, while the output terminal of a digital voltmeter should be connected to a second test point. So the tester translates from this level of description to the level of description that is specific to the particular configuration of tester 10.

To this end, the system precedes its performance of the test program 60 by running system program 62, which includes an initialization routine for determining the current tester configuration. Suppose, for instance, that boards 44 and 46 have the (greatly simplified) topology depicted in Fig. 4 and are located in the twenty-second tester slot. Suppose further that a fixture 64 is in place and that among its connections are those that Fig. 4 depicts. Either from the indication by a user or from interrogation of an identity register (not shown) on the fixture, the system program is apprised of the identity of the fixture, and it fetches that fixture's description from fixture-description files 65 containing descriptions of the various fixtures that the tester might use. Such files would typically reside in a mass-storage segment of the tester's memory 29. The fixture's description sets forth the correspondence between user names for DUT test points and the scanner-board terminals ("system pins") to which the fixture will connect those terminals if the expected scanner boards are in the positions expected for testing the board. For the three test points that Fig. 4 depicts, for instance, the entries might be those shown in Table 1.

TP1 TP2 TP3 V22.A V22.B V22. C Table 1. Fixture-Description-File Entry

The first entry in the left column specifies the test point that the user calls TP1, and the first entry in the right column indicates that the fixture connects test point TP1 to the scanner board in the twenty-second slot (11V2211) and in particular to the node called node A on the type of board required in that slot to test the DUT for which the fixture is intended. The fixture similarly couples test points TP2 and TP3 to nodes V22.B and V22.C.

The system program then proceeds to determine the scanner configuration. Specifically, by means of signals sent over scanner bus 50, the system program obtains from control circuitry 74 on scanner board 46 the typeidentifying contents of an internal type register. As was mentioned above, the fixture information in the illustrated embodiment gives an indication of the proper identity and placement of scanner boards in the tester, so in that embodiment this step merely confiris that the proper scanner boards are present. Other embodiments might specify the test- point connections simply in terms of the physical edge-connector positions to which they correspond, however, and such information would not generally imply a particular scanner configuration.

Using the thus-obtained identifying information, the system program 62 obtains from a scanner-description file 66, which is a component library of scannerboard descriptions, a description of the particular scanner-board type that board 46's control circuitry 74 has identified.

The contents of this file may be of the type set forth in Table 2.

SIDE 1 SIDE 2 RELAY BIT A D 00 A E 01 A F 02 B D 03 B E 04 B F 05 c D 06 c E 07 c F 08 G D 09 G E 10 G F 11 H D 12 H E 13 H F 14 I D 15 I E 16 I F 17 HF1/I F is HF110 F 19 Terminals:

A B c G H I Table 2. Scanner-Description-File Entries

The names HF1/I and HF110 distinguish those nodes from the others for purposes that will be explained presently.

Each entry in the relay-bit column of this table represents a different bit location in a relay-state register 76 on scanner board 46. Each bit location represents the state of a different one of the relays 78 that make up scanner board 46. In the "Side 111 column is the name of the node on one side of the relay, while the "Side 211 column contains the name of the node on the other side of the relay.

Therefore, by sending over scanner bus 50 control signals that set the contents of bit position 01 in the relay-state register 76, the computer can close the relay that thereby connects node A to node E. Similarly, node E can in turn be connected to node G by closing the relay whose state is represented by bit position 10. Additionally, Table 2 identifies certain nodes as scanner-board terminals. Specifically, Table 2 so lists nodes A, B, and C (which are fixture-side edge-connector terminals) as well as nodes G, H, and I (which are instrument-side edge-connector terminals).

It is the storage of the scanner-configuration information in this form that permits a scanner-independent scanner driver to be employed. Any such driver must, of course, be apprised of the current scanner-system configuration and refer to some general library of scannerconfiguration information for the specifics of the current information. But such a library would be prohibitively large if it were provided, say, in the form of total-scanner-system states and the resulting combinations of ultimate connections. In the illustrated form, on the other hand, which lists only individual relay closures and the individual pairs of node connections that result, the necessary scanner-specific information can be contained in a reasonable amount of memory, and desired ultimate connections can be derived by way of a scanner-independent search routine in the driver.

in short, we have made the scanner-independent driver feasible by separating the source of the ultimate-connection information into (1) a manageable-sized library of scannerboard-specific intermediate-node-level information and (2) a scanner-independent search program that converts individual parts of that library to the ultimate-connection level as needed.

The initialization program next interrogates the instrument slots on VXI bus 38. When an inquiry addressing the twenty-second slot appears on VXI bus 38, an output from a board-type-identifying register in board 44's control circuitry 68 is applied to bus 38, and the system program 62 uses this board-type information to fetch from instrumentinterface files 67 information concerning a board 44. Files 67 contain, for each of a variety of instruments that might be used in the tester, a description of that instrument's interface to each type of scanner board to which it could be connected. The initialization program therefore fetches the information describing the interface between board 44's instrument type and board 46's scanner-board type.

Suppose, for instance, that board 44 is of the type named WVM and that such a board (atypically) includes two driver/sensors 14a and 14b and a digital voltmeter 18. The left column of Table 3, which depicts the relevant portion of the instrument interface file 67, lists two instrument leads typically known to users as D/S1 and D/S2 (i.e., driver/sensor inputloutput leads) and one known as WM (i.e., the input terminal of the digital voltmeter 18).

D/S1 WM D/S2 G H I Table 3. Instrument Interface Description File

For each of these leads, the instrument-interface fi contains a separate corresponding entry for each type^of scanner board into which the instrument board could be plugged. Each entry specifies the name of the scanner-board terminal to which the listed lead would be connected by plugging the instrument board into the scanner board that corresponds to that entry. The right column in Table 3 lists the entries that correspond to the scanner-board type that the system program has identified as occupying the slot into which the instrument board has been plugged.

le From this information and the identity of the slot in which the instrument board is located, the system program places into a terminal decode table 70 the entries in Table 4, which sets forth the correspondence between instrument-lead names and scanner-terminal names that distinguish terminals on a scanner board not only from each other but also from similar scanner terminals on other scanner boards.

SLOT INST. LEAD SCANNER TERMINAL 22 DSVM D/S1 V22.G 22 WVM WM V22.H 22 WVM D/S2 V22.I Table 4. Decode-Table Entries Table 4 shows that the system program has recorded the presence of an instrument of type WVM attached to the scanner board in slot 22 and that the instrument terminals named D/S1, WM, and D/S2 are connected respectively to scanner terminals V22.G, V22.H and V22.I, i.e., to nodes G, H, and I on the scanner board in the twenty-second slot.

From the information in Tables 2 and 4, the system program then creates a scanner-node-connection table 77, which lists for each individual node the other nodes to which the relays can connect it. Table 5 depicts the entry for the node that was referred to as node A in the individual-board data.

NODE USE TERMINAL CONNECTION COUNT NODE ? ITEM RELAY V22.A 0 Yes V22.D 2201 V22.E 2202 V22.F 2203 Table 5. Scanner-Node-Connection-Table Entry This node, now known as node V22.A, is provided with a use count whose contents are initially zero but can change during a test run. For node V22.A, there is a list of "connection items," i.e., nodes to which it can be connected, and associated relays by which those connections can be made. The system program compiles this list from the information in the Side 1 and Side 2 sections of the scanner-description file.

Also included in a node's entry is an indication of whether that node is a "terminal node," and, if so, of what type of terminal node it is. A terminal node is one that is directly connected to an instrument or the fixture or scanner bus. The purpose for such an indication will become apparent from the connection-algorithm description.

In addition to the connection-table entries that are readily apparent from the scanner-description-file information, the system program adds information concerning inter-board connections. As is described in, for instance, U.S. Patent Application Serial No. 660,289, filed on February 22, 1991, of Sullivan et al. for an Automatic Circuit Tester with Separate Instrument and Scanner Buses, which is hereby incorporated by reference, the scanner bus 50 that conducts control signals to the scanner may also conduct test signals between scanner boards. A final pass of the setup portion of the system program therefore adds the information about connection between scanner boards. It is here that the special names HF1/I and HF1/0 in Table 2 have meaning: they indicate that those nodes are connected to one or the other side of a particular signal line on the scanner bus. As a result of this indication, the system program may, for instance, add V21.HFI/0 to the connection list for V22. HF1/I and add V23.W1/I to the connection list for V22.HF1/0.

The manner in which the tester 10 employs this table will now be explained in connection with a simple test example. After the initialization described above, the test that the computer 28 is to run includes a burst that, for the sake of example, we will assume is to be applied with two concurrent connections. In the first connection, test points TP1 and TP2 -is- and the instrument terminals to which the user refers as WVM1.D/S1 and WVM1.WM1 are all to be connected together. In the second connection, test point TP3 is to be connected to instrument terminal DSVM1.D/S2.

Fig. 5 depicts an exemplary routine that the system program 62 in a tester employing the invention might use to determine how to make these connections. The first block 90 in Fig. 5 represents reading the first connection from the test program 60. The test program identifies these terminals by their scanner-configuration-independent names, i.e., TP1, TP2, WVM1.D/S1, and WVM1.DVM1. At this point, the tables do not yet include an instrument name lIDSVM1,11 which the test program specified, but they do have at least one called WVM, and lIDSVM111 means "a first one of the WVMs.11 Accordingly, system program searches its decode table for a DSVM entry in the instrument column, and it finds one in slot 22. (Although users will ordinarily prefer this automatic instrument-naming capability, the user may also be afforded the option of making the choice himself.) It therefore names that WVM lIDSVM111 by entering into an instrument-location table 88 (Fig. 3) an entry, such as that set forth in Table 6, that specifies the location of the particular WVM that will be considered WVM1.

Instrument Name DSW1 Slot No.

22 Table 6. Instrument-Location-Table Entry The routine then proceeds to the step of block 92, in which it consults the instrument-location table 88 and the terminal-decode table 70 (Fig. 3) to convert the instrumentterminal names in the test program 60 to the names of the scanner terminals to which they are connected, namely, terminals V22.A, V22.B, V22.G, and V22.H. The routine arbitrarily picks one of these terminals, say, terminal V22.A, as a "root" terminal, places it in a to-do list 96 (Fig. 3), and puts the other three terminals in a search list 98. Its task is now to find paths from the root terminal to the search-list terminals.

Block 100 represents selecting the next node V22.A in the to-do list (in this case, the only node in the to-do list) as a subject node, which it will process. Processing a subject node involves determining whether any single-relay linkage from the subject node to another node has the potential to be part of a path from the root node to a search-list node. To this end, the system programing 62 consults the subject node's entry in the terminal-decode table 70 to determine, for each "connection item" in the subject node's terminal-decode-table entry, whether that connection item either (1) is one of the search-list nodes, and thus is definitely part of one of the desired connection paths, or (2) meets a disqualification criterion and can thus definitely be ruled out as part of the path. If the answer to both questions is no, then the connection itemmust be placed in the to-do list for further processing. This is the function of the steps repeated by blocks 101-106.

Specifically, on the first pass through the routine, the routine will not have examined all of the subject node's connection items, so the result of the block-101 step will be affirma ' tive. As Table 5 indicates, one of the connection items for the subject node V22.A (Fig. 4) is a connection node V22.D (Fig. 4), and block 102 represents selecting this as the first connection item to be examined. Decision block 103 represents determining whether this node is one of the nodes in the to-do list, i.e., whether it has already been identified as a potential link in a desired connection path. If so, further processing would be redundant, so the loop starts over with the next connection item. otherwise, the routine proceeds to the test of block 104, which determines whether the current connection item is on the search list.

Since connection item V22.D is not one of the three terminals V22.B, V22. G, and V22.H on the search list, the result of this determination is negative.

This does not mean that node V22.D cannot be part of a path that ultimately will lead to one of the terminals to be connected, however. The routine therefore proceeds to further steps, in which it determines whether a linkage between the subject node and the connection item currently being considered can be ruled out at this point as a potential part of a path to one of the terminals to which the root terminal is to be connected. Block 105, for instance, represents consulting the current connection item's scanner-nodeconnection-table entry (as opposed to that of the subject node) to determine whether that item is in use, i.e., whether the entry in its use-count field has a value other than zero. If so, this connection item cannot be used as part of the current connection, because to do so would short the terminals in the current connection to the terminals connected by the connection of which that connection item is already a part.

If the current connection item V22.D is not in use, the routine proceeds to decision block 106. The step represented by this block branches on the contents of the terminal-node field of the current connection item's scanner-nodeconnection-table entry. If the connection item is a terminal node--t.e., if it is a fixture terminal or an instrument terminal---then it should not be tied up with the current connection. Instead, it should be saved for some other connection, one whose purpose is to connect that terminal to others.

If the tests of blocks 104 and 106 cannot rule out the current connection item as a link in a desired connection path, that connection item is added to the to-do list, i.e., to the list of nodes whose connection items are to be examined for possible inclusion in the connection, as block 107 indicates. When any node other than the root node is placed in the to-do list 96, it is accompanied by a backwards pointer, which comprises the name of the subject node in whose scanner-node-connection- table entry that node was found at step 102 as well as an indication of the relay that makes the connection between those nodes. The routine then returns to decision block 101, as it does upon an affirmative decision in any of the steps represented by blocks 103, 105, and 106.

When connection node V22.D has been considered, two more connection items, namely, nodes V22.E and V22.F, remain in the scanner-node-connectiontable entry for the current subject node V22.A, and the routine proceeds through the same sequence of steps for those two nodes that it did for node V22.D. When it has finished with node V22.F, however, the result of the decision represented by block 101 is negative, so the routine returns to the determination, represented by block 99, of whether any entries remain in the to-do list. The routine does not reach the block-99 step if it has already found paths to connect all the terminals that the test has designated for this connection. Accordingly, if no lines remain in the to- do list, then a connection path cannot be found by using the criteria that the routine of Fig. 5 imposes. The routine reports this fact to the user or proceed to an alternate routine, such as one that does not impose the block 106 criterion.

ordinarily, however, the test design and number of tester resources prevent this eventuality, and the result of the block-99 decision is affirmative. The result is step 100, in which the next item on the to-do list is selected as the subject node. In the example, the next item is node V22.D.

Inspecting the new subject node's scanner-nodeconnection-table entry, the routine makes a positive determination in step 101 and, in step 102, chooses node V22.A, i.e., the previous subject node, for processing. This node is already on the to-do list (and, in fact, has been "done"), and the resultant affirmative result of the block-103 test is thus enables the test to avoid again considering a link between these two nodes.

The routine then obtains another affirmative result from step 101 and performs steps 102 and 203 for the next node, node V22.B, in subject node V22.DIs scanner-node-connectiontable entry. Since that node is not in the to-do list, the routine proceeds to step 104, which determines that node V22.B is indeed in the search list; i.e., a path has been found from the root node to one of the lines to which it is to be connected. The routine therefore proceeds to the step represented by block 108, in which the current connection item V22.B is placed in a found list 118 and removed from the search list.

The routine then proceeds to the decision step represented by block 109, which indicates that more terminals remain in the search list; paths to nodes V22.G and V22.H have not yet been found. Now, it is possible in some topologies that a node in the search list, such as node V22.B, which is the terminal point in a path that has already been found, can also be used as a link in a path from the root node to another node on the second list. If the search list is not empty, therefore, processing of the current connection item, node V22.Bi continues even though that node is now known to be at the end of a desired connection path. Since node V22.B is a termina ' 1 node, however, branching at step 106 prevents its being added to the to-do list.

After again performing steps represented by blocks 101 and 102, the routine proceeds, as block 103 indicates, to determine whether the next node V22.G in the subject node V22.DIs scanner-node-connection-table entry is already on the to-do list. Since it is not, the routine performs the block-104 test of whether the current connection item is in the search list. The affirmative result of this test causes that node V22.G to be removed from the search list and placed in the found list, as block 108 indicates.

The next iteration similarly finds that terminal V22.H is in the search list. That terminal V22.H is therefore removed from the search list and placed in the found list. Node V22.H having been the last item in the search list, test 109 yields an affirmative result. That is, paths have been found from the arbitrarily designated "root" terminal V22.A (also known as test point TP1) through the scanner circuitry to all of the terminals to which the first connection was to link it.

What remains is to set the relays in those paths. This step, represented by block 110, starts with one of the foundlist entries and follows the accompanying pointer to a to-dolist entry, which represents the previous node in the identified path. It then follows the pointer accompanying that node, and it continues in this fashion until it reaches the root node. As it does so, it compiles in a connection list 124 (Fig. 3) an entry for the first connection by placing in that entry the linkages that it encounters in following the pointers.

By beginning with found-list node V22.B, for instance, the routine places into the connection-list entry for the first connection the linkage from node V22.B to node V22.D and the linkage from node V22.D to node V22.A. Beginning with the next found-list node V22.G, the routine enters only the linkage from that node to node V22.D, since the further linkage from node V22.D to the root node V22.A has already been entered into the first connection's connection-list entry.

The routine completes the entry by tracing back from the last found-list entry line V22.H. Table 7 gives the resultant n!T entry.

Connection 1D: 1 lst Node 2nd Node Relay Bits V22.B V22.D 2203 V22.D V22.A 2200 V22.G V22.D 2209 V22.H V22.D 2212 Table 7. Connection-List Entry, Connection 1 With the path information compiled for the first connection, the routine then operates the relays by setting the listed relay bits from Table 7. It also increments the use-count entry in the scanner-node-connection table for each node listed in that connection. (The use-count field is incremented only once for each node even though that node may be listed more than once in the path information for the first connection.) The routine of Fig. 5 then ends by emptying the temporary search, found, and to-do lists, as block ill indicates.

As is mentioned above, a second connection must be made for this burst. The connection request for this connection is that test point TP3 be connected to driver/sensor terminal DSVM1.D/S2. Reference to the instrument-location and terminal-decode tables 70 and 88 translates this into a request for a connection from scanner terminal V22.C to scanner terminal V22.I. The system program then follows the routine of Fig. 5 in the manner described above. The result is entry of a second connection (given in Table 8) into the connection list, incrementing of the use-count fields, and setting of the indicated relays.

Connection ID: 2 1st Node 2nd Node V22.C V22.E 2207 V22.E V22.I 2216 Relay Bits Table 8. Connection-List Entry, Connection 2 With the relay registers like register 76 set in the scanner driver 34 in accordance with the foregoing routine, the relays 98 assume states in which they make the proper connections, and the computer 28 further prepares for the upcoming burst by loading memories 32a and 32b with the values to be applied during the burst. The computer 28 similarly loads other pin-memory devices. With these values entered, it then causes the sequencer 30 to operate the various instruments so as to apply the burst and record the results. In Fig. 4, memories 32a and 32b represent memories for both applying vector components and recording the results, and the computer 28 ordinarily reads out these results, as well as the MM results continued in another memory 120, before applying the next burst.

Also before applying the next burst, it sets up the scanner,20 to make the proper connections for the new burst. Suppose the test program 60 indicates that the next burst should be applied with the digital voltmeter and the first driverlsensor disconnected but with the second driver/sensor connected to test points TP1 and TP3. One way to achieve all these connections is to reset all the relays and then perform the routine of Fig. 5 for this connection. That is, one could reset the scanner and start from the beginning, as is done in conventional approaches. In some situations, however, such an approach would require considerably more relay operation than would result from leaving in place the connections that are common to the previous and upcoming bursts. We will therefore assume that the system program changes the scanner state "incrementally" rather than by resetting all scanner relays after each burst.

This incremental approach is most effective when the techniques of the present invention are employed. For a given burst, the difference between its connections and those of the previous burst may change from one use of the test to the next because the test may branch on the results of different bursts. For a given connection, the set of linkages that minimizes relay switching in one test run may therefore differ from the set that minimizes relay switching in another test run. But traditional approaches, in which the test specifies connections in terms of specific relay states, do not lend themselves to permitting such differences. The present invention, in which the test program specifies connections in terms of the ultimate terminals to be connected rather than in terms of the specific paths by which those connections are made, is readily implemented in a system in which the linkage sets are determined between bursts, so it readily permits such differences, since the previous relay state can be taken into account in determining the paths, as block 105 of Fig. 5 indicates.

In accordance with the incremental approach, the system program has therefore compared the new set of connections with the previous set of connections and concluded that the first connection (ID=1) must be canceled and a third connection, connecting the instrument lead DSVM1. D/S2 to test point TP1, must be made. It accordingly resets the relayregister bits listed under the first connection, thereby eliminating that connection, and decrements the use count for the nodes that the connection included. That is, it decrements the use counts for nodes V22. A, V22.B, V22.D, V22.G, and V22.H. It then performs the routine of Fig. 5 to find an appropriate linkage set to implement this third connection, and Table 9 gives the result.

Connection ID=3 ist Node 2nd Node Relay Bit V22.A V22.D 2201 V22.D V22.I 2215 Table 9. Connection-List Entry, Connection 3 With the third connection in place, the next burst is applied. Subsequent scanner-state changes and vector bursts occur in this manner until the test has been completed.

A review of the foregoing description reveals that the test generation can be made virtually hardware independent when the approach of the present invention is employed. As was described above, the test program 60 specifies the connections in terms of instrument terminals and test points, and it requires no change when either the instrument or the scanner configuration changes. The present invention thus constitutes a significant advance in the art.

1

Claims (3)

1. An automatic circuit tester, adapted for installation therein of different types of replaceable instruments having instrument terminals, for installation therein of different types of replaceable DUT-containing fixtures having fixture terminals providing connections to DUT test points, and for installation therein of different types of scanner components, comprising scanner nodes and scanner switches operable to connect pairs of the scanner nodes to form a scanner having some scanner nodes connected to instrument terminals and other scanner nodes connected to fixture terminals, the tester being adapted to receive a test program that includes instructions that specify signal bursts and associated connection specifications that specify connections to be made between designated instrument terminals and designated DUT test points during the associated signal burst and being responsive thereto to operate instruments installed therein in accordance with the specified bursts, the tester comprising:

A) storage means containing a component library of scanner-component descriptions, each scanner-component description including a list of scanner switches and, for each scanner switch, the scanner nodes connectable thereby; B),a configuration compiler, adapted to receive identity signals representing the identities of the scanner components currently in the tester and of DUT testpoint connections and instrument terminals to produce a scanner description comprising a list of the scanner switches and, for each switch, the instrument terminals, DUT test points, and scanner nodes that the switch connects; and C) a scanner driver responsive to the connection specification for responding thereto by searching through the scanner description for a sequence of scanner nodes that can be so linked by scanner switches as to form a path from the designated instrument terminal to the designated DUT test point and operating the scanner switches that complete the path found thereby.

2. An automatic circuit tester as defined in claim 1 wherein:

A) the scanner components include identity circuits adapted to receive interrogation signals and respond thereto to generate identity signals that represent the respective components' identities; and B) the configuration compiler includes means for applying interrogation signals to the scanner components, and the identity signals that the configuration compiler receives are those that the identity circuits generate as a result.

3. An automatic circuit tester substantially as herein described with reference to any of Figures 1 to 5B of the accompanying drawings.

1 1 1