European Test Symposium, May 28, 2008 Nuno Alves, Jennifer Dworak, and R. Iris Bahar Division of Engineering Brown University Providence, RI Kundan Nepal Electrical Engineering Dept. Bucknell University Lewisburg, PA 17837

Online Error Detection GOAL: Detect transient faults that may occur in a circuit during operation Becoming critical as circuits scale to smaller sizes Error detection in memory is “relatively easy” since we know the answer a priori What about random logic? Determine that the functional transformation of the inputs to the outputs has occurred correctly. But how do we know what it’s supposed to be?

Online Detection Techniques Use of pre-computed test vectors and their expected responses (stored in hardware) Duplicating the computation of disjoint hardware elements and voting on the result (e.g.: TMR or logic duplication) Use of check bits (e.g.: parity bit or Hamming Codes)

Our Approach Instead, find invariant relationships that are naturally present among circuit sites in a block of logic. Discovered automatically without requiring knowledge of the circuit’s function or designer constraints. Can be used for combinational or sequential circuits. For sequential circuits, invariants can be within a single cycle or across multiple cycles Violations of these expected relationships can then be used to identify errors. All error checking is done off the critical path

Error Detection Flow invariant relationships verified by checker logic

Invariant Relationships in Circuits In all digital circuits, certain relationships must always be present among particular circuit sites if the circuit is operating correctly. n5=1 n8=0 These relationships can be thought of as logic invariants or logic implications n1 n2 n3 n4 n5 n6 n7 n8

Error Detection with Implications Once we have discovered the implication, extra HW is added to the circuit to verify if implication holds If n5=1 & n8=1, this implies an error occurred in the circuit ERROR n1 n2 n3 n4 n5 n6 n7 n8 n5=1 n8=0

Process Overview (1/2) Verilog Description Logic Simulation Find & Validate Implications 1.Run logic simulation to identify potential implication sites (parallel search). 2.Check all implications for validity using a SAT solver. 3.Eliminate implications subsumed by others.

Process Overview (2/2) Fault Analysis Compress Implications Return Verilog Description with Additional HW 4.Determine the fault coverage of all valid implications. 5.Select a subset of the valid implications such that the highest fault coverage is obtained given a user- specified hardware budget. 6.Deliver a modified Verilog file with implication logic

Multi-cycle Implications Implications can also exist across latch boundaries, over multiple time cycles Faults not adequately covered by single-cycle implications may be better covered across cycles with additional spatial distance. In particular, including multi-cycle implications in checker hardware can help detect errors near latch boundaries May also be useful in detecting delay faults

Multi-cycle Implication Example Consider only the combinational portion of this circuit: There are no useful implication we can use for error checking What if we created a (virtual) copy of this circuit and searched for implications across time cycles? A B F Y X

Multi-cycle Implication Example A B F Y X A B Y X F A B Y X F B=0 F=0

Multi-cycle Implication Example A B F Y X A B Y X F A B Y X F ERROR B 1 =0 F 2 =0

Multi-cycle Implication Example A B Y X F A B Y X F B 1 =0 F 2 =0

Multi-cycle Implication Example A B F Y X ERROR

Experimental Setup Tested approach on circuits from ISCAS benchmarks 3 step process: 1. Initial (non-validated) implications generated using a random set of 32,000 input vectors 2. Zchaff SAT solver used to valid initial set of implications 3. Run fault coverage using these implication in checker Process completed for single cycle and across 2 time cycles

Discovered Implications

Case 1 Case 2 Case 3 Case 4 Error Propagates To Output  An Implication is Violated  Covering faults with implications For each random input vector, and at each fault, the implications-based circuit operation can fall into the following 4 categories:

Detection of Observable Faults Average 9.6% improvement in detection rate Case1/[Case1+Case4]

Do We Need All Implications? Generating checker logic for all discovered implications is unnecessary and wasteful We only want to keep important implications that: Detect many faults Identify hard-to-detect faults Cover faults not detected by other implications

Identifying Important Implications Finding these important implications requires a combination of: structural analysis to removed subsumed implications fault analysis to determine the specific fault coverage for each implication.

Removing Subsumed Implications Some implications may be contained within other implications. Implications i 2 –i 5 are in the path from n 4 to n 8. Of these implications, i 3 has the longest distance. All nodes that have n 4 as parent and n 8 as child and leads to implication with n 8 = 0 can be dropped n6n6 n1n1 n2n2 n3n3 n4n4 n5n5 n7n7 n8n8 n9n9 n 13 n 12 n 11 n 10 i 1 : n 3 =0  n 8 =0 i 2 : n 4 =1  n 12 =0 i 3 : n 4 =1  n 8 =0 i 4 : n 12 =0  n 8 =0 i 5 : n 4 =1  n 13 =0 i 6 : n 12 =0  n 8 =0

Pruning Implications

Conclusions We presented a practical online error detection alternative based on implication validation Does not require modification of targeted logic Checker logic is added off the critical path and run in parallel rest of circuit. We show our approach can easily be expanded to discover implications across multiple time frames to improve fault coverage. We detect up to 90% of observable faults Multi-cycle implications boost detection rate by almost 10% on average