What's Missing from Design for Testability?
Louis Y. Ungar, President, Advanced Test Engineering (A.T.E.) Solutions
EETimes (12/14/2015 06:00 AM EST)
For years, engineers have neglected the "design" part of design-for-test. DFT shouldn't be an afterthought and test engineers can take on some of the task.
Design for Testability (DFT) is comprised of two very important terms. "Testability" is a condition of a circuit that makes it possible, easy, and cost-effective to test and diagnose the circuit (unit) under test (UUT). There is a wide acceptance that such a characteristic should be part of electronics ICs, boards and systems, too. After all, without DFT, faults can go undetected, making them difficult to repair. For far too long, the "Design" part of DFT that has been neglected.
Clearly, the features needed for implementing DFT, such as controllability, observability and diagnosability must be incorporated into a design. DFT shouldn't be an afterthought or a redesign activity. Designers must purposely create testable circuits. DFT is, however, more problematic than it appears. Let's examine the hurdles and see what we can do to improve design activities for testability.
E-mail This Article | Printer-Friendly Page |
Related Articles
New Articles
- Early Interactive Short Isolation for Faster SoC Verification
- The Ideal Crypto Coprocessor with Root of Trust to Support Customer Complete Full Chip Evaluation: PUFcc gained SESIP and PSA Certified™ Level 3 RoT Component Certification
- Advanced Packaging and Chiplets Can Be for Everyone
- Timing Optimization Technique Using Useful Skew in 5nm Technology Node
- Streamlining SoC Design with IDS-Integrate™
Most Popular
- System Verilog Assertions Simplified
- System Verilog Macro: A Powerful Feature for Design Verification Projects
- Dynamic Memory Allocation and Fragmentation in C and C++
- Enhancing VLSI Design Efficiency: Tackling Congestion and Shorts with Practical Approaches and PnR Tool (ICC2)
- UPF Constraint coding for SoC - A Case Study