February 16, 1998

Add Testability NOW to Core-based Chips, OR Pay Later

Jim Lipman, Technical Editor

Designing chips with reusable cores lets you put lots of logic on a piece of silicon but also creates difficult chip-test problems. Knowing what design-for-test techniques and EDA tools to implement these techniques are available helps you over your system-on-a-chip test hurdles.

Adding testability to a chip is always important. When you design ICs around reusable embedded cores that someone else often designed, understanding the testability features in these cores becomes even more difficult. You may also need to supplement core testability to reach acceptable fault coverage. If you design chips with multiple cores, perhaps from a variety of sources, the task of adding full-chip testability features is critical to a successful design.

Knowing how to add testability to a complex core-based IC depends on your understanding the types of testability schemes designed into the various intellectual-property (IP) blocks on the chip. In addition, you need to know what tools are available to enhance core design-for-test (DFT) and to integrate core-testability strategies. You also have to understand how to integrate testability design into functional chip design.

What's in a name?

Core-based chip design is not new; designers have been using this approach for about 15 years. In the early 1980s, ASIC chips used blocks called "megafunctions," or "megacells," surrounded by custom-designed logic, to implement complex functions. These cores were predefined and preverified blocks of logic designed for a specific process and, often, a specific application.

Yesterday's megacells have evolved into today's cores, often made reusable by being defined as a netlist or piece of HDL code. Designers often refer to cores as "IP." However, "IP" is such a broad term that you're better off using the term "core" for describing reusable pieces of logic or analog functions used on chips.

Chip cores can be soft, hard, or firm. A soft core comes in the form of synthesizable Verilog or VHDL code or as a netlist of library cells. If the core is available in HDL format, you must synthesize the core to the gate level and then optimize its layout on a chip. A soft core is portable, meaning that you can implement it in a variety of processes and design it using various cell libraries. The trade-off for this portability and flexibility is unpredictability. The performance and size of a physically implemented soft core varies with the cell library, the chip process, and your skill in implementing the core.

You target a hard core for a specific process. Hard cores come as either physical layouts or as netlists of library elements along with placement-and-routing information. Although neither portable nor flexible, hard cores have well-known performance parameters. Designers usually define timing-critical cores, such as µPs and DSP engines, as hard cores.

Developers optimize firm cores for performance and area within a fixed number of processes. Core vendors often achieve this flexibility by making the core parameterizable, meaning that the core has features that can vary depending on the target process. A firm core is less flexible than a soft core but has more predictable performance and size. For core testability, you should consider only soft and hard cores, because firm cores are not in widespread use and are hybrids of the other two core types.

A number of techniques are available for adding DFT to digital cores. Analog blocks require different DFT methods and are not included in this discussion (see box "Testing embedded analog cores"). The most common digital-core DFT technique is scan design. This testability scheme modifies your design's flip-flops and latches to allow serial read-in and readout of a core's logic states in a scan-test mode. You can control and observe the core's flip-flops and latches by making them into serial-shift registers during test. Scan test lets you use EDA tools to automatically generate high-fault-coverage test vectors for the scan circuitry.

Scan test for cores can be full or partial. Full scan covers all flip-flops and latches and, because of its high fault coverage, finds use in chips in which time to market is critical. In contrast, partial scan lets you test only a portion of a core. Designers often use partial scan for high-speed cores. Partial scan provides lower fault coverage but has less impact on core and chip performance.

High fault coverage of a complex core means a longer testing process because this coverage requires you to serially load and read the scanned block. In addition, the scan circuitry adds silicon area, making your chip more expensive, and increases on-chip signal-transition times. Because of scan test's performance impact, some companies still omit some critical high-speed paths for a core with full-scan DFT implementation.

A variation of scan testability involves the use of parallel-scan access instead of a serial-scan chain to shorten testing. Parallel-scan chains are more complex to implement, use more area, are more difficult to route, and usually require either adding or multiplexing the on-chip I/O pins. Speeding testing by concurrently running multiple scan chains also has these drawbacks.

Most user-defined logic and large unstructured logic blocks use scan techniques for DFT compliance. Keep in mind that not all logic blocks can use scan testing. Cores with asynchronous logic, multiple clocks, or gated clocks may need other DFT techniques, such as BIST, to obtain a desired level of testability. Variations of scan test that you can use depend on the type of logic block you want to make testable (see box "Scan test's many faces"). Structured blocks, such as memories and datapaths, usually use BIST for testability.

BIST methodology uses built-in test circuitry in the logic block you want to test. The test-generation and -response logic lets  the block test itself. However, the presence of additional logic for testability, such as scan-logic circuitry, also adds silicon area. You may want to add extra test points within the block you want tested to increase fault coverage. In general, BIST has higher area overhead than does scan. However, BIST is the preferred technique for testing large blocks of embedded, structured logic and on-chip memories, such as RAMs and ROMs.

A variation of scan-path DFT is boundary scan. With a boundary-scan architecture, each I/O pin on the device you want to test has an added register and, sometimes, a special latch. The added circuitry allows you to scan in test patterns to input pins and then scan out output-pin states. A small amount of control logic and four connections outside the device you're testing provide control of stimulus input and scanned-data output.

Although designers developed boundary scan to isolate and test ICs on pc boards, they often use boundary scan to test cores embedded on chips. With boundary scan, you can access and test blocks with multiple scan, BIST, and multiplexer-isolation DFT schemes (Figure 1). The multiplexer-isolation technique lets you isolate and access the core. Most designers of core-based chips and vendors of chip-DFT tools use the IEEE 1149.1 boundary-scan standard.

Cores come in many "flavors," requiring you to handle each one somewhat differently when considering testability. Some core vendors supply the core as a black box with little or no information on the internal core logic. In this case, the vendor should also supply a test-vector set with a guaranteed level of fault coverage, which you need to integrate into the overall chip-test strategy. Similarly, legacy cores, which are blocks designers developed for an earlier design and are reusing for a current chip, also should have a complete test-vector suite. New cores require you to develop a DFT strategy and test-vector suites if you plan to use a scan-test methodology for these blocks.

Soft cores complicate testing more than hard-core DFT does. Ensure that the person who developed the core used no RTL constructs that could create test problems when you add testability using a testbench. If you add your own test, that test scheme may depend on the library the synthesis tool uses to generate the gate-level core description and on the synthesis tool itself. Make sure that you verify testability and fault coverage on the synthesized block before stitching it into the chip.

Core and ASIC vendors use different DFT techniques for different types of core products. Some combine DFT with other test-related design, such as emulation. LSI Logic's (Milpitas, CA) Tiny RISC product family employs enhanced JTAG (EJTAG), which combines JTAG with some in-circuit-emulation (ICE) features, including software breakpoints, single-stepping of code, and DMA support. The price you pay for this additional chip-debugging capability is four to 20 extra pins on the chip, with the number depending on the level of ICE capability you want.

ARM (Cambridge, UK) also includes ICE capability for its RISC cores along with the Advanced Microcontroller Bus Architecture (AMBA) test methodology. AMBA uses a test bus on a chip to isolate the ARM and peripheral cores, allowing you to more easily test each core separately. This test bus has a pipelined Advanced System Bus to connect the processor core, on-chip memory, and other high-bandwidth peripheral cores, as well as a separate Advanced Peripheral Bus for lower performance cores (Figure 2). Using the Advanced Peripheral Bus reduces loading on the Advanced System Bus and minimizes the performance impact of the added test circuitry.

When you develop a complete test strategy for core-based chips, consider different factors. The first part of total chip testing concerns using predefined core-level DFT and test generation or defining these elements to make each core testable. This approach can combine the efforts of core providers and chip designers. The second part of the complete-test approach concerns chip-level DFT and testability that you have to do yourself. A good source of information on testing embedded cores is the Virtual Socket Interface (VSI) Alliance (see box "VSI's role in core-based chip testability"). Your responsibilities for implementing chip testability are:

• integrating your test to include blocks that have defined DFT strategies and test vectors,

• defining techniques to implement DFT schemes for new logic blocks,

• implementing component isolation during test to guarantee test of only one core at a time and to make sure that you don't drive other chip logic into an unsafe and potentially damaging state, and

• debugging DFT logic that you add to a chip.

Most multicore chips have different DFT structures for different cores. For example, memory blocks almost always use BIST, whereas µP blocks usually use scan. When defining logic to interface the chip's blocks, you may combine scan, BIST, and multiplexer-isolation techniques. When designing chip-level DFT, you need a way to integrate each block's DFT structures and to connect these structures to simulators and testers outside the chip, usually through an IEEE 1149.1 boundary-scan interface. You can manually integrate these structures, a tedious and time-consuming operation, or use some available EDA tools (Table 1).

EDA tools for core-based chip DFT can be memory-DFT (always BIST) tools, logic-block-DFT (usually BIST) tools, and tools to integrate multicore-DFT techniques. Most test-synthesis tools support 1149.1 boundary scan, and a few synthesize the boundary-scan chain and test-access-port (TAP) controller for you as well.

Memory-BIST tools vary among vendors, depending on the types of memories the vendors support, the types of memory-test algorithms you can implement, and whether multiple memory blocks on a chip can share a controller.

Tools for multiple-logic-block and memory-core test integration include Duet Technologies' VisibleCores and Mentor Graphics' CTIntegrator. VisibleCores integrates TAP and core testing using a test-bus architecture for test isolation and multiple-block access on a chip. VisibleCores contains one or more of the following: test-data buses, a test-control bus, test-collar cells (interface logic surrounding each core for test access and test isolation), multiple-input shift registers (MISRs), and a test controller. The tool automatically creates variable-width test buses to provide access to test-collar cells at core-I/O ports and then combines component-level test patterns for chip-level testing (Figure 3). VisibleCores is compatible with IEEE 1149.1 boundary scan and uses a JTAG TAP controller. CTIntegrator assembles existing multicore-DFT methodologies into a unified, top-level test environment. These methodologies include BIST, full and partial scan, and boundary scan. CTIntegrator also gives you access to hard and soft test cores with precomputed test vectors, and it reports chip-level test coverage.

EDA companies are not the only vendors concerned with products for multiple-technique DFT designs. Artisan Components (Sunnyvale, CA) has developed a Universal Test Interface (UTI) that it has built into its 0.25-µm-process memory compilers. The UTI supports many DFT options, including serial BIST, scan, serial-memory test, and multiplexer isolation. LogicVision implements UTI in its memBIST-IC tool, eliminating some of the synthesized-BIST circuitry that you would normally need.

Taking another approach to simplifying the embedded-memory-test problem, the Self-Testable Memory Core (STMC) products from Virage Logic (Milpitas, CA), combine a memory compiler with BIST circuitry and diagnostic capabilities. Because Virage optimizes the BIST logic for a memory block, fault coverage is greater than 99%. In addition, the STMC requires less silicon overhead to support a memory's DFT features than would memory core and BIST from different sources. However, some third-party BIST-synthesis products let you synthesize a single controller for multiple memory blocks on a chip. This feature makes it unclear at what point the STMC's area-saving feature disappears for chips with many memory blocks.

References

1. Ghosh, Indradeep, NK Jha, and S Dey, "A Low Overhead Design for Testability and Test Generation Technique for Core-Based Systems," 1997 International Test Conference Proceedings, Nov 3 to 5, 1997, pg 50.

2. Pouya, Bahram, and SA Touba, "Modifying User-Defined Logic for Test Access to Embedded Cores," 1997 International Test Conference Proceedings, Nov 3 to 5, 1997, pg 60.

3. Yervant, Zorian, "Test Requirements for Embedded Core-Based Systems and IEEE P1500," 1997 International Test Conference Proceedings, Nov 3 to 5, 1997, pg 191.

4. Hemmady, Shankar, T Anderson, and Y Zorian, "Verification and Testing of Embedded Cores," Design SuperCon97: On-Chip System Design Conference Proceedings, Jan 21 to 23, 1997, pg S122-1.

5. Bhatia, Sabdeep, T Gheewala, and P Varma, "A Unifying Methodology for Intellectual Property and Custom Logic Testing," 1996 International Test Conference Proceedings, Oct 20 to 25, 1996, pg 639.

Acknowledgments

Thanks to Chit Mallipeddi of Cadence (San Jose, CA) and Rudy Garcia of Schlumberger (San Jose, CA) for their helpful insight into core-test methodology and problem-solving.

| EDN Access | Feedback | Table of Contents |