| |
 | |  |  | | | | Pay Now or Pay Later: Design for Test (DFT) in the Verification Process
Stylianos Diamantidis
Managing Director, Globetech Solutions | |
| |  | |  |
Q. Design for Test (D F T) as a concept has been around for a long time, what has changed recently to make this more important?
A. Changes in the design and manufacturing processes require us to focus more on DFT today than in the past. Historically, test first relied on functional vectors, usually extracted or generated from the verification environment. As chip sizes and features sets began to grow, structural testing, which associates manufacturing defects of devices with one or more fault models, hence, greatly reducing the problem space, began replacing functional testing. DFT mechanisms, such as scan, appeared in the mainstream as a means to apply structural vector sets, generated by EDA tools using a variety of algorithms. Currently, structural vector generation and analysis algorithms are being packed into more complex DFT elements, such as Built-In-Self-Test (BIST).
Today, we are at a crossroads regarding test. Against all odds, Moore's law continues to drive modern SoCs, pushing the number of gate-counts into the tens of millions at nanometer scales. The structural testing methodology that carried the industry through the last two decades is beginning to break. Large SoCs simply cannot be tested cost-effectively using traditional ATEs, the main issues being delivery of test stimuli at extremely high frequencies, controllability/observability of deeply embedded structures and the storage issues resulting from exploding vector set sizes. Compression is adding some temporary relief but it is becoming clear that a paradigm shift for test will become an absolute necessity.
To handle this growing area of concern, SoC designers are adding an ever-increasing set of DFT features into their design. They are trading functionality for testability and partitioning more test resources away from the external tester and into the silicon itself. This trend is driven by the hard economics of exploding costs and shrinking time-to-market windows. SoCs that do not present a solid, uniform, embedded test scheme will simply not be manufacturable. Of course this places enormous pressure on design and test engineers to ensure that not only a complete scheme is available, but that it is fully functional and reliable. DFT is already in the critical path and will become much more so in years to come.
Q. What are the dangers for a design project when DFT is ignored and test concerns are addressed as an after-thought?
A. The dangers are many, ranging from increased costs to completely missing time-to-market windows. In the best case scenario, lack of test resource planning and unreliable or partially working DFT will result in more time in the lab debugging first silicon, less ability to characterize a prototype and transition to volume production, increased test time due to non optimal DFT resource utilization and larger vector sets requiring more expensive test equipment. The result can be a complete break-away from test strategy which exposes the project to a large and unnecessary element of risk.
The consequences of not adhering to test strategy enormously impact manufacturing costs and time-to-market. In today's terms, silicon debug can account for up to 30% of total project time, while test typically accounts for 30-50% of total manufacturing costs. At nanometer scales, the ITRS projects that over the next five years testing a transistor will become more expensive than actually manufacturing it. Simply put, DFT, if addressed as an afterthought, is a major risk to manufacturability. On the other hand, if the design process embraces DFT, the result will be a more disciplined cost structure and development time, resulting in a significant competitive edge.
Q. What types of designs or design teams need to implement DFT the most, and why?
A. I don't think that any one type of design is more applicable to DFT than any other. DFT is pervasive and must be consistently supported by all design teams. The issue facing designs and design teams is more about how they are going to enable DFT and break down the barriers resulting from test engineers operating in a separate silo from the rest of the design team.
Of course, this is not as simple as it may sound. Proper tools and methodologies need to be adopted which will enable the test engineers to collaborate and leverage from the design team's methodology flow from the very beginning of project development. Verification can play a key role here; capturing test intent early in a verification plan can be an excellent framework in which design and test engineers can enable DFT.
Another challenge for design teams stems from the heterogeneous nature of DFT. Indeed this heterogeneity, inherent in the SoC design model, means that most of DFT is supplied by silicon IP vendors. Building coherent system-level test resource schemes based on components that are put together with different test specs, tool flows and quality requirements, is not a trivial task and should not be treated as such.
Finally, all design teams can benefit from better EDA tools for DFT. Today, almost half of all semiconductor companies implement in-house DFT and test tools, a figure two to three times higher than for other areas of design. Before any of these issues can be adequately addressed, EDA solutions need to be developed for specifying, inserting, integrating and, most importantly, verifying DFT. Productivity gains can be realized across various aspects of the SoC ecosystem.
Q. Do you believe there is an increase in accountability for designers to produce not just working products, but manufacturable products? What has fueled this shift?
A. Absolutely. At the end of the day, manufacturability is the ultimate objective. However, design methodology beginning in the 1980s drew a clear line between design and manufacturing with the introduction of EDA. Design engineers were able to leverage EDA tools to follow their design through to closure; manufacturing and silicon test were the responsibility of a completely different team of people, with different skills, tools and expertise. This, in turn, allowed for better productivity and focus as well as for the creation of a wealth of fabless semiconductor companies and numerous foundries. The paradigm worked quite well but resulted in a clear technical and cultural segregation of the pre- and post-silicon worlds.
Today we are experiencing a shift in this paradigm. Design teams are finding themselves having to work much more closely with the fab and post-silicon worlds than in the past. The main reason is that starting at 90nm, there no longer exists a reliable and automated highway to getting from design models to working silicon with good yield and cost effectiveness. The seamless transition is being replaced by an iterative cycle where manufacturing and test issues need to be taken into consideration at design time. That is why today we are talking about Design-for-Yield, -Manufacturing and -Silicon. There is definitely a clear requirement for manufacturing and test aware design.
This is particularly the case for DFT. Design engineers in the 1990s and early 2000s did not worry about test. But now, design teams are (once again) in charge of not only verifying but also testing their designs. They are directly responsible for the test strategy and resources that will need to work seamlessly with fab test equipment to ensure an optimal result. What's the point of designing DFT that is not accessible or operable by the manufacturer? Conversely, what's the use of spending 20% of useful gates on DFT if it's not going to work?
Q. What types of metrics are the most important when tracking DFT verification?
A. DFT verification is a requirement for modern, complex, DFT structures. Several aspects need to be taken into account when choosing the right metrics. Overall, they can be grouped into completeness, compliance and functionality.
Completeness – One of the trickiest aspects of ensuring a reliable DFT infrastructure is completeness. This is where investing time upfront in proper planning can result in huge gains down the road. Verification engineers need to understand their DFT strategy and specification in order to translate them into executable plans. These plans will not only provide a base metric for completeness, but will also help designers and managers isolate areas of exposure. Once problematic areas are identified, managers can allocate resources and time more effectively. Executable verification plans will also provide a roadmap forming a solid basis for reuse at different levels of abstraction as well as across other projects.
Compliance – A key aspect of DFT is interoperability. SoCs offer a design method which maximizes IP reuse. Different design cores implement a wide range of DFT schemes based on different design flows and tools, each with its own end quality of result in mind. In the case of hard cores, DFT information in the form of Test Information Models (TIMs), is scarcely available and may even contain errors. Measuring compliance to industry as well as to proprietary standards is critical to solving the Gordian knot of heterogeneity.
Functionality – Another key misconception in the world of DFT stems from the design-manufacturing culture gap that widened over the last few years. DFT structures are often treated as a derivative of a completely automated and hence flawless tool-driven process. While this is not far from the truth with respect to scan insertion and simple stuck-at models, it is not applicable to more complex DFT elements, such as BIST controllers, or the integration of complete test infrastructures at the system level. Functionality metrics, in the form of functional, assertion or even structural coverage information, can be defined early and used consistently throughout the project.
Q. So now that you've helped us understand all of these complexities hiding in DFT, what solutions can you offer us?
Globetech Solutions believes the best way to approach DFT is with an Enterprise-Level Verification Process Automation (VPA) Solution that can be applied to test infrastructures based on the integration of advanced planning templates, verification IP targeted at specific structural elements of DFT, and test information models for enhanced automation and integration. The aim is to provide a platform, based on proven technologies and tools such as Cadence's vManager and Specman Elite [tm], in order to ensure that mistakes of the past are not repeated and risk of exposure to inadequate or inefficient test capabilities is minimized early in the design process.
I encourage readers to contact me directly at stelix@globetechsolutions.com with questions about our solutions or to discuss any aspect of DFT verification.
Read more about planning for verification of DFT in this paper written by Stylianos Diamantidis "How are you Planning to Verify all that DFT?"
| |
This content has been rated 5 out of 5 by other users |
|
|
|
|
|