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
- Ultra Ethernet MAC & PCS 100G/200G/400G/800G
- Ethernet PCS 100G/200G/400G/800G/1.6T
- Ethernet MAC 100G/200G/400G/800G/1.6T
- Junction Over-Temperature Detector with Linear Centigrade-to-Voltage Output - X-FAB XT018
- Performance P570 Gen 3
Related Articles
- The Quest for Reliable AI Accelerators: Cross-Layer Evaluation and Design Optimization
- Verification and Validation (V&V)-in-the-Loop for RISC-V Design: The Holistic Vision of BZL
- Design and Implementation of Test Infrastructure for Higher Parallel Wafer Level Testing of System-on-Chip
- PCIe 5.0: The universal high-speed interconnect for High Bandwidth and Low Latency Applications Design Challenges & Solutions
Latest Articles
- Closer in the Gap: Towards Portable Performance on RISC-V Vector Processors
- TTP: A Hardware-Efficient Design for Precise Prefetching in Ray Tracing
- Heterogeneous SoC Integrating an Open-Source Recurrent SNN Accelerator for Neuromorphic Edge Computing on FPGA
- A Reconfigurable Multiplier Architecture for Error-Resilient Applications in RISC-V Core
- ObfAx: Obfuscation and IP Piracy Detection in Approximate Circuits