An Optimal Path To DFT Automation

To keep up with time-to-market demands when SoCs keep increasing in size and complexity requires the adoption of better DFT flows and technologies. One of the most successful changes in design-for-test (DFT) flows in recent years has been the deployment of hierarchical DFT. Taking the divide-and-conquer approach delivers real savings in test time and cost, plus keeps DFT out of the critical path to tape-out.

However, it turns out that retrofitting legacy flows with hierarchical methods creates new inefficiencies. For example, tracking setup information and tool configuration for different cores and levels of hierarchy requires a lot of manual intervention, which is tedious and can introduce errors.

But now there is a production-proven solution to ease the adoption and implementation of hierarchical DFT flow. It helps by providing advanced, end-to-end automation that better connects the people, processes, and tools involved in the DFT work. The result is the creation of a reliable and sustainable flow that is both flexible and highly customizable.

Divide-and-conquer DFT
Most projects today use some form of hierarchical design in which cores are designed by different teams or individuals concurrently, then assembled and finished at the chip level. Hierarchical DFT uses the existing hierarchy of an SoC to insert all DFT and generate test patterns at the core level. The lowest level of hierarchy is the ‘core,’ which can be a single core or a group of cores. Some applications, such as AI chips, commonly group several smaller cores together for ATPG in order to share scan channels and minimize routing. Cores are isolated with core-level clocking and wrapper chains. All DFT insertion, verification, and pattern generation are performed at the core level. Patterns are retargeted to the chip level, where cores are represented by graybox models.

The challenges of adopting hierarchical DFT
Legacy, flat DFT flows have been successfully translated to hierarchical flows, but it requires a lot of manual work. Typically, the designer has to describe every step the DFT tools should take and repeatedly input the same information to each step. It makes sense to introduce more automation to the DFT flow. With the right level of automation, designers can describe their intent rather than detailed commands. With a universal test infrastructure, there would be a plug-and-play continuity across all the test instruments. With flexible and easy customization, the flow would be future-proofed against changes per design, designer, team, or company that occur.

Elements of end-to-end DFT automation
We think of the elements of an optimal end-to-end automation for DFT flows in terms of three main categories:

•  Intent-driven automation
• Universal test infrastructure
• Future-proof customization

These things together enable efficient concurrent design with easy hand-off between teams that reduces DFT time and increases predictability (Fig 1).

Fig. 1: Advanced end-to-end automation creates more reliable, predictable, and sustainable hierarchical DFT flows.

Intent-driven automation
What is intent-driven automation? It means that designers can describe the high-level test goals to the tool early in the flow rather than writing detailed, step-by-step scripts. For example, say you need to setup ATPG for different scan modes. The designer would have to write multiple scripts, keep track of the scripts and procedure files, and then load the correct setup files for each test mode. But now, all the scan configurations (internal, external, bypass mode, etc.) are inserted all at once and stored in a common database. Then, during ATPG, the tool only needs to know which scan mode to import and it takes care of the details.

A common database ends up being very important from a flow usability perspective. With this new automation, all the data and generated files are organized hierarchically in the database and called on throughout the flow as needed. For example, when you generate the database for a particular project in which you have inserted memory BIST, EDT, IJTAG, etc., the different components, instruments, patterns, and information needed for subsequent steps are stored in sub-directories (Fig 2).

Fig. 2: Common database structure.

The high-level DFT specification that captures the designer’s intent starts with a network to allow access and control of IJTAG-compliant on-chip resources. The specification guides memory BIST insertion (type, number, grouping, location) and scan insertion (number and type of EDT controllers, chains per controller, locations). It also manages clocking control, power, and custom DFT signals and verifies that all the setups have no errors. It even generates the SDC files needed for physical design signoff.

Universal test infrastructure
The automation scheme relies on IEEE 1687, IJTAG, infrastructure for plug-n-play automation across all test instruments (Fig 3). The advanced DFT automation also includes smart IJTAG network insertion , extracts and learns the addition and removal of IJTAG instruments, incrementally creates ICL and PDL network description files and performs hierarchical PDL retargeting. Using IJTAG compatible IP significantly eases core and IP integration and reuse. It also allows the core-level test patterns to be retargeted to the next level up and to broadcast the patterns to identical cores.

Fig. 3: Example IJTAG network implementation.

The universal test infrastructure also simplifies the initialization procedures for a TAP controller. The cycle-by-cycle procedure creation process can be very time-consuming and error-prone. But now, it can be accomplished at a higher level of abstraction that enables automatic procedure creation through simple-to-use commands and built-in procedures.

Future-proof customization
Adopting a complete hierarchical flow from scratch might not be practical, so design teams need to be able to seamlessly integrate existing custom design steps and requirements into this new automation scheme. The flow can be customized to perfectly suit individual users, groups, or company-wide requirements.
We refer to this as having multiple entry/exit points, and it welcomes custom and third-party tools. There are powerful introspection and Tcl scripting capabilities that can blend standard tool features and commands with user-defined commands and scripts.

Examples of future-proof customizations include:

• Create and automatically execute DRCs to check the status of enable pins on clock-gaters, check that memories are in bypass mode or enabled, check the slew rate of I/O pads, etc.
• Introspect design and tool data models.
• Add a new user-defined attribute to track and fully introspect custom settings.
• Change tool and user-defined attributes on any object type.

Getting started with this new advanced, end-to-end DFT automation starts with a flow assessment to review your current DFT goals, methodology, and flow. Complete reference flows, documentation, and test cases are also available to speed up adoption. No matter how much of the new automation is deployed, the results include a reduction in DFT implementation time and cost and a more efficient, predictable, and sustainable DFT flow.

For more information, download the whitepaper Keep DFT Out of the Critical Path with Optimal End-to-End Automation.