the following description is directed to a tester architecture for use in testing semiconductor integrated circuits . the tester has a system architecture in which modular tester resource units are interconnected via a network and controlled by information sent serially over the network . the following terminology is used below in describing components of the tester system architecture : test system resource : a test system “ resource ” can be any single functional circuit or a collection of circuits designed to accomplish a task . there are various types of resources called “ modules .” test module : a test system resource that contains test instrumentation and is controlled by the module network communications interface and synchronization bus . it is designed to have one or more connections to the dut for applying test stimulus to the dut and / or collecting responses from the dut . power module : a test system resource that is controlled by the module network communications interface and synchronization bus . it is designed to provide electrical power to the dut in order facilitate testing . system modules ( storage module , control module ): a test system resource that is also controlled by the module network but is not connected to the dut . these can include storage modules , control modules , etc . module network : a communications interface for exchanging data between test system resources . a typical example of an embodiment would be a high speed serial communications interface , such as ieee 1394 firewire . tester synchronization bus ( tsb ): a high speed control interface for accurately synchronizing the action of multiple modules in time . test system : a collection of test modules and system modules configured to carry out tests on one or more duts either sequentially or in parallel . test head : a collection of test modules and system modules mounted in an enclosure or sub - assembly . test system controller : the device that is controlling the application of test stimulus to the dut and the collection of responses . a typical embodiment of this is a computer workstation running test application software , such as the teseda workbench ( twb ) available from teseda corporation . however , other embodiments are also possible . test head controller : an example of a control module that acts as a local controller for the module network and the module within a test head . one embodiment of the tester is shown in fig1 . the illustrated tester embodiment includes relevant portions of a dft tester setup 100 , a semiconductor wafer 102 , a dft probe card 104 , test module sockets 106 , test modules 108 installed in the sockets , a network 110 to connect all the modules together , and a computer 112 which is also connected to the network . the computer 112 uses this network 110 to initialize the test modules 108 with test data , extract test results at the conclusion of the test , and also to provide control commands during the execution of the test . however , the network 110 alternatively or additionally can be used for other purposes . the network 110 as illustrated in fig1 is a wired network such as firewire ( ieee - 1394 ), but other wired networking technologies such as usb , as well as wireless networking technologies such as ieee 802 . 11b alternatively can be used . [ 0063 ] fig1 illustrates a setup of the tester including four sockets ( and 4 modules ), but alternative embodiments can include any number of modules installed in this way . the number of modules ( in their sockets ) which it is possible to install is limited only by the size of the probe card , which will be determined by the user of this equipment . the probe card 104 is annular , with a central aperture 116 to allow test probes 114 to extend through the central aperture 116 and make electrical contact with one or more ic die 120 which have been fabricated on the wafer 102 to be tested . in an alternate embodiment , the testing probes 114 are mounted such that they do not extend through the central aperture 116 . in that embodiment , the probe card 104 is a disk without a central aperture 116 and the probes 114 are mounted on the side of the disk which is brought closest to the wafer 102 for testing . in yet another embodiment , the testing probes 114 are replaced with a socket connected to the probe card 104 . a packaged die is inserted into this socket for testing after packaging . further alternative embodiments include various combinations of these probe configurations . in order to perform testing , the probe card 104 is positioned adjacent to the semiconductor wafer 102 so that the probes 114 make electrical contact with pads on one or more ic die 120 fabricated on the wafer 102 . these pads may be located anywhere on the die . once electrical contact has been established , the test is initiated by the twb software 122 by sending commands to the test modules 108 . under the direction of these commands , the modules generate appropriate test stimuli ( which are stored within the module ) into the die 120 with which the probes 114 are in electrical contact . these test stimuli as generated by a combination of modules 108 are synchronized by using the tester synchronization bus ( tsb ) 118 ( e . g ., conforming to the teseda synchronization bus specification provided by teseda corporation ) which is a synchronization protocol and a physical bus specification . the output of the die are examined and compared with expected values stored in the test modules , and discrepancies are noted and stored for later examination and evaluation by the twb 122 . to facilitate this testing , the following types of modules 108 are envisioned : 1 . scan chain data driver module — drives scan chain data into the dft - enabled dut and records the outputs at the conclusion of the test . 2 . clock driver module — drives clock and scan - enable signals into the dut . 3 . command / control module — allows the twb 122 to control auxiliary equipment such as power supplies over legacy interfaces such as rs - 232 , gpib and others . in an alternate embodiment , these modules may be mounted and powered in a physical location other than the probe card 104 to facilitate simple connection to auxiliary equipment . other combinations of command / control modules can be included in alternative embodiments of the tester . 4 . bist control and diagnostics module — allows the twb 122 to control and interact with a built in self test engine designed into the dut . this bist control module is programmable so that different bist engines can be controlled by reprogramming the bist control module . this module also permits diagnosis of design and implementation flaws in the bist engine within the dut . 5 . current measurement module — allows current measurements to be performed on the dut . 6 . analog data stimulus and acquisition module — allows digitization and capture of analog data output from the dut . also allows analog voltages , either static or time - varying , to be driven into the dut . 7 . specific radio frequency standard interface module — each such type of module is tuned to a specific radio frequency standard , such as 3g wireless telephony or 802 . 11 g wireless networking standard . depending upon the design of the dut , one or more such modules would be selected from a large selection of available modules . however , various other modules which operate within this architecture also can be included . the modules 108 described above have a common architecture , and are distinguished from one another by unique circuitry which is added to the common elements . a block diagram of the module architecture is shown in fig2 . the module consists of a network interface 202 , a controller 204 , a controller program store 206 , a test memory 208 , a tester synchronization bus ( tsb ) interface 214 , a connector 212 and a module - unique circuitry 210 . the function of these elements is described below . 1 . network interface ( 202 )— connects the module to the wired or wireless network so that the module can be controlled by software resident on a remote computer . 2 . controller ( 204 )— provides overall control of the module and serves as the communication conduit for communication with external objects on the network . 3 . stored program ( 206 )— the program which operates and controls the module is stored here , and can be updated over the network . 4 . test memory ( 208 )— is used to store the test data which will be driven into the dut and also to store the outputs of the dut which might be recorded for later evaluation . 5 . module - unique circuitry ( 210 )— this is the unique circuitry which implements the functions described earlier for the various module types available . 6 . connector ( 212 )— allows the module to be plugged into the probe card 104 on which matching sockets 106 are installed . even though these functions are shown as separate blocks in fig2 alternative implementations of the tester architecture can combine one or more of these blocks into a single block . after testing die on the semiconductor wafer , the wafer is cut up into individual die . these are then installed into a protective package and the electrical contact pads on the die are connected to electrical contact points on the package which can be variously known as pins , pads or bumps ( depending upon the style of package used ). once this process has been completed , it is again necessary to test the packaged die to verify that the process of packaging has not ruined it , and also to verify that the additional interconnect ( from the die to the package ) is correct and does not degrade the performance of the overall package to an unacceptable degree . to facilitate this testing , the described tester architecture incorporates the paradigm of using the same modules as were used during die testing on the semiconductor wafer . this is depicted in fig3 . [ 0087 ] fig3 shows a printed circuit board ( pcb ) 300 on which are mounted module sockets 304 ( these are the same sockets as the sockets 106 in fig1 ), into which are installed tester modules 306 , which are the same modules as the fig1 modules 108 . the module / socket combinations are networked together via the network 310 ( which can be either wired or wireless , even though the wired version is shown here ), and are also connected to the tester synchronization bus 308 ( which is the same as the tester synchronization bus 118 in fig1 ). the pcb also contains a dut - socket 300 into which the packaged die will be installed for testing . a computer 312 running control software 314 is also connected to the network 310 to manage and control the testing process . in order to perform testing , a mechanical handler places each chip to be tested into the dut - socket 302 . the control software 314 is informed ( or senses ) when the chip is correctly installed in the dut - socket 300 and initiates testing . upon completion of testing , the results are extracted from the modules 306 , and the mechanical handler is instructed to remove the tested chip and replace it with another . in an alternate embodiment , the dut - socket 302 may be mounted on the opposite side of the printed circuit board 300 as the side on which the module sockets 304 , modules 306 are mounted to facilitate integration with the mechanical handler . the sockets can be mounted in other configurations in alternative embodiments of the tester architecture . in yet another embodiment , the modules 306 would be mounted in a sub - assembly ( enclosed or otherwise ) which would be installed into an existing packaged part handler for the purpose of testing packaged devices . [ 0091 ] fig4 shows the synchronization bus 118 ( fig1 ) and 308 ( fig3 ) used in the embodiment of the tester system architecture 100 of fig1 . the main purpose of the tsb is to maintain synchronization across all the test modules in the tester system architecture to guarantee an accurate test of a particular dut . with the synchronization bus , the tester system architecture achieves synchronization with the use of phase - locked clocks . two clocks are used , a high frequency and a lower frequency clock . the system relies on the phase - locked nature of the circuit and careful pcb signal routing to achieve the desired clock edge alignment . in addition to synchronizing the reference clocks of the individual modules , the synchronization bus also operates to guarantee the alignment of single pulse events such as the start and halt of the dut test , or capturing of test failures , and any additional proprietary information that needs to be communicated from module to module within a test clock cycle . this is achieved by using a combination of single bussed signals and a time - division multiplexed bus , consisting of a reference clock , a frame pulse and the data bus . the tester system architecture just described can include various possible arrangements of the tester system resources . these variations include , without limitation , direct control by the test system controller of the modules in a test system ( as in the first example variation of the tester system shown in fig5 ), or the interpretation and retransmission of commands and information by a local test head controller ( as in the second example variation of the tester system shown in fig6 ). further , in the embodiment described above and shown in fig1 - 3 , the tester system architecture is arranged with the modular tester resource units all located on the probe card or load board within a test head . while in some other variations of the tester system architecture , some of the test modules may be located external to a testhead . in first and second example variations of the tester systems ( fig5 and 6 ) described below , some test instrumentation modules may be present on the dut probe card or load board and are under the control of the test system via a module network connection . [ 0096 ] fig5 shows a first example variant 500 of the tester system architecture 100 ( fig1 ) that employs a “ flat ” variation of the system architecture . more specifically , in this flat version of the system architecture , the test system controller communicates directly with every module in the system . also , in this first example variation 500 , modules located externally to the testhead chassis are physically connected to the dut card . [ 0097 ] fig6 depicts a second example variant 600 in which the tester system architecture 100 ( fig1 ) is hierarchical . in this case , the test system controller communicates with multiple test head controllers provided in the separate test heads , so as to improve the efficiency and throughput of the overall test system . the test head controllers can themselves be test modules of the architecture 100 . [ 0098 ] fig7 depicts a third example variant 700 , which uses another standard control mechanism ( e . g ., the ieee 1149 . 1 standard test access port , described in “ ieee std 1149 . 1 - 1990 ieee standard test access port and boundary - scan architecture ,” ieee , 1990 ) in conjunction with the tester system architecture 100 ( fig1 ) to facilitate certain dut control requirements . for example , the tester system architecture can switch the dut into the “ test ” state , and thus activate a high speed test interface and protocol on the dut . in this way , the tester architecture 100 can maintain compatibility with other standards including , for example , the ieee p1500 standard for embedded core test of the ieee p1500 working group on a standard for embedded core test ( sect ), and other ic test standards . the third example variant of the tester system architecture 100 does not limit testing of the dut to a particular time or location . for example , once the device has been inserted into a pc board , it can still be placed into test mode and its port accessed . [ 0099 ] fig8 shows a further example variant 800 of the tester system architecture 100 that supports the ability for the test system to collect data from multiple duts in large quantities during production test while minimally impacting the test throughput time . while the tester system architecture is not limited to such applications , a typical application of this example variation of the tester system architecture is to conditionally collect detailed information for all failing devices to support rapid analysis and isolation of the cause of the failures . this is in contrast to traditional ate system architectures which are optimized for “ go / no - go ” testing , and do not typically provide the ability to collect large amounts of diagnostic data on the fly . in the variant 800 , a storage module initially stores diagnostic data . the storage module can be implemented in a variety of ways , ranging from memory embedded in a test module to a dedicated storage device such as a disk drive . the dut diagnostic data is logged via a high speed path , such as a dma channel to minimize impact on test throughput . the data can then be unloaded more slowly over the module network to the test system controller for analysis after a series of devices have been tested . in view of the many possible embodiments to which the principles of our invention may be applied , we claim as our invention all such embodiments as may come within the scope and spirit of the following claims and equivalents thereto .