These devices, which can contain multiple intellectual property (IP) blocks that require different algorithms, edge sequences, clock domains, and supply voltages, can provide a challenge to cost-effective testing. So while IC prices continue to fall, the cost of test keeps escalating, making it a major cost factor for new IC development.
Proven Multisite Testing
The rising cost of test has the test industry searching for innovative ways to improve tester throughput and eliminate inefficiencies. A tried and true approach for boosting throughput is multisite testing. Testing multiple devices simultaneously can enhance throughput dramatically, scaling to accommodate two, four, eight, 16, 32, and even 64 devices.
However, a tester typically has a limited number of algorithmic pattern generators (APGs) as well as a limited number of digital pins and analog pins. To test more devices simultaneously requires more tester resources. Multisite testing also places significant demands on the test team. It requires that the team create special fixturing to support multiple devices and generate the requisite test programs.
Even so, multisite testing has been heavily deployed in markets where the cost of test is large compared to the cost of manufacturing. For example, the wireless and consumer-products industries have eagerly adopted multisite testing to drive down the expense of test for cost-sensitive ICs.
The Emergence of Concurrent Test
A promising new approach for improving tester efficiency is concurrent test. Concurrent test supports simultaneous testing of different IP blocks within a hierarchical SOC design. Being able to test multiple blocks at the same time significantly shortens test times while ensuring tester resources are being used at full capacity, as shown in Figure 1 (see below).
Figure 1. Example of Concurrent Test Flow
In fact, as SOC complexity rises, concurrent test becomes more effective because more IP blocks can be tested in parallel. Consequently, concurrent test provides a feasible way to bring test costs in line with Moore’s Law, even in the face of increasing integration in SOCs. Concurrent test is ideal for testing complex ICs for emerging consumer industries such as Bluetooth-enabled devices where RF, analog, and digital circuitry are combined on a single SOC.
Concurrent test is most successfully implemented using a flexible, test processor-per-pin architecture as opposed to the traditional shared-resource architecture found in most testers. Instead of sharing crucial testing resources like most tester architectures, every pin supports the full range of tester modes including clock, scan, built-in self-test control, functional, algorithmic pattern generation, and digital source and capture. Essentially, every pin in this new type of tester platform provides complete period, timing, levels, patterns, and sequencing, as shown in Figure 2.
Having such a flexible arrangement allows for grouping of pins into virtual ports to test IP blocks. Each port can behave as if it were an independent machine, with different test periods and loop/subroutine instructions. Once the test is complete, the tester pins can be immediately reconfigured and assembled into new port configurations to conduct a completely different set of tests.
With this elastic architecture, the tester can provide full support for concurrent tests on potentially dozens of ports with different sequencing. Even the need for different test speeds—often to address the increasing clock domains among the different blocks in an SOC—can be supported, allowing for higher levels of concurrent test.
With a multiport architecture, more expensive, high-performance resources can be intermixed with less expensive resources on a pin-per-pin basis, helping to lower fixed tester costs. For example, if an SOC needs only two or three 1-Gb/s signals and the remaining signals operate at frequencies below 200 MHz, only the necessary high-performance pins are required, and the rest of the system can be filled with low-cost, lower speed pins.
Channels with different speeds can operate at different frequencies in a single test run. This capability, called port scalability, enables a test system to be configured with the appropriate resources to meet the test requirements of a particular device.
To make concurrent test work, the processor-per-pin hardware must be supported by a software environment that decouples the testing of each IP block. That way, concurrent test can support “n” simultaneous test programs on the same device by focusing each test program on a different I/O or internal core section of the device.
To achieve maximum return, concurrent test requires some consideration by the IC designer early in the design cycle. Although concurrent test does not entail a major overhaul in how designers create their ICs, there are some requirements SOC designers must keep in mind. Specifically, IP blocks that are to be tested concurrently must be isolated and made independently accessible, observable, and controllable.
Throughput Squared
Concurrent test can be used in tandem with multisite testing to yield significant increases in tester efficiency. For example, four devices could be tested simultaneously, with six IP blocks in each device being tested concurrently. So instead of a fourfold increase in device test throughput using multisite testing, the combined outcome could be as high as a 24× improvement in throughput.
It is very easy to extend multisite testing to support concurrent test to simultaneously test multiple IP blocks on multiple devices. The combination of multisite and concurrent test already has been used successfully with memories that have a lower pin-count than the typical ASIC or SOC.
For all the benefits that accrue from combining multisite testing and concurrent test, sometimes it makes sense to use one or the other and not both. It helps to think of multisite test and concurrent test as tools in the test engineer’s arsenal for improving throughput and tester utilization.
When and where to use multisite or concurrent test alone, or together, depend on the type of device being tested. Judicious use of these tools, on a case-by-case basis, can significantly lower the overall cost of test, especially when testing cost-sensitive consumer and communications ICs.
Let’s take a look at a few scenarios:
Scenario 1: Taking a Tiered Approach
With almost any new IC destined for the consumer market, there always is uncertainty about the long-term success of the device. In this case, management would be reluctant to commit upfront to additional testing resources to test the device. A more prudent approach uses concurrent test with existing tester resources to boost tester throughput in the short term. Then, once the device is shipping in volume and has been accepted by the market, the test engineers could justify the investment in added tester resources to support multisite, concurrent test.
Scenario 2: Nonhierarchical Design
There still are many cases today where ICs are relatively flat designs. These nonhierarchical designs do not map well to concurrent test since little, if any, of the testing can be done in parallel. In this situation, the test engineer should rely on multisite testing exclusively to enhance tester throughput.
Scenario 3: Best of Both Worlds
There will be cases where testing resources are sufficient to test multiple devices and concurrent test can be deployed with a block-based SOC. In these circumstances, the full benefit of the combined multisite, concurrent approach will directly lead to significant improvements in tester efficiencies.
Driving Down the Cost of Test
Combining multisite test with concurrent test leads to more efficient test. Together, these two techniques can yield tremendous increases in throughput and tester utilization, helping to drive down the immediate cost of test. And looking into the future, using concurrent test in conjunction with multisite testing offers a long-term solution to cost-effectively test ever more complex devices. In short, the combination of these two approaches goes a long way toward bringing test costs in line with Moore’s Law.
Multisite, Concurrent Test With Reduced Tester Resources
Combining multisite test with concurrent test typically demands a robust set of resources. But with some minor design modifications early in the design flow, it is possible to support multisite, concurrent test with reduced pin-count. All it takes is upfront thought and care applied in the design phase along with reliance on design tools that are aware of the capabilities of the target test equipment.
For example, design-for-test capabilities can be used to reduce the pin requirements, increase the degree of parallelism, and decrease the overall cost of the tester. Then, concurrent test and multisite implementation can be relied on to minimize the test time to maximize throughput gains.
About the Author
Wilson Spence is the concurrent test program manager at Agilent Technologies. In 20 years with the company, he has held a number of positions in application engineering, engineering management, technical consultancy, and marketing management. Prior to joining Agilent, Mr. Spence was employed by Philips and John Vince Controls. Agilent Technologies, 815 14th St. SW, DL 416, Loveland, CO 80537, 970-679-3726, e-mail: [email protected]
Return to EE Home Page
Published by EE-Evaluation Engineering
All contents © 2001 Nelson Publishing Inc.
No reprint, distribution, or reuse in any medium is permitted
without the express written consent of the publisher.
January 2002