1. 6/14/991 Symbolic verification of systems with state machines David L. Dill Jeffrey Su Jens Skakkebaek Computer System Laboratory Stanford University

2. Outline  Introduction Verification Method TORCH Verifying Instruction Fetch Unit of TORCH Conclusion

3. 6/14/993 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

4. 6/14/994 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.”

5. 6/14/995 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. 6/14/996 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.

7. 6/14/997 A simple example Data Path Control FSM Source M Dest CW T1T1 T2T2 ready true new_data ready Clean state: C Dirty states: W, T 1, T 2 0 1 1 0

8. 6/14/998 A simple example Control FSM CW T1T1 T2T2 ready true new_data ready Data Path Source M Dest 0 1 1 0 37 62 37 62 Desired Property: (FSM = C) => (Source = Dest)

9. 6/14/999 A simple example Data Path Control FSM Source M Dest CW T1T1 T2T2 ready true new_data ready 0 1 1 0 37 62 25 74 New values loaded

10. 6/14/9910 A simple example Data Path Control FSM Source M Dest CW T1T1 T2T2 ready true new_data ready 0 1 1 0 37 62 25 74 First half of value 25 Requirement: (FSM = T 1 ) =>(Source[0] = M)

11. 6/14/9911 A simple example Data Path Control FSM Source M Dest CW T1T1 T2T2 ready true new_data ready 0 1 1 0 62 25 74 Second half of value 25 74 First half of value Requirement: (FSM = T 2 ) => ((Source[1] = M)  (Source[0] = Dest[0]))

12. 6/14/9912 A simple example Data Path Control FSM Source M Dest CW T1T1 T2T2 ready true new_data ready 0 1 1 0 25 74 25 74 Requirement: (FSM = C) => (Source = Dest)

13. 6/14/9913 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 = T 1 ) => (Source[0] = M)  (FSM = T 2 ) => ((Source[1] = M)  (Source[0] = Dest[0]))

14. 6/14/9914 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.

15. Outline Introduction  Verification Method TORCH Verifying Instruction Fetch Unit of TORCH Discussion

16. 6/14/9916 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.”

17. 6/14/9917 Extracting Regular Expressions C W T1T1 T2T2 ready true new_data ready new_data + new_data  ready *  ready  True  True

18. 6/14/9918 Symbolic simulation example Control FSM CW T1T1 T2T2 ready true new_data ready Data Path Source M Dest 0 1 1 0 M0M0 A0A0 A1A1 A0A0 A1A1 Initial state

19. 6/14/9919 Symbolic simulation example Control FSM CW T1T1 T2T2 ready true new_data ready Data Path Source M Dest 0 1 1 0 M0M0 B0B0 B1B1 A0A0 A1A1

20. 6/14/9920 Symbolic simulation example Control FSM CW T1T1 T2T2 ready true new_data ready Data Path Source M Dest 0 1 1 0 B0B0 B1B1 A0A0 A1A1 B0B0

21. 6/14/9921 Symbolic simulation example Control FSM CW T1T1 T2T2 ready true new_data ready Data Path Source M Dest 0 1 1 0 B0B0 B1B1 A1A1 B0B0 B1B1

22. 6/14/9922 Symbolic simulation example Control FSM CW T1T1 T2T2 ready true new_data ready Data Path Source M Dest 0 1 1 0 B0B0 B1B1 B0B0 B1B1 B1B1 Invariant holds again

23. 6/14/9923 Proving clean state invariants C C Assuming source = dest here Prove source = dest here Use symbolic simulation to “skip over” dirty states and assuming conditions that enable this path (path constraints) Prove for every clean state and path to next clean state:

24. 6/14/9924 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,  ),  )

25. 6/14/9925 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.

26. 6/14/9926 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.

27. 6/14/9927 Verification Process Verilog Translator Guidance Tool Symbolic Simulator SVC Impl. (Verilog) Impl. (HLN) Impl. (HLN) Correctness Property Theorems to prove Counter Example Valid

28. Outline Introduction Verification Method  TORCH Verifying Instruction Fetch Unit of TORCH Conclusion

29. 6/14/9929 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/.

30. 6/14/9930 Block Diagram of TORCH TLB Load/Store Unit IFetch Unit Shadow Register File Register File A-Side Decoder & Execution Unit B-Side Decoder & Execution Unit Level 2 Cache

31. 6/14/9931 Instruction Fetch Unit IFetch Datapath PC Unit Datapath ICache IFetch Control Level 2 Cache Instrs 3000 lines of Verilog No independent specification

32. Outline Introduction Verification Method TORCH  Verifying Instruction Fetch Unit of TORCH Conclusion

33. 6/14/9933 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.)

34. 6/14/9934 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.

35. 6/14/9935 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...

36. Outline Introduction Verification Method Verification Process TORCH Verifying Instruction Fetch Unit of TORCH  Conclusion

37. 6/14/9937 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