| To succeed in the competitive electronics marketplace, semiconductor companies need silicon that is ready on schedule and with sufficient quality for the target application. Typical devices are designed in hierarchical or system-on-chip (SoC) flows, which can include tens of millions of logic gates, hundreds of memory blocks, high-speed I/O, and mixed-signal blocks. |
Creating a full-chip test for these devices currently requires the use of several suboptimal point tools at the design flow back-end, with no full-chip test automation or optimization methodology yet available.
As a result, test is increasingly responsible for tapeout delays, unnecessarily high manufacturing costs, and poor product quality. This article will discuss the shortcomings of today's test flows and propose a unified methodology for specifying, implementing, and verifying full-chip test.
The problem with today's front-end test flow
Today's designs can contain a number of cores, hundreds of memories, and several levels of logic hierarchy. Table 1 represents a typical design that currently supports the wired and wireless communications industry.
Note that the complexity includes external intellectual property (IP); almost half of the chip is memory, and it has multiple clock domains and multiple levels of hierarchy, many of which are designed by large, distributed design teams.
Table 1 — Typical SoC design circa 2004
Complex devices are typically designed with hierarchical methods, while test remains a flat, back-end implementation step. This approach leads to suboptimal test architecture, puts test architecture development on the critical path, and creates physical implementation problems (such as changes in placement, routing, amd timing optimization to accommodate test structures).
It also requires design teams to expend significant, additional effort on test if there are any significant design changes in logic, memories, or cores. Finally, with this method, test cannot be leveraged for yield ramp or in system bring-up.
The problem is further complicated by the fact that in order to create the necessary full-chip test today, test teams separately specify, implement, and verify each structural element — typically with different tools — and manually create the test infrastructure that ties everything together.
Figure 1 shows an example of how a hierarchical design flow is impacted by a back-end test bottleneck. Logic blocks are designed separately, and then brought together at the full-chip level. Memory and IP blocks are also integrated. There is no top-down test planning, and no test activity at the individual block level, except scan insertion with tied back terminals.
Figure 1 — Test in the critical path of timing closure
At final chip integration, there is a massive test step to handle all of the required full-chip test needs. Designers need to use separate point tools serially to insert different test structures such as boundary scan, memory built-in self-test (BIST), and compression. Synthesis tools are then used to stitch these structures together.
This is followed by a final verification step. Problems detected at the final test verification step will cause a re-spin of the test activity.
This massive test insertion activity needs to be completed before timing closure can begin. Once in timing closure, changes to the design hierarchy or placement can cause additional re-spins of the test step. This tedious, time-consuming, and error-prone process is increasingly responsible for tapeout delays, possible silicon re-spins, unnecessarily high cost-of-test, and poor product quality.
The solution: A unified full-chip test methodology
Testing complex chips requires a unified methodology for specifying, implementing, and verifying full-chip test. The result is faster development of a higher-quality test infrastructure than is currently possible with point test tools.
Full-chip test is a design's complete hierarchical test infrastructure. It includes all of the design's test structures (such as scan, compression, memory BIST, on-product clock generation, and IP core wrappers) and the complete infrastructure for connecting these to the design I/O (such as hierarchical interconnect, boundary scan/tap controller, and test I/O).
Figure 2 shows an example of the full-chip test infrastructure. A way to visualize full-chip test infrastructure is to take a completed design and pull out the test controller (TAP). All the connections and blocks that it pulls with it comprise the full test-chip infrastructure.
Figure 2 — Test structures in full-chip test
A unified methodology for full-chip test provides a single environment for specifying, implementing, and verifying the full-chip test infrastructure. This multilevel, heterogeneous test infrastructure is able to support both top-down and bottom-up design methodologies.
Implementation of full-chip test requires creation, insertion and interconnection of test structures for a given design. Ideally the underlying technology for implementation is based on test structure compilation.
This enables design teams to specify the test structures by a few parameters, the structures are created on-the-fly for a particular design, and to rely on an underlying synthesis technology to insert and connect test structures across the hierarchy. Figure 3 shows the flow that would result from a unified methodology for full-chip test.
Figure 3 — Full-chip test methodology flow
The test specification step assigns and communicates test implementation and verification requirements for full-chip test. The foremost consideration of the specification step is to remove test from the critical path of time-to-tapeout.
Accordingly, any implementation that modifies the design netlist needs to take place early in the design flow and in concert with the hierarchical attributes of the design. At the top level of the hierarchy, the specification includes I/O test, boundary scan, top-level compression, and scan muxing. At the block level, the specification data communicates the test strategy for each block to the distributed design team.
The test implementation step modifies the netlist for test per the test specification, including test-structure insertion and interconnection. As shown in Figure 3, the unified methodology calls for parallel implementation of top-level test structures and block-level test structures, synchronized with the hierarchical nature of the design flow.
Top-level test-structure implementation includes insertion and verification of standard test control (such as IEEE 1149.1 boundary scan controller), compression logic, I/O test, on-product clock generation, and support for additional custom functions or variations on these standard structures. At the block level, test implementation and verification includes all test activity that is contained in the block.
Examples include scan insertion, memory BIST macro insertion and local connection, and IP-core wrapping. Once top-level and block-level insertion and verification are completed, the remaining task is to interconnect the top level to the block-level test structures during the chip-integration step.
Implementation must be able to handle design changes with minimum time impact. An example of this requirement is the sharing and stitching of memory BIST engines. This is a complex problem that is in series with the timing closure step. It needs to be optimized to take as little time as possible and to accept design changes incrementally without having to start from scratch. Other implementation issues include the impact test has on area, timing, and power.
The test verification step validates the full-chip test infrastructure functionality, the testability of the design, and that the test infrastructure itself is testable. Test verification and analysis must ensure several key attributes for a full-chip test methodology, including:
In general, test design-rule compliance, or the lack thereof, is a choice that affects the automatic test pattern generation (ATPG) process to varying degrees. Violation of rules can prevent the generation of patterns or generate patterns that will never work, or it may cause the ATPG to generate bad patterns that give a zero yield on the tester, reduce test coverage, or increases data volume. The result is weeks of debugging on the time-to-market critical path, increased cost of test and rework, and reduced quality.
- All logic inserted for test is correct
- Design rules are followed
- The required testability for the given quality goals exists
- The test logic itself can be tested
- The test logic conforms to automatic test equipment (ATE) requirements
Unified methodology benefits
Designers of complex systems-on-chip will benefit from a unified full-chip test methodology because it will enable them to address test issues earlier into the design cycle, support hierarchical design flows, insert and verify top-level test structures, insert and verify block-level test structures, and connect all test structures automatically, both locally and globally. As a result, designers will experience increased productivity, shorter time-to-tapeout, reduced cost-of-test, and improved end-product quality.
Scan-based tests and back-end test methods are no longer sufficient to achieve the time-to-tapeout, product quality, and cost-of-test requirements of today's complex devices. This article has described a unified methodology for specifying, implementing, and verifying full-chip test, including scan, compression, memory BIST, on-product clock generation, boundary scan, and I/O test. The result is faster development of a higher-quality test infrastructure than is possible with point test tools alone.
Mick Tegethoff is product director of design for test marketing at Cadence Design Systems. He has over 20 years of experience in design, manufacturing and test of semiconductors and electronic products. Prior to Cadence, Tegethoff held various technical and marketing positions in the electronics industry, including 10 years at Hewlett Packard.