Test and Design Reuse

A design approach based on reuse of intellectual property may be essential for efficient design creation and verification, but what is the impact for test? Teresa McLaurin, Design Center Consultant, ARM, and Rohit Kapur, Synopsys Scientist, explain the techniques necessary to get the best out of test in an SoC design methodology.

Design reuse is a natural consequence of the magnitude of the design effort involved in creating and verifying huge chips in deep submicron (DSM) technologies. This approach has become the basis for System-on-Chip (SoC) design, in which various intellectual property (IP) components are created and reused to produce even larger, more complex chips. This necessitates the emergence of advanced design flows and methods for handling IP protection, as well as hierarchy and SoC test.

As more IP is utilized in SoC designs, a key design issue is how the design can be tested efficiently while taking advantage of the hierarchy imposed by design reuse.

To enable SoC test, two technologies have been developed:

• Wrapper technology, in which a wrapper isolates the core from the embedded environment during test, such that the core can be tested independently from the logic in which it is embedded.
• Core Test Language (CTL) which communicates test information for the core and allows for the successful creation of a complete SoC test set.

As the industry matures in the use of these technologies, hierarchical SoC test flows have begun to emerge, and the benefits of having an SoC test methodology are being recognized.

Isolating IP for Test
SoCs will invariably incorporate IP from more than one company, and the benefit of testing the SoC hierarchically — offering the capability to isolate each section of a design for debug — is proving highly advantageous. By isolating the IP test, each test issue also becomes isolated to a specific block of the design.

Scan insertion completed on a flat — not per-core — basis, makes the SoC design difficult to debug. If a test failure occurs, there is no way to figure out which portion of the design is failing without deeper diagnostics – it is usually difficult to tell by the pattern name that failed.

Figure 1 illustrates how scan chains may be inserted in an SoC that is tested flat. The scan chains connect to multiple cores, or to a core plus its user-defined logic (UDL). The patterns created will test the entire design, but if a scan chain failure occurs, it is not obvious which block of logic caused that failure.

Figure 1: SoC Scan Inserted Flat

Figure 2 shows another way of inserting scan chains in an SoC to allow for isolation of test. In this example, there are separate scan chains for each core. These scan chains are connected to the top-level ports. This allows a pattern set to test a specific portion of the SoC. If that pattern set fails, it is obvious which block of the design caused the failure, making it easier to track yield issues during manufacturing test. This approach offers additional test time and cost reduction advantages, due to the use of the much shorter scan chains resulting in a requirement for fewer test vectors.

Figure 2: SoC Scan Inserted Hierarchically

Maintaining High Coverage
To maintain high coverage of a core in the hierarchically scan inserted SoC, a mechanism is needed to control logic going into the core and to observe logic coming out of the core. This mechanism is needed because most functional ports of a core are not accessible from the top level of the SoC. A wrapper boundary register (WBR) — as shown in Figure 3 — isolates a core by bounding that core with a chain of registers, allowing for testing of the internal logic of that core without access to the functional ports.

Figure 3 Core with Isolation Wrapper Boundary Register

A WBR comprises a register for each functional input and output. Flip-flops that are part of the function of the design at the input or output can be reused as a WBR cell. When no reusable flip-flop exists, a dedicated WBR cell must be placed on the functional input or output as shown in Figure 4 . The dedicated input WBR cell, rather than the input port, has the capability of driving the internal logic with the register during internal test (Intest) mode. If the input port were used instead of the WBR cell, it would generate an X in this scenario, as there is no access to logic external to the core during the Intest mode. This would cause a decrease in test coverage of the core. During Intest mode, a dedicated output WBR cell captures responses from the functional logic into the WBR cell. The WBR added to a core can also be used to test the user-defined logic surrounding a core.

Figure 4: Dedicated WBR Cell Examples

Test isolation can be leveraged to test each core with a different methodology — such as flip-flop or latch-based scan, or BIST. This allows the best test methodology to be applied to each core — and eliminates the requirement that the entire SoC have a matched test method. Test isolation also allows for each core to be tested at different frequencies, which is often a requirement in SoC design.

Test Effort: Divide and Conquer
When an SoC is created, it can be a massive effort to create the test patterns for screening the device, and this effort cannot be begun until very late in the design flow. With an SoC that is composed of wrapped cores, this effort can be divided in many ways. Each core’s test can be created whenever the core is completed, and much earlier in the SoC design cycle to absolutely minimize schedule impacts. Also, different resources (people, CPUs, tools) can be used at different times to allow for a more serial flow and a reduction of cost.

Once a pattern set is created for an isolated core, this pattern set can be reused every time the core is reused. If hierarchical isolation is not used, the test patterns must be created each time the core is instantiated.

If the environment allows, all of the cores can be tested in parallel. The number of pins, tester memory capacity and peak power are considerations that must be taken into account. If any of the environment will not allow for all of the cores and UDL to be tested in parallel, hierarchical testing allows for other options. One core at a time can be tested, two cores at a time can be tested, or any other combination of cores and UDL can be tested in parallel. The capability of hierarchical testing has the flexibility to test the SoC in a way that best fits the test environment. In the case of an SoC flat test, the choices are much more limited.

Another advantage of hierarchical test is that if there are unexpected problems during test, such as excess power dissipation or IR drop, it may be possible to circumvent them. An example of this is if three cores are being tested in parallel and the IR drop during the test is high enough to cause data inversion or insufficient frequency measurements, then the testing order can be changed to accommodate these issues.

Test isolation also provides the ability to use the cores as a guideline to divide the power domains. The current/voltage measurements can be taken for each design entity. The separation of the power information is extremely important in an SoC environment.

The benefits of an SoC test methodology are significant enough for designs to be processed in an SoC flow by partitioning the design hierarchically – even if the IP reuse doesn’t strictly demand it.

Teresa McLaurin is a consulting member of the technical staff at the ARM Design Center in Austin, TX. She manages and leads the DFT and Test teams and she creates DFT methodology for use across ARM. She is a member of the IEEE and the IEEE P1500 standard task force.

Dr. Rohit Kapur, Synopsys Scientist, guides the development of Synopsys design-for-test (DFT) solutions based on Core Test Language (CTL) and other open standards. He is chair of the Core Test Language, IEEE P1450.6, standard committee, and was named IEEE Fellow in January 2003 for his outstanding contributions to the field of IC test technology.

Dr. Kapur wrote a book on the industry's first standards-based system-on-chip (SoC) test modeling language. The book, titled CTL for Test Information of Digital ICs and published by Kluwer Academic Publishers, is a reference guide for the IEEE CTL standard.

Dr. Kapur received a bachelor's degree in engineering from Birla Institute of Technology in Mesra, India and his master's and doctorate degrees in computer engineering from the University of Texas at Austin. Dr. Kapur continues his research interests in testing of Very Large Scale Integration (VLSI) systems.

©2005 Synopsys, Inc. Synopsys and the Synopsys logo are registered trademarks of Synopsys, Inc. All other company and product names mentioned herein may be trademarks or registered trademarks of their respective owners and should be treated as such.