'Wrap' your cores to enable SoC test (ARM & Synopsys)

To enable SoC test, two technologies emerged:

• 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.

SoCs can incorporate IP from one or more companies, 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 rather than per-core basis makes the SoC design difficult to debug. If a test failure occurs, there is no way to figure out what portion of the design is failing without deeper diagnostics (it is usually difficult to tell by the pattern name).

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 fewer test vectors.

Figure 2 — SoC scan inserted hierarchically

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.

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. Number of pins, tester memory and power are considerations that must be taken into account for this decision.

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 environment. In the case of an SoC flat test, the choices are much more limited.

Another advantage of testing hierarchically is that if there are unexpected problems during test, such as excess power dissipation or IR drop, they may be able to be circumvented. 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.

Conclusions

A number of benefits of SoC test methodologies have been identified. These benefits are significant enough for designs to be processed in an SoC flow by partitioning the design hierarchically without the traditional IP reuse aspects of SoCs.

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.

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.