Blog
Comment
sharps_eng
All good design methodologies have a 'Test early, and test often' mantra. The ...
Viewpoint: An Evolution in Design for Test
Brian Bailey
2/16/2012 12:43 PM EST
Sandeep Bhatia Senior R&D Director Oasys Design Systems
Designers relate to Design for Test (DFT) in much the way that small children relate to scary programs on TV: if they cover their eyes with their hands, perhaps it will go away. But every designer also knows that the design that they are so lovingly bringing into existence won’t see the light of day without addressing the test problem. After all, every single chip needs to be tested.
These days, there is a growing realization that DFT is evolving and, in particular, is not something that can be left to the end of the design cycle when some resident test expert lays his or her hands on the design and pronounces it good. We have all heard far too many stories of the last-minute chaos, and the inevitable schedule slips, that come from leaving test as an after thought. DFT in a modern design requires a systematic approach to planning early on.
As I was writing this viewpoint, I was struck by how DFT has evolved over the years. It started, like most areas of EDA, with verification. In this case, fault-coverage with fault simulation. How vectors were generated was not really addressed.
Next came a set of methodologies to support scan-test and automatic test pattern generation (ATPG), and then built-in self-test (BIST) initially for memories and then for generating patterns for scanning logic too, often called Scan-BIST.
All of these technologies sat outside the design flow and could not make full use of a synthesis tool’s capabilities, which meant designers had to move scan-path implementation in and out of synthesis to run them through BIST, scan and ATPG. It made for plenty of iterations and unfinished business, but worked fine when chips were small and had single clock domains, single voltage domains, low clocks speeds and reasonable power budgets. And, schedules had enough time to allow a reasonable amount of manual fix-up.
That cobbled-together approach made way for test capabilities within synthesis tools to hide the full complexity of the situation from designers. While merging test and synthesis was a great move and a push forward, for capacity reasons, many synthesis tools are block-based. That creates an additional level of unneeded complexity. Designers are forced to partition the design and then stitch the blocks back together while, in the case of test, making good decisions about how exactly to divide up and link up the segments of the scan chains.
The electronic design automation (EDA) community has moved the technology forward again with two recent breakthroughs that help to further integrate DFT into the design flow. The first is early analysis of DFT issues, changing the approach from bottom-up –– or last minute when changes are harder to make and more expensive –– to a top-down methodology that is more flexible and give designers more visibility. Moving DFT analysis and insertion early in the design flow helps the project team meet DFT/test goals and, by identifying problems early, gives them time to work around or fix issues before the design becomes much harder to change once synthesis is “almost” finished. This is more critical than ever in a design with multiple-voltage domains and multiple-clock domains — today, the rule rather than the exception. Many test issues crop up on boundaries of such domains and it is a rare chip that has the luxury of keeping each scan chain so it doesn’t need to cross any such boundaries.
Test is now moving up in the design flow with the help of new, full-chip synthesis tools that include DFT capabilities. It’s a natural progression and one to be welcomed by designers everywhere. Test is inherently a chip-level problem — eventually, designers test each chip and deem it good or bad. Combine test and synthesis at the chip level and the problem is easier to manager.
Chip Synthesis offers high capacity and fast turnaround, and can handle 100,000 flops per minute for analysis and half that rate for insertion. One 10-million instance design with one-million flops can be processed for scan insertion in close to 10 minutes for analysis and 20 minutes for scan insertion.
In order to implement DFT at the chip level, a designer would need to check the register transfer level (RTL) code before synthesis. Some RTL constructs lead to gate-level structures inherently untestable with a standard DFT methodology and the earlier these are expunged from the RTL the better.
DFT has evolved from being mostly an afterthought into a strategic component of the design flow. With today’s large and complex SoC designs with multiple clocks and multiple voltage domains, it has to be. Moving it up the design flow allows project teams to treat test insertion as a strategic problem and a more suitable DFT architecture can be chosen. The full-chip view enables full-chip analysis and optimizes the overall architecture leading to shorter test times, smaller die and fewer problems.
About Sandeep Bhatia
Sandeep Bhatia is Senior R&D Director at Oasys Design Systems, where he leads Design-for-Test (DFT) and Low-Power Synthesis. He received his Ph.D. degree in Electrical Engineering from Princeton University, and a Master of Science degree in Computer Engineering from the University of Rochester. Before joining Oasys, he was a product director for DFT product at Atrenta, and senior architect for DFT Synthesis at Cadence Design Systems. Bhatia has authored several papers published in the IEEE Transactions and Conference Proceedings, and has served on technical committees for various conferences and workshops. The author can be contacted at sbhatia@oasys-ds.com
If you found this article to be of interest, visit EDA Designline where you will find the latest and greatest design, technology, product, and news articles with regard to all aspects of Electronic Design Automation (EDA).
Also, you can obtain a highlights update delivered directly to your inbox by signing up for the EDA Designline weekly newsletter – just Click Here to request this newsletter using the Manage Newsletters tab (if you aren't already a member you'll be asked to register, but it's free and painless so don't let that stop you [grin]).
Navigate to related information



sharps_eng
2/20/2012 5:34 PM EST
All good design methodologies have a 'Test early, and test often' mantra. The problem has been integrating whatever testing has gone before with downstream formal testing.
Maybe Oasis tools will help in that direction, but if new testing tools are unwieldy or too formal, (ie not engineer-friendly), then we can lose the '..test OFTEN' element in the above policy.
Sign in to Reply