To Overtest Or Not To Overtest - More Questions Than Answers

Summary form only given. Overtesting occurs when a defect that would not be detected under functional operation conditions of a chip is detected due to non-functional conditions created during test application. More generally, overtesting refers to a failure of a chip that occurs during test application when the chip would operate correctly in functional mode. Thus, overtesting results in yield loss that is arguably unnecessary. Overtesting was reported under two-pattern scan-based tests applied for detecting transition faults. However, a wider range of test and defect types may be involved in overtesting. This talk reviews the existing methodologies for addressing overtesting. These methodologies can be broadly classified as based on redundant faults, or based on operation conditions. Methodologies based on redundant faults attempt to prevent faults, which do not affect the functional operation of the circuit, from being detected. Methodologies based on operation conditions attempt to ensure that non-functional operation, which is made possible by scan (or other design-for-testability logic), is avoided. Functional operation conditions in these methodologies are defined to occur when the circuit is in its reachable state space. For a synchronizable circuit, this includes every state that the circuit can visit after synchronization. This talk discusses the fundamental differences between these methodologies, their advantages and limitations. The differences between the methodologies can be seen from the following: 1) A detectable fault may have a test that detects it using a non-reachable state. 2) A redundant fault may become detectable under scan using a reachable state. The talk also raises questions related to overtesting, including the following: 1) Should overtesting (always) be avoided? 2) Should avoidance of overtesting focus only on transition (delay) faults and scan based tests? 3) Even if testing under functional operation conditions can achieve complete fault coverage, is the test set comprehensive enough? 4) Is there a preferred class of methodologies for avoiding overtesting?