- 125 Views
- Uploaded on

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

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

- 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

- 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

- 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

- 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

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

Latches

Combinational Logic

Latches

Combinational verification: prove this works

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

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

- 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

- 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

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

- 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 Å 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 Å 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

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

- 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

- 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

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

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

A

B

B

B

B

C

C

C

C

1

1

0

0

BDD’s For VerificationReduced, 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

- 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

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

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 Å 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

- 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 Set

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

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

- 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

- 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

- 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”

- 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 -- R0

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

FSM Traversal – R1

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

FSM Traversal – R2

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

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!

- 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

- 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

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!

- 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

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

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

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

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

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

Download Presentation

Connecting to Server..