by Jay Jahangiri, Product Manager for Mentor, a Siemens Business, Tessent product family
The increase in IC design size and complexity adds a number of new challenges to the design flow, including design-for-test (DFT). One of the most successful changes in design-for-test (DFT) flows in recent years has been the deployment of hierarchical DFT. For large SoCs in the automotive or AI markets, 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, adopting new design flows and methodologies presents problems of its own. Retrofitting an existing, flat DFT flow with increasingly common hierarchical DFT steps requires a lot of manual intervention, and this, in turn, often introduces errors and inefficiencies. But new tools and techniques are emerging to ease the adoption and implementation of hierarchical DFT flow. The goal is to establish end-to-end DFT automation that better connect the people, processes, and tools involved in the DFT work. The goal is to build a reliable and sustainable flow that is both flexible and highly customizable. This article will cover the basics of hierarchical DFT, the challenges of building resilient DFT flows, and the elements of an optimal path to DFT automation.
Divide-and-conquer with Hierarchical DFT
Companies that tried to continue with full, flat ATPG or partitioned-based approaches with manual steps suffered severe time-to-market delays. Breaking designs into smaller pieces makes physical implementation more manageable for designers as well as for automation tools. It also lets you take advantage of cores that have many identical instantiations, as seen in many AI designs. All the design effort goes into one instance, which can then be instantiated as many times as required. DFT also benefits from a similar divide-and-conquer approach that is consistent with the rest of the design flow and addresses the same problems with large designs.
Most projects today use some form of hierarchical design in which cores are concurrently designed by different teams or individuals, 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 designs group many smaller cores together for ATPG 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.
Hierarchical DFT requires a few key technologies such as core wrapping for core isolation, graybox model generation to reduce machine memory consumption, and pattern retargeting to reuse core level generated patterns. Figure 1 illustrates chip-level DFT in a hierarchical DFT methodology.
The move to hierarchical DFT has led to dramatic improvements in all aspects of DFT. Some of the largest chip makers, including Amazon (D. Trock, 2016) and Samsung (B. Shin, 2019), have published their results demonstrating how hierarchical DFT took DFT work out of the design critical path to tapeout, improved run time, pattern count, and compute resources.
Another upcoming trend in DFT is to migrate the work upstream into the RTL stage. An RTL-based DFT flow needs to be merged with front-end design flow so tasks can be managed in a repeatable, reliable manner that facilitates the downstream integration.
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. This approach adds significant time to the flow, introduce unnecessary iterations, complicates debug, and can introduce errors.
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
Hierarchical DFT benefits from having a fully automated DFT solution—including a set of DFT tools that work on a common platform—that can take general user directives across all parameters (test time, area consumption, power consumption, etc.), to make smart decisions that balance test costs, time, and coverage.
As DFT necessarily migrates further upstream into the RTL stage, it becomes increasingly important to merge with the front-end design flow, manage these tasks in a repeatable flow, and maintain design awareness to facilitate downstream integration.
The elements of an optimal end-to-end automation for DFT flows can be described 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 reduce DFT time and increases predictability. These are the capabilities to look for when planning DFT for your next project. An “intent-driven” environment reduces the complexity of many DFT steps and accelerates time-to-market. Users can work at a higher level of abstraction. The challenge of inserting DFT, creating patterns, and integrating the DFT functions at the top level are all managed in a unified, plug-and-play environment. Without such an integrated platform, companies struggle to manage DFT functions such as BIST and ATPG and would have many steps to integrate core-level DFT and patterns at the top level.
Intent-driven automation
What does intent-driven automation mean? That designers can describe the high-level test goals to the DFT 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 with intent-driven automation, 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 among DFT tools 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 with meaningful names and structure. A database setup is shown in Figure 2.
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
End-to-end DFT automation relies on IEEE 1687, a.k.a IJTAG, infrastructure for plug-n-play automation across all test instruments. The ability to universally use any vendor’s IJTAG-compliant 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. Figure 3 illustrates an IJTAG network with sub-networks for scan testale (STI) and scan resource (SRI) instruments. Advanced DFT automation can insert the IJTAG network, incrementally create ICL and PDL network description files, and performs hierarchical PDL retargeting.
A 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 more advanced automation scheme. The flow can be customized to suit individual users, groups, or company-wide requirements perfectly.
This flexibility in adoption is achieved by having multiple entry/exit points, and it welcomes custom and third-party tools. Using powerful introspection and Tcl scripting capabilities 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
Adopting end-to-end DFT automation is made easier with the help of a trusted tool supplier who can assess your current DFT goals and provide complete reference flows, documentation, and test cases along with the tools. As more of an end-to-end DFT automation scheme is deployed, the results include further reduction in DFT implementation time and cost and a more efficient, predictable, and sustainable DFT flow.
