English
Putting the D Back into Design for Test
by Dr. Ralph Marlett, Product Director, Atrenta Inc.
Design-for-Test (DFT), has become ReDesign-for-Test at most companies. Altogether too often, test is an afterthought. First the design is coded, then simulated and synthesized. After all that (months into the design cycle), it's handed over to the test team to ensure the design is testable. And most often, it isn't.
If RTL designers don't properly apply testability rules at the initial design stage, the design can have poor test coverage or even be untestable until extensive changes are made.
The most popular DFT tools operate at the gate level - again, after simulation and synthesis. When any changes are made at the gate level, there's no longer a one-to-one correlation between gates and RTL code. Good luck trying to go back to the original RTL to make the corresponding gate-level changes. And, since synthesis tools do not provide correlation from the gates back to RTL, the task of modifying the RTL to repair a particular gate-level construction is labor intensive. In large designs, with hundreds of design files and numerous levels of hierarchy, finding the precise cause of a gate-level violation can be a daunting task. If the RTL isn't changed (and often it isn't), the same diagnostic effort and associated design changes will have to be made again at the gate level if that code is ever re-used.
The goal, of course, is to create designs that are testable in the first place, not to re-design for test. The problem is that RTL coders aren't really taught how to create testable code. Plus, different test tools have different rules for best practices, so the exact coding style depends on the test tool you plan to use.
A new approach for DFT must start at the beginning, with RTL coding. The ideal approach has little or no impact on system performance and allows RTL design engineers to focus on achieving system requirements. DFT functions defined at the pre-synthesis stage also benefit from optimization performed by logic synthesis tools.
Design-for-Test (DFT), has become ReDesign-for-Test at most companies. Altogether too often, test is an afterthought. First the design is coded, then simulated and synthesized. After all that (months into the design cycle), it's handed over to the test team to ensure the design is testable. And most often, it isn't.
If RTL designers don't properly apply testability rules at the initial design stage, the design can have poor test coverage or even be untestable until extensive changes are made.
The most popular DFT tools operate at the gate level - again, after simulation and synthesis. When any changes are made at the gate level, there's no longer a one-to-one correlation between gates and RTL code. Good luck trying to go back to the original RTL to make the corresponding gate-level changes. And, since synthesis tools do not provide correlation from the gates back to RTL, the task of modifying the RTL to repair a particular gate-level construction is labor intensive. In large designs, with hundreds of design files and numerous levels of hierarchy, finding the precise cause of a gate-level violation can be a daunting task. If the RTL isn't changed (and often it isn't), the same diagnostic effort and associated design changes will have to be made again at the gate level if that code is ever re-used.
The goal, of course, is to create designs that are testable in the first place, not to re-design for test. The problem is that RTL coders aren't really taught how to create testable code. Plus, different test tools have different rules for best practices, so the exact coding style depends on the test tool you plan to use.
A new approach for DFT must start at the beginning, with RTL coding. The ideal approach has little or no impact on system performance and allows RTL design engineers to focus on achieving system requirements. DFT functions defined at the pre-synthesis stage also benefit from optimization performed by logic synthesis tools.
Related Articles
- Optimizing Automated Test Equipment for Quality and Complexity
- ASICs Bring Back Control to Supply Chains
- Pytest for Functional Test Automation with Python
- System on Modules (SOM) and its end-to-end verification using Test Automation framework
- Creating IP level test cases which can be reused at SoC level
New Articles
Most Popular
- System Verilog Assertions Simplified
- System Verilog Macro: A Powerful Feature for Design Verification Projects
- Synthesis Methodology & Netlist Qualification
- Enhancing VLSI Design Efficiency: Tackling Congestion and Shorts with Practical Approaches and PnR Tool (ICC2)
- Demystifying MIPI C-PHY / DPHY Subsystem
|
E-mail This Article | 
|
|
Printer-Friendly Page |