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
- 1.6T Ultra Ethernet Controller
- Chiplet Die-to-Die Interconnect IP Solution
- High speed MACsec Engine 100G/200G/400G/800G/1.6T
- Temperature/Voltage sensors
- AMBA Bus Host to eSPI Controller/Target
Related Articles
- The Quest for Reliable AI Accelerators: Cross-Layer Evaluation and Design Optimization
- PCIe 5.0: The universal high-speed interconnect for High Bandwidth and Low Latency Applications Design Challenges & Solutions
- Verification and Validation (V&V)-in-the-Loop for RISC-V Design: The Holistic Vision of BZL
- FlexLLM: Composable HLS Library for Flexible Hybrid LLM Accelerator Design
Latest Articles
- ZK-Flex: A Flexible and Scalable Framework for Accelerating Zero-Knowledge Proofs
- ITP-STDP: An Intrinsic-Timing Power-of-Two Learning Engine for On-Chip SNN Training
- OpenEye: A Scalable Open-Source Hardware Accelerator for DNNs
- CHIMERA: A Flexible and Scalable 3.1 TOPS/W AI-MCU with Transformer Accelerator and 563 Gb/s Shared-L2 Memory Subsystem with QoS Guarantees
- CXL-ClusterSim: Modeling CXL-based Disaggregated Memory Cluster for Pooling and Sharing using gem5 and SST