MPD 575 Design for Testability

1. MPD 575Design for Testability Jonathan Weaver

2. Development History • This material was prepared by Cohort 3 students in the Fall of 2002: • Ron Anger • Jim Gregoire • Guillermo Jimenez • Bob Ognjanovski • Rob Spinks

3. Need for Testing • High Complexity • Mass Production • High cost of replacement in the field • “The earlier the faulty part is rejected, the cheaper it is” • Testing is no longer viewed as a “no value add” or “hard to justify” expense

4. Need for Testing (Cont.) • Testing is viewed as an integral part of the manufacturing process • Customer expectations of “0” PPM • Increase in customer chargeback to recover all costs associated with “faulty” components

5. Problems with Testing • Testing can comprise as much as 30% of the cost of building a product • Testing is difficult and time consuming due to the large number of test steps, that must be applied • Testing is boring and considered not creative • Designs are completed without testing in mind “ Testing is painful, Not Testing is suicidal.”

6. Why Testing:Relative cost of finding and fixing errors

7. Design for Testability • Introduction to DFT • Key Principles in DFT • DFT Considerations • DFT Process • DFT in Hardware development • DFT in Software development • DFT, Reliability, and Robustness • Examples of DFT techniques • Heuristics • References

8. Related DFXs • Design for Inspectability • Design for Dimensional control • Design for Serviceability • Design for Diagnostics • Design for Modularity • Design for Reliability • Design for Robustness

9. Testability The IEEE Standard Glossary of Software Engineering Terminology (1990) defines testability as: "(1) the degree to which a system or component facilitates the establishment of test criteria and the performance of tests to determine whether those criteria have been met, and (2) the degree to which a requirement is stated in terms that permit establishment of test criteria and performance of tests to determine whether those criteria have been met."

10. Design TESTABILITY Test Requirements Test Equipment

11. Definitions of DFT • Ability to generate, to evaluate and to apply tests that improve quality and minimizes time-to-profit • Extent to which a design can be tested for the presence of manufacturing, base component, system, and/or field defects • Measure of how easy it is to generate test sets that have a high fault coverage

12. Design for Testability • An initiative in the computer hardware industry in the 1980’s • Objectives: • Lowers the cost of manufacturing • Minimizes the design engineer's involvement in production set-up • Improves cross-functional communication and cooperation among design, engineering, and manufacturing

13. Design for Testability (Cont.) • Testing is more expensive in the short-term but cheaper in the longer-term • Lowers both production and life-cycle costs • Decreases test times and virtually eliminates harrowing production delays • Guarantees more efficient diagnosis and repair in the field • Improves fault coverage

14. Design for Testability (Cont.) • Testability must be engineered into the product at the design stage itself, such that optimal compromise is archived between system maintainability and performance. • To maximize its impacts, DFT must be performed at all stages of the design –from schematics –to design of subsystems – to system integration

15. Test Coverage vs. DFT 100% A C B Test Coverage (%) Number of Test Steps B= Design made without Testability in mind by a good fault coverage due to large effort in making test steps C=Design very difficult to test A=Design done with testability in mind

16. Motivation, Goals, and Benefits of DFT • Better fault coverage and fault isolation • Shorter testing time • Higher quality product • Shorter time-to-market • Lower life-cycle cost

17. Design for Testability • Introduction to DFT • Key Principles in DFT • DFT Considerations • DFT Process • DFT in Hardware development • DFT in Software development • DFT, Reliability, and Robustness • Examples of DFT techniques • Heuristics • References

18. Key Principles of DFT • Interfaces that are standard, common, and simple • Accessible points • Automated • Self-test with onboard sensors • Integrated (testing multiple components at the same time) • Testing in parallel (sweep gauges at the same time) • Testing one thing verifies many (Traction control switch checks switch, MUX, cluster,…)

19. Key Principles of DFT • Identification of opportunities • Standardization • Simplification of interfaces • Adjustable • Tunable • Diagnostics • Indicators • Procedures • Location

20. Key Principles of DFT • Accessibility • Obstruction • Orientation • Visibility • Intuitive • Tools (not specialized) • Ergonomic • Non-destructive • Models/CAE

21. Design for Testability • Introduction to DFT • Key Principles in DFT • DFT Considerations • DFT Process • DFT in Hardware development • DFT in Software development • DFT, Reliability, and Robustness • Examples of DFT techniques • Heuristics • References

22. Perspective of DFT • Keywords in Testability: • Understandability (The more information we have, the smarter we test) • Predictability • Observability and Traceability (What we see is what we test ) • Controllability (The better we can control it , the more the testing can be optimized)

23. Perspective of DFT • Keywords in Testability: • Understandability (The more information we have, the smarter we test) • Predictability • Observability and Traceability (What we see is what we test ) • Controllability (The better we can control it , the more the testing can be optimized)

24. Perspective of DFT (Cont.) • DFT involves modifying the design in such way that maximum controllability and observability are attained. • DFT is an approach in which the component (SW or HW) is designed from the start such that testing problems do not arise during the product life-cycle

25. Evaluation of Component Testing Capability Four Levels of testing • Level 1: Initial • Constructed with ad-hoc testing mechanism, testing format, and testing functions • More time in understanding behaviors, debugging, and testing

26. Evaluation of Component Testing Capability (Cont.) • Level 2: Standardize • Built to support pre-defined testing mechanism & testing format • Reduces cost of debugging and testing • Extra programming overhead

27. Evaluation of Component Testing Capability (Cont.) • Level 3: Systematic • Design with a set of systematic testing mechanics • Easy to monitor and to test the components • Reduce programming overhead

28. Evaluation of Component Testing Capability (Cont.) • Level 4: Customizable • Design to facilitate the support of the testing functions & customization • Help to set-up testing for components based software

29. Mechanisms to Increase Component Testability • Framework-based Testing facility • Well-defined framework (such as class library) to add test code • Simple and flexible to use • Need component source code

30. Mechanisms to Increase Component Testability (Cont.) • Built-in testing • Need well-defined built-in mechanisms to add test code • High programming overhead during component development • No external support needed

31. Mechanisms to Increase Component Testability (Cont.) • Automatic component wrapping for testing • Component wrapped inside program for testing • Low programming overhead • Well-defined testing framework to interact with testing tools

32. Design for Testability • Introduction to DFT • Key Principles in DFT • DFT Considerations • DFT Process • DFT in Hardware development • DFT in Software development • DFT, Reliability, and Robustness • Examples • Heuristics • References

33. DFT Process • Evaluate testability of system architecture • Define testability requirements and targets • Describe testability context • Perform testability reviews • Define required design changes

34. DFT Process (cont.) • Collect experience • Define General testing strategy and standards • The design is not finished until final testing requirements are defined and accounted for

36. Design for Testability • Introduction to DFT • Key Principles in DFT • DFT Considerations • DFT Process • DFT in Hardware development • DFT in Software development • DFT, Reliability, and Robustness • Examples • Heuristics • References

37. DFT in Hardware Development • Test generation for large circuits is very time consuming. One way to get around this problem is to constrain or to modify the design in order to make test generation easier.

38. DFT in Hardware Development • Most DFT techniques are targeted to sequential circuits where test generation is usually a difficult problem

39. DFT in Hardware Development • If testing is not considered during the design phase, then very low fault coverage and high test generation times can result.

40. DFT in Hardware Development • The objective of DFT is to improve the controllability and observability of internal circuit nodes so that the circuit can be tested more efficiently and effectively

41. DFT in Hardware Development Controllability: • Ability to set or to reset internal nodes from the primary inputs Observability: • Ability to observe the value of an internal node at the primary outputs

42. DFT in Hardware Development • DFT attempts to improve circuit testability by making the internal nodes more controllable and observable

43. DFT in Hardware Development • Benefits in implementing DFT in HW development: • Shorter time-to-market • Reduced test time • Less expensive testing equipment • Yield learning, which is often overlooked

44. DFT in Hardware Development • Sacrifices in implementing DFT in HW development: • Increased area of components • More pins on printed circuit boards(PCB) • Increased PCB area • Degraded performance on the circuits

45. Design for Testability • Introduction to DFT • Key Principles in DFT • DFT Considerations • DFT Process • DFT in Hardware development • DFT in Software development • DFT, Reliability, and Robustness • Examples of DFT techniques • Heuristics • References

46. DFT in Software development • Most complex modern systems are a blend of Software and Hardware • Testability analysis of a system is incomplete without adequately accounting for the effect of software

47. Challenging Problems in Software Testing • Software is usually much more complicated than hardware • Typically, about 40 to 50% of the overall development budget is spent on testing • Absence of “Known good” response • Lack of testing models, adequate testing criteria, and testing methods • Software flaws are design flaws

48. Software Verification The IEEE Standard Glossary of Software Engineering Terminology (1990) defines software verification to be the “Process of evaluating a system or component to determine whether the products of a given development phase satisfy the conditions imposed at the start of that phase."

49. Software Testability Software testability can be defined as “the probability that a piece of software will fail on its next execution during testing (with a particular assumed input distribution) if the software includes a fault.”

50. True Reliability Software Testing Software Code Software Testability Formal Verification