Post on 20-Dec-2015
CS 150 - Spring 2008 – Lec #23 – Verification - 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 - 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 - 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 - 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 - 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 - 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 - 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 - 8
Circuit Model
Latches
Combinational Logic
Latches
Combinational verification: prove this works
CS 150 - Spring 2008 – Lec #23 – Verification - 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 - 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 = (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 - 11
Another Canonical Form: Decision Trees
Graphical Form of Function Evaluation
1 Decision Tree for 1 0 Decision Tree for 0
A
DecisionTree for
f|A=1
DecisionTree for
f|A=0
CS 150 - Spring 2008 – Lec #23 – Verification - 12
Ex: Decision Tree for f = AB C
1 0
A
B B
C C C C
1 01010
CS 150 - Spring 2008 – Lec #23 – Verification - 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 - 14
Ex: Decision Tree for f = AB C
1 0
A
B B
C C C C
1 01010
Identical
CS 150 - Spring 2008 – Lec #23 – Verification - 15
Ex: Decision Tree for f = AB C
1 0
A
B B
C C C C
1 01010
Identical
CS 150 - Spring 2008 – Lec #23 – Verification - 16
Fold Together identical nodes
1 0
A
B B
CC
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”
CS 150 - Spring 2008 – Lec #23 – Verification - 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 - 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 - 19
Bryant’s procedures
1 Bdd = 1
0 Bdd = Bdd
1 Bdd = Bdd
0 Bdd = 0
Not BDD: just swap terminals
CS 150 - Spring 2008 – Lec #23 – Verification - 20
Bryant’s procedures
BDDforf|A=1
BDDforf|A=0
A
BDDfor
g|A=1
BDDfor
g|A=0
Aop
=BDDfor
f op g|A=1
BDDfor
f op g|A=0
A
CS 150 - Spring 2008 – Lec #23 – Verification - 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 - 22
Example: a’b’c + ab’c’
A
B
C
1 0
+
A
B
C
1 0
CS 150 - Spring 2008 – Lec #23 – Verification - 23
Example: a’b’c + ab’c’
0 + B
C
1 0
= B
C
1 0
CS 150 - Spring 2008 – Lec #23 – Verification - 24
Example: f = a’b’c + ab’c’
B
C
1 0
+
0
=
B
C
1 0
CS 150 - Spring 2008 – Lec #23 – Verification - 25
Example: a’b’c + ab’c’
B
C
1 0
B
C
1 0
A
CS 150 - Spring 2008 – Lec #23 – Verification - 26
Example: a’b’c + ab’c’
A
B
C
1 0
+
A
B
C
1 0
=
A
B
C
1 0
B
C
CS 150 - Spring 2008 – Lec #23 – Verification - 27
Example: a’bc’ + abc
A
B
C
1 0
+
A
B
C
1 0
=
A
B
C
1 0
B
C
CS 150 - Spring 2008 – Lec #23 – Verification - 28
Example: f = a’b’c + ab’c’ + a’bc’ + abc
+ =
A
B
C
1 0
B
C
A
B
C
1 0
B
C
A
B
C
1 0
B
C
CS 150 - Spring 2008 – Lec #23 – Verification - 29
BDD’s For Verification
1 0
A
B B
CC
Reduced, Ordered Binary Decision Diagram of function for f = A B C (slide 16)
1 0
A
B B
CC
Reduced, Ordered Binary Decision Diagram of function for f = A’B’C + A’BC’ + AB’C’+ ABC (slide 16)
CS 150 - Spring 2008 – Lec #23 – Verification - 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 - 31
General Formulation of the Satisfiability Problem
R
C
X
Y
Z
V
W
Out
V
W
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 - 32
Example: Verification of f = A B C
A B C
Implementation of f = A B C
C
B
A
Specification of f = A B C
CS 150 - Spring 2008 – Lec #23 – Verification - 33
Example: Verification of f = A B C
A B C
Check
Implementation
Specification
Works when check can’t be set to 1
CS 150 - Spring 2008 – Lec #23 – Verification - 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 - 35
Verification With a Don’t-Care Set
R
C
X
Y
V
W
Out
V
W
Care
CS 150 - Spring 2008 – Lec #23 – Verification - 36
Example: Verify A B C with don’t-care set A+B
A B C
Check
Implementation
Valid unless check=1
Don’t-careSpecification
CS 150 - Spring 2008 – Lec #23 – Verification - 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 - 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 - 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 - 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 | ST 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 - 41
FSM Traversal
A
B C
D E
G
F
CS 150 - Spring 2008 – Lec #23 – Verification - 42
FSM Traversal -- R0
CS 150 - Spring 2008 – Lec #23 – Verification - 43
FSM Traversal – R1
CS 150 - Spring 2008 – Lec #23 – Verification - 44
FSM Traversal – R2
CS 150 - Spring 2008 – Lec #23 – Verification - 45
FSM Traversal – R3
R3 = R2 = R* = {A, B, C, D, E, F}
G is unreachable!
CS 150 - Spring 2008 – Lec #23 – Verification - 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 - 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 - 48
Example
A
B
I
x’
x
(Dy)’
Dy
C
D
J
y’
y
(Bx)’
Bx
CS 150 - Spring 2008 – Lec #23 – Verification - 49
Example
A
B
x’
x
D
C
y’y
Prove those two machines are a partition of this one:
CS 150 - Spring 2008 – Lec #23 – Verification - 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 - 51
State Diagram for the Combined Machine
A,C
B,C
I,C
A,D
B,D
I,D
A,J
B,J
I,J
CS 150 - Spring 2008 – Lec #23 – Verification - 52
Filling in the transitions
A
B
I
x’
x
(Dy)’
C
D
J
y’
y
(Bx)’
Bx
Dy
•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
CS 150 - Spring 2008 – Lec #23 – Verification - 53
State Diagram for the Combined Machine
A,C
B,C
I,C
A,D
B,D
I,D
A,J
B,J
I,J
CS 150 - Spring 2008 – Lec #23 – Verification - 54
Filling in the transitions
A
B
I
x’
x
(Dy)’
C
D
J
y’
y
(Bx)’
Bx
Dy
•In state (B,D)
•Possible Transitions:
•x’y’ to (A,C)
•xy to (I,J)
•x’y to (A,J)
•xy’ to (I,C)
CS 150 - Spring 2008 – Lec #23 – Verification - 55
State Diagram for the Combined Machine
A,C
B,C
I,C
A,D
B,D
I,D
A,J
B,J
I,J
CS 150 - Spring 2008 – Lec #23 – Verification - 56
State Diagram for the Combined Machine
A,C
B,C
I,C
A,D
B,D
I,D
A,J
B,J
I,J
CS 150 - Spring 2008 – Lec #23 – Verification - 57
State Diagram for the Combined Machine
A,C
B,C
I,C
A,D
B,D
I,D
A,J
B,J
I,J
CS 150 - Spring 2008 – Lec #23 – Verification - 58
Reachable States for the Combined Machine
A,C
B,C
I,C
A,D
B,D
I,D
A,J
B,J
I,J
CS 150 - Spring 2008 – Lec #23 – Verification - 59
Reachable States for the Combined Machine
A,C
B,C
I,C
A,D
B,D
I,D
A,J
B,J
I,J
CS 150 - Spring 2008 – Lec #23 – Verification - 60
Reachable States for the Combined Machine
A,C
B,C
I,C
A,D
B,D
I,D
A,J
B,J
I,J
CS 150 - Spring 2008 – Lec #23 – Verification - 61
Reachable States for the Combined Machine
A,C
B,C
I,C
A,D
B,D
I,D
A,J
B,J
I,J
CS 150 - Spring 2008 – Lec #23 – Verification - 62
Reachable States for the Combined Machine
A,C
B,C
I,C
A,D
B,D
I,D
A,J
B,J
I,J
CS 150 - Spring 2008 – Lec #23 – Verification - 63
Forbidden States
A,C
B,C
I,C
A,D
B,D
I,D
A,J
B,J
I,J
CS 150 - Spring 2008 – Lec #23 – Verification - 64
Reachable and Forbidden States for the Combined Machine
A,C
B,C
I,C
A,D
B,D
I,D
A,J
B,J
I,J
CS 150 - Spring 2008 – Lec #23 – Verification - 65
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 - 66
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