formal verification
Download
Skip this Video
Download Presentation
Formal Verification

Loading in 2 Seconds...

play fullscreen
1 / 66

Formal Verification - PowerPoint PPT Presentation


  • 125 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Formal Verification' - howell


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
formal verification
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

why verify
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

lessons from the pentium bug
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

simulation
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

speeding up simulations
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

still too much data
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

formal verification7
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

circuit model
Circuit Model

Latches

Combinational Logic

Latches

Combinational verification: prove this works

CS 150 - Spring 2008 – Lec #23 – Verification - 8

combinational verification problem
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

canonical form
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

another canonical form decision trees
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

ex decision tree for f a b c
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

still too large
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

ex decision tree for f a b c14
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

ex decision tree for f a b c15
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

fold together identical nodes
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

bdd applications
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

forming bdd s
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

bryant s procedures
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

bryant s procedures20
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

key to efficiency
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

example a b c ab c
Example: a’b’c + ab’c’

A

A

B

B

+

C

C

1

0

1

0

CS 150 - Spring 2008 – Lec #23 – Verification - 22

example a b c ab c23
Example: a’b’c + ab’c’

B

B

=

0

+

C

C

1

0

1

0

CS 150 - Spring 2008 – Lec #23 – Verification - 23

example f a b c ab c
Example: f = a’b’c + ab’c’

B

B

+

=

C

C

1

0

0

1

0

CS 150 - Spring 2008 – Lec #23 – Verification - 24

example a b c ab c25
Example: a’b’c + ab’c’

A

B

B

C

C

1

0

1

0

CS 150 - Spring 2008 – Lec #23 – Verification - 25

example a b c ab c26
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

example a bc abc
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

example f a b c ab c a bc abc
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

bdd s for verification

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

satisfiability
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

general formulation of the satisfiability problem
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

example verification of f a b c
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

example verification of f a b c33
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

verification with a don t care set
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

verification with a don t care set35
Verification With a Don’t-Care Set

CS 150 - Spring 2008 – Lec #23 – Verification - 35

example verify a b c with don t care set a b
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

solving the sat problem
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

finite state machine verification
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

fsm verification
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

key technique reachable states iteration
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

fsm traversal
FSM Traversal

A

B

C

G

F

D

E

CS 150 - Spring 2008 – Lec #23 – Verification - 41

fsm traversal r 0
FSM Traversal -- R0

CS 150 - Spring 2008 – Lec #23 – Verification - 42

fsm traversal r 1
FSM Traversal – R1

CS 150 - Spring 2008 – Lec #23 – Verification - 43

fsm traversal r 2
FSM Traversal – R2

CS 150 - Spring 2008 – Lec #23 – Verification - 44

fsm traversal r 3
FSM Traversal – R3

R3 = R2 = R* = {A, B, C, D, E, F}

G is unreachable!

CS 150 - Spring 2008 – Lec #23 – Verification - 45

this was obvious from the state graph
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

multiple machines
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

example
Example

C

A

Dy

y’

x’

Bx

D

B

y

x

J

I

(Bx)’

(Dy)’

CS 150 - Spring 2008 – Lec #23 – Verification - 48

example49
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

form the single machine and prove it
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

state diagram for the combined machine
State Diagram for the Combined Machine

A,C

A,D

A,J

B,C

B,D

B,J

I,C

I,D

I,J

CS 150 - Spring 2008 – Lec #23 – Verification - 51

filling in the transitions
Filling in the transitions
  • In state (I,J)
  • Possible Transitions:
    • (Bx)’(Dy)’ to (I,J)
    • (Bx)’(Dy) to (A,J) (X)
      • Not in state D
    • (Bx)(Dy)’ to (I,C) (X)
      • Not in state B
    • (Bx)(Dy) to (A,C) (X)
      • Not in states B or D

C

A

Dy

y’

x’

Bx

D

B

y

x

J

I

(Dy)’

(Bx)’

CS 150 - Spring 2008 – Lec #23 – Verification - 52

state diagram for the combined machine53
State Diagram for the Combined Machine

A,C

A,D

A,J

B,C

B,D

B,J

I,C

I,D

I,J

CS 150 - Spring 2008 – Lec #23 – Verification - 53

filling in the transitions54
Filling in the transitions
  • In state (B,D)
  • Possible Transitions:
    • x’y’ to (A,C)
    • xy to (I,J)
    • x’y to (A,J)
    • xy’ to (I,C)

C

A

Dy

y’

x’

Bx

D

B

y

x

J

I

(Dy)’

(Bx)’

CS 150 - Spring 2008 – Lec #23 – Verification - 54

state diagram for the combined machine55
State Diagram for the Combined Machine

A,C

A,D

A,J

B,C

B,D

B,J

I,C

I,D

I,J

CS 150 - Spring 2008 – Lec #23 – Verification - 55

state diagram for the combined machine56
State Diagram for the Combined Machine

A,C

A,D

A,J

B,C

B,D

B,J

I,C

I,D

I,J

CS 150 - Spring 2008 – Lec #23 – Verification - 56

state diagram for the combined machine57
State Diagram for the Combined Machine

A,C

A,D

A,J

B,C

B,D

B,J

I,C

I,D

I,J

CS 150 - Spring 2008 – Lec #23 – Verification - 57

reachable states for the combined machine
Reachable States for the Combined Machine

A,C

A,D

A,J

B,C

B,D

B,J

I,C

I,D

I,J

CS 150 - Spring 2008 – Lec #23 – Verification - 58

reachable states for the combined machine59
Reachable States for the Combined Machine

A,C

A,D

A,J

B,C

B,D

B,J

I,C

I,D

I,J

CS 150 - Spring 2008 – Lec #23 – Verification - 59

reachable states for the combined machine60
Reachable States for the Combined Machine

A,C

A,D

A,J

B,C

B,D

B,J

I,C

I,D

I,J

CS 150 - Spring 2008 – Lec #23 – Verification - 60

reachable states for the combined machine61
Reachable States for the Combined Machine

A,C

A,D

A,J

B,C

B,D

B,J

I,C

I,D

I,J

CS 150 - Spring 2008 – Lec #23 – Verification - 61

reachable states for the combined machine62
Reachable States for the Combined Machine

A,C

A,D

A,J

B,C

B,D

B,J

I,C

I,D

I,J

CS 150 - Spring 2008 – Lec #23 – Verification - 62

forbidden states
Forbidden States

Ó

Ó

A,C

A,D

A,J

Ó

Ó

B,C

B,D

B,J

I,C

I,D

Ó

I,J

CS 150 - Spring 2008 – Lec #23 – Verification - 63

reachable and forbidden states for the combined machine
Reachable and Forbidden States for the Combined Machine

Ó

A,C

A,D

A,J

Ó

Ó

B,C

B,D

Ó

B,J

I,C

I,D

I,J

Ó

CS 150 - Spring 2008 – Lec #23 – Verification - 64

conclusion
Conclusion
  • Two machines are a partition of the one logical machine!
  • Forbidden states didn’t overlap reachable states

CS 150 - Spring 2008 – Lec #23 – Verification - 65

formal verification66
Formal Verification
  • How do I know if my circuit works?
  • Simulation
  • Formal Verification: prove it works
    • Combinational verification
      • Bdd’s as canonical forms
      • SAT-based approach
    • Sequential Verification
      • Reachable-states iteration

CS 150 - Spring 2008 – Lec #23 – Verification - 66

ad