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