1 / 66

Formal Verification

Formal Verification. How do I know if my circuit works? Simulation Formal Verification: prove it works Combinational verification Sequential Verification. Why Verify?. November 1994: Pentium Step D Division Bug Original Pentium chip could return incorrect results on division operation

howell
Download Presentation

Formal Verification

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. Formal Verification • How do I know if my circuit works? • Simulation • Formal Verification: prove it works • Combinational verification • Sequential Verification CS 150 - Spring 2008 – Lec #23 – Verification - 1

  2. Why Verify? • November 1994: Pentium Step D Division Bug • Original Pentium chip could return incorrect results on division operation • Discovered by Prof. Thomas Nicely, professor at Lynchburg College, in November 1994 • Forced recall of Pentium chips in December, 1994 • Bug was extremely rare! • Byte: chances of exciting bug 1 in 9 billion • Other estimates 1 in 60 million • But even 1 in 9 billion happens occasionally… • Pentium executed about 500 million instructions/sec • 1 in 1000(?) FDIV • 500000 FDIVs/sec • One bug every 5 hours CS 150 - Spring 2008 – Lec #23 – Verification - 2

  3. Lessons from the Pentium Bug • Subtle! Happened Very Rarely • Therefore hard to detect… • Expensive! • Intel forced to recall Pentium chips • Took huge black eye in November/December 1994 • Generated by accident • Pentium used SRT Division algorithm • Table Look up for partial quotients, remainders • Perl script used to generate table, extract to PLA generator for LUT • Bug in the perl script • Mistakes are easy to make, expensive to correct! CS 150 - Spring 2008 – Lec #23 – Verification - 3

  4. Simulation • Main workhorse of verification • Simple procedure: • Apply vectors to design • Either compare to reference design or put error-checking into model • See if any problems occur • What’s the problem? • Too many vectors, too much computation! • ~5 billion transistors on modern chip • ~1 billion gates • At 1 instruction/vector/gate, approx 1 CPU second to simulate 1 cycle on a machine • ~30 CPU-years to simulate 1 CPU second! CS 150 - Spring 2008 – Lec #23 – Verification - 4

  5. Speeding up simulations • Hierarchical (Cycle) Simulation • Simulate subcircuits in isolation and prove they work • Substitute compiled (faster) form of circuit in simulator • Ex: prove adder adds, then simulate with “+” • Massive parallelism • In 1995, all of Intel workstations were used to run simulations • BOINC-like technology crawled workstations and simulated when idle • Helps, But… CS 150 - Spring 2008 – Lec #23 – Verification - 5

  6. Still too much Data • Exhaustive simulation of 32-bit adder • 265 possible vectors • 1 simulation/instruction (how?) • 230 simulations/second • 235 seconds to simulate (32 billion seconds = 9000 years) • Exhaustive simulation of 64-bit adder • 2129 possible vectors • 299 seconds to simulate • Universe is 1.4E10 x 3.6E7 = 5E17 = 250 seconds old • To do it in the age of the universe would require about 249 million computers doing nothing else… (100 quintillion computers) • Adder is only tiny chunk of a chip… CS 150 - Spring 2008 – Lec #23 – Verification - 6

  7. Formal Verification • Prove the chip works • No simulation • Combinational Verification • Prove combinational circuit (no latches) equivalent to reference design • Ex: Prove carry-bypass adder computes same function as ripple-carry adder • Sequential Verification • Prove finite-state machine can’t get into bad state, can’t deadlock, etc CS 150 - Spring 2008 – Lec #23 – Verification - 7

  8. Circuit Model Latches Combinational Logic Latches Combinational verification: prove this works CS 150 - Spring 2008 – Lec #23 – Verification - 8

  9. Combinational Verification Problem • Formal Statement: • Given Circuit C and Reference Circuit R, does C compute the same function as R? • Key: we can usually describe what a circuit does very simply • Complexity comes from making it fast, compact, etc • For example: given a carry-bypass adder C, does it compute the same function as a (simple) ripple-carry adder R? • Two Approaches: Canonical Form and Satisfiability CS 150 - Spring 2008 – Lec #23 – Verification - 9

  10. Canonical Form • Unique Form of a function: if f = g, then f º g • Example: list of minterms • List of minterms is unique to a function • Ex: f = A Å B Å C • F = S(1,2,4,7) • Problem: Too large! • In general, O(2n) minterms for function of n variables • Note: for any canonical form, must be O(2n) for most functions • Simple counting argument: 2^2^n functions of n variables • Representation must be log number of functions • But humans don’t design most functions! • Need canonical form usually small for functions humans actually design CS 150 - Spring 2008 – Lec #23 – Verification - 10

  11. Another Canonical Form: Decision Trees • Graphical Form of Function Evaluation Decision Tree for 0 Decision Tree for 1 0 1 A Decision Tree for f|A=0 Decision Tree for f|A=1 CS 150 - Spring 2008 – Lec #23 – Verification - 11

  12. Ex: Decision Tree for f = AÅ B Å C A B B C C C C 1 0 0 1 1 0 0 1 CS 150 - Spring 2008 – Lec #23 – Verification - 12

  13. Still Too Large • n variable function • Full binary tree of depth n • 2n leaves • 2n -1 internal nodes • But we can do better • Full binary tree contains many identical nodes • Fold these together, retain canonical form, greatly reducted size CS 150 - Spring 2008 – Lec #23 – Verification - 13

  14. Ex: Decision Tree for f = AÅ B Å C A B B Identical C C C C 1 0 0 1 1 0 0 1 CS 150 - Spring 2008 – Lec #23 – Verification - 14

  15. Ex: Decision Tree for f = AÅ B Å C A B B Identical C C C C 1 0 0 1 1 0 0 1 CS 150 - Spring 2008 – Lec #23 – Verification - 15

  16. Fold Together identical nodes A Reduced, Ordered Binary Decision Diagram of function for f = AÅ B Å C Canonical Form Often Small “Most important computer science structure of last 20 years” B B C C 1 0 CS 150 - Spring 2008 – Lec #23 – Verification - 16

  17. BDD Applications • Formal Verification • Canonical form for circuit • Represent sets of states in finite state machine • Low-power circuitry • Each edge becomes AND gate • Each node becomes OR • Output is “1” terminal • At most one transition per simulation • Simulation • Compile circuit into BDD • Compile BDD into code • Number of instructions to simulate circuit = number of variables in BDD CS 150 - Spring 2008 – Lec #23 – Verification - 17

  18. Forming BDD’s • Due to Bryant, 1986 • Key observation: can’t form Decision Tree (also called “Shannon Tree”) and then fold • Decision Tree is too big • Bryant showed how one could build up BDDs from component functions • Developed efficient algorithms to OR, AND, etc BDDs together • Meant one could always work with small structures CS 150 - Spring 2008 – Lec #23 – Verification - 18

  19. Bryant’s procedures Bdd Bdd Bdd Ú 1 1 Ù 1 = = Bdd Bdd Ú 0 = Bdd Ù 0 0 = Not BDD: just swap terminals CS 150 - Spring 2008 – Lec #23 – Verification - 19

  20. Bryant’s procedures A A op BDD for f|A=0 BDD for g|A=0 BDD for g|A=1 BDD for f|A=1 A = BDD for f op g|A=0 BDD for f op g|A=1 CS 150 - Spring 2008 – Lec #23 – Verification - 20

  21. Key to Efficiency • Kept a hash table (var, low, high) • If var, low, high already in table returned stored function • Kept each function at most once CS 150 - Spring 2008 – Lec #23 – Verification - 21

  22. Example: a’b’c + ab’c’ A A B B + C C 1 0 1 0 CS 150 - Spring 2008 – Lec #23 – Verification - 22

  23. Example: a’b’c + ab’c’ B B = 0 + C C 1 0 1 0 CS 150 - Spring 2008 – Lec #23 – Verification - 23

  24. Example: f = a’b’c + ab’c’ B B + = C C 1 0 0 1 0 CS 150 - Spring 2008 – Lec #23 – Verification - 24

  25. Example: a’b’c + ab’c’ A B B C C 1 0 1 0 CS 150 - Spring 2008 – Lec #23 – Verification - 25

  26. Example: a’b’c + ab’c’ A A A B B B B + = C C C C 1 0 1 0 1 0 CS 150 - Spring 2008 – Lec #23 – Verification - 26

  27. Example: a’bc’ + abc A A A B B B B + = C C C C 1 0 1 0 1 0 CS 150 - Spring 2008 – Lec #23 – Verification - 27

  28. Example: f = a’b’c + ab’c’ + a’bc’ + abc A A A B B B B B B + = C C C C C C 1 0 1 1 0 0 CS 150 - Spring 2008 – Lec #23 – Verification - 28

  29. A A B B B B C C C C 1 1 0 0 BDD’s For Verification Reduced, Ordered Binary Decision Diagram of function for f = A’B’C + A’BC’ + AB’C’+ ABC (slide 16) Reduced, Ordered Binary Decision Diagram of function for f = AÅ B Å C (slide 16) CS 150 - Spring 2008 – Lec #23 – Verification - 29

  30. Satisfiability • Formal Statement: • Given Circuit C and Reference Circuit R, does C compute the same function as R? • Key: we can usually describe what a circuit does very simply • Easy to formulate as a circuit-satisfiability problem • For each output Ci, Ri, is CiÅRi = 0? CS 150 - Spring 2008 – Lec #23 – Verification - 30

  31. General Formulation of the Satisfiability Problem C is identical to R only when out == 0 (no inputs X, Y, Z that makes out 1) CS 150 - Spring 2008 – Lec #23 – Verification - 31

  32. Example: Verification of f = A Å B Å C Specification of f = A Å B Å C Implementation of f = A Å B Å C CS 150 - Spring 2008 – Lec #23 – Verification - 32

  33. Example: Verification of f = A Å B Å C Implementation Works when check can’t be set to 1 Specification CS 150 - Spring 2008 – Lec #23 – Verification - 33

  34. Verification With a Don’t-Care Set • Key: only need to verify against care set • Error only if: • Check = 1 AND don’t-care = 0 • Check = 1 and care = 1 • Therefore: use same procedure as before but just AND with the don’t-care set CS 150 - Spring 2008 – Lec #23 – Verification - 34

  35. Verification With a Don’t-Care Set CS 150 - Spring 2008 – Lec #23 – Verification - 35

  36. Example: Verify A B C with don’t-care set A+B Implementation Valid unless check=1 Specification Don’t-care CS 150 - Spring 2008 – Lec #23 – Verification - 36

  37. Solving the SAT problem • Assert 1 on the output • Trace implications back to inputs • No contradiction => error, input vector found • Contradiction: Circuit works • SAT is NP-complete (first NP-Complete problem; Cook’s paper was called “Complexity of Theorem-Proving Procedures) • But extensively studied • Current best heuristics (Malik, Princeton) up to 5000 variables… CS 150 - Spring 2008 – Lec #23 – Verification - 37

  38. Finite State Machine Verification • Does my finite-state machine work? • In the limit, proves the whole design works • (Any design is just one big FSM) • In general, this is too hard – prove things about pieces at a time • “Works” is too complicated and ill-formed a question to prove • We mean multiple properties • How can we say “video feed displays properly” mathematically? • Need to pose questions we can answer • E.G. Prove when we get an init message we always respond with an ack CS 150 - Spring 2008 – Lec #23 – Verification - 38

  39. FSM Verification • Two general classes of property to prove • Safety: Bad things don’t happen • e.g., two FSMs can’t deadlock • Liveness: Good things eventually happen • E.g., I can always recover locally from a failure • The two techniques are somewhat similar • Safety: prove a machine can never get into a bad state • Liveness: prove that a particular state is on a cycle in the state graph • We’ll consider safety • Liveness proof turns out to be a simple manipulation of the state graph CS 150 - Spring 2008 – Lec #23 – Verification - 39

  40. Key Technique: “Reachable States Iteration” • Compute the reachable states of a finite state machine • Initial State is Reachable R0 = {Init} • Next is reached by iteration: • Rn = Rn-1 È {T | S®T is a transition and Te Rn-1} • R* = Reachable States = Rn where Rn = Rn-1 • Lots of mathematics, but just the breadth-first traversal of the state graph until we have hit every state • Notice that every new state is one we’ve visited before CS 150 - Spring 2008 – Lec #23 – Verification - 40

  41. FSM Traversal A B C G F D E CS 150 - Spring 2008 – Lec #23 – Verification - 41

  42. FSM Traversal -- R0 CS 150 - Spring 2008 – Lec #23 – Verification - 42

  43. FSM Traversal – R1 CS 150 - Spring 2008 – Lec #23 – Verification - 43

  44. FSM Traversal – R2 CS 150 - Spring 2008 – Lec #23 – Verification - 44

  45. FSM Traversal – R3 R3 = R2 = R* = {A, B, C, D, E, F} G is unreachable! CS 150 - Spring 2008 – Lec #23 – Verification - 45

  46. This was obvious from the State Graph! • But, typically don’t have an explicit representation for a state graph • Just latches and logic • Need to mathematically represent current set of reachable states • Use BDD to represent set of reachable states • Push BDD through the logic using Bryant’s Procedure • Get a new BDD – if equal to old, we are done • Many variants: “Iterative Squaring”, “Transitive Closure”, “Prefix Sets” CS 150 - Spring 2008 – Lec #23 – Verification - 46

  47. Multiple machines • Often, we want to prove two communicating machines have some property • E.g., Two machines are a factored form of a single machine • Solution: express two machines as single combined FSM • State property as safety property on the combined machine • Use R.S. iteration to prove the property CS 150 - Spring 2008 – Lec #23 – Verification - 47

  48. Example C A Dy y’ x’ Bx D B y x J I (Bx)’ (Dy)’ CS 150 - Spring 2008 – Lec #23 – Verification - 48

  49. Example Prove those two machines are a partition of this one: D A y y’ x’ C B x CS 150 - Spring 2008 – Lec #23 – Verification - 49

  50. Form the single Machine and prove it! • States are pairs of states from the original machines • Transitions are legal transitions from the original machines • Thing to prove: • (I, J) is unreachable • {A, B} x {C, D} are unreachable • E. G., (A, D) is unreachable CS 150 - Spring 2008 – Lec #23 – Verification - 50

More Related