1 / 37

Symbolic verification of systems with state machines

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. The context.

kyle
Download Presentation

Symbolic verification of systems with state machines

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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. 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. 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. 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. 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. new_data C ready W A simple example Data Path Control FSM Source Dest M 0 0 1 1 new_data true T2 Clean state: C true ready T1 Dirty states: W, T1, T2

  8. Data Path Source Dest M 37 new_data 37 0 0 62 62 1 62 1 C ready W A simple example Desired Property: (FSM = C) => (Source = Dest) Control FSM new_data true T2 true ready T1

  9. new_data C ready W A simple example Data Path Control FSM Source Dest M 25 37 0 0 62 74 1 62 1 new_data true New values loaded T2 true ready T1

  10. new_data C ready W A simple example Data Path Control FSM Source Dest M 25 37 0 0 25 74 1 62 1 new_data true First half of value T2 true Requirement: (FSM = T1) =>(Source[0] = M) ready T1

  11. new_data C ready W A simple example First half of value Data Path Control FSM Source Dest M 25 25 0 0 74 74 1 62 1 new_data true Second half of value T2 true Requirement: (FSM = T2) => ((Source[1] = M) (Source[0] = Dest[0])) ready T1

  12. new_data C ready W A simple example Data Path Control FSM Source Dest M 25 25 0 0 74 74 1 74 1 new_data true T2 true Requirement: (FSM = C) => (Source = Dest) ready T1

  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]))

  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.

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

  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.”

  17. new_data C new_data true ready T2 W true ready T1 new_data + new_data  ready *  ready  True  True Extracting Regular Expressions

  18. new_data C ready W Symbolic simulation example Control FSM Data Path Source Dest M A0 A0 0 0 M0 A1 1 1 A1 new_data true Initial state T2 ready true T1

  19. new_data C ready W Symbolic simulation example Control FSM Data Path Source Dest M B0 A0 0 0 M0 B1 1 1 A1 new_data true T2 ready true T1

  20. new_data C ready W Symbolic simulation example Control FSM Data Path Source Dest M B0 A0 0 0 B0 B1 1 1 A1 new_data true T2 ready true T1

  21. new_data C ready W Symbolic simulation example Control FSM Data Path Source Dest M B0 0 B0 0 B1 B1 1 1 A1 new_data true T2 ready true T1

  22. new_data C ready W Symbolic simulation example Control FSM Data Path Source Dest M B0 0 B0 0 B1 B1 1 1 B1 new_data true T2 Invariant holds again ready true T1

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

  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, ), )

  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.

  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.

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

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

  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/.

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

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

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

  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.)

  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.

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

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

  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

More Related