Use a smarter DFT tool environment for better design customization
Ron Press- February 5, 2013As the name suggests, electronic design automation (EDA) companies strive to provide as much automation as possible to simplify the design process. However, many companies develop customized flows that require very specialized design modifications. EDA tools can’t natively handle all potential customizations, so some custom scripting in a common editing language such as perl or within a synthesis tool is often performed. Design for test (DFT) is no exception to this situation. Scripts are often written to identify logic that relates to DFT, inhibit DFT operation, understand a DFT operational mode, and/or perform design edits.
The custom scripting for DFT is problematic because the scripts become complicated and difficult to maintain, and because they attempt to perform DFT-related tasks without having key DFT knowledge about the design, such as clock gater locations, DFT DRC violations, and other DFT-related information. So, if you’re going to script, perhaps your DFT software provider can at least make it easier.
One practical approach to improving custom scripting is to switch from inefficient common scripting to a new integrated DFT platform with a built-in scripting environment. This one tool enables multiple DFT functions within one environment that would have existed in separate tools.
By definition, a platform is extensible and offers more integration among its parts than the current tool-plus-scripting setup. With a DFT platform, you can perform scan insertion, add scan compression logic, perform ATPG, and experiment with diagnosis without having to exit the DFT tool. All attributes related to DFT can be shared between these DFT functions.
A DFT platform should include editing and introspection features to access and utilize the DFT tool knowledge. Design introspection means accessing attributes assigned to instances, library cells, ports, and other design elements. Introspection allows tools to discover information about the design objects. A DFT platform not only has information about the design, but also has information that was learned while DFT tools were analyzing the design. With such a platform, a user can efficiently produce a script to automate any custom activity or process.
For example, consider the situation where a design needs to be edited to make sure clock gaters are enabled during scan shifting. You could write a script to locate clock gaters and add control logic based on scan_enable. However, it is more effective to first understand the DFT mode to determine if some gaters are already in a safe shift state after DFT initialization, or if the gater has an additional DFT DRC violation. Having information about DFT DRC violations and DFT data is very useful when making a custom script (Figure 1).
A few DFT attributes that are helpful when scripting include:
• Clock gater locations
• Power domains
• Location of DFT DRC violations
• Test mode static values
• IEEE P1687
• Logic utilized as various DFT functions
Lots of consideration was made on how to construct a scripting environment within a DFT platform that is more efficient than common scripting practices. For example, a user can simply issue a command to connect one net to another. The DFT scripting environment will figure out how to make the connection through various levels of the design hierarchy. Also, it is possible to get all cells below a instance XXX on power domain YYY with this statement:
• get_instances –below_instance XXX –filter “power_domain==YYY”
In other tools, you have to filter all cells by name to get those below instance XXX which is orders of magnitude slower:
• filter_collection [all_cells] “name~=XXX/* && power_domain==YYY”
Figure 1. This figure shows a display of an attribute of C3 DRC violation. A script could locate certain DRC violations, and perform edits selectively on those that also contain additional attributes.
I am not a fan of telling EDA users to “just write a script” when a tool doesn’t provide the desired feature. I always prefer adding native support of automation for functionality that many users need, but in some cases, customized scripts are required to meet the user’s specialized functionality. Providing a scripting environment with access to DFT tool knowledge about the design provides a powerful new solution to simplify the scripting effort.
Finally, a powerful integrated design editing platform can go much further than automation DFT customization. It can also enable the automation of the functional design activities that are less standardized as compared to DFT. As a result, many users have moved their efforts from inefficient common scripting environments to a new scripting environment within an integrated DFT platform.
An additional benefit of the DFT scripting environment is that it enables multiple DFT functions within one common environment. As a result, you can perform scan insertion, add scan compression logic, perform ATPG, experiment with diagnosis, and perform design edits without having to exit a tool. All the DFT attributes can be shared between these DFT functions. Furthermore, to further facilitate user-specific editing, custom attributes can be assigned to design objects within this environment.
About the Author
Ron Press is the technical marketing manager of the Silicon Test Solutions products at Mentor Graphics. The 25-year veteran of the test and DFT (dseign-for-test) industry has presented seminars on DFT and test throughout the world. He has published dozens of papers in the field of test, is a member of the International Test Conference (ITC) Steering Committee, and is a Golden Core member of the IEEE Computer Society, and a Senior Member of IEEE. Press has patents on reduced-pin-count testing and glitch-free clock switching.
- Product How To: DFT strategy for ARM processor-based designs
- Imec, Cadence develop 3-D memory-on-logic DFT tool
- Mentor Graphics announces partnership with NXP for DFT