Testing System Chips: Methodologies and Experiences

Advances in semiconductor process and design technology require new strategies for testing complex system chips.

by Sujit Dey, Erik Jan Marinissen, and Yervant Zorian

Figure 1 - Contrasting integration flows
System-on-board integration incorporates previously manufactured and tested components. Integrating embedded blocks into system-on-a-chip design complicates validation.

The systems industry has embraced the paradigm shift from traditional chip and system-on-board designs to system-on-a-chip (SOC) designs with reusable cores due to the large potential for both enhancing design productivity as well as meeting aggressive system performance and cost constraints. However, the new design methodology entailing integration of embedded cores on silicon poses serious challenges to testing SOCs, since the manufacturing test requirements differ significantly from traditional system-on-board testing. The traditional approach manufactures and tests each of the components (chips) individually before board assembly and holds the system integrator primarily responsible for testing the board assembly (interconnects) (see Figure 1a). However, in a core-based SOC, the system integrator designs the system using predesigned cores from core providers and proprietary user-defined logic (UDL), none of which has been manufactured or tested (see Figure 1b). Manufacturing and test have to be performed for the entire SOC, in contrast to traditional systems on boards. The use of heterogeneous cores from multiple providers further compounds the complexity of testing SOCs and leads to wide variations in test strategies, test structures, and test requirements employed by the components of a single-system chip.

Test preparation for cores

Though the system integrator tests a given core as part of the overall SOC, the core provider must prepare the core's internal test--DFT structures and the corresponding test patterns--in advance of delivery with the core. Typically, the system integrator has very limited knowledge of the implementation of the adopted core and has to deal with it as a black box without information for developing the necessary tests. The core provider must determine the internal tests for the core, without knowledge of the eventual SOC environment, the target application, the test quality required for the final SOC, or the target process. While low fault coverage of the core may jeopardize the quality level of the SOC, high fault coverage may drive test costs to prohibitive levels with respect to test time, performance, area, or power. Furthermore, different processes have different defect densities and distributions. These problems make test preparation of the cores a real challenge.

The core-internal test developed by a core provider must be adequately described, ported, and ready for plug-and-play interoperability with the SOC test. Internal tests, which accompany a core and are interoperable, require descriptions in a commonly accepted standard format, such as the IEEE P1500 standard currently under development.

Accessibility to component inputs and outputs also differentiates between traditional approaches and test strategies for SOCs. In a system on a board, direct physical access to chip pins permits probing during manufacturing test. For cores deeply embedded in an SOC, however, more limited physical access to its terminals necessitates an electronic access mechanism as well as additional logic, such as a wrapper around the core and wiring of a test access mechanism to connect core peripheries to test sources and sinks.

Figure 2 - Conceptual test architecture
The three elements in an embedded-core test approach include source and sink, test access mechanisms, and a core test wrapper.

System-level test and architecture

The integration and coordination of the on-chip test and diagnostic capabilities present one of the major challenges in the SOC realization process. Far more complex than PCB assembly tests, an SOC test consists of a single composite test comprised of individual tests for each core, tests for user-defined modules, and the test of interconnect logic and wiring. Certain peripheral constraints--safe mode, low-power mode, and bypass mode--are often required, which necessitate access and isolation modes.

In addition to the test integration and interdependence issues, the SOC composite test requires adequate test scheduling to meet a number of chip-level requirements such as total test time, power dissipation, or area overhead. Test scheduling also makes intracore and intercore tests run in a certain order so as not to impact the initialization and final contents of individual cores. Using these constraints, a schedule for the composite SOC test can be developed. In addition, since SOCs employ deep-submicron (DSM) technologies, they fall prey to various adverse effects and manufacturing defects imposed by DSM.

The conceptual architecture for testing embedded core based systems consists of three structural elements. The test pattern source generates the test stimuli for the embedded core, and the test pattern sink compares the actual responses to the expected responses. The test access mechanism (TAM) provides on-chip transport of test patterns and test stimuli from a test pattern source to the core under test, as well as test responses from that core to a test pattern sink. The core test wrapper forms the interface between the embedded core and its environment. It connects the terminals of the embedded core to the rest of the IC and to the TAM. All three elements can be implemented in various ways such that a whole palette of possible approaches for testing embedded cores emerges (see Figure 2).

Test pattern source and sink

A test pattern source generates the test stimuli for an embedded core, while a test pattern sink compares the response(s) to the expected response(s). Test pattern source as well as sink can be implemented either off-chip by external automatic test equipment (ATE), on-chip by built-in self test (BIST or embedded ATE), or as a combination of both. Source and sink do not need to be of the same type. The types of circuitry in the core, type of predefined tests that come with the core, as well as quality and cost considerations determine the choice of a particular type of source or sink.

We distinguish between three main types of circuitry used in SOCs today: logic, memory, and analog. Simple cores consist of one type of circuitry only--complex cores consist of multiple simple cores, possibly of different circuitry type. These three types of circuitry exhibit different defect behavior and, therefore, their tests are quite different in nature and require different types of sources to generate the stimuli and sinks to compare responses. ATE systems as well as BIST schemes for logic, memory, and analog are also quite different. ATE vendors, as well as providers of BIST solutions, are now moving toward integrating their separate solutions for logic, memory, and analog into combined product offerings.

Figure 3 - Accessing the embedded core
The testing strategy of multiplexing for parallel access to each embedded core creates as many test modes on an SOC as there are cores.

The variety in types of core tests actually exceeds the three-circuitry types listed above. Tests are also categorized by the type of measurement they require (voltage or current), the method through which they are generated (functional or structural), the amount of core-internal adaptation they require (scan or test points), or other parameters.

A random logic core tested by an on-chip source has to contain DFT structures like scan and test points, but may not include a pattern generator or response compactor. The core user has the option to trade-off between dedicated pattern generators and response compactors per core, or a shared pattern generator and response compactor which serve multiple cores. The on-chip test resources are often described indirectly using the primitive polynomial, which characterizes the LFSR, which in turn generates pseudo-random test patterns to achieve the quoted fault coverage. Such cores, although prepared for an on-chip test pattern source, can also be served by an off-chip source.

Cores which come with functional tests or ATPG deterministic tests, in general, do not have regular test pattern sets. An on-chip source for irregular test patterns can be implemented as a large ROM, but may lead to prohibitive silicon area costs. While research continues to study whether the generation of irregular deterministic test patterns on-chip require acceptable area costs, typically off-chip sources are used for cores that require an irregular deterministic set of test patterns.

For one core, the same type of TAM serves both stimuli as well as response transportation; various combinations may co-exist.

Off-chip sources and sinks often require a large capital investment and suffer from two major problems. Increasing IC speeds require greater accuracy for resolution of timing signals at the IC pins. While tester accuracy has only improved at a rate of 12 percent per year, IC speeds have improved at 30 percent per year. This gap leads to reduced ability to properly identify bad chips and significant yield losses, as well as cost increases. Due to the demand for higher speeds, off-chip ATE cannot match the high frequencies needed to test the performance related defects of today's ICs. In addition to these test quality issues, the increased pin count and the mixing of diverse technologies in SOCs drives ATE costs to unacceptable levels. These problems are exacerbated by high-speeds, high-density, and mixed-technology SOCs, which render external ATE inaccurate and prohibitively expensive.

While the type of circuitry and pre-defined tests that come with a core determine which implementation options are feasible for test pattern source and sink, the actual choice is generally determined by quality and cost considerations. On-chip sources and sinks provide better accuracy and performance-related defect coverage, but also increase silicon area and reduce manufacturing yield. While it may be possible to generate any type of test patterns on-chip, only algorithmic patterns such as regular patterns for memory testing, functional patterns for analog core testing, or pseudo-random patterns for random logic testing can be generated on-chip without excessive overheads today. On-chip sources and sinks still need some form of off-chip ATE, and therefore do not eliminate ATE costs completely.

Test access mechanism

Implemented on-chip, the TAM handles on-chip test pattern transport, test stimuli transport from the test pattern source to the core under test, or test response transport from the core under test to the test pattern sink. Although for one core, the same type of TAM serves both stimuli as well as response transportation; various combinations may co-exist.

Designing a TAM requires a trade-off between transport capacity (bandwidth) of the mechanism and test application costs. The bandwidth is limited by the amount of silicon area expendable to implement the TAM, the bandwidth of source and sink, and the availability of chip I/Os for test with external source/sink. The test application time is a result of the test data volume of the individual cores and the bandwidth of the TAM. The cost associated with test application time depends on the type of source and sink. A wide range of external ATE exists with associated costs, which differs from the test application time costs of BIST.

When implementing a core TAM, we have several options; a TAM can either reuse existing functionality to transport test patterns or rely on dedicated test access hardware, either go through other cores on the chip or pass around these other cores, have an independent access mechanism per core or share an access mechanism with multiple cores, be a plain signal transport medium or contain certain intelligent test control functions. Several TAMs are described here.

Testing the scan chain and the interconnect wiring and logic between cores provides the benefit of reusing an existing test standard.

An approach based on transparency of cores requires that every core has a transparent mode in which it propagates test data from inputs to outputs without information loss. During the test of a particular core, test access is provided by transparent cores between the test pattern source and the inputs of the core under test, as well as transparent cores between the outputs of the core under test and the test pattern sink. Though significantly lowering the test area and delay overheads compared to other TAMs, the technique has the disadvantage of relatively large test application times. To eliminate such drawbacks, a new transparency-based test access approach has been developed which allows trade-off between test application times and area/delay overheads, through providing different versions of the cores having different area overheads and transparency latencies. A core-level method enables insertion of transparency in the core using the structural description of the core. A chip-level method provides the analysis of the topology of the SOC to select the core versions that meet the user's desired trade-off between area and test time objectives.

An obvious mechanism for making embedded cores testable from the chip I/Os configures the core under test directly with parallel access from the IC pins (see Figure 3). An approach commonly used for embedded memories, many block-based ASICs also utilize this test access strategy. Additional wires are connected to the core's terminals and multiplexed onto existing IC pins; the multiplexor control is coded as a dedicated test mode. In the case of multiple embedded cores, this leads to an equal number of test modes. The advantage of this approach is clear: if the embedded core can be tested as a stand-alone device, the translation of core-level tests into IC-level tests emerges as a simple straightforward process, simplifying silicon debug and diagnosis. The lack of scalability, however, proves to be a disadvantage of this technique. In a system with many cores, this approach leads to high area costs for connecting and multiplexing all core terminals to the IC pins.

Figure 4 - Test access mechanism for multiple cores
Testrail combines test bus and boundary scan test strategies by forming a TAM for parallel or sequential access to multiple cores.

An alternative TAM, recently proposed, also accesses the core under test directly from the IC pins, but provides the option to share one access mechanism with multiple cores. Such a shared access structure, or test bus, permits one or more test buses of varying width--multiple cores then connected to one tri-stateable test bus. All cores on the same bus are tri-stated except for the core under test. The system IC integrator identifies an optimal mix of test buses and number of cores per test bus, providing the trade-off between silicon area and test time. The main disadvantage of this approach comes from the fact that only one core can be connected at a time per test bus. This limits the option of testing multiple cores at the same time, which is sometimes desired or even required.

The boundary scan test (BST) approach developed for board-level interconnect testing and standardized as IEEE 1149.1--a serial scan chain is laid around the terminals of the core--can be reused for testing embedded cores. Testing the scan chain and the interconnect wiring and logic between cores provides the obvious benefit of reusing an existing test standard. Many ICs are equipped with BST augmented with multiple private instructions, which represent all kinds of test, debug, and emulation modes. If these ICs become cores in large system ICs, it seems logical to reuse the test infrastructure as provided by BST. The severely limited bandwidth (1 bit) provided by the BST approach, however, presents serious design drawback. While not a problem for smalltest pattern sets (the case for board-level interconnect testing for which BST was originally developed), for large scan-testable cores providing many scan test patterns via only one serial access wire results in prohibitive long test times.

Case Studies

To better illustrate the issues and solutions of system-chip testing described above, we report two case studies of testing industrial SOCs. The first case study reported by Mukherjee and his collegues at TECS'98 applied the Logicvision embedded test methodology in a core-based industrial SOC made by Fujitsu, which implements an MPEG2 architecture comprised of 29 simple memory cores, 7 complex embedded cores--Core 1 to Core 7--and user defined logic (UDL). One of these complex cores, the video decoder (Core 1) was treated as a nonmerged soft core. Core 2 represented a hard legacy core; no testability modifications were allowed. The remaining five complex cores, as mergeable soft cores, were merged prior to test synthesis with the UDL surrounding them (see figure below). The embedded test methodology implemented on this SOC is a hierarchical one and allows for the creation of self-contained test entities, which can be tested in a modular way at any hierarchical level of a nested SOC. For instance, Core 1 is a reusable core in other SOC designs; its test solution needs to be self-contained and reusable. Core 1 incorporates a memory BIST controller to test the 10 SRAMs embedded in this core, and a single logic BIST controller to test all the logic in Core 1. The core itself is isolated with a dedicated wrapper. This wrapper participates in the logic BIST test of Core 1 if run in an internal test mode and contributes to the UDL test if run in an external test mode. The two BIST controllers act as local sources and sinks for Core 1. The TAMs required to connect the memory BIST controller to the 10 SRAMs and the logic BIST controller to the logic are local TAMs, eliminating the need for high bandwidth chip-wide TAMs to deliver test data to Core 1. Core 2 is a hard legacy core and has no testability modifications, such as insertion of scan chains and test points for logic BIST. However, it had a functional test set from the core creator. The functional test set had to be applied from an off-chip source and sink. This necessitated a chip-wide TAM with high bandwidth to connect the I/Os of the chip to all the terminals of Core 2. In addition, it required a wrapper around the boundaries of Core 2 to switch between different modes: normal mode, internal functional test mode, and external logic BIST mode (where the wrapper of Core 2 is run in an external mode to take part in the logic BIST of the UDL). The rest of the chip is categorized to embedded memories and logic. The 19 embedded memories were divided into three groups and tested by three corresponding memory BIST controllers. While it was possible to use a single memory BIST controller instead of three, the TAM area to connect the single memory BIST controller to all 19 physically distributed memories was higher than the case of using three controllers and local TAMs. The logic in the five soft cores (dotted in figure) merges with the UDL logic to make one logic test block. This is covered by a single chip-wide logic BIST. The analysis of scan rules, the generation of test points, and the assembly of scan chains and test points can be done for the whole logic test block as one entity. The overall wrapper of the SOC is the IEEE 1149.1 boundary-scan chain and the control port to execute the test of the different sessions of this SOC is through the 1149.1 TAP. The second case study reported by Arendsen and Lousberg at TECS '98 applied a core-based test strategy to an industrial IC in Philips Semiconductors (see figure below). The IC in question, meant for graphical consumer applications, was manufactured in a 0.35 µm five metal layer CMOS technology with a total die area of 50 mm 2 . It contained a mix of nine hard, firm, and soft cores. One of the cores, a bus control unit, was considered too small to be treated as a stand-alone unit, and hence tested as part of the overall interconnect test. The other eight cores were tested as individual cores and packaged with the Philips-proprietary core test wrapper Testshell and connected to the Philips-proprietary TAM Testrail (see figure below). The design benefits included a clear separation of tasks between core provider and core user, easy integration with respect to testing, and strongly reduced ATPG run times due to the divide-and-conquer strategy. The additional silicon area costs attributed to Testshell and Testrail varied between 0.5 percent for the largest core and 22.1 percent for the smallest core. On average, 7.7 percent of the total chip area was devoted to test infrastructure--4.5 percent for the core-internal scan chains and an additional 3.2 percent for Testshell and Testrail, which enabled the core-based test approach. These additional area costs were considered acceptable in the view of the associated benefits. As the Philips concept of Testshell and Testrail is very similar to the current propoals of IEEE P1500, these area costs are indicative of the area costs expected for the P1500 standard.

A variation on the boundary scan test approach uses a partial boundary scan ring around the core. The ATPG techniques identify which set of stimuli can be justified from the UDL in front of the core; the corresponding core inputs are then excluded from the partial boundary scan ring. The same strategy allows for modification of the UDL to generate the required test patterns.

A TAM has also been developed which can execute the SOC test in a predetermined schedule. The test sequencing of all the cores embedded in a network of distributed modular controllers provides an integral part of the TAM. This network, or universal BIST scheduler, is either customized to execute a predetermined BIST schedule for manufacturing test or is programmed through the JTAG port to execute the test of individual cores during silicon debug and diagnosis.

The Testrail technique tries to combine the strengths of both the test bus and BST approach. A Testrail forms a TAM for one or more cores. As with test bus, the strategy allows for one or more Testrails of varying width per IC. This allows the core user to make trade-offs between test time and silicon area. And, like BST, multiple cores can be daisy-chained into one Testral with only one Testrail bypass per core. This allows the core user to test each core sequentially or test multiple cores in parallel and, therefore, make trade-offs between diagnostic resolution and test time (see Figure 4).

Core test wrapper

The core test wrapper forms the interface between the embedded core and its SOC environment. It connects the core terminals to both the rest of the IC as well as to the TAM. By definition, the core test wrapper is implemented on-chip.

The core test wrapper should have the following mandatory modes: a normal operation (non-test) mode of the core in which the core is connected to its system-IC environment and the wrapper is transparent; a core-internal test mode in which the TAM is connected to the core and the test stimuli can be applied at the core's inputs while responses are observed from the core's outputs; and a core-external test mode in which the TAM is connected to the interconnect wiring and logic and the test stimuli can be applied at the core's outputs with responses observed at an adjacent core's inputs.

A core test wrapper has some added responsibilities. Since the width of the TAM does not necessarily correspond to the number of core terminals, the core test wrapper performs the additional task of width adaptation through serial-to-parallel conversion at the core inputs and parallel-to-serial conversion at the core outputs. Also, the test wrapper has to guard against clock skew in intercore communication, which may result due to different cores having different clock propagation delays. Since clock skew might corrupt data transfer over a TAM, especially if multiple cores share this mechanism, the core test wrapper offers the best place to have provisions for clock skew prevention in the test access paths between the cores.

Conclusion

Advances in IC process technology allow the integration on a single IC a complete system which, until recently, could only be implemented with multiple ICs on a PCB. In order to reduce the enormous amount of knowledge and time needed to develop such system chips, designers are using predesigned embedded cores. Test represents a key challenge to the effective and efficient integration of embedded cores to produce SOCs.

The conceptual architecture for testing embedded cores consists of three elements. A test pattern source and sink can be implemented off-chip as well as on-chip. Both alternatives are currently in use and pose trade-offs in silicon area and test time. Alternative test access mechanisms include transparent paths through other cores, the system bus, boundary scan, a dedicated test bus, and Testrail. Finally a core test wrapper connects core terminals with other IC modules or the sink and source.

Real-life industrial case studies show that testing complex SOCs is feasible at acceptable costs, if the right methodologies and tools are in place.

Sujit Dey is an associate professor in the ECE department at the University of California at San Diego. He was previously a senior researcher at the NEC C&C Research Laboratories in Princeton, N.J. Dey's research focuses on developing design, validation, and test methodologies for core-based hardware-software system chips. He has co-authored over 70 publications and 10 U.S. patents.

Erik Jan Marinissen is a member of the scientific staff at Philips Research Laboratories in Eindhoven, The Netherlands. His research interests include all topics of test and debug of digital ICs. Marinissen is an active member of the IEEE P1500 Standard for Embedded Core Test (SECT) Working Group.

Yervant Zorian is the chief technology officer for Logicvision, Inc. of San Jose He has 20 years' experience in test technology and holds numerous patents in BIST. He is the founder and chair of the International Workshop on Testing Embedded Core-based System-Chips (TECS) and the IEEE P1500. Zorian was elected as a Fellow of the IEEE, is currently editor-in-chief of IEEE Design & Test of Computers , and has been chair of the IEEE Computer Society Test Technology Technical Council since 1997.

To voice an opinion on this or any other article in Integrated System Design, please e-mail your comments to jeff@isdmag.com.