Since the first transistors went into production almost six decades ago, semiconductor manufacturers have looked for ways to reduce test time and manufacturing costs. As the industry has grown from transistors and diodes to integrated circuits and now complex SOC and SIP devices, the constant need to reduce cost of test continues with even more intensity.
When a digital device is combined with ADCs, DACs, and other analog and digital cells, the mixed-signal device emerges. As more functionality is added, test lists become longer, and test times increase.
The next step in helping to reduce the cost of test for these more complex devices is to test the device in parallel. Multisite testing addresses part of the cost challenge because the devices can only be tested as fast as they actually operate.
For example, a digital device that operates at a maximum vector rate of 100 MHz and requires 250 Mvectors to test the device will consume a minimum of 2.5 seconds of test time. This time also is known as device-limited test time (DLTT) because it is the theoretical minimum possible test time for the device. If the device also contained an ADC and DAC, then the time will continue to increase based on the tests needed for these mixed-signal cells. The DLTT could increase to at least 4.5 seconds.
Concurrent testing can help drive test times below the DLTT. This is accomplished by testing different cells of the device in parallel. That is, where practical, test multiple cells at the same time. If we look at a representative SOC device, it may contain a digital core, ADCs, DACs, and specialty digital and analog cells. Typical programs will test these cells serially and then test the entire device functionality as a complete system. Concurrent test allows testing the cells in parallel and then the entire device functionality, providing a significant reduction in the overall time.
Is the Device Suitable for Concurrent Test?
The most important consideration is whether the semiconductor device has been designed to support concurrent testing. Many of the SOC and SIP devices are designed with building blocks of standard cells, ADC, DAC, and amplifiers. The digital cells might be interfaces such as LAN, PCIE, or other standard ports. The digital core often is one area where long vector bursts may be tested in parallel with other cells. Some of the factors that need to be evaluated are the following:
•?Do tests exist that are long other than system functional tests? Many programs test the individual cells of the device before attempting to test the full functionality.
•?Can individual cells be tested independently? Cells must be capable of being set up and tested without requiring access to other cells.
•?Do the individual cells have independent power pins? Shared power may compromise independent testing.
These items represent a sample of what needs to be examined to determine whether the device is a candidate for concurrent test. Depending on the type of device, there may be other considerations.
Figure 1 illustrates an SOC device candidate for concurrent test. The device requires performance digital, DC and AC instrumentation, and multiple time domains (MTDs). Independent operation of each cell in the mixed-signal SOC device allows concurrent test of several cells at once.
Is the Tester Capable of Concurrent Test?
The tester needs to be evaluated for its capabilities to perform concurrent test:
Support for Multiple Time Domains
Concurrent test of a device will frequently require the tester to provide an independent time domain for each device cell because each cell has its own timing requirements. If the cells were tested serially, then a simple coding change can be performed to modify the tester timing for each of the cells. With concurrent test, the timing for all cells must operate simultaneously.
Independent Pattern Flow
MTDs enable test vectors for each cell to operate independently. The tester’s digital instrument needs to support multiple pattern generators. In concurrent testing, the patterns can start together and then flow independently according to the flow requirements of the cells being tested.
Pattern Control of Instrumentation
Testing mixed-signal cells in the device will require the use of DC and AC instruments. The capability to control these instruments within the pattern flow is very desirable because it can minimize the interaction between the test program and the pattern to greatly simplify the programming effort and minimize test time.
Background Processing of Test Results
A major consideration for successful concurrent test is the capability to process captured data from the cells using DSP techniques. However, the DSP needs to run in the background of the actual testing activity. This will optimize the throughput benefits of performing concurrent testing.
Pattern Sequencing
When testing the digital core cell, it is important to have the capability to start the pattern generator and allow it to execute all of the digital test patterns. While testing the digital core cell, other mixed-signal patterns need to be started and halted as testing of the mixed-signal cells is carried out. As a result, some pattern generators must run sequences of patterns without interruption while other pattern generators need to be started and halted.
Designing a Concurrent Test Interface and Program
The design of a concurrent test interface requires evaluating which device pins align to different time-domain groupings. This involves partitioning tester resources based on the tester’s capability to support MTDs. If both concurrent and multisite testing of the devices are to be implemented, then the various sites may be able to share instruments within the defined time domains, reducing overall cost.
As an example, if the device requires two time domains where each time domain needs 32 pins and the tester instrument board contains 128 channels and will support a single time domain, then two tester instruments are needed to support the time domains, and four device sites can be supported with 32 channels per instrument per site. Boards could be added to the test system to support more time domains and/or more device sites. To achieve the high efficiency benefits of both multisite and concurrent test, enough instruments must be available in the tester.
Once the test configuration and the interface design are understood, the test program design can begin in earnest. The next step is to determine which cells of the device will be tested concurrently and what the sequence of test should be for each cell. Typically, the cell or section of the device that must be tested serially and takes the most time to execute will define the test time. The remaining cells and their respective tests will be tested concurrently.
Figure 2 illustrates a high-level view of how the concurrent test could be implemented. A digital burst of 1 Mvectors executing at 1 MHz will take approximately 1 second to execute. In a traditional test program, the ADC and DAC tests would follow.
These test times are from an actual test program developed to prove these concepts. An ideal implementation of concurrent test would put all the ADC cell and DAC cell tests under the umbrella of the digital core vector burst. The selection of tests to run concurrently with the digital core tests should have test time equal to or less than the digital core tests. Once the tests are selected, it is best to combine the setups for the tests.
Patterns for the mixed-signal cells may need to be modified to allow them to drop into idle or keep-alive loops. This will facilitate handshaking between the mixed-signal cell patterns and the test program. While the mixed-signal cells are being tested, the digital core patterns are being executed as an independent serial set of pattern bursts.
Once the digital core pattern and the first set of mixed-signal cells are started for the concurrent test burst, the flow needs to be monitored by the test program. Communications between the mixed-signal cell tests and the test program allow the flow to progress through the multiple tests executed in that area.
Typically, the program polls for a test complete from one of the time domains. After starting the post-processing of that test sequence, the next test for that time domain can be queued up and polling can resume looking for the next time domain that needs servicing.
This is where tester architecture can provide a major benefit. If the tester is capable of allowing multithreaded test code, then the polling processes can become multithreaded wait loops that will continue when their time domain is ready to be serviced. If multithreading is not available, then the polling loop may need to be designed into the test program, and this will make development significantly longer.
Potential Payoff From Concurrent Testing
Concurrent test solutions can provide a significant reduction in test time. Depending on the design of the device, 50% reductions can be attained, providing significant throughput improvement. When this is combined with multisite testing such as dual- or quadsite testing, even greater throughput benefits can be realized. The key to successful concurrent testing is a device design that allows access to separate cells or sections of the device, a test system architecture with the critical features described, configuration flexibility to have the right mix of instrumentation, and multithreaded software to enable short test-program development time.
About the Author
John Yost is an applications engineer in the Semiconductor Test Division of Teradyne. He has 40 years of experience in the ATE industry focused on mixed-signal and analog products. Mr. Yost attended Arizona State University. Teradyne Semiconductor Test Division, MS 600-3, 600 Riverpark Dr., North Reading, MA 01864, 978-370-2566, e-mail: [email protected]
April 2009