Improving Test Efficiency with Concurrent Test

The semiconductor industry is driven by market demands for smaller form factors, greater functionality, higher performance, lower power, component availability, and the need to integrate ever more functional blocks into a single package. State-of-the-art SoCs embed blocks from various sources, such as silicon intellectual-property (SIP) providers, and integrates them within a semiconductor device to provide the system's functionality and performance. SoC design methodology empowers the industry to continue the integrating trend described by Moore's Law, enabling complex, hierarchical designs to be brought to market in a timely fashion.

A functional block may be an embedded memory, a system-interface controller (such as USB), or an internal or third party SIP block designed into the device. Highly integrated SoC devices, for example the 3G-baseband processor in Figure 1, are composed of a wide variety of embedded functional blocks such as:

• Processor/DSP
• Memory
• CODEC
• PLL
• Standard interfaces
• Memory interfaces
• Utility interfaces (such as keyboard, Serial I/O, and others.)
• Mixed-signal I/O
• RF circuitry
• JTAG circuitry.

Improvements in wafer-fabrication technology and industry acceptance of hierarchical design methodologies have enabled ever-increasing levels of integration while speeding time-to-market and lowering overall IC product-development costs. Unfortunately, the trend toward higher levels of integration has resulted in a dramatic increase in the number of transistors relative to the number of pads on these devices, limiting access to SIP blocks. In addition, because each embedded block and interface in the SoC design requires a different test method or test period, cost-of-test is further increased. As a result, test cost-per-transistor, unlike manufacturing cost-per-transistor, has not tracked Moore's Law (Figure 2).

Figure 2:  This cost-per-chip diagram demonstrates that while manufacturing costs track Moore's Law, test costs do not

The embedded SIP blocks in an SoC usually have completely different natures requiring tremendous flexibility in the test hardware architecture for optimal fault coverage and throughput. In the 3G baseband processor example of Figure 1, the target automatic test equipment (ATE) must offer digital pins with scan-test capability, one or more memory test algorithmic pattern-generators (APGs), multiple digital source and capture memories, and analog test instruments including digitizers and arbitrary waveform generators (AWGs).

Traditional shared-resource ATE architectures were not designed to optimize test execution time for complex SoC designs. These architectures use central resources to force common digital sequencing, period generation, time-set selection, scan test, memory-test APG, and digital source/capture on two or more ATE pin channels, preventing the execution in parallel of different SIP blocks. These testers are limited to sequential test execution on a block-by-block basis. Hence, the test time of the SoC is the sum of the test times for each functional block in the chip. As more functional blocks are integrated into next-generation SoCs, test times soar and so does the cost-of-test.

Sequential test execution results in under-utilization of expensive tester resources. As one functional block is tested with a subset of ATE pins, all other channels and subsystems remain unused. Moreover, the need for different test speeds—often to address the increasing complex clock-domain issues among the different blocks in the SoC—prevents full utilization of the installed digital subsystem.

Trends in the test industry—such as BIST, scan-vector-compression techniques, and other methodologies—are aimed at improving tester throughput and utilization when testing complex SoCs. However, for state-of-the-art, hierarchically designed SoCs, it is unlikely that a single test methodology running at a single frequency can test the entire IC. This certainly is true for mixed-signal and RF blocks, and even for the multitude of designs that combine logic and memory blocks. Consequently, there is a good probability that tester I/O bandwidth is not optimally used during the majority of SoC testing on today's shared-resource ATE equipment.

One way to maintain high tester throughput while continuously integrating more functionality into SoCs is to test several of the embedded blocks and device interfaces concurrently. Consider the SoC device in Figure 1. With the appropriate isolation, access, and control schemes, it is possible to execute four tests concurrently on this device resulting in a significant throughput improvement (Figure 3). While this is only a hypothetical example, it shows how powerful concurrent testing can be—reducing the test-time requirement in this example by nearly 70 percent.

Unfortunately, the shared-resource architecture pervasive in today's tester equipment cannot support this type of concurrent test. Concurrent operation in a shared-resource environment demands either common sequencing periods, APG patterns across targeted IP blocks, or significant design work. You need these efforts to ensure that the device, probe card, and load board do not require one or more shared resources for the targeted blocks. Either approach is impractical for today's complex SoC devices.

Achieving true concurrent testing that scales with Moore's Law calls for a new test paradigm. Instead of treating the SoC as a single, homogeneous entity for test, an SoC needs to be viewed as what it actually is—a collection of SIP blocks with multiple testing requirements that can, and should, be tested concurrently.

However, implementing concurrent test demands a full suite of independent test resources dedicated to testing each functional block. In other words, a new tester paradigm needs to emerge to support concurrent test.

Tester architecture needs to move from a shared-resource approach to a per-pin architecture that provides the flexibility to dynamically match the SoC's pin-out. Essentially, a tester per-pin architecture supplies, on each pin, independent periods, timing, levels, patterns, and sequencing. That way, each tester pin can operate in various modes, including clock, SCAN, BIST-control, functional, APG, digital source, and digital capture. Such a flexible arrangement allows on-the-fly grouping of pins into virtual ports to test individual IP cores. Upon completion of one set of concurrent IP testing, the architecture supports immediate port reconfiguration and moves on to the next set of concurrent IP tests until the SoC is fully tested.

Per-pin granularity and the ability to dynamically reconfigure ports are the base requirements for a new multi-port ATE architecture that can independently operate multiple tests at different test speeds. The result is a flexible tester per-port architecture, supporting all traditional ATE capabilities while providing full support for concurrent tests on potentially dozens of ports with different sequencing and digital data rates. Referring to the 3G baseband-processor example in Figure 1, when tested on this ATE architecture, you can configure the memory and logic ports as a single port at the beginning of the test while a setup sequence is executed. Thereafter, the three ports might run independently and concurrently.

There are many benefits of this multi-port ATE architecture. First, tester throughput is optimized with on-the-fly-reconfiguring of the ATE ports to support concurrent test. Obviously, this significantly boosts tester utilization because all of the ATE resources are used throughout the shorter test-execution time. Second, the concurrent test approach allows for straightforward cycling of fractional buses and simplified scan-chain balancing for multiple clock domains, accelerating faster time-to-market. Third, the freedom to combine mission-mode and test-mode execution allows device test to more closely emulate system operation for improved yield accuracy. All of this leads to a lower cost-of-test and faster time-to-market for SoC designs. In fact, the more SIP blocks there are, the more efficient concurrent testing becomes because more of the blocks can be tested in parallel. This allows concurrent testing to scale cost-of-test in accordance with Moore's Law.

Designing for concurrent test does not require major changes in the design process. Target SIP blocks must be completely isolated from each other and the rest of the logic on the chip. In addition, the design needs to enable independent access to, and control of, each block's I/O, ensuring fully independent test execution.

The Design-for-Concurrent-Test (DFCCT) implementation is especially critical to the success of concurrent test. DFCCT plays a key role in ensuring the SoC design can be tested concurrently. Today, DFT tools provide design-for-test capabilities that remove block dependencies and enable the SoC to exploit the parallelism concurrent test offers.

There is a wide range of SoC devices that you can test more efficiently using an ATE architecture that supports true concurrent test. For instance, today's SoC devices embed increasing numbers of memory arrays. Concurrent test enables parallel testing of embedded memories of various sizes, at different frequencies, and with different patterns. In addition, concurrent test supports the need for match-loop functions to test flash memory without interrupting test execution on other pins.

A concurrent test platform will easily handle the various JTAG and parallel test sequences needed for microprocessor and DSP tests, along with the embedded memory tests associated with these cores. The tester will support long pattern lists as well as scan and varying data, making them independently available on a per-port basis. A concurrent test platform also simultaneously sources analog waveforms and captures digital data along with sourcing digital data and capturing analog waveforms on multiple ports running fully independently, as required for testing A/D and D/A converters.

Concurrent testing also provides significant benefits for functional as well as structural test approaches. Even for a hierarchical design that is digital-only, it might be worthwhile to concurrently test embedded blocks, each with its own set of scan chains (possibly running in different clock domains). When combined with multi-site testing, concurrent test can have a significant impact on cost-of-test.

The effectiveness of concurrent test promises to scale with increasing SoC complexity and integration—thereby enabling test costs to track manufacturing cost reductions. As the complexity of the typical SoC increases, opportunities for more and more concurrent test flows will emerge.

About the Author Kathleen Kollitz is the Concurrent Test Program Director at Agilent Technologies. Kollitz has worked for Hewlett Packard/Agilent Technologies since 1989. While at Hewlett Packard/Agilent, Kollitz held a number of positions including Manufacturing Test Engineering, Product Design Engineering, Intellectual Property Team Manager, Application District Manager, and Business Development Manager. Kollitz holds a BSEE from the University of Iowa and a BA from Portland State University.