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

L L
a a
t t
c Combinational Logic c
h h
e e
s s

Combinational
verification: prove
thisCS
works
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 = (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

1 Decision Tree for 1 0 Decision Tree for 0

Decision Decision
Tree for Tree for
f|A=1 f|A=0

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

CS 150 - Spring 2008 – Lec #23 –

Verification - 15
Fold Together identical nodes

A
Reduced, Ordered
Binary Decision
B B Diagram of function
for f = A B  C
Canonical Form
C C Often Small
“Most important
computer science
structure of last 20
1 0 years”
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

1  Bdd
=
1 1  Bdd
= Bdd

0  Bdd
= Bdd

0  Bdd 0
=

Not BDD: just swap terminals

CS 150 - Spring 2008 – Lec #23 –
Verification - 19
Bryant’s procedures

A op A

BDD BDD BDD BDD

for for for for
f|A=1 f|A=0 g|A=1 g|A=0

=
BDD BDD
for for
f op g|A=1 f op g|
CS 150 - Spring 2008 – A=0Lec #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: 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’c’

= B
0 + B

C
C

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

B
B
+ =

C
C

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

B B

C C

1 0 1 0
CS 150 - Spring 2008 – Lec #23 –
Verification - 25
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

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

B B
B B B B
+ =

C C
C C C C

1 0
1 0 1 0
CS 150 - Spring 2008 – Lec #23 –
Verification - 28
BDD’s For Verification
A
A
B B
B B

C C
C C

1 0
1 0

Reduced, Ordered Binary Reduced, Ordered Binary

Decision Diagram of function Decision Diagram of
for f = A B CS
 C150 16) 2008function
- Spring
(slide – Lec #23for
– f = A’B’C + A’BC’
Verification - 29 + AB’C’+ ABC (slide 16)
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
CS 150 - Spring1) 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 T 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

B C G

D E F

CS 150 - Spring 2008 – Lec #23 –

Verification - 41
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
C
A

Dy y’
x’ Bx
D
B

y
x

J
I
(Bx)’
(Dy)’ CS 150 - Spring 2008 – Lec #23 –
Verification - 48
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)
A C
•Possible Transitions:
Dy
x’ y’ •(Bx)’(Dy)’ to (I,J)
Bx
•(Bx)’(Dy) to (A,J) (X)
B D
•Not in state D

x y •(Bx)(Dy)’ to (I,C) (X)

•Not in state B

I J •(Bx)(Dy) to (A,C) (X)

•Not in states B or
(Dy)’ CS 150 - Spring 2008 – Lec
(Bx)’ #23 –
Verification - 52 D
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)
A C
•Possible Transitions:
Dy
x’ y’ •x’y’ to (A,C)
Bx
•xy to (I,J)
B D
•x’y to (A,J)

x y •xy’ to (I,C)

I J

(Dy)’ CS 150 - Spring 2008 – Lec #23 –

(Bx)’
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
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

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