
cf0102cdcc99e9823f73316976b1042b.ppt
- Количество слайдов: 21
ATS Backward Reasoning with Formal Properties: A methodology for bug isolation on simulation traces Anvesh Komuravelli 1 Srobona Mitra 1 Ansuman Banerjee 2 Pallab Dasgupta 1 1 Dept. 2 Adv. of Comp. Sc. & Engg. , IIT Kharagpur Comp. & Microelectronics Unit, ISI Kolkata Presented by: Srobona Mitra 2011 Asian Test Symposium
Outline • Background and Objective • Example • The Approach • Running on the example • Experimental Results • Conclusion and Future Work
Background • When a logical bug is sensitized, it may take several cycles for the bug to propagate to the design interface and manifest itself in the trace • Automated bug localization techniques for hardware designs typically work on the design implementation to root-cause the given bug – Advantage: complete approach – Disadvantage: scalability issues • Assertions are scattered throughout the design, at the interface of each component module and globally
Objective • To pinpoint the location of bug with the help of the assertions given the buggy trace – Advantage: • highly scalable • Works for incompletely specified designs, where the RTL code of some components is not available • new properties can be added in hindsight to perform what-if analysis – Disadvantage: • incomplete approach
The Problem • Given: – A buggy simulation trace where the simulation output differs from the golden output – The set of assertions scattered all over the design • Goal: – To use causal deduction using the assertions to locate the bug • Challenges: – To use the properties to propagate the causeeffect relationships through internal signals of design not visible in the trace – To do the deduction backwards starting from the bug manifestation
Example a c f d b e • • • G(a → e) G(e → ¬Xf ) G(f ↔ F[2, 2]c) G(c V XXd) G(d → XXXXb) b 20 = FALSE d 16 = FALSE c 14 = TRUE f 12 = TRUE e 11 = FALSE a 11 = FALSE Refutation! Buggy Trace Cycle: a b 1: 0 0 2: 0 1 3: 0 1 ……. . 11: 1 1 12: 1 1 13: 1 1 14: 0 1 15: 0 1 16: 0 1 17: 0 1 18: 0 1 19: 0 1 20: 0 0
Bounded LTL Semantics • Let π = < s 0, s 1, … > be the infinite state sequence corresponding to an infinite execution of the system beginning at s 0 • So πk = < sk, sk+1, … >
Subformulae of an LTL formula
Rewriting of LTL formulae
Overall Methodology • Extract all the subformulae of all the properties. – G(pi) → pi → sf(pi) • Form the bi-implications corresponding to all the subformulae (using rewrite rules) • Form the conjuncts corresponding to the properties – a & Xb → (a) & (Xb) • Create new variables for all subformulae at each time step while going back • Add the signal valuations at each cycle • Form a SAT expression and check for unsatisfiability
On the example - Subformulae G(a → e) G(e → ¬Xf ) G(f ↔ F[2, 2]c) G(c V XXd) G(d → XXXXb) {a, e} {e, f, Xf} {f, F[2, 2]c, F[1, 1]c, F[0, 0]c, c} {c, XXd, d} {d, XXXXb, b} E = {a, b, c, d, e, f, XXXXb, F[2, 2]c, F[1, 1]c, F[0, 0]c, XXd, Xf}
Bi-implications Xb XXXb XXXXb F[0, 0]c F[1, 1]c F[2, 2]c Xd Xf (Xb)t ↔ bt+1 (XXb)t ↔ (Xb)t+1 (XXXb)t ↔ (XXb)t+1 (XXXXb)t ↔ (XXXb)t+1 (F[0, 0]c)t ↔ ct (F[1, 1]c)t ↔ (F[0, 0]c)t+1 (F[2, 2]c)t ↔ (F[1, 1]c)t+1 (Xd)t ↔ dt+1 (XXd)t ↔ (Xd)t+1 (Xf)t ↔ ft+1
Conjuncts formulae a→e e → ¬Xf f ↔ F[2, 2]c c V XXd d → XXXXb ¬at V et ¬et V ¬(Xf)t (¬ft V (F[2, 2]c)t) Λ (¬(F[2, 2]c)t V ft) ct V (XXd)t ¬dt V (XXXXb)t
Running of the algorithm ¬b 20 ¬(Xb)19 ¬(XXb)18 ¬(XXXb)17 ¬(XXXXb)16 ¬d 16 ¬(Xd)15 ¬(XXd)14 c 14 (F[0, 0]c)14 (Xb)19 ↔ b 19+1 (XXb)18 ↔ (Xb)18+1 (XXXb)17 ↔ (XXb)17+1 (XXXXb)16 ↔ (XXXb)16+1 ¬d 16 V (XXXXb)16 (Xd)15 ↔ d 15+1 (XXd)14 ↔ (Xd)14+1 c 14 V (XXd)14 (F[0, 0]c)14 ↔ c 14 (F[1, 1]c)13 ↔ (F[0, 0]c)13+1
Running of the algorithm (F[1, 1]c)13 (F[2, 2]c)12 ↔ (F[1, 1]c)12+1 (F[2, 2]c)12 (¬f 12 V (F[2, 2]c)12) Λ (¬(F[2, 2]c)12 V f 12) f 12 (Xf)11 ↔ f 11+1 (Xf)11 ¬e 11 V ¬(Xf)11 ¬e 11 ¬a 11 V e 11 ¬a 11 (from trace) Refutation!
Experimental Results • Experiments with randomly generated safety properties and randomly generated traces • Varied the average length of the properties, visibility, total number of signals, length of refutation trace • To analyze, formed a digraph with properties as vertices and an edge from p 1 to p 2 iff p 1 affects p 2. • G(a Λ Xb) affects G(b → c)
Experimental Results • Despite wide variations in the properties of the digraph like number of components, component size, longest path in a component, significant factors affecting the time and space are: – Number of properties – Length of property – Length of counterexample
Experimental Results Tabulated Average Property Length = 6 and Properties# = 10 Average Property Length = 6 and Properties# = 50
Experimental Results Tabulated Average Property Length = 20 and Properties# = 10 Average Property Length = 20 and Properties# = 50
Conclusion and Future Work • We propose a methodology for property-assisted debugging of a hardware design • Future direction is to explore how to use the refutation provided by the methodology – Can a subset of the total set of properties be reasoned which accounts for the refutation? – Constrain the search space of the design to locate and fix the bug – Combine property assisted debugging with design assisted debugging
Thank You! Questions? E-mail ID: srobona@cse. iitkgp. ernet. in
cf0102cdcc99e9823f73316976b1042b.ppt