|Download Help (Windows Only)|
|active site||Site that is currently testing DUTs and not disabled.|
|batch||A set of DUTs you test simultaneously.|
|bin definitions file||Defines the hardware bins and software bins, defines how the software bins relate to hardware bins, and defines the default software bins for the test program main sequence file.|
|binning||Process of assigning a tested DUT to a software bin and hardware bin.|
|channel||Connection to a data acquisition system or to an instrument.|
|channel group||A synchronized group of channels.|
|configuration||Defines values for conditions that a test program can reference at run time and the test limits file that loads before running a test lot. A test program can use multiple configurations to implement multiple test flows using the same sequences and code modules. For example, you can create configurations for Hot and Cold flows or for QA and Production lots.|
|connection||An entry in a pin map file that defines the relationship of a pin to a channel on an instrument.|
|custom instrument||An instrument that TSM does not natively support.|
|device||Item you are testing.|
|DIB||Device interface board.|
|DUT||Device under test.
See also part.
|DUT pin||A pin that corresponds to a specific pin on the DUT of an individual site.
See also system pin.
|grading||Process in which the test program evaluates a DUT with different test criteria and assigns a pass bin to the DUT depending on the level of criteria the DUT met.|
|handler||Places DUTs on the test head for testing, removes the DUTs from the test head after testing completes, and places the DUTs in a hardware bin, depending on the test results.|
|handler/prober index time||Time required for the handler to bin and place new DUTs for testing or the time required for a prober to position probes to the next set of die to test.|
|hardware bin||Physical location into which handler places a DUT after testing.|
|hardware configuration file||Defines the configuration of the instruments in the test system.|
|inline QA||Performing one or more quality assurance tests within a standard test sequence.|
|instrument||Equipment used to test devices. TSM supports NI and custom instruments.|
|lot||See test lot.|
|multisite||Testing multiple DUTs at the same time in parallel to improve tester efficiency.|
|part||The item to test.
See also DUT.
|pin||Input or output of a connection to a device you are testing.|
|pin group||A collection of pins defined in a pin map that can be specified in a Semiconductor Multi Test step test or passed as a parameter to the TSM Code Module API.|
|pin map||Defines the instrumentation on the tester, defines the pins on the DUT, and defines how the DUT pins are connected to the tester instrumentation for each test site.|
|prober||Tests integrated circuits on a wafer.|
|PTE||Parallel test efficiency.|
|result||Data that is logged for analysis or used to evaluate the pass/fail status of a DUT.|
|Semiconductor Module context||Required input to all TSM Code Module API VIs and .NET methods that represents a subset of pins, sites, and instruments on a test system.|
|site||Physical location on a tester for testing DUTs.
See also test socket.
|socket time||Time spent for the DUT in the test socket, as measured by the time elapsed between receiving the start-of-test (SOT) notification from the handler or prober and sending the end-of-test (EOT) notification to the handler or prober.|
|software bin||Virtual bin you define in software to store information about a DUT or testing results for a DUT before assigning the DUT to a hardware bin after testing. Use a bin definitions file to define the relationship between software bins and hardware bins.|
|software fail bin||Software bin associated with a hardware bin of the Fail type. The Software Bin column on the Tests tab of the Semiconductor Multi Test step lists only software fail bins.|
|software pass bin||Software bin associated with a hardware bin of the Pass type.|
|STDF||Standard Test Data Format. A standard file format for storing semiconductor test result data.|
|subsystem||A set of sites and system resources on the tester that can operate independently. A Semiconductor Multi Test step automatically calculates and creates subsystems depending on the active sites for the step and the pins required to complete the test.|
|system pin||A pin that corresponds to a shared resource on a tester. A system pin affects all test sites.
See also DUT pin.
|test cell||The entire physical area for testing DUTs. The test cell includes the tester (or test station), the DUT handler or prober, the operator, and anything else physically located in the test area that has an effect on the test cell operation.|
|test code||A program module, such as a DLL or VI, that contains one or more functions that perform a specific test or other action.|
|test condition||Specifies historical information, descriptive information, such as DUT numbers or package types, and conditions under which to test the DUTs, such as temperature or voltage. The test program can use test conditions to determine how to execute tests. For example, test conditions might dictate which steps execute, what temperature to apply to a DUT, what voltage to use, and so on.|
|test limits file||Defines test limits the test program loads before running a test lot. The test program replaces test limits in test steps in the sequence file with those specified in the test limits file. You can embed test limits in the sequence file to prevent viewing or tampering with the limits.|
|test lot||Set of DUTs tested during a single testing session.|
|test number||Integer that uniquely identifies a specific test instance.|
|test program||The set of information that specifies how to execute the test. A semiconductor test program requires a main sequence file, optional subordinate sequence files, a pin map file, a bin definitions file, and code modules.|
|test program main sequence||Specifies the tests and test limits and determines which code modules to call to test a DUT. The main sequence file refers to a pin map file and bin definitions file that the test program uses during execution.
The sequence file contains at least one MainSequence sequence and can optionally contain one or more subsequences. A subsequence can call its own code modules, but you can specify only one pin map file or bin definitions file for a test program. You can use multiple sequences in a test program to keep the test code modular and organized.
|test socket||An execution thread in TestStand for testing a DUT for an associated site.|
|test station||A complete test implementation that production operators, test engineers, and system engineers use to perform tests.|
|test step||An instance of the Semiconductor Multi Test step type that performs one or more parametric or functional tests. A test step calls a code module implemented in LabVIEW or .NET to control the instrumentation on the tester, take measurements from the DUT, and pass measurement values back to the Semiconductor Multi Test step.|
|tester||The hardware solution for executing semiconductor tests. The tester is connected to a handler, which places DUTs in a test site or a prober that probes a wafer. The tester includes on-board instruments that perform measurements. The tester executes the tests the tester software defines.|
|tester index time||Time required to update the operator interface, generate an STDF record, and perform other tasks that must be completed before starting the next testing cycle.|
|tester software||The software solution installed on a tester that defines the test program and provides software tools for configuring and executing tests, such as a handler/prober driver for communicating with a handler or prober.|
|TSM||NI TestStand Semiconductor Module™|
|virtual pin||A DUT pin that does not physically exist but that you create in the pin map so you can map multiple instruments to the same physical DUT pin.|
|working site||The test socket that executes the code module. When testing multiple sites, the working site is assigned to the first site that reaches a step for the set of sites that must execute together during execution and, when you configure the test step to execute all sites in a single thread, is therefore the only site that executes a copy of the code module.|