[go: up one dir, main page]

WO2009004608A2 - Gestion de journaux de données dans le test des semiconducteurs - Google Patents

Gestion de journaux de données dans le test des semiconducteurs Download PDF

Info

Publication number
WO2009004608A2
WO2009004608A2 PCT/IL2008/000768 IL2008000768W WO2009004608A2 WO 2009004608 A2 WO2009004608 A2 WO 2009004608A2 IL 2008000768 W IL2008000768 W IL 2008000768W WO 2009004608 A2 WO2009004608 A2 WO 2009004608A2
Authority
WO
WIPO (PCT)
Prior art keywords
test
datalog
testing
manager
logging
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/IL2008/000768
Other languages
English (en)
Other versions
WO2009004608A3 (fr
Inventor
Eran Rousseau
Igal Gurvits
Reed Linde
Gil Balog
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
OptimalTest Ltd
Original Assignee
OptimalTest Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by OptimalTest Ltd filed Critical OptimalTest Ltd
Publication of WO2009004608A2 publication Critical patent/WO2009004608A2/fr
Anticipated expiration legal-status Critical
Publication of WO2009004608A3 publication Critical patent/WO2009004608A3/fr
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/22—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
    • G06F11/2268—Logging of test results

Definitions

  • This invention relates to semiconductor device testing and more specifically to the logging of test data ("data-logging").
  • test capacity is an inverse function of test time, since test capacity is the volume of material (i.e. number of semiconductor devices) that can be processed through a factory test operation within a fixed period of time, given the available test equipment and test times for that operation.
  • the desire to increase capacity may therefore provide motivation to reduce the amount of test data collected through datalogging.
  • data logged during testing is critical to the kind of analysis involved in many semiconductor manufacturing improvement activities, including test time reduction, yield improvement, quality and reliability improvement, design improvements, etc., there is motivation to maintain data-logging, and in some cases even to increase data-logging.
  • test data relating to some material is logged, while test data relating to other material is not logged).
  • test on which data is logged i.e. a test which is data-logged
  • test that is not data-logged may in some cases produce no output at all, or may in some cases simply produce a failure indicator in the event of test failure.
  • a test that is data-logged may in some cases produce detailed information about the test results, often even when the device has passed all test conditions. For example, in the absence of datalog the output of a test of a device' s power consumption might simply be a pass/fail indicator of whether or not its power use exceeds specifications.
  • test is data-logged, a measurement of the actual power level consumed by the device is made and recorded in this example.
  • a test may be developed to determine the maximum or the minimum power supply voltages under which a device remains functional, and the resulting power supply voltage values obtained in this test may be data-logged.
  • a device may be tested through a sequence of various test conditions, and rather than simply terminating with a pass/fail indicator of the device's compliance to the set of test conditions, the identity of any specific conditions under which the device failed to operate correctly might be data- logged.
  • a system for managing logging of semiconductor test data comprising: handling equipment configured to prepare a semiconductor device for testing; a datalog generation tool configured to log data relating to semiconductor testing; and a datalog manager configured to at least occasionally allow the datalog generation tool to log data while the handling equipment is preparing the device for testing.
  • a module for managing datalog comprising: at least one interface configured to at least receive a first indication that a device is being prepared for testing and a second indication that the device is ready for testing; and a datalog manager control engine configured to schedule logging of data based at least partly on any received first and second indications.
  • a method of managing logging of semiconductor test data comprising: allowing logging of semiconductor test data during at least part of a time interval in which a group of at least one device is being prepared for testing by handling equipment.
  • a system for managing logging of semiconductor test data comprising: a tester operating system and test program server associated with a test site controller configured to test at least one device, the at least one device being tested in parallel with at least one other device; a datalog generation tool configured to log data relating to semiconductor testing; and a datalog manager configured to at least occasionally allow the datalog generation tool to log data relating to the test site controller after the at least one device has completed testing but testing is continuing at any of the at least one other device.
  • a method of managing logging of semiconductor test data comprising: testing devices in parallel at test sites associated with test site controllers; and allowing logging of semiconductor test data relating to one of the test site controllers during at least part of a time gap between testing completion at all test sites associated with the one test site controller and testing completion at all test sites associated with the test site controllers.
  • a module for managing datalog comprising: at least one interface configured to at least receive an indication that testing has completed at all test sites associated with a test site controller; and a datalog manager control engine configured to at least occasionally allow logging of data relating to the test site controller after the indication has been received while testing is continuing at at least one other test site associated with a different test site controller.
  • a computer program product comprising a computer useable medium having computer readable program code embodied therein for managing logging of semiconductor test data, the computer program product comprising: computer readable program code for causing the computer to allow logging of semiconductor test data during at least part of a time interval in which a group of at least one device is being prepared for testing by handling equipment.
  • a computer program product comprising a computer useable medium having computer readable program code embodied therein for managing logging of semiconductor test data
  • the computer program product comprising: computer readable program code for causing the computer to test devices in parallel at test sites associated with test site controllers; and computer readable program code for causing the computer to allow logging of semiconductor test data relating to one of the test site controllers during at least part of a time gap between testing completion at all test sites associated with the one test site controller and testing completion at all test sites associated with the test site controllers.
  • Figure 1 is a block diagram of a system for testing semiconductor devices and logging test data, according to an embodiment of the present invention
  • Figure 2 is a conceptual illustration showing the indexing of packaged devices into a test socket on a loadboard at a final test operation, according to an embodiment of the present invention
  • Figure 3 is a sample of ASCII data relating to the testing of semiconductor devices, according to an embodiment of the present invention.
  • Figure 4 is a block diagram of a datalog manager, according to an embodiment of the present invention.
  • Figure 5 (comprising Figure 5 A and Figure 5B) is flowchart of a method of managing data-logging, according to an embodiment of the present invention
  • Figure 6 is a flowchart of another method of managing data-logging, according to an embodiment of the present invention.
  • Figure 7 is a flowchart of another method of managing data-logging, according to an embodiment of the present invention.
  • Some embodiments described herein minimize or render negligible the amount of time that data-logging adds to the time required for processing semiconductor devices under test, thereby optimizing processing time (i.e. throughput time) and test capacity.
  • the optimization may be achieved without requiring any significant reduction in the amount of datalog data being processed and/or any significant increase in system hardware costs (for example without requiring more computational "horse-power" obtained through hardware enhancements such as upgrading the CPU to one with higher performance, adding additional CPU's, adding more memory, etc).
  • a computer,, processor or similar electronic computing system may manipulate and/or transform data represented as physical, such as electronic, quantities within the computing system's registers and/or memories into other data, similarly represented as physical quantities within the computing system's memories, registers or other such information storage, transmission or display devices.
  • Embodiments of the present invention may use terms such as, processor, device, tool, interface, computer, apparatus, memory, controller, console, system, element, sub-system, server, engine, module, manager, component, program, ' prober, handler, unit, equipment, etc, (in single or plural form) for performing the operations herein.
  • These terms, as appropriate, refer to any combination of software, hardware and/or firmware configured to perform the operations as defined and explained herein.
  • the module(s) may be specially constructed for the desired purposes, or it may comprise a general purpose computer selectively activated or reconfigured by a program stored in the computer.
  • a program may be stored in a readable storage medium, such as, but not limited to, any type of disk including optical disks, CD-ROMs, magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), electrically programmable read-only memories (EPROMs), electrically erasable and programmable read only memories (EEPROMs), magnetic or optical cards, any other type of media suitable for storing electronic instructions that are capable of being conveyed, for example via a computer system bus.
  • Systems, methods and modules described herein are not limited to testing of particular types of semiconductor devices, and may be applied to CPU's, memory, analog, mixed-signal devices, and/or any other semiconductor devices.
  • testing of the semiconductor devices may occur through, use of automated electronic test equipment, potentially in combination with BIST (Built-in Self-Test) circuitry.
  • BIST Built-in Self-Test
  • the systems, methods and modules described herein can benefit wafer-level sort operations, strip-test operations, final test package-level test operations, multi-chip-package module-level test operations, and/or any other test operations.
  • devices refers to semiconductor devices and may refer to the semiconductor devices at any stage of the manufacturing process (fabrication and/or testing), and is therefore not limited herein to any particular stage.
  • the devices are commonly called dice when in wafer form.
  • the devices are commonly called packaged parts or packed devices in final test.
  • Systems, methods and modules described herein can be applied to any semiconductor test environment depending on the embodiment, including inter-alia sequential and/or parallel (synchronous and/or asynchronous) test environments.
  • system 100 for testing semiconductor devices and logging test data, according to an embodiment of the present invention is illustrated. Only elements pertinent to embodiments of the invention are shown, for simplicity of illustration. Each element in Figure 1 is named in the single form for ease of description, but should be understood to include embodiments where there is a single or a plurality of that element in system 100.
  • system 100 includes a test system controller 110, N test site controllers 115 (N ⁇ l), a test operations console 135, handling equipment 150, and an interface unit 160.
  • test system controller 110, 115, 135, 150 and/or 160 may be made up of any combination of software, hardware and/or firmware that performs the functions as defined and explained herein.
  • system 100 may comprise fewer, more and/or different elements than shown in Figure 1. In one embodiment, system 100 may include additional, less and/or different functionality described herein. In one embodiment, any of elements 110, 115, 135, 150, and/or 160 may include additional, less and/or different functionality than described herein. Depending on the embodiment, elements 110, 115, 135, 150, and/or 160 may be concentrated or dispersed.
  • handling equipment 150 communicates with test system controller 110.
  • the communication between handling equipment 150 and test system controller 110 may occur, for example, via parallel digital communication, RS -232 serial communication, a Transmission Control Protocol/Internet Protocol TCP/IP network, a GPIB bus (General Purpose Interface Bus), also known as a IEEE-488 or HP-IB bus (Hewlett-Packard Instrument Bus), or by any other means of communication.
  • GPIB bus General Purpose Interface Bus
  • IEEE-488 also known as a IEEE-488 or HP-IB bus (Hewlett-Packard Instrument Bus
  • devices are tested a single one at a time, sequentially, whereas in another embodiment, several are tested at the same time "in parallel”.
  • a plurality of devices being tested in parallel is sometimes referred to as a "touchdown”.
  • the term “touchdown” is used because interface unit 160 (for example, at wafer sort - a probecard 160a, or at final test - the loadboard 160b) usually "touches" the plurality of devices under test to make electrical contact.
  • the physical touching however is not necessary for embodiments of the invention, and in some cases instead of a physical contact there may be, for example, an electrical inductive coupling with interface unit 160.
  • contact refers to an electrical pairing between device(s) under test and interface unit 160 including inter- alia: physical contact, electrical inductive coupling or any other appropriate electrical pairing.
  • handling equipment 150 in the case of a wafer sort test operation, where wafer-level testing of devices is being performed, handling equipment 150 includes a wafer prober 150a and interface unit 160 includes probecard 160a.
  • prober 150a includes a prober chuck which provides mechanical support and thermal stability to a wafer which sits on the chuck while being sorted.
  • handling equipment 150 at a final test operation, after the wafer has been sawed-up to separate individual devices and those devices have been placed in packages, handling equipment 150 includes a unit handler 150b and interface unit 160 includes a loadboard 160b.
  • one or more devices may in one embodiment be electrically contacted with interface unit 160 during testing, allowing testing to occur either on individual devices, sequentially, or on multiple devices at a time, in parallel.
  • handling equipment 150 may represent equipment for placing devices in electrical contact with interface unit 160 for a "strip test" operation, in which devices are tested at an intermediate stage of assembly, after having sawed-up wafers to singulate and mount individual die on package leadframes, but before singulating the individual packaged units.
  • handling equipment 150 may be any suitable commercially available prober or handler including inter-alia: Tel P8i, Tel P12xl (both manufactured by Tokyo Electron Limited, headquartered in Tokyo, Japan), Advantest 4741, and Advantest M4841 (the latter two manufactured by Advantest Corporation, headquartered in Tokyo, Japan).
  • the group that is being prepared may include a single device which will be tested at a time or may include a plurality of devices which will be tested in parallel. Therefore, the term "group” should be understood herein below to include one or more devices.
  • Preparing action(s) and time(s) associated with these action(s) are referred to herein below as “preparing”, “preparation”, or using similar terms.
  • preparing actual testing (Le. execution of test program(s)) is halted.
  • the time for preparing therefore represents an additional overhead time which adds to the total time required to process semiconductor devices under test.
  • handling equipment 150 may prepare a group (of one or more devices) for testing by any of the following activities, inter-alia: removing a group of previously tested devices from electrical contact with interface unit 160, unloading a batch of previously tested devices, loading a batch of untested devices which includes the .group which is being prepared for testing, placing the group which is being prepared for testing in electrical contact with interface unit 160, and/or indexing.
  • the term batch should be understood to refer to a set of devices undergoing testing together and in various embodiments may refer to a wafer, a cassette, a package holder of packaged devices, any other set of devices, or a combination of sets.
  • handling equipment loading or unloading a batch may refer to handling equipment loading or unloading a wafer, a cassette, a package holder, etc.
  • the physical format of a package holder depends on the type of packages used to assemble the devices. For example, for DIP (dual in-line packages), the devices from a lot are batched into “tubes" for final test; for TSOP (thin small outline packages), the devices are batched into "trays”.
  • Another example of a package holder is the "matrix carrier", batching BGA ("ball grid array packages"), for example, in such a way to facilitate parallel testing.
  • the type of package holder is not limited by the examples and may comprise any suitable type.
  • the handling solution depends on the nature of the package.
  • the next group to be placed in electrical contact with interface unit 160 may be from the same batch or from a different batch.
  • indexing refers to the action (and time associated with the action) in which handling equipment 150 removes a tested group from electrical contact with interface unit 160 and places another group from the same wafer or package holder in electrical contact with interface unit 160, thus preparing the other group for testing. Therefore indexing may conceptually be considered to comprise a combination of two actions, removing one group from electrical contact and placing another group into electrical contact, where the groups are from the same wafer or package holder.
  • indexing is illustrated, for example, for a final test environment in Figure 2, according to an embodiment of the present invention.
  • the conceptual illustration of Figure 2 is not necessarily typical of a test environment.
  • a sequence of three devices - 230, 240, and 250 respectively, are placed consecutively into Test Socket -220 (located on Loadboard 160b) for testing.
  • the time required to remove the device that has just completed test and replace it with the next device requiring test is the indexing time.
  • indexing time is of fixed duration for the specific handling equipment 150 used (whether prober 150a, handler 15Ob 5 and/or other).
  • indexing occurs at wafer sort, in a sequential (non- parallel) test environment where devices are tested one after the other.
  • prober 150a when a device completes testing, prober 150a will move the wafer so that the next device to be tested will be contacted by probecard 160a.
  • prober 150a at wafer sort, in a parallel test environment, when devices tested together in the same touchdown have completed testing, prober 150a will move the next touchdown to be tested in place to be electrically contacted by probecard 160a.
  • interface unit 160 and/or a plurality of devices mounted on a strip (a packaging leadframe or substrate) that are to be tested in parallel must be put into position for electrical contact before testing may begin.
  • the indexing time adds to the total time required to process a batch of devices under test, and therefore to the total processing time required to process a lot. It should be noted that the indexing will, by necessity, take place at a different time than the execution of the test program(s) 120 by the tester operating system and module control(s) 105 (see description below). During indexing, actual testing (i.e. execution of test program 120) is not performed, since during that time one group is being removed from electrical contact and another group is being placed into electrical contact with interface unit 160.
  • preparing may include other times during which actual testing is necessarily halted in addition to indexing.
  • interface unit 160 may temporarily break contact with device(s) to be tested at the point in the wafer sort operation during which wafers are being exchanged (i.e., completed wafers are • being unloaded from prober 150a and wafers requiring test are being loaded).
  • interface unit 160 may temporarily break contact with devices to be tested at the point in the final test operation during which holders of packaged parts are being exchanged by handler 150b.
  • test system controller 110 is the overall controller of the testing, including inter-alia the coordination of testing by N (N ⁇ l) test site controllers 115 (of which one is illustrated in Figure 1).
  • test system controller 110 coordinates communications among test site controllers 115 (assuming more than one).
  • test system controller 110 alternatively or additionally coordinates communication between test site controllers) 115 and handling equipment 150.
  • test system controller 110 alternatively or additionally supports operations relating to more than one test site controller 115, for example relating to all test site controllers 115 in one of these embodiments.
  • test operations console 135 is manned by test engineers and/or test operation technicians, allowing manual control of the processing of the devices under test.
  • test operations console 135 is the interface by which test engineers or test operation technicians may manually enable or disable datalog relating to any of the test site(s), as desired.
  • test system controller 110 test operations console
  • test site controller 115 refers to control resources dedicated to one or more devices under test, at one or mote test sites.
  • a single test site may refer to one out of a plurality of test sites in a parallel test environment or may refer to the one test site in a sequential test environment.
  • handling equipment 150 provides for example a set of probes located on probecard 160a or a socket located on loadboard 160b.
  • each of the N test site controllers 115 operates independently of one another.
  • test site controller 115 includes a tester operating system and test program server 105, a test program 120, a datalog manager 170, and a datalog generation tool 130.
  • Each of elements 105, 120, 130 and/or 170 may be made up of any combination of software, hardware and/or firmware that performs the functions as described and explained herein.
  • test site controller 115 may include fewer, more and/or different elements than shown in Figure 1.
  • the functionality of test site controller 115 may be divided differently among elements 105, 120, 130 and 170.
  • test site controller 115 may include additional, less, and/or different functionality than described herein.
  • any of elements 105, 120, 130 and/or 170 may have additional, less, and/or different functionality than described herein.
  • a test execution run for one or more test sites controlled by test site controller 115 includes one or more individually executed tasks forming a sequence of test execution events.
  • (raw) data is generated by test program 120 via an event-based mechanism.
  • test-related (raw) data may be generated by tester operating system and test program server 105 outside of test program 120 execution via an event based mechanism.
  • tester operating system and test program server 105 may produce a stream of identifying raw data, such as test site identity, device identity, test execution time/duration, test program name and so forth. Then during test program 120 execution, elements of the individual tests in test program 120 may produce additional (raw) data in this example. Each piece of raw data is associated with a test event in one embodiment.
  • the associated event may be for example an operation (a subroutine, a module) within one of the tests within test program 120, or for example an operation external to test program 120, such as reading a system clock or reading data previously stored from a data-entry operation, etc.
  • tester operating system and test program server 105 (in at least two test sites) controlled by a particular test site controller 115, those devices may be individually selected or deselected during testing.
  • tester operating system and test program server 105 (included in particular test site controller 115) generates signal sequences that simultaneously control the test sites of all selected devices associated with the particular test site controller 115. hi these embodiments, testing between selected devices is therefore synchronized.
  • device-specific test conditions are to be performed, all devices but one are deselected and the one remaining selected device is tested.
  • raw data is generated for each device associated with the particular test site controller 115 separately, for example sequentially for each device.
  • the generated raw data relating to test site controller 115 (regardless of the number of device(s)/test site(s) associated with test site controller 115) is available for datalog generation tool 130 associated with test site controller 115).
  • datalog generation tool 130 supports "pause and resume functions", and therefore datalog by datalog generation tool 130 relating to a test site may be managed, for example allowed or disallowed by a datalog manager 170 associated with the test site (see below). Li one of these embodiments, datalog generation tool 170 is customized for test site controller 115 or test system controller 110. ⁇
  • the raw data generated by tester operating system and test program server 105 and/or by test program 120 of test site controller 115 is temporarily stored in native format in local memory at test site controller 115 prior to being retrieved by the associated datalog generation tool 130 when allowed by the associated datalog manager 170 (as described further below).
  • the associated datalog generation tool 130 is temporarily stored in native format in local memory at test site controller 115 prior to being retrieved by the associated datalog generation tool 130 when allowed by the associated datalog manager 170 (as described further below).
  • datalog generation tool 130 is the creation of the sequential stream of datalog data from the raw data. For example, in some of these embodiments, datalog generation tool 130 collects/retrieves raw data, reformats the data into a predetermined data output format, and creates a datalog data stream in event order. Continuing with the example, hi one of these embodiments, based on the available information for a test site, such as whether datalog is allowed/not allowed (discussed below), which raw data are available, what type of information the raw data represent, and the order in which the events that generated the raw data occurred, datalog generation tool 130 manages the task of collecting/retrieving, sequencing, and formatting the raw data relating to test-site(s) controlled by associated test site controller(s) 115.
  • the datalog stream holds the event records in the order in which the events occurred.
  • each event record contains all the attributes which are related to the event.
  • the datalog stream produced by each datalog generation tool 130 is transferred to test system controller 110.
  • test operations console 135 transfers data which are not derived from the actual testing to test system controller 110.
  • data transferred by test operations console 135 may include data manually entered into test operations console 135 (for example in one embodiment, any of the following inter-alia, wafer numbers, fabrication process origin, fabrication plant origin, handling equipment identity, interface unit identity, test module identity, etc) , and/or data automatically generated which associates the lot number with various lot specific information (for example in one embodiment any of the following, inter-alia: wafer numbers, fabrication process origin, fabrication plant origin, etc.).
  • test system controller 110 receives datalog stream(s) from the datalog generation tool(s) 130 associated with the N test site controllers) 115 and receives data from test operations console 135.
  • test system controller 110 combines and stores the received datalog stream(s) and data from test operations console 135.
  • storage may be provided in a non volatile memory such as a hard disk attached to test system controller 110 or a hard disk connected via a communication network.
  • the format and content of the datalog data stream generated by any datalog generation tool 130 may vary between different semiconductor devices tested, being a function, for example, of a test site controller's specific test program 120 , the configuration of tester operating system and test program server 105, and/or the- functions or settings supported by datalog generation tool 130 used to generate the datalog stream, etc.
  • datalog formats currently used in creating a datalog stream. For example, some are binary, while others are ASCII (see below the example of Figure 3).
  • STDF Standard Test Datalog Format
  • ATDF ASCII Test Datalog Format
  • Datalogs of various formats, both standardized and custom may be created by any datalog generation tool 130, depending on the embodiment. Embodiments of the present invention, described herein, are not limited to any particular datalog format.
  • the received data include datalog stream(s) generated by one or more datalog generation tool(s) 130 from a sort test operation for three devices and lot-level data provided by test operations console 135.
  • the illustrated received data are not necessarily typical in either format or content.
  • the received data shown in Figure 3 are in ASCII format for the purposes of readability.
  • Pre-Test Lot- Level Data 310 shown here includes fabrication plant identity "FabOl”, fabrication process identity “POA”, lot identity “ABCDOOOl”, wafer identity "100", sort sequence/step identity “1", manufacturing operation identity "1000", test program identity "PGBaalOO", test step temperature “OC”, tester hardware identity "GX415", prober hardware identity "TeMlS”, probecard hardware identity "PGBPCOOl", and the time and date the test process began "153008082005” (i.e., 3:30pm, August 8 th , 2005). Following next are data-sets derived from the testing of three devices - 320, 330, and 340 respectively.
  • the data-set associated with each device 320,330, 340 includes delimiting text ("start_die” and "end_die) indicating -where each device's data begin and end, as well as coordinates providing the location of each device within the wafer ("Xaxis” and "Yaxis” data). Data specific to each device acquired during testing are also included, involving various items such as power supply performance, leakage, test time, and pass/fail test results. Note that the set of data included for each device may vary, as illustrated by parameters shown in device 320 dataset that are not found in the dataset of device 330, and parameters shown in device 340 dataset that are not found in the dataset of devices 320 or 330. Finally, Post-Test Lot-Level Data 350 concludes the example, consisting simply of the time and date that the test process ended "154508082005" (i.e., 3:45pm, August 8 th , 2005).
  • test programs 120 associated with different test site controllers 115 may be the same or different depending on the embodiment. Even in an embodiment where the same test program 120 is executed for a plurality of test site controllers 115, there may or may not be concurrent execution of the test program 120, depending on the embodiment.
  • a separate datalog manager 170 manages data-logging related to each test site controller 115 as illustrated in Figure 1, allowing independent management of the data-logging. In some of these embodiments, having separate datalog managers 170 associated with each test site controller 115 acknowledges the possibility of multiple test programs 120 and/or non-concurrent execution of test programs 120 for the various test site controllers 115.
  • a single datalog manager 170 may manage data-logging for a plurality of test site controllers 115 or for all N test site controllers 115.
  • the position in system 100 of a datalog manager 170 responsible for managing datalog for at least one test site controller 115 may vary depending on the embodiment, for example located within one test site controller 115 and providing datalog management for the associated test site(s), having a location relating to a plurality of test site controllers 115 and providing datalog management for the plurality of associated test sites, located on test system controller 110 and providing datalog management for all test sites, located fully or partially outside of test system controller 110 and test site controller 115, etc.
  • test operations console 135 may input indications independently into each of the plurality of datalog manager 170 or independently into a subset of the plurality of datalog managers 170, whereas in another embodiment, any indications from test operations console 135 are inputted into all of the plurality of datalog managers 170.
  • an indication from test operations console 135 inputted into a particular datalog manager 170 may relate to all test site(s) associated with the particular datalog manager 170 or selectively relate to test site(s) associated with the particular datalog manager 170.
  • each datalog generation tool 130 may generate a datalog stream relating to a different test site controller 115 or one datalog generation tool 130 may generate a datalog stream relating to a plurality of test site controllers 115.
  • each test site controller 115 is associated with one tester operating system and test program server 105, one datalog manager 170 and one datalog generation tool 130.
  • datalog manager 170 controls the associated datalog generation tool 130 so that data-logging is at least occasionally allowed while handling equipment 150 is preparing a group of one or more devices for testing.
  • datalogging may or may not overlap completely with all the preparation intervals occurring during the processing of devices under test.
  • data-logging may only be allowed during certain type(s) of preparation, for example in one embodiment concurrently with indexing.
  • datalogging is allowed to occur during operations in which individual wafers are being exchanged (i.e., completed wafers are being unloaded from the prober and wafers requiring test are being loaded), in addition to or instead of data-logging during indexing.
  • data-logging is allowed additionally or alternatively during operations in which batches of packaged devices (for example package holders) are being exchanged.
  • data log may also or alternatively be allowed during preparation in "strip test" operations.
  • data-logging may also or alternatively be allowed during other preparing activities.
  • data-logging during particular preparation interval(s) or during all preparation intervals may be overridden, for example in one embodiment by a manual indication from test operations console 135.
  • data-logging during particular preparation interval(s) or during all preparation intervals may be allowed for some of the test sites but may be disallowed for other test sites, for example due to a manual override indication.
  • data-logging may not be allowed while preparation is taking place because there is no data to be logged.
  • any data-logging which is performed concurrently with preparing has little or no impact on the length of time it takes handling equipment 150 to prepare for testing, and therefore has little or no impact on the total processing time.
  • test site controller(s) 115 may be completely idle or partially idle when handling equipment 150 is preparing a group for testing.
  • test site controller(s) 115 may not be completely idle during preparing, for example sending the bin (test result) when the current device(s) has completed testing.
  • actual testing is not occurring, (i.e. test program(s) 120 are not being executed by tester operating system and test program server(s) 105 ) while handling equipment 150 is preparing a group for testing, in some embodiments test site controller(s) 115 has resources available which can potentially be used for data-logging.
  • a particular datalog manager 170 controls the associated datalog generation tool 130 so that data-logging related to test site(s) controlled by the associated test site controller 115 is at least occasionally allowed during the "time lag" after testing has been completed at all associated test site(s) but testing is continuing at one or more test site(s) controlled by other test site controller(s) 115.
  • time lag is used to connote the difference in time between completion of testing by the various test site controllers 115.
  • data-logging may or may not overlap completely with all time lags occurring during the processing of devices under test.
  • data-logging related to a particular test site controller 115 which is initiated after testing completion by that test site controller 115 may be completed prior to the completion of testing for all test sites, and therefore may not overlap completely with the time lag between test completion by that test site controller 115 and test completion at all test sites.
  • data-logging during time lags when testing particular touchdown(s) or during time lags when testing each touchdown may be overridden, for example in one embodiment by a manual indication from test operations console 135.
  • data-logging relating to particular test site(s) during time lag(s) when testing particular touchdown(s) or during each time lag when testing each touchdown may be allowed, but data-logging relating to other test site(s) during time lag(s) when testing those particular touchdown(s) or during each time lag when testing each touchdown may be disallowed, for example in one embodiment by to a manual override indication.
  • data-logging may not be allowed during a particular time lag because there is no data to be logged.
  • the resources for testing at different test site controllers 115 are independent of one another, there are resources available which can potentially be used for data-logging related to a particular test site controller 115 when actual testing is not occurring at associated test site(s), regardless of the testing status at other test site(s). In one of these embodiments therefore, data-logging relating to test site(s) controlled by a particular test site controller 115 which, occurs during the time lag between the time that testing ends at all test site(s) associated with that particular test site controller 115 and testing ends for all the test sites, has little or no impact on the total processing time.
  • no data-logging is allowed during actual testing.
  • data-logging may occur, at least sometimes, during actual testing.
  • an over-riding enable indication from test operations console 135 may allow data-logging associated with one or more test sites during actual testing.
  • data-logging that began during preparing and/or during a time lag may continue during testing for remaining raw data.
  • data-logging may be at least occasionally allowed at any stage of the processing, for example, during preparing, testing and/or during any time lag when waiting for testing to end at the other test site(s).
  • a time period dedicated to data-logging may be inserted between completing actual testing of a first group and preparing a next group for testing.
  • the data-logging period adds to the total processing time.
  • preparing a next group for testing follows as soon as possible after actual testing is completed on a first group.
  • Figure 1 may vary.
  • communication between handling equipment and test system controller 110 may include "handling status" indications which in some cases are used for managing datalog.
  • handling status indications sent from handling equipment 150 to test system controller 110 may include any of the following indications inter-alia: "in-contact” indications, where an in-contact indication indicates that a group of devices has been placed in electrical contact with interface unit 160 and is ready for test, and/or "end-of-batch” indications (for example end-of- wafer” indications or "end-of-cassette” indications), where an end-of-batch indication indicates that there are no remaining untested devices in the batch.
  • handling status indications sent from test system controller 110 to handling equipment 150 may include inter-alia a "break-contact” indication, when testing of all devices in the group has been completed.
  • the "in-contact” indication may be identical to a "start test” indication generated by handling equipment 150 when a group of devices is ready for testing as is known in the art.
  • the "break-contact” indication may be identical to an "end-of-test” indication transferred to handling equipment 150 when testing has ended as is known in the art.
  • handling status indications sent between test system controller 110 and handling equipment 150 are also provided to each datalog manager 170 in system 100.
  • test system controller 110 may provide handling status indications to each datalog manager 170 directly or via the associated tester operating system and test program server 105 and/or handling equipment 150 may provide handling status indications to each datalog manager 170 directly or via the associated tester operating system and test program server 105.
  • the status of testing at each test site controller 115 may be provided by each tester operating system and test program server 105 to the associated datalog manager 170.
  • an "end-of-site-test" indication is provided by each tester operating system and test program server 105 to the associated datalog manager 170 when testing has completed at all test site(s) controlled by associated test site controller 115.
  • each tester operating system and test program server 105 provides an "end-of-site-test" indication to test system controller 110 when testing at all test site(s) controlled by associated test site controller 115 has ended, and once all devices in the group have completed testing, test system controller 110 generates the break-contact indication.
  • the end-of-site-test for the last test site controller 115 to complete testing is substantially coincident with the generation of the break-contact indication.
  • test site there is more than one device (test site) associated with a particular test site controller 115
  • there may be an indication provided each time one of the devices finishes testing with datalog manager 170 and/or test system controller 110 recognizing when the indication for the last device associated with the particular the test site controller 115 to finish testing has been provided.
  • tester operating system and test program server 105 provides test site testing status indications
  • tester operating system and test program server 105 provides an end- of-site-test indication when all devices associated with the particular the test site controller 115 have finished testing, and does not provide individual device testing status.
  • Figure 1 illustrates in-contact, break-contact, end-of-wafer, and end-of-cassette indications being transferred to datalog manager 170, in some embodiments less of these indications, additional indications and/or different indications may be transferred to datalog manager 170. Similarly, although an embodiment where an end-of-site-test indication is transferred to datalog manager 170 has been described, in some embodiments the end-of-site-test indication may not be transferred to datalog manager 170. The meaning and application of indications in managing datalog will be described in more detail further below.
  • any datalog manager 170 can be made up of any combination of software, hardware and/or firmware that performs the functions as defined and explained herein.
  • Figure 4 illustrates a block diagram of a particular datalog manager 170 which manages datalog for an associated test site controller 115, according to one embodiment of the present invention.
  • test program interface 440 which provides an interface to test program 120 for the associated test site controller 115
  • TOS interface 430 which provides an interface to tester operating system and test program server 105 for the associated test site controller 115
  • test operations console interface 420 which provides an interface to test operations console 135,
  • handling status interface 410 which provides an interface to handling equipment 150 and/or to test system controller 110.
  • handling status indications are received by datalog manager 170 directly from test system controller 110 via handling status interface 410.
  • test program event information 445 received via test program interface 440, is provided to datalog manager control engine 450.
  • TOS event information 435 received via TOS interface 430, is provided to datalog manager control engine 450.
  • TOS event information may include an end-of-site-test indication indicating that testing is complete at all test site(s) controlled by the associated test site controller 115.
  • test console datalog status 425 received via test ops console interface 420, is provided to datalog manager control engine 450.
  • test ops datalog status can include an override disabling or enabling indication relating to all test site(s) associated with the particular datalog manager 170 or selectively relating to test site(s) associated with the particular datalog manager 170.
  • handling status indications 415 received via handling status interface 410, is provided to datalog manager control engine 450.
  • handling status indications 415 may include for example an "in-contact” indication, indicating that a group is ready for testing, a "break-contact” indication, indicating that testing on all devices in a group has completed , and/or an end-of batch indication, indicating that mere are no remaining untested devices in a batch (i.e. batch has been completely tested).
  • end-of-batch signals include end-of- wafer (i.e. wafer completely tested), end-of-cassette (i.e. cassette completely tested), etc.
  • any of the indications used herein such as “in- contact”, “break-contact”, “end-of-site-test”, “end-of-wafer”, “end-of-cassette”, etc. may take any format suitable for the particular implementation of system 100.
  • the in-contact indication may take the form of "Ready to test the next semiconductor group”.
  • datalog manager control engine 450 periodically polls/queries in order to receive any relevant information/status 445, 435, 425, 415 (including inter-alia indications such as "in-contact”, “break-contact”, “end-of-site-test”, “end-of-wafer”, and/or “end-of-cassette” ) that have been generated, whereas in another embodiment relevant generated information/status 445, 435, 425, 415 (including inter- alia indications such as "in-contact”, “break-contact”, “end-of-site-test”, “end-of-wafer”, and/or "end-of-cassette”) are additionally or alternatively received automatically by datalog manager control engine 450.
  • information and/or status 445, 435, 425, 415 are information and/or status 445, 435, 425, 415
  • indications transferred between test system controller 110 and/or handling equipment 150 and indications originating from tester operating system and test program server 105 may be interfaced to datalog manager 170 through a single interface, for example via TOS interface 430.
  • handling status indications originating from test system controller 110 may be interfaced to datalog manager 170 through a separate interface than handling status indications originating from handling equipment 150.
  • control over data-logging may be asserted from test program 170 indirectly via tester operating system and module control 105 and TOS interface 430 rather than via a separate test program interface 440.
  • datalog manager control engine 450 outputs datalog source event information 470 and/or outputs a datalog enable/disable indication 460 to the datalog generation tool 130 for the associated test site controller 115.
  • datalog source event information 470 presents the associated datalog generation tool 130 with information on the datalog event that is the source of raw data (see above discussion) based for example on received test program event information 445 and/or received TOS event information 435.
  • datalog manager control engine 450 may specify in source event information 470 the kinds of raw data that are staged to be data-logged, including for example for each event, an indication that an event has occurred, whether or not the event should be data-logged, and/or the specific nature of the event.
  • the specific nature of the event may be used by datalog generation tool 130 to locate the appropriate raw data and/or to properly format the raw data for the type of event.
  • datalog manager control engine 450 is configured to selectively output an enable datalog indication 460 (allowing datalog) and/or configured to selectively output a disable datalog indication 460 ( not allowing datalog) to datalog generation tool 130 associated with test site controller 115 based on the condition of one or more inputs 445, 435, 425, and 415 and rules which may vary depending on the implementation.
  • data-logging may thus be controlled by test operation events and functions within or outside of test site controller 115.
  • the conditions may include which inputs 445, 435, 425 and/or 415 have been received and/or may include which inputs are anticipated (waited for) but have not yet been received.
  • handling equipment 150 is currently preparing the next group for testing.
  • the status of the testing may in some cases reflect anticipated inputs (for example, actual testing is stopped while "in-contact” indication is awaited, actual testing is occurring on at least one device in a group while "break- contact" is awaited).
  • conditions may include which inputs 445, 435, 425 and/or 415 have been received and/or may include which inputs are anticipated (waited for) but have not yet been received
  • a rule may state that an "override" disabling indication received from test operations console 135 results in a disabling output indication 460 regardless of the condition of any other inputs.
  • a rule may state that an "override" enabling signal received from test operations console 135 results in a disabling output indication 460 regardless of the condition of any other inputs.
  • automated conditional datalog controls may be embedded within test program 120 (for example, datalog only in the event of device failure), which may be subordinate to master data-log control from test Operations console 135 by which an. engineer or technician may elect to enable/disable some or all datalog operations.
  • a rule may state that datalog is disallowed after an in- contact indication is issued by handling equipment 120 until a break-contact is received.
  • a rule may state that datalog is disallowed after an in-contact indication is issued by handling equipment 120 until a break-contact or end-of-batch indication is received. In another example, in one embodiment a rule may state that datalog is disallowed after an in-contact indication is issued by handling equipment 120 until a break-contact, end-of-site-test or end-of-batch indication is received. In another example, in one embodiment a rule may state that datalog should be postponed until the completion of testing for a batch of devices, for example, after testing has been completed on all of the devices within a single wafer, cassette, and/or package holder. Other rules are possible in various embodiments, some of which are described or are apparent from what is described elsewhere herein.
  • datalog manager 170 may comprise fewer, more, and/or different modules than those shown in Fig 4.
  • the functionality described herein may be divided into fewer, more and/or different modules than shown in Fig 4.
  • datalog manager 170 may include more, less and/or different functionality than described herein.
  • datalog manager 170 may receive feedback from datalog generation tool 130. The functionality of datalog manager 170 may be concentrated in one location or dispersed over more than one location.
  • Figure 5 illustrates a method 500 of datalog management, according to an embodiment of the present invention.
  • prober 150a parallel processes are described for prober 150a, test system controller 110, datalog manager 170 associated with any one of the N test site controllers 115, and tester operating system and test program server (TOS) 105 associated with the same test site controller 115.
  • TOS tester operating system and test program server
  • the reference numerals for prober 150a, test system controller 110, datalog manager 150, tester operating system and test program server (TOS) 105, and test site controller 115 are omitted in the description of method 500.
  • the described embodiments ignore activity (if any) by the prober, the test system controller , and the tester operating system and test program server that is unrelated to datalog management.
  • the described embodiments assume that the tester operating system and test program server receives the "in-contact" indication but no other indications originating at the prober or the test system controller. It should be evident that in some embodiments of the invention any of the above assumptions may not be made.
  • Method 500 discussed inter-alia six possible embodiments for managing data-logging.
  • trie datalog manager allows datalogging during any preparation intervals in which the prober is preparing a group for testing.
  • the datalog manager allows data-logging during preparation activity which includes unloading/loading of any type of batch.
  • the datalog manager allows data-logging during preparation activity which includes unloading/loading of a cassette (specific type of batch).
  • the datalog manager allows data-logging during preparation activity which includes unloading/loading of a wafer (specific type of batch) and subsequent contacting of the first group in the loaded wafer.
  • the datalog manager allows data-logging during preparation activity which includes indexing (specific type of preparation).
  • the datalog manager allows data-logging during the time lag between when testing ends for all test site(s) controlled by the associated test site controller and testing ends for all test sites (controlled by the N test site controllers).
  • the datalog manager allows datalogging during the time lag between when testing ends for all test site(s) controlled by the associated test site controller and testing ends for all test sites (controlled by the N test site controllers) and also during any preparation intervals in which the prober is preparing a group for testing.
  • an indication issued by the prober that is received by the test system controller and/or by the tester operating system and test program server may in some cases be received by the datalog manager.
  • the indication may be independently received by the datalog manager and by the test system controller/tester operating system and program server.
  • the indication may be received by the datalog manager and forwarded to the test system controller/tester operating system and test program server.
  • the indication may be received by test system controller/tester operating system and test program server and forwarded to the datalog manager.
  • an indication issued by the test system controller which is received by the prober may in some cases be received by the datalog manager. In one of these embodiments, the indication may be independently received by the datalog manager and by the prober. In one of these embodiments, the indication may be received by the datalog manager and forwarded to the prober. In one of these embodiments, the indication may be received by the prober and forwarded to the datalog manager.
  • an end-of-site-test indication issued by the tester operating system and program server may in some cases be received by the datalog manager and/or by the test system controller.
  • the indication may be received independently by the datalog manager and the test system controller, may be received by the datalog manager and forwarded to the test system controller, or may be received by the test system controller and forwarded to the datalog manager.
  • different indications may be transferred via different paths. There is no limitation in the described embodiments on the path for transferring indications.
  • stage 5024 the prober loads a new cassette of wafers.
  • the test system controller and the tester operating system and test program server wait for an in-contact indication (stage 5124 and 5224 respectively).
  • stage 5124 and 5224 the datalog manager allows datalog, whereas under options 4, 5, or 6 data-logging is not allowed (stage 5324).
  • stage 5026 the prober loads anew wafer onto the prober chuck.
  • the test system controller and the tester operating system and test program server still wait for an in-contact indication (stage 5126 and 5226 respectively).
  • the datalog manager allows datalog whereas under options 3, 5, or 6 data-logging is not allowed (stage 5326).
  • stage 5028 the prober places a group of devices on the wafer in electrical contact with the interface unit (for example probecard 160a).
  • the test system controller and the tester operating system and test program server wait for an in-contact indication (stage 5128 and 5228 respectively).
  • the datalog manager allows datalog whereas under options 3, 5, or 6 data-logging is not allowed (stage 5328). If data-logging is not allowed in any of stages 5324, 5326 or 5328 datalog manager waits for the appropriate indication to allow data-logging according to the option followed.
  • datalog is not allowed for any option during the initial execution of stages 5324, 5326, or 5328 (i.e. when no devices have yet been tested), for example because of a lack of data to be logged prior to testing.
  • stage 5030 of the embodiment illustrated in Figure 5 the prober issues an "in-contact" indication indicating that there is a group prepared for testing.
  • the test system controller, the tester operating system and test program server, and the datalog manager respectively receive the "in-contact” indication which in the described embodiment respectively notifies the test system controller to coordinate the testing of the group of devices, the tester operating system and test program server to start actual testing at the associated test site(s), and the datalog manager to not allow data-logging.
  • the datalog manager may not receive (or may receive and ignore) an "in-contact" indication in stage 5330 if the datalog manager was already not allowing data-logging.
  • stage 5231 of the embodiment illustrated in Figure 5 the tester operating system and test program server tests the device(s) at the associated test site(s) while in stage 5131 the test system controller coordinates the testing of the group.
  • the prober in stage 5031 waits for the next "break-contact" indication, whereas the datalog manager in stage 5331 waits for an indication to allow data-logging as appropriate for the datalog option.
  • datalog manager waits in stage 5331 for an "end-of-site-test" indication, whereas if data-logging is not allowed during the time lag but allowed during indexing, the datalog manager waits for a "break-contact" indication.
  • the datalog manager instead waits in stage 5331 for the appropriate end-of-batch indication for allowing data-logging in accor ⁇ ance with the option followed by the datalog manager.
  • the associated test site controller is not the last test site controller to complete testing.
  • the tester operating system and test program server issues an end-of-site-test, indicating that testing has ended for all test site(s) controlled by the associated test site controller.
  • the test system controller and the datalog manager respectively receive the end-of-site-test.
  • the datalog manager does not necessarily receive (or receives and ignores) the end-of-site-test, for example because the indication does not cause the datalog manager to switch to allowing datalogging (for example under options 1, 2, 3, 4, 5).
  • the test system controller does not receive the end-of-site-test issued by tester operating system and test program server.
  • stage 5032 the prober still waits for a "break-contact” indication.
  • the datalog manager allows data-logging under option “ 6 or 7 but does not allow data-logging under options 1, 2, 3, 4 or 5.
  • stage 5233 the tester operating system and test program server waits for an "in-contact” indication (to begin testing again).
  • the tester continues to coordinate group testing until the last test site has completed testing (i.e. until all the devices in the group have completed testing).
  • stage 5033 the prober still waits for a "break-contact" indication.
  • stages 5032, 5132, 5232, 5332, 5033, 5133, 5233, and 5333 may be omitted.
  • stage 5134 when all devices have completed testing, the test system controller issues a "break-contact" indication which is received by the prober and the datalog manager in stages 5034 and 5334 respectively.
  • the datalog manager may not receive (or may receive and ignore) the "break-contact” indication, for example because the "break-contact” indication does not cause the datalog manager to switch to allowing data-logging or disallowing datalogging.
  • the "break-contact” may cause a switch to allowing data-logging (option 1 or 5) or to disallowing data-logging (option 6), but under options 2, 3, or 4, the "break-contact” does not cause data-logging to begin to be allowed, nor under option 7 does the "break-contact” cause data-logging to stop being allowed.
  • the tester operating system and test program server continues to wait for an "in-contact” indication.
  • only one of the end-of-site-test indication or the break- contact indication may be required to be issued, because either would indicate that testing has been completed for the group and that the prober may remove electrical contact.
  • the datalog manager assumes that there is another (untested) group on the wafer to be tested unless notified otherwise. Therefore, while the prober in stage 5036 is determining whether there is another (untested) group on the wafer to prepare for testing, the test system controller and the tester operating system and test program server wait for an in-contact signal (stage 5136 and 5236 respectively) and in stage 5336 the datalog manager allows datalogging under options 1, 5, or 7. Under options 2, 3, 4, or 6, the datalog manager does not allow data-logging because the datalog manager assumes that no unloading/loading or time lag will be occurring unless notified otherwise.
  • stage 5038 the prober indexes to another group on the wafer.
  • the test system controller and the tester operating system and test program server respectively wait for an in-contact indication, hi stage 5338, under option 1, 5, or 7 the datalog manager allows datalogging. Under option 2, 3, 4, or 6, the datalog manager does not allow data-logging.
  • Method 500 then iterates back to 5030, 5130, 5230, and 5330.
  • stage 5040 the prober issues an end-,of -wafer indication.
  • the test system controller receives the end-of- wafer and notes the change in wafer status.
  • the datalog manager receives the end-of-wafer-indication.
  • the datalog manager may not receive (or receive and ignore) the end-of- wafer indication, for example if the indication does not cause a transition from allowing data-logging to not allowing data-logging or from not allowing data-logging to allowing data-logging.
  • the tester operating system and test program server continues to wait for an "in-contact" indication.
  • stage 5042 the prober unloads the tested wafer from the prober chuck.
  • stage 5142 the test system controller and the tester operating system and test program server wait for an "in-contact" indication in stages 5142 and 5242 respectively.
  • stage 5342 the datalog manager allows data-logging under option 1, 2, A, or 7. Under options 3, 5, or 6 data-logging is not allowed and instead the datalog manager waits for the appropriate indication to allow data-logging according to the option followed.
  • the datalog manager assumes that there is another untested wafer on the cassette, unless notified otherwise. Therefore, while the prober in stage 5044 is determining whether there is another (untested) wafer on the cassette to load and the test system controller and the tester operating system and test program server wait for an in-contact indication (stage 5144 and 5244 respectively), the datalog manager in stage 5344 allows data-logging under option 1, 2, 4,or 7. Under options 3, 5, or 6 data-logging is not allowed and instead the datalog manager waits for the appropriate indication to allow data-logging according to the option followed.
  • method 500 iterates back to stages 5026, 5126, 5226 and 5326. Otherwise if there is no untested wafer on the cassette (no to stage 5044) then the prober issues an end-of-cassette indication in stage 5046.
  • the tester operating system and the datalog manager receive the end-of-cassette indication in stages 5146 and 5346 respectively.
  • the datalog manager may not receive (or may receive and ignore) the end-of-cassette indication for example if the indication does not cause a transition from allowing data-logging to not allowing datalogging or from not allowing data-logging to allowing data-logging.
  • stage 5246 the tester operating system and test program server continues to wait for an "in-contact" indication.
  • the prober unloads the tested cassette.
  • the test system controller and the tester operating system and test program server respectively wait for a start-test indication.
  • the datalog manager allows data-logging under option 1, 2, 3, or 7. Under options 4, 5, or 6 data-logging is not allowed and instead the datalog manager waits for the appropriate indication to allow data-logging according to the option followed.
  • the datalog manager assumes that there is another untested cassette in the lot unless notified otherwise. Therefore, while the prober in stage 5050 is determining whether there is another (untested) cassette in the lot to load and the test system controller and the tester operating system and test program server wait for an in-contact signal (stage 5150 and 5250 respectively), the datalog manager in stage 5350 allows data-logging under options I 3 2, 3, or 7. Under options 4, 5, or 6 data-logging is not allowed and instead the datalog manager waits for the appropriate indication to allow data-logging according to the option followed.
  • method 500 iterates back to stages 5024, 5124, 5224 and 5324.
  • method 500 iterates back to stages 5024, 5124, 5224 and 5324 but in the execution of stages 5326 and 5328 in this embodiment, datalog is allowed under options 1, 2, 3 or 7 and not allowed under options 4, 5, and 6 (because it is assumed that the datalog manager does not know when the prober moves from loading the new cassette to loading the new wafer).
  • method 500 ends, hi one embodiment, for example the prober may issue an end-of-lot indication when all cassettes have been tested in the lot, notifying the test system controller, tester operating system and test program server and/or the datalog manager that the lot has been completed. In one embodiment method 500 restarts the next time a lot is loaded for testing.
  • fewer, more, or different stages than those shown in Figure 5 may be executed. In other embodiments, the stages may be executed in a different order than shown in Figure 5 and/or different stages may be executed in parallel. Each of the stages of method 500 may be executed automatically (without user intervention), semi-automatically and/or manually, depending on the embodiment.
  • FIG. 6 is a flowchart of a method 600 for datalog management, according to an embodiment of the present invention. For simplicity of description it is assumed in method 600 that data-logging is allowed only during indexing. For simplicity of description, it is also assumed that there is only one device (one test site), per test site controller 115. It should be evident that in another embodiment of the invention, these assumptions may not be made.
  • each datalog manager 170 receives an. indication that a new group is ready for testing, for example a new device (in a sequential testing environment) or a new touchdown (in a parallel testing environment). For example, each datalog manager 170 may receive an "in-contact" indication.
  • Stages 604 and 606 are then executed in parallel.
  • each tester operating system and test program server 105 begins testing a device from the new group at the associated test site.
  • each datalog manager 170 communicates to the associated datalog generation tool 130 to pause data logging.
  • datalogging relating to one or more test sites may be allowed while testing, for example if manually forced to datalog during testing by test operations console 135, or for example in some cases if datalog for earlier events had not yet been completed.
  • each datalog manager waits for a signal that testing has ended on the group. For example in one embodiment, there is an "break-contact" signal from the test system controller 110 which indicates that testing of the group (for example one device in sequential testing or a touchdown in parallel testing) has been completed. [00109] In stage 609, when testing of the currently contacted device or touchdown, has been completed, each datalog manager 170 receives a signal that testing has ended, for example the "break-contact" signal generated by test system controller 110.
  • Stages 610 and 612 are then executed in parallel.
  • handling equipment 150 begins an indexing operation to contact a new group.
  • each datalog manager 170 indicates to the associated datalog generation tool 130 that data-logging is allowed. For example if data-logging was halted then the indication in stage 612 can cause data-logging to resume. As another example, if data-logging is already taking place, the indication in stage 612 may indicate that data-logging continues to be allowed. In another embodiment of stage 612, one or more datalog manager(s) 130 associated may not indicate to the associated datalog generation tool(s) 130 that data-logging is allowed, for example if manually disabled from test operations console 135, or for example if there is no data to datalog, or for example if data-logging is already taking place.
  • Method 600 repeats. In one embodiment, when there are no more groups on a wafer or a package holder to test, an "in-contact" indication will not be received in stage 602 and therefore method 600 will end. In another embodiment, additionally or alternatively, an indication originating from handling equipment 150 such as "end-of- wafer" may be received by each datalog manager 170 indicating that there are no more groups on the wafer to test, causing method 600 to end. In one embodiment, method 600 restarts the next time a wafer or package holder is loaded for testing.
  • FIG. 6 is a flowchart of a method 700 for datalog management, according to an embodiment of the present invention.
  • the described embodiments ignore activity (if any) by the handler, the test system controller, and the tester operating system and test program server that are unrelated to datalog management. Seventh, the described embodiments assume that the test operation system and test program server only receives the "in-contact" indication, but no other indications originating at the handler or the test system controller. It should be evident that in some embodiments of the invention any of the above assumptions may not be made.
  • Method 700 discussed inter-alia three possible embodiments for managing data-logging.
  • the datalog manager allows data-logging during any preparation intervals in which the handler is preparing a group for testing.
  • the datalog manager allows data-logging during the time lag between when testing ends for all test site(s) controlled by the associated test site controller and testing ends for all test sites (controlled by the N test site controllers).
  • the datalog manager allows data-logging during the time lag between when testing ends for all test site(s) controlled by the associated test site controller and testing ends for all test sites (controlled by the N test site controllers) and during any preparation intervals in which the handler is preparing a group for testing.
  • an indication issued by the handler that is received by the test system controller and/or by the tester operating system and test program server may in some cases be received by the datalog manager.
  • the indication may be independently received by the datalog manager and by the test system controller/tester operating system and program server.
  • the indication may be received by the datalog manager and forwarded to the test system controller/tester operating system and test program server.
  • the indication may be received by test system controller/tester operating system and test program server and forwarded to the datalog manager.
  • an indication issued by the test system controller which is received by the handler may in some cases be received by the datalog manager. In one of these embodiments, the indication may be independently received by the datalog manager and by the handler. In one of these embodiments, the indication may be received by the datalog manager and forwarded to the handler. In one of these embodiments, the indication may be received by the handler and forwarded to the datalog manager.
  • an end-of-site-test indication issued by the tester operating system and program server may in some cases be received by the datalog manager and/or by the test system controller.
  • the indication may be received independently by the datalog manager and the test system controller, may be received by the datalog manager and forwarded to the test system controller, or may be received by the test system controller and forwarded to the datalog manager.
  • different indications may be transferred via different paths. There is no limitation in the described embodiments on the path for transferring indications.
  • stage 7024 the handler loads a new package holder of devices.
  • the test system controller and the tester operating system and test program server wait for an in-contact indication (stage 7124 and 7224 respectively), and under option 1 or 3 datalog manager allows datalog (stage 7324). Under option 2, datalog is not allowed.
  • stage 7028 the handler places the first group in the package holder to be tested in electrical contact with the interface unit (for example loadboard 160b). For example, the one or more devices included in the first group are socketed (placed into test sockets).
  • stage 7128 and 7228 The test system controller and the tester operating system and test program server still wait for an in-contact- indication (stage 7128 and 7228 respectively), and the datalog manager allows datalog under option 1 or 3 but not under option 2 (stage 7328). If data-logging is not allowed in stages 7324 or 7328 (for example under option 2), then datalog manager waits for the appropriate indication to allow data-logging according to the option followed. In another embodiment, datalog is not allowed during the initial execution of stages 7324 or 7328 (i.e. when no devices have yet been tested), for example because of a lack of data to be logged prior to testing. [00123] In stage 7030 of the embodiment illustrated in Figure 7, the handler issues an. "in-contact" indication indicating that there is a group ready for testing.
  • stage 7130, 7230, and 7330 the test system controller, the tester operating system and test program server and the datalog manager respectively receive the in-contact indication which,, in the described embodiment, respectively notifies the test system controller to coordinate the testing of the group of devices, the tester operating system and test program server to start actual testing at the associated test site(s), and the datalog manager to not allow data-logging .
  • the datalog manager may not receive (or may receive and ignore) an "in-contact" indication in stage 7230 if the datalog manager was already not allowing data-logging.
  • stage 7231 of the embodiment illustrated in Figure 7 the tester operating system and test program server tests the deyice(s) at the associated test site(s) while in stage 7131 the test system controller coordinates the testing of the group.
  • the handler in stage 7031 waits for the next "break-contact" indication, whereas the datalog manager in stage 7331 waits for an indication to allow data-logging as appropriate for the datalog option.
  • datalog manager waits in stage 7331 for an "end-of-site-test" indication, whereas if data-logging is not allowed during the time lag but allowed during indexing, the datalog manager waits for a "break-contact" indication.
  • the associated test site controller is not the last test site controller to complete testing.
  • the tester operating system and test program server issues an end-of-site-test, indicating that testing has ended for all test site(s) controlled by the associated test site controller.
  • the test system controller and the datalog manager respectively receive the end-of-site-test.
  • the datalog manager does not necessarily receive (or receive's and ignores) the end-of-site-test for example because the indication does not cause the datalog manager to switch to allowing datalogging (for example under option 1).
  • the test system controller does not receive the end-of-site-test issued by tester operating system and test program server.
  • stage 7032 the handler still waits for a "break-contact” indication.
  • stage 7333 the datalog manager allows data-logging under option 2 or 3 but does not allow data-logging under option 1.
  • stage 7233 the tester operating system and test program server waits for an "in-contact” indication (to begin testing).
  • stage 7133 the tester continues to coordinate group testing until the last test site has completed testing (i.e. until all the devices in the group have completed testing).
  • the handler still waits for a "break-contact” indication.
  • stages 7032, 7132, 7232, 7332, 7033, 7133, 7233, and 7333 may be omitted.
  • stage 7134 when all devices have completed testing the test system controller issues a "break- contact" indication which is received by the handler and the datalog manager in stages 7034 and 7334 respectively.
  • the datalog manager may not receive (or may receive and ignore) the break-contact indication for example because the break-contact indication does not cause the datalog manager to switch to allowing data-logging or disallowing data-logging such as per option 3.
  • the tester operating system and test program server continues to wait for an "in-contact” indication.
  • only one of the end-of-site-test indication or the break-contact indication may be required to be issued, because either would indicate that that testing has been completed for the group and that the handler may remove electrical contact.
  • stage 7038 the handler indexes to another group in the package holder, for example unsocketing the tested group of device(s) and socketing an untested group of device(s).
  • the test system controller waits for an in-contact indication.
  • stages 7236 and 7238 the tester operating system and test program server waits for an in-contact indication.
  • the datalog manager allows data-logging under option 1 or 3 but not under option 2 in stage 7336 and 7338.
  • Method 700 then iterates back to 7030, 7130, 7230 and 7330.
  • stage 7042 the handler unloads the package holder.
  • stages 7142, 7150 and 7242, 7250 respectively the test system controller and the tester operating system and test program server wait for an in-contact indication.
  • stages 7342 and 7350 the datalog manager allows datalogging under option 1 or 3 but not under option 2.
  • method 700 if there is another (untested) package holder in the lot (yes to stage 7050), then method 700 iterates back to stages 7024, 7124, 7224 and 7324. Otherwise if there are no untested package holders in the lot (no to stage 7050) then method 700 ends. In one embodiment, method 700 restarts the next time a lot is loaded for testing.
  • stages may be executed in a different order than shown in Figure 7 and/or different stages may be executed in parallel.
  • Each of the stages of method 700 may be executed automatically (without user intervention), semi-automatically and/or manually, depending on the embodiment.
  • datalog management may be allowed regardless of whether testing is occurring or waiting/preparation for testing is instead occurring.
  • the datalog manager (for example datalog manager 170) does not necessarily need to distinguish between when testing is occurring and when preparation for testing or waiting is occurring, because the distinction does not impact on the decision of whether or not to allow data-logging. Therefore in some of these embodiments, Figures 1 and 4 may be simplified so that the in-contact, end-of batch, end-of-site-test and/or break-contact indications are not necessarily provided to datalog manager control engine 450 in datalog manager 170.
  • datalog is allowed at any time during the processing, provided there is data to log and no disabling indication is received from test operations console 135.
  • handling equipment 150 proceeds to prepare a new group for testing, regardless of whether datalogging is occurring or not.
  • the new group is ready for testing, testing begins, regardless of whether data-logging is occurring or not.
  • the system according to the invention may be a suitably programmed computer.
  • the invention contemplates a computer program being readable by a computer for executing the method of the invention.
  • the invention further contemplates a machine-readable memory tangibly embodying a program of instructions executable by the machine for executing the method of the invention.

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Tests Of Electronic Circuits (AREA)

Abstract

L'invention concerne des procédés, des systèmes et des modules permettant la gestion de journaux de données. Dans un mode de réalisation, la consignation des données est permise pour se produire au moins occasionnellement alors que l'équipement de manutention prépare le ou les composants en vue d'un test. De plus ou en variante, dans un mode de réalisation comportant une pluralité de contrôleurs de sites de test, après que le test a été achevé sur la totalité du ou des sites de test associés à un contrôleur de sites de test particulier, la consignation de données se rapportant à ce contrôleur de sites de test est permise pour se produire au moins occasionnellement alors que le test se poursuit au niveau du ou des sites de test associés à un ou à d'autres contrôleurs de sites de test.
PCT/IL2008/000768 2007-07-02 2008-06-05 Gestion de journaux de données dans le test des semiconducteurs Ceased WO2009004608A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US11/772,676 2007-07-02
US11/772,676 US20090013218A1 (en) 2007-07-02 2007-07-02 Datalog management in semiconductor testing

Publications (2)

Publication Number Publication Date
WO2009004608A2 true WO2009004608A2 (fr) 2009-01-08
WO2009004608A3 WO2009004608A3 (fr) 2010-02-25

Family

ID=40222366

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IL2008/000768 Ceased WO2009004608A2 (fr) 2007-07-02 2008-06-05 Gestion de journaux de données dans le test des semiconducteurs

Country Status (2)

Country Link
US (1) US20090013218A1 (fr)
WO (1) WO2009004608A2 (fr)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101932947B (zh) * 2008-09-18 2013-09-18 爱德万测试(新加坡)私人有限公司 共享测试资源的方法、自动测试设备以及测试系统
US10118200B2 (en) * 2009-07-06 2018-11-06 Optimal Plus Ltd System and method for binning at final test
TWI539275B (zh) * 2009-10-07 2016-06-21 聯詠科技股份有限公司 觸控裝置及其控制器、測試方法與測試系統
CN113485911B (zh) * 2021-06-07 2025-01-14 广发银行股份有限公司 一种基于银行业务的测试数据生成平台

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6681351B1 (en) * 1999-10-12 2004-01-20 Teradyne, Inc. Easy to program automatic test equipment
CA2321346A1 (fr) * 2000-09-28 2002-03-28 Stephen K. Sunter Methode, systeme et produit programme d'essai et/ou de diagnostic de circuits utilisant des donnees d'acces a un controleur d'essai integre
CA2448460A1 (fr) * 2001-05-24 2002-11-28 Test Advantage, Inc. Procedes et testeur de semi-conducteurs
US7146584B2 (en) * 2001-10-30 2006-12-05 Teradyne, Inc. Scan diagnosis system and method
US7184917B2 (en) * 2003-02-14 2007-02-27 Advantest America R&D Center, Inc. Method and system for controlling interchangeable components in a modular test system
US7209851B2 (en) * 2003-02-14 2007-04-24 Advantest America R&D Center, Inc. Method and structure to develop a test program for semiconductor integrated circuits
US7183785B2 (en) * 2004-01-29 2007-02-27 Howard Roberts Test system and method for reduced index time
US7107173B2 (en) * 2004-02-03 2006-09-12 Credence Systems Corporation Automatic test equipment operating architecture
US7430486B2 (en) * 2004-05-22 2008-09-30 Advantest America R&D Center, Inc. Datalog support in a modular test system
US20070260937A1 (en) * 2006-04-13 2007-11-08 Carli Connally Systems and methods for selectively logging test data
US20070260938A1 (en) * 2006-04-24 2007-11-08 Carli Connally Method, code, and apparatus for logging test results

Also Published As

Publication number Publication date
WO2009004608A3 (fr) 2010-02-25
US20090013218A1 (en) 2009-01-08

Similar Documents

Publication Publication Date Title
US11919046B2 (en) System and method for binning at final test
EP1849019B1 (fr) Procede et systeme pour la programmation d'essais dans un systeme d'essais paralleles
US9551740B2 (en) Parallel concurrent test system and method
US6842022B2 (en) System and method for heterogeneous multi-site testing
US9817062B2 (en) Parallel concurrent test system and method
US6857090B2 (en) System and method for automatically analyzing and managing loss factors in test process of semiconductor integrated circuit devices
US7420385B2 (en) System-on-a-chip pipeline tester and method
US20130096866A1 (en) Method And Apparatus For Designing A Custom Test System
US20090013218A1 (en) Datalog management in semiconductor testing
US6304095B1 (en) Semiconductor measurement instrument with the capability to dynamically change examination criteria
WO2003052437A2 (fr) Sonde a microprocesseur pour test de circuit integre
US7253606B2 (en) Framework that maximizes the usage of testhead resources in in-circuit test system
US7208969B2 (en) Optimize parallel testing
US20090024324A1 (en) Method and System for GRR Testing
US7774670B2 (en) Method and apparatus for dynamically determining tester recipes
US20110254579A1 (en) Semiconductor test method and semiconductor test system
Khasawneh Reducing the production cost of semiconductor chips using (parallel and concurrent) testing and real-time monitoring
US7983871B2 (en) Method and apparatus for employing previous test insertion results for testing a device
CN113760772A (zh) 面向测试性试验的半自动/自动执行系统的用例执行方法
US10386405B2 (en) Method for continuous tester operation during multiple stage temperature testing
Dworak et al. An industrial case study: Parent (parallel & concurrent) testing for complex mixed-signal devices

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 08763526

Country of ref document: EP

Kind code of ref document: A2

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 08763526

Country of ref document: EP

Kind code of ref document: A2