ATE Implementations for Multisite Device Test

Hand-held consumer products, such as cellular phones and PDAs, are driving demand for system-on-a-chip (SOC) and system-in-a-package (SIP) devices. SOCs and SIPs contain multiple integrated functions and are designed to reduce device size and product cost.

SOC devices comprise analog, digital, or mixed analog and digital cores on a single die. These mixed cores include digital-to-analog converters (DACs) and analog-to-digital converters (ADCs). They provide complete system functionality on a single chip. SIP devices also offer complete system functionality but integrate multiple independent die.

Multisite Test Efficiency

Semiconductor manufacturers are implementing multisite test to drive test costs down. The effectiveness of multisite testing on cost is determined by efficiency, the relationship between single-site test times vs. multisite test times. A 100% efficient multisite program achieves the same test time as a single-site test time. So if you are testing four sites, the test time per device is the equivalent of 25% of the single-site test time. If you are testing four sites at 0% efficiency, the total test time for four sites would be four times the single-site test time.

To achieve the optimum cost of test on SOC and SIP devices, efficiencies of 90% to 99% are necessary. The calculation for multisite efficiency is as follows:

When operating in multisite, a series of test issues must be addressed. The most important is to strive for efficiency not impacted by added site count. It is preferred to have the efficiency for eight sites be the same as the efficiency for two sites. Management of divergent test-program flow execution, where one site needs to execute a different set of test code or tests from other sites, ranks as a secondary factor.

The computer-based control of ATE is made up of hardware, the software operating system, and tester instrument software drivers. Each of these elements is key to the overall performance efficiency of multisite testing. Four common implementations of ATE computer controls are found today:

1. Standard Computer Implementation

2. Standard Computer With Multi-threading Software

3. Controller-Per-Site Implementation

4. Distributed Control Implementation

Standard Computer Implementation

The standard computer implementation uses a brute force type of software solution. It offers the lowest efficiency because it only executes one command at a time in a serial flow. As an additional test site is added, the computer simply repeats the command used to control hardware at the first site for each successive site.

The execution of a test involves the setup of the test-instrument hardware, wait time to allow the hardware and the device to settle, measurement execution of the hardware, and finally a readback of the measurement from the hardware followed by a decision in the software of whether the measurement was a pass or fail when compared to limits (Figure 1).

Figure 1. Mixed-Signal Test With a Standard Computer Implementation (Single vs. Dual-Site)

The only steps in the test that can take place at the same time are some of the wait time for settling and part of the measurement execution. For the model test we are using in this example, the efficiency is only 81.25%, primarily due to the serial execution of setup commands. As the site count scales upward, the efficiency moves up to 85% (Figure 2).

Figure 2. Mixed-Signal Test With a Standard Computer Implementation (Quad-Site)

When implementing multisite testing, it is important to manage divergent test-program flow. In both SIP and SOC testing, there are times when a test measurement is taken from the device, and based on that measurement, a different test needs to be executed or the setup of the test hardware needs to be changed.

If we look at an example where a test-program flow changes based on the operating speed of the device, there may be a device in one site that operates at a full 1-Gb/s data rate, but the device in the second site is operating at only 730 Mb/s. In this situation, the tester hardware on the two sites must be set up to different sets of timing values. It is important for the device manufacturer to do this because the higher performance device will command a higher selling price.

Another example of divergent flow is when a measurement on the device is taken and the result requires additional tests to be made on that one device. If the measurement on another site does not require the additional tests, then a divergent flow needs to take place.

In both this and the previous example, divergent flow becomes a serial process of additional tests while the second site remains idle. This results in 0% efficiency for that portion of the test program. The single-computer implementation does not provide efficient multisite testing and cannot manage divergent test flow.

Standard Computer With Multithreading

With a multithreaded environment, divergent flows can be well managed. Multithreading provides the capability to launch a thread on a per-site basis. From the user�s perspective, a thread appears as though the computer is dedicated to that site and manages the divergent flow independently of the other sites but in parallel with different activity on the other sites. In other words, a thread is launched per site, and the computer services each of the threads independently as though they were separate program executions.

You could assume that this yields 100% efficiency, but it doesn�t. In fact, with a single computer, the computer must service each thread and is the common element between the threads or sites. As a result, the commands from the computer go to each thread in a serial fashion.

This is one of the major shortfalls of the multithreaded environment. Since the computer manages multiple threads at a time as a shared resource, the execution of commands is still serial. Consequently, the efficiency is not impressive.

The multithreaded environment has an additional shortfall. To manage the threads that need to share a common set of resources such as a single computer, single data bus, and a single digital signal processor (DSP) for testing mixed-signal devices, the software needs to have additional code embedded to manage the integration of the threads.

The added embedded code is in the software whether testing in a multisite or single-site environment. This embedded code causes additional test time overhead when testing a single site because the computer is required to execute those extra commands.

This additional test time at a single site inhibits the tester from approaching device-limited test time, test time limited only by the operation of the device. Although the multithreaded environment is very effective at managing divergent test-program flow, the additional overhead in software code adversely affects both single-site test time and multisite test efficiency.

Controller Per Site

The controller-per-site architecture provides a test computer for each test site, which is a good solution to divergent test flow and multisite efficiency.

With a computer per site, the tester hardware for each site is completely dedicated to the site. This also includes the computer control bus.

Essentially, it appears as though there is a complete test system per site packaged in one test head and system mainframe. This solution is effective at maintaining nearly 100% efficiency and very effective at handling the divergent flow challenge.

However, there is a higher cost associated with the controller-per-site solution. There is a need to replicate the test computer and each instrument for the number of sites. The per-site controller architecture cannot handle the sharing of resources across sites. For example, if a DSP engine and time-measurement instrument are used for mixed-signal test, they need to be provided on a per-site basis.

And for all device testing, the computer control bus must be physically partitioned for each site. In the end, providing a partitionable computer bus is complex and very costly. An implementation like this can consist of a programmable multiplexer in the mainframe that assigns card slots in the test head to specific test sites. Not only is the multiplexer a large cost overhead, but the effectiveness of hardware utilization also is reduced.

To drive cost down in test-instrument design, equipment vendors are driving the density of instrumentation up with more digital pins per board and larger numbers of sources and digitizers per board. When the computer bus for a specific site is programmed to control a specific slot, then all of the pins on the board in that slot are assigned to that site.

For example, if a site needs 96 digital pins and each digital board supports 64 pins, then there are two boards that must be assigned per site. This leaves 32 unused digital pins per site, and this has a significant cost-of-test impact.

Implementing Distributed Control

Distributed control overcomes some of the shortfalls of the previous approaches while maintaining lowest cost of test. With a distributed control implementation, the entire system is designed from the ground up with the requirement of supporting highly efficient multisite testing for SOC and SIP devices. With this approach, the instrumentation, the computer, and the software environment are designed for multisite testing.

For example, one of the elements of test that impacts a single-site test time is the time required to set up instrumentation to the proper values prior to making a test measurement. This typically is time added to the test program and considered overhead.

When going to multisite such as eight sites, this overhead may be repeated for each site, further reducing the overall test-time efficiency at multisite test. In this example, if the test setup requires 5 ms to program all the different instruments connected to the device to the proper values, then when the program is converted to a multisite test program, the time to program instruments is a multiple of the number of sites or 40 ms.

This issue can be overcome if the hardware instruments and software drivers are designed to allow the added sites to be programmed and settle to their programmed values simultaneously. To do this, the instrument needs to be designed with site-enable registers that allow it to listen to the data bus and, when a command is sent over the bus, respond to it accordingly.

This capability allows a single computer command to be broadcast to multiple instruments at the same time, resulting in the instrument at each site being programmed at the same time. It leads to efficiency values that can exceed 96% (Figure 3).

A second key enabler to a multisite architecture is providing ways of minimizing the amount of measured data that needs to be read back from the instruments at each test site. This can be accomplished by providing measurement instruments with local hardware-based comparison to test limits that enable the computer to read back pass/fail values vs. numerical values for each site and then comparing them in the software program.

When testing SOC devices that contain analog components such as ADCs or DACs, it is necessary to use DSP techniques to determine the test results. The system architecture needs to add processing power to ensure that efficiency is not reduced as the site count increases. There are more converters to be tested, increasing the amount of data to be processed that otherwise could reduce efficiency.

The test system also is required to manage a significantly larger volume of data. A system architecture that has multiple data paths and multiple DSP engines can be scaled to meet the requirements of a multisite test scenario and not cause an impact on the multisite efficiency.

Conclusion

There have been many ATE computer-controlled implementations that address the challenge of performing multisite test efficiently. These implementations focus on computer architecture, a computer-control bus, and software.

However, to deliver the optimum efficiency with the flexibility necessary for a low-cost test system, the solution also must include test-system instrument design. A system architecture with the computer, instrumentation, and software designed from the ground up with high-efficiency multisite and optimum test throughput will deliver the results semiconductor manufacturers need to minimize the challenge of reducing overall cost of test.

About the Authors

Randy Kramer is the technical marketing manager for the Semiconductor Test Division at Teradyne. The 23-year veteran of the ATE industry has a background in mixed-signal testing and graduated from Rensselaer Polytechnic Institute with a B.S.E.E. e-mail: [email protected]

Dan Proskauer is the lead software architect for the Semiconductor Test Division at Teradyne. He joined the ATE industry 15 years ago after graduating from Cornell University with a B.S.C.S. and holds several patents in the ATE software area. e-mail: [email protected]

Teradyne, 321 Harrison Ave., Boston, MA 02118, 617-422-2700.

July 2005