This article discusses the test development architecture and features available in the TS-900e and TS-960e series semiconductor test stations when creating a test program for multiple site parallel testing. It covers built-in ATEasy tools for semiconductor testing, ICEasy abstraction layer drivers for model independence and scalable test program development, as well as some considerations for measuring performance.
Single site testing is use of a test station, test equipment and software to evaluate a single die. The necessary stimulus and measurement channels are routed to a test socket mounted on a device interface board (DIB) attached to the test station. When testing completes, the device-under-test (DUT) is classified and binned according to the test results. After the test is complete, a new DUT is tested by moving the IC out of the test socket manually or with an automated handler, or by moving the test head to the location of the next die in queue.
Multiple site testing involves testing multiple dies in parallel on the same test station, which is achieved by using duplicate test sockets or test heads, sharing instrument resources or augmenting the test station with duplicate test instruments to operate in parallel. Coordination of these instruments and any shared resources is regulated by the test program's underlying software.
Software Considerations when Designing for Multi-Site TestingATEasy’s approach to multi-site testing is to design a single Test Program file (.PRG) from which multiple identical instances can be created and executed against a physical DUT. Since identical copies of test software are run against various ICs, the test program should be written is a way which allows it to scale up to the amount of DUTs the load board and instrumentation is capable of supporting.
When multiple instance of a Program are started, an identical instance of the test program is created for each configured DUT based upon the configured value of App.UutCount, as described below. These programs can be executed sequentially or in parallel based on user configuration. Usually, both tests sites will use an identical test program to test DUTs of the same series although it is possible to configure the test program to test different ICs in parallel.
Since the test code is identical, a method to differentiate the Program instances and sockets was devised. During test execution, the ATEasy reserved project variable App.UutIndex is automatically set to reflect the active Program instance at the moment the test code is executing.
When enabling multi-site testing, an ATEasy reserved property, App.UutIndex, is used by the test program instance to differentiate between test programs and to determine which instruments should be used for stimulus and measurement. During test program execution, App.UutIndex will update to report a value between 0 and App.UutCount-1 where App.UutCount is the value configured by the user via the Select Program/Profile dialog or SetUutCount() command.
See the ATEasy help article for more information on using "App.UutIndex".
Design EfficiencyEfficiency can be quantified by comparing the multisite test time with single-time test time as follows:
This can also be represented mathematically as follows:
Where:- tN is the test time for N sites
- t1 is the test time for a single site
In the best case scenario: a single site takes 100 mSec and two sites in parallel also 100 mSec to test, tN and t1 are equal and the equation simplifies to 1 or 100% efficiency. This example is truly parallel. Conversely and a worse scenario, if a single site takes 100 mSec and two sites take 200 mSec, tN - t1 is equal to (N-1) * t1 and the efficiency equation simplifies to 0 or 0% efficiency, which is more representative of serial operation. A more realistic example would be converting a single site test of 100 mSec to a quad site test which takes 130 mSec to complete all 4 dies. Test time growth would be 30 mSec and 3 sites were added to the system resulting in a 90% efficiency.
To evaluate this in another way, we define a simplified cost-to-test formula as the cost of the test station plus operational costs divided by the parts produced.
In the previous example, 1 unit was tested in 100 mSec. The parallel testing paradigm improved this to 4 units in 130 mSec. Let's assume that operational costs for the single unit amounts to 0.50 cost units.
Evaluating multi-site testing improvement is a matter of find the ratio between the original cost-to-test and the multisite cost-to-test.
The cost-to-test improvement is 0.5 / 0.165 or approximately 3 times (i.e 3 parts tested for the price of 1 part).
Configuring Multi-Site Domains Using Driver ShortcutsAll ATEasy drivers, including drivers such as the GX5296.drv for digital input/output (DIO) and AgNA.drv for vector network analyzer (VNA) are designed to initialize instruments when the system module is initialized and store the driver handle for each initialized instrument. During initialization, test sites are separated in the Driver shortcut parameters using a ‘;’ delimiter. For instance, a VNA driver shortcut with the ResourceName of “PXI17::0::INSTR;PXI18::0::INSTR” will use PXI17::0::INSTR for the first site in which App.UutIndex=0 and PXI18::0::INSTR will be used for second site in which App.UutIndex=1.
Calls to these instruments will have a parameter nDomainIndex or nHandleIndex which will route the command to the appropriate instrument. The default index value is 0, which is the App.UutIndex when only one instrument exists. If developing for multi-site testing, the usual input argument will be App.UutIndex.
In addition to setting the Driver Shortcut parameters through the Properties Editor, the configuration can be done dynamically during system initialization. Dynamic configuration is not required in most cases as the slot number and resource string will not change unless a PXI instrument is inserted or removed.
ICEasy Structure for Multi-Site TestingThe ICEasy driver resolves the problem of resource allocation and App.UutIndex value allowing the user to write a test program which scales to the number of test sites automatically. A top-level command of a test program written by a test engineer using ICEasy does not reference the App.UutIndex property. The reference to App.UutIndex occurs in the abstraction layer of the driver.
The command written by the test engineer would look like this:
! Measure nChannel at a rate of 60 Hz and assign to TestResult
TestResult=ICEasy DIO Measure Voltage(nChannel, 60)
If this command were written using low-level or direct instrument commands, each command would need to be written to pass the App.UutIndex in the nDomainIndex parameter. The same test code in a test program using direct driver commands would be written like this GX5296-specific example:
DIO Measure Voltage (nChannel, TestResult, 60, , , , App.UutIndex)
In either scenario, the test program would support both single-site and multi-site testing as App.UutIndex value would remain at its default value of 0 for a single DUT.
Configuring a Single Instrument to Service Multiple Test SitesIf an instrument has multiple independently operating channels, the instrument may be configured to support expansion to multiple test sites. As an example, consider a test station which includes two Source Measure Units (SMUs), each with four channels. If these cards are initialized using the method suggested in the Driver Shortcuts section, they could support two test sites with the first test program instance sending all commands to the first board and the second test program instance routing all commands to the second board. If the test program only utilizes two channels per site, then a total of four channels would be unused.
To remove this inefficiency, ICEasy can be configured with some instrument classes to specify the number of channels to be used per site (the domain size).
! Configure the SMU to use 2 channels per DUT
ICEasy SMU Set DomainSize(2)
In this example, the two SMU test station will direct commands from the first site to channels 1 and 2 of the first SMU and the second program will control channels 3 and 4 of the first SMU. The second SMU would not be needed for this test configuration, but would automatically be used if up to two more test sites were added to the system.
Because the model of the instrument is unknown by the ICEasy driver, the board’s maximum channel count must be written into the ICEasy interface driver (e.g. ICEasy_GX3104.drv). This value will be used to determine if the specific model is capable of supporting a split domain and how many channels are supported. The test program will notify via exception if the domain size requested is beyond the capacity of the selected instrument model. For backwards compatibility, the default domain size is equal to the maximum channel count of the board.
System, Program and Test VariablesEach instance of the Program module has unique instances of all the Program and Test variables which are independent from the Program instances from the other DUTs. These variables can be accessed from the test code and procedures without any modifications or concerns. Variables in the System module and Drivers are not duplicated and are shared by all Program instances. This means that multiple Program modules could attempt to write to or read from the same data in parallel. This behavior could lead to one thread accessing stale data or data intended for another Program or overwriting data which another thread intends to access. To mitigate this potential issue, the test developer should avoid the use of System variables in the Program modules. If System variables are used, access to these variables should be protected with a synchronization object and each thread should have a copy of the variable that is independent from the other instances.
See the following ATEasy help article for more information on multithreading and synchronization "Multithreading Considerations", "Procedure Properties"
Configuring your Test Application to Support Multiple UUTsThe default state of ATEasy and the Test Executive is to use single-site testing. To configure for multi-site testing, multiple UUTs must be enabled and test programs must be assigned to each site. Enabling multiple UUTs can be done manually or programmatically.
Manual configuration- Launch a single-site application which utilizes the Test Executive.
- From the Test Executive menu, open the Customize dialog by clicking the menu item Tools | Customize
- Navigate to the Options tab and switch the ‘Enable Multiple UUTs’ value to True.
After multiple UUTs is enabled, the DUT count can be set to a value greater than 1 and test programs can be assigned to the DUTs.- From the Test Executive menu, open the Select Program/Profile dialog.
- Change the UUT Count to the desired number of test sites.
- Enable Run Parallel. The default option is to execute the test programs sequentially.
Programmatic configuration- In a system or driver module, call the following command to enable execution of multiple test programs
TestExec Customize Options Set (ateOptionsEnableMultipleUUTs, True) - In a system or driver module, call the following command to set the DUT count to match the number of parallel test sockets available
! Configure for two DUTs
TestExec Execution SetUutCount(2) - Assign the test program to the test sockets, making sure to set the test mode to parallel
! Assign programs, setting sites 0 and 1 run the same test program in parallel
TestExec Execution LoadProgram("DualSiteExample", , aUutRunModeParallel, 0)
TestExec Execution LoadProgram("DualSiteExample", , aUutRunModeParallel, 1)
Final ConsiderationsWhen designing for multi-site applications:- Modify the Driver Shortcut parameters to add the extra domain using the ‘;’ delimiter so instruments are initialized into different domains and can be called using a single driver
- At the Test level of your code, avoid the use of commands which target a specific instrument driver. Instead of calling DIO directly, use an abstraction layer like ICEasy.drv which can handle the task of directing the command to the correct instrument domain and supports instrument replacement
- Only Program variables are duplicated in a multi-site application. If a System or driver variable is used, check to ensure that access is protected with a synchronization object and the variable can support access from multiple-threads without impacting other Test Programs
More articles on Multisite Design
KB Article #Q200340 - Multisite Digital Test System Design
KB Article #Q200242 - Testing Multiple UUTs in ATEasy
|