datasheets.com EBN.com EDN.com EETimes.com Embedded.com PlanetAnalog.com TechOnline.com   UBM Tech
UBM Tech

Boost DFT efficiency for large SoCs

-April 23, 2013

One significant design challenge for today’s SoCs is managing the impact of the very large design size on EDA tools and flows. Front-end and back-end design flows have managed this challenge by breaking up the design along hierarchical boundaries. The resulting physical cores are then assembled together at the SoC level. This core-based approach to design not only allows EDA tools to run more efficiently but enables multiple design blocks to be completed in parallel, thereby improving overall throughput.

The same principles and resulting benefits can be applied towards the design-for-test DFT effort as well. With some basic design infrastructure in place, each core can be “DFT-complete” before SoC-level integration. Upon integration, the internal logic of each core can be tested one core at a time or in groups when configured in their Internal test mode. A separate External test mode configuration would target all the logic outside of the cores. By breaking up the test of the SoC into one or more Internal configurations and an external configuration, pattern generation effort is greatly reduced in both runtime as well as memory footprint of the DFT tool.

To use a hierarchical DFT methodology, you need to add one or more wrapper chains(s) for the cores. Similar in concept to an 1149.1 boundary scan chain, the wrapper chains define the boundary between internal and external test modes (the equivalent of INTEST and EXTEST in boundary scan). When configured in Internal mode, the wrapper chains isolate the core from outside activity while providing controllability on the core inputs and observation on the core outputs. Conversely, when configured in external mode, the wrapper chains will observe on the core inputs and control from the outputs so that logic outside the core can be tested.

The wrapper chains can consist of two different types of wrapper cells: shared and dedicated. A shared wrapper cell is actually an existing functional flop in the design that also shares duty as a wrapper cell. No additional logic is required. You only need to identify the correct functional flop as the shared wrapper cell and stitch it into the wrapper chains. A dedicated cell is a new cell that is added to the design. In its simplest form, it can be just a mux and a flop. But it can also be more complex.
(Dedicated cells will add area to the design as well as introduce some delay to the functional path.)

Wrapper chains also make it possible to generate a lightweight version of the core netlist, which is sometimes referred to as a scan shell, interface logic model, or graybox. It includes just the wrapper chains and the logic between the wrapper chains and the core’s I/Os. It is the only portion of the core netlist needed for external test mode. By eliminating most of the logic in the cores (i.e. the logic inside the wrapper chains) the SoC-level netlist used for external mode has a dramatically smaller memory footprint than the full-chip netlist.   

Figure 1 illustrates some hierarchical test configurations. Figure 1a shows a traditional DFT methodology in which the entire chip is tested at once. With hierarchical DFT, you could break up this SoC into two internal mode configurations and an external mode. The first internal mode configuration (figure 1b) tests just the two “Core 1” instances while the “Core 2” instance is tested in second Internal mode configuration (Figure 1c). Figure 1d shows how the top-level logic is tested in external mode, with just grayboxes used for the cores. In each of the modes (1b, 1c and 1d), the full netlist is never required.


Figure 1. Several views of an SoC with an hierarchical DFT implementation

To perform pattern generation for internal test modes, load the top-level netlist along with just the targeted cores for that configuration into your ATPG tool. The non-targeted cores can be blackboxed, thereby reducing the size of the netlist. Patterns are then generated with respect to the SoC-level pins. Compared to a traditional methodology, this approach has a much smaller memory footprint and ATPG runtime is significantly shorter.

The advantages of the hierarchical approach are even greater when your ATPG tool is capable of pattern retargeting.  Pattern retargeting refers to the ability to generate patterns at the core level and retarget those patterns to the SoC-level pins. This means only a single core netlist need be loaded, further reducing memory footprint. One pattern set can also be retargeted to multiple instances of an identical core at the SoC level with the exact same pattern count. A robust retargeting capability will also retarget multiple patterns sets of non-identical cores and merge them together for simultaneous application. This results in a very compact, efficient pattern set at the SoC level.

With some basic hierarchical DFT infrastructure and capabilities (wrapper chains, graybox netlist, and pattern retargeting), the same advantages that front-end and back-end design practices enjoy can be realized for DFT as well. The results vary with each design, but a large SoC that may require over a 100GB memory footprint with a traditional approach could be reduced to less than a tenth of that with the hierarchical approach. ATPG runtimes that might be measured in days or weeks can easily be reduced to hours.

Related Articles
Product How To: DFT strategy for AMR processor based designs
Embedded memory test and repair optimizes SoC yields

If you liked this feature, and would like to see a weekly collection of related features delivered directly to your inbox, sign up for Test&Measurement World (www.tmworld.com) newsletters here.

Loading comments...

Write a Comment

To comment please Log In

FEATURED RESOURCES