6/14/991 Symbolic verification of systems with state machines David L. Dill Jeffrey Su Jens...
-
Upload
bathsheba-willis -
Category
Documents
-
view
213 -
download
0
Transcript of 6/14/991 Symbolic verification of systems with state machines David L. Dill Jeffrey Su Jens...
6/14/99 1
Symbolic verification of systems with state machines
David L. Dill
Jeffrey Su
Jens Skakkebaek
Computer System Laboratory
Stanford University
Outline
Introduction• Verification Method• TORCH• Verifying Instruction Fetch Unit of TORCH• Conclusion
6/14/99 3
The context
For the last few years, my research group has been working on “symbolic verification” methods
Defining characteristics:– Higher-level data types: integers, bitvectors, arrays,
uninterpreted functions– High level symbolic simulation– Automatic procedures for deciding the validity of logical
formulas
Applied to microprocessor design verification
6/14/99 4
The problem
How can we formally verify systems that are both control- and data-intensive?
(e.g., memory systems, communications protocols, etc.)
Problems with model checking:• Values in data path blow up state space.• Abstracting data path is often difficult.• Specifying control without data path is hard
“The control is correct if it makes the data path do the right thing.”
6/14/99 5
Symbolic approaches
Theorem proving and/or symbolic simulation often can deal with data paths, but have problems with control-dominated systems.
Reachability invariants are required, to capture– legal combinations of FSM states– relations between FSMs and datapath elements– relations between values in different parts of datapath.
Automatic methods for discovering invariants are weak.
Invariants for systems that combine control and data are especially hard.
6/14/99 6
Key Idea
• Many systems can be considered as processing a sequence of transactions.
• Processing a transaction involves a sequence of steps.• When the system is not processing a transaction, its states are
defined as “clean states.” Otherwise, they are in “dirty states.”
Observation:
Invariants needed for the clean states are much simpler than for the other states.
6/14/99 7
A simple example
Data Path Control FSMSource
M
Dest
C
W
T1
T2
readytrue
true new_data
new_data
ready
Clean state: C
Dirty states: W, T1, T2
0
1 1
0
6/14/99 8
A simple example
Control FSM
C
W
T1
T2
readytrue
true new_data
new_data
ready
Data PathSource
M
Dest
0
1 1
037
62
37
6262
Desired Property: (FSM = C) => (Source = Dest)
6/14/99 9
A simple example
Data Path Control FSMSource
M
Dest
C
W
T1
T2
readytrue
true new_data
new_data
ready
0
1 1
037
6262
25
74
New valuesloaded
6/14/99 10
A simple example
Data Path Control FSMSource
M
Dest
C
W
T1
T2
readytrue
true new_data
new_data
ready
0
1 1
037
62
25
74
First half ofvalue
25
Requirement: (FSM = T1) =>(Source[0] = M)
6/14/99 11
A simple example
Data Path Control FSMSource
M
Dest
C
W
T1
T2
readytrue
true new_data
new_data
ready
0
1 1
0
62
25
74
Second half of value
2574
First half ofvalue
Requirement: (FSM = T2) =>
((Source[1] = M) (Source[0] = Dest[0]))
6/14/99 12
A simple example
Data Path Control FSMSource
M
Dest
C
W
T1
T2
readytrue
true new_data
new_data
ready
0
1 1
025
74
2574
74
Requirement:(FSM = C) => (Source = Dest)
6/14/99 13
Invariants to Prove
• The invariant we want:
(FSM = C) => (Source = Dest)
• But to prove the invariant, we need the stronger property:
(FSM = C) => (Source = Dest) (FSM = T1) => (Source[0] = M) (FSM = T2) => ((Source[1] = M) (Source[0] = Dest[0]))
6/14/99 14
Summary of the problem
• Invariants for clean states are:– Relatively simple– Directly related to desired properties
• Required properties of dirty states makes it much harder to find inductive invariants.
• Goal: Prove invariants on clean states without considering invariants on dirty states.
Outline
• Introduction Verification Method• TORCH• Verifying Instruction Fetch Unit of TORCH• Discussion
6/14/99 16
Verification Method
• Identify control FSMs and clean states in the design.• Extract regular expressions from FSMs that describe all paths
between clean states.• Symbolically simulate all the paths.
– Intuition: computes next state function from clean states to clean states, skipping over dirty states.
• Prove that invariants hold on clean states.• Note: explanation below is “somewhat idealized.”
6/14/99 17
Extracting Regular Expressions
C
W
T1
T2
readytrue
true new_data
new_data
ready
new_data + new_data ready * ready True True
6/14/99 18
Symbolic simulation example
Control FSM
C
W
T1
T2
ready
true
true new_data
new_data
ready
Data PathSource
M
Dest
0
1 1
0M0
A0
A1
A0
A1
Initial state
6/14/99 19
Symbolic simulation example
Control FSM
C
W
T1
T2
ready
true
true new_data
new_data
ready
Data PathSource
M
Dest
0
1 1
0M0
B0
B1
A0
A1
6/14/99 20
Symbolic simulation example
Control FSM
C
W
T1
T2
ready
true
true new_data
new_data
ready
Data PathSource
M
Dest
0
1 1
0B0
B1
A0
A1
B0
6/14/99 21
Symbolic simulation example
Control FSM
C
W
T1
T2
ready
true
true new_data
new_data
ready
Data PathSource
M
Dest
0
1 1
0B0
B1 A1
B0B1
6/14/99 22
Symbolic simulation example
Control FSM
C
W
T1
T2
ready
true
true new_data
new_data
ready
Data PathSource
M
Dest
0
1 1
0B0
B1
B0B1
B1
Invariant holds again
6/14/99 23
Proving clean state invariants
C C
Assuming source = dest
here
Provesource = dest
here
Use symbolic simulation to “skip over” dirty states
and assumingconditions that
enable this path(path constraints)
Prove for every clean state and path to next clean state:
6/14/99 24
Simulating along regular expressions
• Regular expressions have three operators– concatenation (sequencing)– union (choice)– star (repetition)
• We have to deal with each operation• Concatenation is easy
– simulate(s, ( )) = simulate(simulate(s, ), )
6/14/99 25
Simulating union
• Path splitting: Simulate ( ) as two separate paths– prove invariant separately for each path
– problem: multiplicative growth (1 1) (2 2) splits into four paths.
• State merging: simulate( ) =
merge(simulate() simulate())• s’’ = merge(s, s’): For each variable v,
– if s(v) = s(v’) = e, then s’’(v) = e– else, set s’’(v) = a, where a is a new variable that appears
nowhere else.
6/14/99 26
Simulating repetition
* represents a cycle in the state machine• It is the most difficult case because it represents infinitely many
paths: . . .• Approach
– Use path splitting for first 1 to 3 cases– Merge remaining infinite number of cases
• This basically only works because * is often a wait loop– No important variables change after the first few iterations.
6/14/99 27
Verification Process
VerilogTranslator
GuidanceTool
SymbolicSimulator
SVC
Impl.(Verilog)
Impl.(HLN)
Impl. (HLN)
CorrectnessProperty
Theoremsto prove Counter
Example
Valid
Outline
• Introduction• Verification Method TORCH• Verifying Instruction Fetch Unit of TORCH• Conclusion
6/14/99 29
TORCH
• TORCH was designed by Prof. Horowitz’s group at Stanford University.
• The design was for research into the microprocessor architectures and has not been fabricated.
• It has several interesting features:– Two asymmetric pipelines– 40 bit instruction– Instruction cache and Data cache
• The Verilog description of TORCH is publicly available at http://www-flash.stanford.edu/torch/.
6/14/99 30
Block Diagram of TORCH
TLB
Load/StoreUnit
IFetchUnit
Shadow Register File
Register FileA-Side
Decoder &Execution Unit
B-SideDecoder &
Execution Unit
Level 2 Cache
6/14/99 31
Instruction Fetch Unit
IFetchDatapath
PC UnitDatapath
ICache
IFetchControl
Level 2 Cache
Instrs
• 3000 lines of Verilog• No independent specification
Outline
• Introduction• Verification Method• TORCH Verifying Instruction Fetch Unit of TORCH• Conclusion
6/14/99 33
Verifying IFetch Unit of TORCH
The correctness invariant about the ICache:
Every valid location in the cache has the “same” contents as the corresponding location in memory.
(The actual property is somewhat more complicated because data is rearranged in the cache.)
6/14/99 34
Results
• This method is capable of finding bugs in the design.– Four bugs were found in the IFetch unit.
• Updating the tag for noncacheable instructions• Writing an incorrect tag when two consecutive cache
misses access the same cache line (two bugs)• Transferring FSM to an incorrect state when there is a
level 2 cache miss– These bugs had been found previously with much more
difficulty using symbolic verification and computing invariants on the dirty states.
6/14/99 35
Limitations
• These results are very preliminary and has many restrictions– Sequential transactions– There must be few clean states– FSMs must be small– Loops must be wait loops
• Still requires some manual invariants• We’re working on it . . .
Outline
• Introduction• Verification Method• Verification Process• TORCH• Verifying Instruction Fetch Unit of TORCH Conclusion
6/14/99 37
Conclusion
• A method is presented to verify systems with data and control.• This method was used to verify a non-trivial microprocessor.• Verification was finished in manageable time.• Verification revealed the design errors.
• Future work:– Fully automate the method– Eliminate limitations of the method– Try on more examples