Glossary

A

  • active site—Site that is currently testing DUTs and not disabled.

    • B

  • 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 software bin and hardware bin to a tested DUT.

    • C

  • 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.
  • cycle time—The socket time plus the index time. You can use the TSM Application API to obtain cycle time information.

    • D

  • device—Item you are testing.
  • DIB—Device interface board.
  • DUT—Device under test.
  • DUT pin—One of the following:
    • A specific pin on the DUT.
    • A resource on the tester or DIB that has instrument connections and that is associated with one or more sites. This resource can have one connection per site or can have one connection per group of sites.

    • G

  • 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.

    • H

  • 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 spent by a handler to remove and bin the tested parts and place new parts to be tested or by a prober to move the probes from the current position to the position of the next dies to be tested. Index time is measured by the time elapsed between sending the end-of-test notification to the handler or prober and receiving the start-of-test (SOT) notification from the handler or prober.
  • 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.

    • I

  • index time—See handler/prober index time.
  • 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.

    • L

  • lot—See test lot.

    • M

  • multisite—Testing multiple DUTs at the same time in parallel to improve tester efficiency.

    • P

  • part—The item to test.
  • 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.

    • R

  • result—Data that is logged for analysis or used to evaluate the pass/fail status of a DUT.

    • S

  • 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. TSM site numbers do not always directly correspond to test socket indexes. Use the Get Site Runtime Data VI or the GetSiteRuntimeData .NET method of the TSM Application API or use the Get Test Information step to obtain specific site numbers.
  • site relay—A relay on the tester or DIB that is connected to a relay driver module and that is associated with one or more sites. A site relay can have one connection per site or can have one connection per group of sites.
  • socket time—Time spent by 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. You can use the TSM Application API to obtain socket time information.
  • software 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 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.
  • STS—NI Semiconductor Test System.
  • 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 resource on the tester or DIB that is connected to an instrument. A system pin has a single connection and is associated with all sites. You can also use DUT pins for shared resources by specifying the sites that share the resource in the connection. Use a DUT pin instead of a system pin if you need to burst patterns to the pin using the NI-Digital Pattern instrument driver.
  • system relay—A relay on the tester or DIB that is connected to a relay driver module and that is associated with all sites. A system relay has a single connection for all sites.

    • T

  • 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. See also Process Model Thread Types. TSM site numbers do not always directly correspond to test socket indexes. Use the Get Site Runtime Data VI or the GetSiteRuntimeData .NET method of the TSM Application API or use the Get Test Information step to obtain specific site numbers.
  • 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, process results for reports and data logs, and perform other tasks that the tester must complete before starting the next testing cycle. See also Execution Timing Overview.
  • 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— TestStand Semiconductor Module™

    • V

  • 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.

    • W

  • 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.