Detecting Multi-cycle Errors using Invariance Information

1. Detecting Multi-cycle Errors using Invariance Information Nuno Alves, Jennifer Dworak, and R. Iris Bahar Division of Engineering Brown University Providence, RI 02912 Kundan Nepal Electrical Engineering Dept. Bucknell University Lewisburg, PA 17837 European Test Symposium, May 28, 2008

2. 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?

3. 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)

4. 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

5. Error Detection Flow invariant relationships verified by checker logic

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

7. n1 n2 n8 n3 n4 n5 n6 n7 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 n5=1n8=0 ERROR

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

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

10. 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

11. Multi-cycle Implication Example X A • 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? B Y F

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

13. Multi-cycle Implication Example X X A A B B Y Y F F B1=0F2=0

14. Multi-cycle Implication Example X A B Y ERROR F

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

16. Discovered Implications

17. 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:

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

19. 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

20. 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.

21. Pruning Implications

22. 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