Design holds the key to cost-effective SOC testing

As device complexity grows and fabrication costs continue to fall, test is emerging as the largest expense in complex SOC (system-on-chip) IC manufacturing. At the same time, ICs continue to exponentially increase in complexity, driving up test times. Many SOC devices incorporate multiple technologies, such as high-speed logic, DRAM, flash memory, and analog circuits. Testing these circuit types has historically required diverse types of ATE (automated test equipment). High-performance mixed-signal ATE is now available to handle SOC devices that contain multiple circuit types, eliminating the need for multiple test insertions. However, the multiple technologies' different testing requirements normally require you to sequentially conduct tests, lengthening test times and raising manufacturing costs.

IC manufacturers are looking for ways to significantly shorten test times and thereby reduce manufacturing costs. However, IC designers usually don't consider the cost of testing. This situation is unfortunate, because eliminating a few seconds of test time would significantly reduce the cost of testing most SOCs.

Tester time on high-performance ATE systems can cost as much as 10 cents/sec, which might not seem like much. But if a company ships millions of ICs per month or per year, the tester-cost savings can easily add up to millions of dollars. For example, if you can shave 5 sec of test time per device in production test, and the volume of devices is 10 million units a year, the cost savings would be $5 million: Savings=(10 cents/sec)×(5 sec)×(10 million units)=$5 million.

Viewed from another perspective, if you can trim 5 sec off the test time for each device, the total time saved (assuming 100% equipment usage and round-the-clock operation seven days per week) would be 578 days: (5 sec/unit)×(10 million units)=578.70 days. If the IC-test systems run approximately 80% of the time, the test-time savings would eliminate the need for two systems, each of which probably costs $3 million or more.

As these examples show, time is money in manufacturing test, and every second counts. The most effective way to shorten test times is to test more of the SOC IP (intellectual-property) cores in parallel. However, for best results, the SOC design should anticipate parallel testing, and manufacturers must perform testing in a way that doesn't compromise high-performance test requirements. Many test approaches allow for some degree of parallel testing, but all have limitations.

For example, serial-access schemes are predicated on embedded scan ports for each of an SOC's IP blocks. A tester can access and examine multiple scan chains if the IC designers add a few pins per port. IDDQ test, which measures the device's power-supply-current drain, I_DDQ, when the device is in the quiescent state, is inherently concurrent and requires no additional pins. I/O multiplexing allows internal-core access using shared I/O during test. But this technique often requires some internal multiplexer isolation and is limited by the number of top-level I/O pins that can be shared.

Several BIST (built-in-self-test) approaches support concurrent test for specific applications. For instance, memory-BIST engines are widely used for large memory arrays. Logic-BIST engines support core-based testing, helping to reduce test-data volume. Other methods include bus splitting, in which each IP block controls a portion of the bus during test mode, providing independent IP testing with few, if any, additional pins. And loopback schemes are well-suited for analog-interface tests. Loopback schemes allow testing of two or more blocks at once without requiring any dedicated test pins.

All of these methods support test concurrency to some degree, but most do not address the isolation requirement necessary to simultaneously conduct different types of testing with different timing conditions on multiple IP cores.

As high-performance and mixed-signal SOCs have emerged, so have ATE systems with per-pin architectures. This new breed of ATE systems is enabling IC designers to pay close attention to a relatively new technique called CCT (concurrent-core test). With CCT, test systems designed for the purpose can easily test in parallel dozens of IP blocks representing a broad spectrum of circuit types—from memory and high-speed logic to analog and even RF blocks (Figure 1).

CCT relies heavily on tester architecture as opposed to placing the burden on IC designers. CCT demands a flexible tester architecture that can group subsets of ATE pins into temporary ports to test specific circuits in an SOC. Test engineers can define dozens of these ports and simultaneously implement them in the device under test. There, multiple tests can execute independently, each with its own vector set and timing, even including different clock rates. This approach enables concurrent testing of circuits, such as analog and digital function blocks, which use widely different technology.

Unlike the traditional shared-resource approach employed by large numbers of older ATE systems still in use, CCT requires ATE systems to use a per-pin architecture. For example, Agilent's 93000 SOC-series test system offers a test processor per pin, minimizing tester-related design constraints and enabling the tester to concurrently test an SOC's many functions. Each pin is equipped with independent APG (algorithmic pattern generation), period timing, levels, patterns, and sequencing. As a result, each pin can operate in a different mode—clock, APG, scan, BIST-control, or functional—that can change for each test. This flexible architecture supports unrestricted configuration of each pin's function, allowing phase-synchronous operation of interdependent ports and approximating asynchronous operation of independent ports. To realize even greater gains in tester efficiencies, test developers can even use the traditional test methods—scan, BIST, and IDDQ—in conjunction with CCT.

CCT can have a significant impact on manufacturing-test throughput. Take, for example, the results of testing a cellular device: The test time without CCT is 8.8 sec, and the test time with CCT is 5 sec. Therefore, using CCT results in a 43% reduction in test time.

IC designers need to keep in mind some considerations to optimize devices for concurrent test. DFCCT (design-for- CCT) extends core-based design to enable chip-level vectors to target specific cores. For core-based testing, the cores must be accessible, observable, and controllable. To support CCT, the cores must also be designed to be independent from each other. In other words, different cores that you are going to test concurrently cannot share any chip-level I/O pins or internal test-data buses.

IC designers need to think about CCT in the same way that they think about any other important device feature. They should specify, design, and verify CCT operation for correct function, timing, and power requirements. You must define DFCCT early in the design project to ensure that it does not later impact the schedule (Figure 2). The design team should also clearly understand the manufacturing requirements and the resources of the ATE system that will be used in manufacturing test. It is important to know the target tester's CCT capabilities, such as vector-memory size and number of signal pins.

Once the IC-design team has determined all of these factors, the next step is to identify the IP cores that consume the most test time and decide whether you can test those cores concurrently. The goal is to minimize the idle time of expensive tester resources. To minimize the device's overall test time, the goal is to test the cores with the longest test-time budgets concurrently with other cores. The design team also needs to define the top-level core-test access, top-level test-signal connections, SOC-test-controller requirements, and test-mode scheduling. The team needs to consider these and many other CCT-related issues early in the project (see sidebar "Some questions to ask at the start of an SOC design intended for concurrent test").

The design team needs to keep in mind crosstalk and noise issues when determining which IP blocks to test concurrently. The interconnection between IP blocks must support IP blocks running concurrently at their native speeds without the test conditions' artificially creating crosstalk and noise. EDA tools such as Synopsys' (www.synopsys.com) PrimeTime-SI can help pinpoint such problems. If the embedded cores must interact at different frequencies in the system, concurrent test enables verification of signal integrity before assembly and system integration. This test-quality improvement is a substantial benefit of concurrent test.

Power delivery is an important concern during concurrent test. Simultaneous test modes can produce large current spikes. For example, scan tests tend to run circuits in nonstandard modes, and scan shifting causes maximum power dissipation for short periods. Such high power dissipation during production test can stress an IC enough to degrade its quality or life. When such possibilities exist, the test protocol must avoid damaging the device or creating false failure results.

Once you've answered the basic questions, the next task is to define the DFCCT technique and architecture and to determine the design methodology for implementing and verifying CCT logic that achieves sufficient IP isolation and test access. You must isolate the activity of each core being tested concurrently from the rest of the device. Sufficient isolation ensures true test independence among an SOC's IP blocks.

To ensure the isolation necessary for test independence, you may need to insert some type of test "wrapper" around the targeted IP core's boundary. Core-test wrappers provide and test-control logic enables three key design-for-test capabilities for embedded-core testing. Core-test access allows for reapplication of an embedded core's previously generated test set at the system-chip level. Interconnect- and UDL (user-defined-logic)-test access allows for testing of interconnect and UDL between cores. Core-test isolation ensures that you can test an embedded core in isolation; that is, without the core's disturbing or being disturbed by other cores or system logic (for example, UDL).

There are basically two types of wrappers for IP. Multiplexed wrappers support vector reuse and at-speed functional test, resulting in faster testing. Scan-register-based wrappers for both serial and parallel access reduce the number of chip I/O pins used for test and also facilitate CCT by eliminating the interdependence of cores during test. The die-area impact of adding wrappers on silicon is relatively minor, because wrappers' gate areas are negligible.

The IEEE is defining the P1500 standard to support an embedded-core design-for-test-wrapper architecture. The P1500 architecture supports test-data access, isolation, interconnect testing, and core-test control. For test-data access, P1500 defines serial- or parallel-access core-test capabilities, or both; UDL test via serial access; and optional isolation. For core-test control, the standard describes serial and parallel test control using a wrapper-instruction register that provides flexible test-access bandwidth. The P1500 standard also supports scan, BIST, and IDDQ test methods to facilitate test reuse of embedded cores, and promotes core-test interoperability with plug-and-play protocols.

P1500's architecture, which is similar to that of IEEE 1149.1 boundary scan, is a boundary-scan architecture supported by an instruction register, a bypass register, a test-interface port, and wrapper-boundary register cells that can perform Intest (internal-core-test) and Extest (external-core-test) operations (Figure 3).

Once the cores are wrapped, you must define and implement a TAM (test-access mechanism). The TAM is basically the test-data highway to the core wrappers. The width of the TAM is flexible: The greater the width, the shorter the test-application time, but the greater the routing impact and number of chip-I/O pins necessary for test. Because it requires fewer chip-I/O pins per core, a narrower TAM can facilitate concurrent testing. A scan-data bus is a good example of a TAM. Cores tested concurrently cannot share a TAM.

The SOC-test controller controls multiple test modes. Each test mode enables one of the design's logical configurations. Wrapper-operation modes include normal functional operation; internal test operations, such as scan and BIST; external test operations, such as interconnecting and core-shadow-logic testing; and safe mode, which puts the core into a "safe" state when scan vectors are being shifted onto the chip or other cores are under test.

The SOC-test controller should conform to the IEEE 1149.1 specification and should also support all SOC-test modes and test scheduling. Cores that target CCT should have both serial and CCT-test modes.

Simultaneously with the IEEE P1500 standards effort, the VSI (Virtual Socket Interface) Alliance has defined a specification for embedded-core testing of individual virtual components (cores) within an SOC. This standard is compatible with P1500. This VSI Alliance effort enables the definition of a standard and its use by IC designers before approval of the P1500 specification. For more information on each of these standards, visit http://grouper.ieee.org/groups/1500 and http://vsi.org/library/specs/summary.htm.

There are two primary methods for wrapper insertion. One offers an IP-core-centric approach, in which you insert wrappers at the IP level. This approach may result in better core timing. The other approach separately creates wrappers for the IP and inserts them at SOC integration. This approach provides more flexibility to customize the wrapper to the SOC. Plan ahead and insert DFCCT logic into the design as early as possible in the project to avoid the risk of the test-logic insertion becoming part of the design's critical path.

To ensure effective deployment of CCT on today's SOC designs, the EDA community must accept the challenge of creating approaches that support the design of CCT-compliant IP cores and design-for-test structures. Specifically, designers need tools that provide design-for-test analysis and CCT-test synthesis. These tools also should provide core-test-access and isolation methodologies and must support a full range of core-test approaches, including scan, BIST, IDDQ, path-delay, and boundary-scan.

Test standards, such as IEEE P1500, STIL (pronounced "style"—the IEEE 1450 Standard Test Interface Language) and CTL (the P1450.6 Core-Test Language STIL extension), will enable EDA vendors to develop tools that automate the insertion of core wrappers, TAMs, and test controllers that control all test operations and scheduling. EDA tools also need to support the optimization and verification of SOC DFCCT structures. CTL, as read by core-level to chip-level EDA tools for test-vector mapping and validation, will describe cores' and SOC devices' test models. In addition, EDA tools must have the flexibility to handle cores that lack design-for-test capabilities and to test all interconnects between cores and user logic.

Concurrent testing is a viable approach to significantly reducing the cost of SOC test. Concurrent test needs to be part of the design specification and manufacturing-test plan, ensuring the definition of a DFCCT architecture early in the design phase. Various design methods exist to support concurrent testing with minimum impact on the chip design. Standards such as IEEE P1500, which are evolving to support embedded-core testing, will lead to EDA tools that support core-based testing and concurrent test. ATE models vary substantially in their ability to support concurrent test. An effective concurrent-test-enabled ATE system can simultaneously test large memory modules, analog modules, and high-speed logic with different timing and test conditions. With concurrent test, small reductions in test time combine to produce large savings in the cost of test.

Author Information

Martin Funcell is the SOC solution manager for Synopsys' test-methodology consulting group (Mountain View, CA). He is responsible for defining, developing, and delivering SOC-test strategies and methodologies. He has been with Synopsys for five years, starting as a principal design consultant. He has more than 20 years of experience in semiconductor test as a test engineer, design-for-test engineer, test-engineering manager, and design-project manager.

Kathleen Ryan Miller is the concurrent-test program director at Agilent Technologies (Chandler, AZ). She has worked for Agilent (originally Hewlett-Packard Test and Measurement) since 1989. At HP and Agilent, she has held such positions as manufacturing-test engineer, product-design engineer, intellectual-property-team manager, district application manager, and business-development manager. She holds a BSEE from the University of Iowa (Iowa City, IA) and an MBA from Portland State University (Portland, OR).