150 likes | 307 Views
Compacting Test Vector Sets via Strategic Use of Implications. Kundan Nepal Electrical Engineering Dept. Bucknell University Lewisburg, PA 17837. Nuno Alves, Jennifer Dworak, and R. Iris Bahar Division of Engineering Brown University Providence, RI 02912.
E N D
Compacting Test Vector Sets via Strategic Use of Implications Kundan Nepal Electrical Engineering Dept. Bucknell University Lewisburg, PA 17837 Nuno Alves, Jennifer Dworak, and R. Iris Bahar Division of Engineering Brown University Providence, RI 02912 International Workshop on Logic and Synthesis, August 1, 2009
Goal and Motivation • Goal: • Reduce # of required test vectors while maintaining the same test coverage • Motivation: • Smaller feature sizes for devices increased logic density increased test data volume • Increased complexity of defects and process variations require more circuit testing • Test time is expensive
Our Approach • Use logic implication checkers, inserted in hardware, to enable more compact n-detect test sets • Extension of our previous work: • “Using implications for online error detection,” in ITC08 • “Detecting errors using multi-cycle invariance information,” in DATE09
n1 n2 n8 n3 n4 n5 n6 n7 Naturally Occurring Implications 0 0 0 1 n5 = 1 → n8 = 0
n1 n2 n8 n3 n4 n5 n6 n7 Implication Violations Can Be Used to Detect Errors Appropriate checker logic can detect multiple errors with a single implication. n5=1n8=0 ERROR
n1 n2 n8 n3 n4 n5 n6 n7 Implication Violations Can Be Used to Detect Errors Appropriate checker logic can detect multiple errors with a single implication. sa1 sa1 sa1 sa1 sa1 sa1 sa1 sa1 sa1 sa1 sa1 sa1 sa1 sa1 sa1 sa1 sa1 sa1 sa1 sa1 sa1 n5=1n8=0 ERROR
Using Implications for Test Vector Compaction • General idea: • Certain faults in a circuit are hard to detect • A circuit with many hard to detect faults requires lots of test vectors • Implications may make faults easier to detect these faults, therefore pattern count can be reduced • In particular: reduce pattern count required for n-detect test
Why Do We Want to Detect Faults Multiple Times? • Faults targeted during test are not perfect models of defects • Each defect may have its own requirements for detection • BUT…there are certain requirements that overlap • Observing a site multiple times, you have multiple opportunities to meet additional requirements for detecting real defects
A s-a-1 0 0/1 1/1 A 1 0/1 S A OR B bridge P 0/1 0/0 0/0 f 0/0 1 Q B Defects & Faults May Not Match To detect the OR bridge with a test for A s-a-1, B must equal 1. Observation for OR bridge: Could be satisfied by observation of A s-a-1 Excitation for OR bridge: Requires satisfying an additional constraint
A s-a-1 0 0/1 1/1 A 1 0/1 S P 0/1 A OR B bridge 0/0 0/0 f 1/1 0 Q B Defects & Faults May Not Match To detect the OR bridge with a test for A s-a-1, B must equal 0. If we observe a site multiple times with different test patterns we increase our chances of fortuitously exciting whatever unmodeled defect may be present.
Uses a combination of functional simulation and SAT-based verification circuit Discover implications Remove dominated & low quality implications ATPG Run Fault dictionary • (f×p matrix) Compress implications Sort implications according to highest fault coverage for least detected faults 15-detect vectors Create Fault Dictionary (n,f×p matrices) Implication selection alg. Adding one implication at a time, observe which implications reduce the required number of ATPG vectors the most Checker matrix Selected implications
Vector count reduction • Average reduction is 8% when checker logic corresponding to a 1% area overhead is added • With 5% overhead, 17% can be achieved on average
Combining Error Detection and Test Pattern Reduction The implication checker can have a dual purpose
Conclusions • Strategic use of logic implication checkers can significantly reduce the number of vectors needed for N-detect test • Reduction in test pattern count • 1% overhead 8% reduction on average • 5% overhead 17% reduction (avg.), 25% (max.) • Non-intrusive (very small impact on delay) • 2% average delay increase for 5% HW overhead • Same checker logic can be used for pattern count reduction and online error detection