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 Semiconductor IP
- OpenGMSL Leaf IP
- FlexGen Multi-Die Smart Network-on-Chip (NoC) IP
- Ncore Multi-Die Interconnect IP
- CryptoManager Root of Trust for Use with the Caliptra Specification
- Switched Capacitor 3.6V Boost-Buck DC-DC Converter
Related Articles
- Verification and Validation (V&V)-in-the-Loop for RISC-V Design: The Holistic Vision of BZL
- The Quest for Reliable AI Accelerators: Cross-Layer Evaluation and Design Optimization
- GenAI for Systems: Recurring Challenges and Design Principles from Software to Silicon
- LLMs for Secure Hardware Design and Related Problems: Opportunities and Challenges
Latest Articles
- Analog Pin Directionality as an Exfiltration Attack Surface in Mixed-Signal ICs
- SIMT-Aware Lockstep Verification and Functional-Coverage Closure Methodology for an Open-Source RISC-V GPGPU: A UVM 1.2 Environment
- Efficient Hardware Information-Flow Tracking for Pre-Silicon Security Testing
- REACH: Controller-Managed Long-Span ECC for HBM AI Inference
- FPGA Acceleration of Fully Homomorphic Encryption with Adaptive Key Switching