1 / 72

Techniques for automated localization and correction of design errors

Techniques for automated localization and correction of design errors. Jaan Raik Tallinn University of Technology. Design error debug. “There has never been an unexpectedly short debugging period in the history of computers.” Steven Levy. 2. Designs are getting bigger.

xannon
Download Presentation

Techniques for automated localization and correction of design errors

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Techniques for automated localization and correction of design errors Jaan Raik Tallinn University of Technology

  2. Design error debug “There has never been an unexpectedly short debugging period in the history of computers.” Steven Levy 2

  3. Designs are getting bigger

  4. Designs are getting costlier • 25-30 % annually decreasing cost per function • 15 percent annual growth of the market for IC • But … • The cost of chip design keeps on growing. • In 1981, development of a leading-edge CPU cost 1 M$ • …today it costs more than 300 M$ !!! • Why do the costs increase ???

  5. System design Logic design Physical design 40 60 70 < 1979 Schematic entry Placement & routing Simulation 30 30 30 50 40 2 2 2 2 2 ~ 1983 Hierarchy, generators Tehnology’s capabilities 1986 transistors on the die Logic synthesis 1988-92 High-level synthesis / System-level synthesis Designer’s productivity 1992-95 10 Specialized high-level synthesis Person months / 20 000 logic gates time ~1996-... today 3 Design automation crisis • productivity gap • 58% versus 21% annually

  6. Verification Development time: Debug Verification and debugging Specify Design Detect Localise Correct • Debug = Localization + Correction • ~2/3 of development time for verification • ~2/3 of verification time for debug • Thus nearly half of the development cycle

  7. Bugs are getting „smarter“ CREDES Summer School, June 2-3, 2011, Tallinn, Estonia

  8. Traditional debug flow ??? Spec Design Counter-examples (waveforms), failed assertions, ... Verification Error! • Too much information • Too little information

  9. Automated debug flow Spec Design Corrected design, Repair log, ... Verification Error! Error localization Error correction

  10. Outline • Verification basics • Automated debug at the gate-level • RTL debug methods • Localization: SAT; correction: resynthesis • Localization: path tracing; correction: mutation • General discussion, future trends • Prototype tools, on-going activities CREDES Summer School, June 2-3, 2011, Tallinn, Estonia

  11. Verification “To err is human - and to blame it on a computer is even more so.” Robert Orben 11

  12. Verification versus test • The goal of verification is to check if a system is designed correctly. • Validation is similar to verification but we check on a prototype device, not a model. • By (manufacturing) test we understand checking every instance of a produced chip against manufacruring defects.

  13. Abstraction levels and verification

  14. Difficulties in verification • Errors may be in implementation, specification or verification environment (constraints) • No way to detect bugs in the spec, because reference object is missing. Thus: verification by redundancy. • Problem: How to assess verification quality i.e. coverage? (except in equivalence checking)

  15. Verification flow

  16. Dynamic verification

  17. Dynamic verification • Based on simulation • Code coverage • Assertions, functional coverage

  18. Formal verification

  19. Dynamic vs formal verification

  20. Automated debug techniques “Logic is a poor model of cause and effect.” Gregory Bateson 21

  21. Concept of design error: Mostly modeled in implementation, sometimes in specification Main applications: Checking the synthesis tools Engineering change, incremental synthesis Debugging Debugging design errors 22

  22. Debugging design errors 23 What leads to debugging? • Design behavior doesn’t match expected behavior When does this occur? • During simulation of design • Formal tools (property/equivalence check) • Checkers identify the mismatch

  23. Design error diagnosis Classification of methods: Structure-based/specification-based Explicit/Implicit fault model (model-free) Single/multiple error assumption Simulation-based/symbolic 24

  24. Debugging combinational logic • Thoroughly studied in 1990s • Many works by Aas, Abadir, Wahba & Borrione, others • Also studied, at TUT (Ubar & Jutman) • Used structural BDDs for error localization

  25. Explicit error model (Abadir) • functional errors of gate elements • gate substitution • extra gate • missing gate • extra inverter • missing inverter • connection errors of signal lines • extra connection • missing connection • wrong connection

  26. Missing gate error (Abadir)

  27. Mapping stuck-at faults to design errors • Abadir: Complete s-a test detects all single gate replacements (AND,OR,NAND,NOR), extra gates (simple case), missing gates (simple case) and extra wires.

  28. F F F F F F F 1 2 3 4 5 6 7 T 0 1 1 0 0 0 0 1 T 1 0 0 1 0 0 0 2 T 1 1 0 1 0 1 0 3 T 0 1 0 0 1 0 0 4 T 0 0 1 5 Combinational fault diagnosis Fault localization by fault table Test responses: 0 1 1 0 T 0 0 1 0 0 1 1 6 Fault F located 5 Faults F and F are not distinguishable 1 4 No match, diagnosis not possible

  29. Mapping stuck-at faults to design errors

  30. Distribution of design errors

  31. Explicit model: disadvantages • High number of errors to model • Some errors still not modeled

  32. Implicit design error models • Do not rely on structure • Circuit under verification as a black box • I/O pin fault models

  33. Design error correction • Classification: • Error matching approach • Resynthesis approach

  34. Design error correction • Happens in a loop: • An error is detected and localized • Correction step is applied • Corrected design must be reverified • ... • Until the design passes verification

  35. Ambiguity of error location • Since there is more than one way to synthesize a given function, it is possible that thereis more than one way to model the error in an incorrect implementation • correction can be made at different locations

  36. Crash course on SAT CREDES Summer School, June 2-3, 2011, Tallinn, Estonia

  37. Satisfiability aka SAT • SAT: a Boolean function issatisfiable iff there exists a variable assignment to make it evaluate to TRUE • The Boolean function must be represented as a CNF: Digitaalsüsteemide verifitseerimise kursus

  38. Satisfiability aka SAT • SAT is transformed to CNF (i.e. product of sums). • Sums are called terms. • If a term has max 2 literals, then 2-SAT  2-SAT is solved in polynomial time • 3-SAT is an NP-complete problem • N-SAT can be reduced to 3-SAT Digitaalsüsteemide verifitseerimise kursus

  39. SAT for circuits • Characteristic function • Build CNF for logic gates using implication: • ab = ¬a + b Digitaalsüsteemide verifitseerimise kursus

  40. a c & b SAT for circuits • Implications for AND-gate: ¬a¬c & ¬b ¬c & ¬c  ¬a  ¬b • Characteristic function for AND as a CNF: (a+ ¬c) (b+ ¬c) (c+ ¬a+ ¬b) Digitaalsüsteemide verifitseerimise kursus

  41. a c 1 b SAT for circuits • Implications for OR-gate: ac & b c & c  a  b • Characteristic function for OR as a CNF: (¬a + c) (¬b + c) (¬c + a + b) Digitaalsüsteemide verifitseerimise kursus

  42. a d & b f 1 e c SAT for circuits Characteristic function for the circuit: (a+¬d)(b+¬d)(d+¬a+¬b)(¬c+¬e)(c+e)(¬d+f)(¬e+f)(¬f+d+e) Digitaalsüsteemide verifitseerimise kursus

  43. SAT-based RTL debug Mux-enrichment Muxes added to RTL code blocks Mux select values select free inputs for the symptom blocks Synthesis is applied to find logic expressions generating the signatures for these free inputs Cardinality constraints Test vector constraints Smith, Veneris, et al., TCAD, 2005 44

  44. SAT-based RTL debug a) Mux enrichment, b) cardinality constraints 45

  45. SAT-based RTL debug SAT provides locations of signals where errors can be corrected Multiple errors considered! They also provide the partial truth table of the fix Correction by resynthesis This is also a disadvantage: Why should we want to replace a bug with a more difficult one? 46

  46. Path tracing for localization 47 One of the first debug methods Backtracing mismatched outputs (sometimes also matched outputs) Dynamic slicing → critical path tracing (RTL)

  47. Mutation-based correction 48 Locate error suspects by backtracing Correct by mutating the faulty block (replace by a different function from a preset library) An error-matching approach

  48. Testbench-based approach if (fn==1) else if (fn==2) ... if (fn==4) else if (fn==5) ... Original system description 1 1 2 3 2 4 4 5 6 5 1. Identify injection location 2. Apply mutation operators accordingly Injected system description

  49. Arithmetic Operator Replacement (AOR) a = b – c; a = b * c; a = b + c; a = b / c; a = b % c; Set of arithmetic operators = {addition, subtraction, multiplication, division, modulo} Replace each occurrence of arithmetic operator with all the other operators in the set

More Related