1. Transaction Based Modeling and Verification of Hardware Protocols Xiaofang Chen, Steven M. German and Ganesh Gopalakrishnan Supported in part by SRC Contract TJ1318 Also supported thru an IBM Summer Internship

2. 2 Cycle accurate RTL level Hardware Protocols Specification Abstraction level Model size

3. 3 Problem Addressed  Specifications –Usually verifiable –But do they correctly represent the implementations?  RTL implementations –Real designs usually too complex to be verified – Even if verifiable, does the impl meet the spec?  Our goal – Develop a practical approach to check refinement

4. 4 Outline  Our approach of refinement check  Compositional refinement check  Experimental results and related work

5. 5 Differences in Modeling: Specs vs. Impls home remote One step in high-level Multiple steps in low-level represents an atomic guarded/command. home router buf remote

6. 6 Differences in Execution: Specs vs. Impls Interleaving in HL Concurrency in LL

7. 7 Our Approach of Refinement  Modeling –Specification: Murphi –Implementation: Hardware Murphi  Use transactions in Impl to relate to Spec  Verification –Muv: Hardware Murphi  synthesizable VHDL –Tool: IBM SixthSense

8. 8 Hardware Murphi  Murphi extension by German and Janssen  Concurrent guarded/commands with shared variables –On each cycle Multiple transitions execute concurrently Exclusive write to a variable Shared reads to variables Write immediately visible within the same transition Write visible to other transitions on the next cycle  Support transactions, signals, etc

9. 9 What Are Transactions?  Group a multi-step execution in implementations Spec Impl

10. 10 Tool: Muv  Initially developed by German and Janssen  Hardware Murphi  synthesizable VHDL  Other usages: –Write verification drivers/checkers –Prototype VHDL implementations –Cycle-accurate modeling

11. 11 Our Definition of Refinement … l0l0 … h n0 l1l1 l2l2 h n1 h n2 … … Impl: Spec: Category 1: interface vars

12. 12 Our Definition of Refinement … l0l0 … h n0 l1l1 l2l2 h n1 h n2 … … Impl: Spec: Category 2: transactional vars

13. 13 Our Definition of Refinement … l0l0 … h n0 l1l1 l2l2 h n1 h n2 … … Impl: Spec: Category 3: non-observable vars

14. 14 Our Refinement Check Spec( I ) I Spec( I ’) Spec transition Multi-step Impl transaction I’ Guard for Spec transition must hold I is a reachable Impl state Observable vars changed by either must match

15. 15 An Example of Refinement Check Transaction Rule-1 guard1 action1; Rule-2 guard2 action2; Rule-3 guard3 action3; End; assert impl_var1 = spec_var1; assert impl_var2 = spec_var2; … assert spec_guard; spec_action;

16. 16 Additional Checks Needed for Refinement  Write-write conflicts  Serializability check

17. 17 Workflow of Our Refinement Check Hardware Murphi Impl model Product model in Hardware Murphi Product model in VHDL Murphi Spec model Property check Muv Check implementation meets specification

18. 18 Driving Benchmark Buf Remote DirCache Mem Router Buf Local Home Remote DirCache Mem S. German and G. Janssen, IBM Research Tech Report 2006 Local Home

19. 19 Bugs Found with Refinement Check  Benchmark satisfies cache coherence already  Bugs still found –Bug 1: router unit loses messages –Bug 2: home unit replies twice for one request –Bug 3: cache unit gets updated twice from one reply  Refinement check is a convenient way of constructing checks

20. 20 Outline Our approach of refinement check  Compositional refinement check  Experimental results and related work

21. 21 Model Checking Approaches  Monolithic –Product model + property check  Compositional –Divide and conquer Product model in VHDL Monolithic Compositional

22. 22 Compositional Refinement Check Spec( I ) I Spec( I ’) Spec transition Multi-step Impl transaction I’ Guard for Spec transition must hold I is a reachable Impl state Observable vars changed by either must match

23. 23 Basic Techniques of Our Compositional Approach  Abstraction –Removing details to make verification easier –A sound approach  Assume guarantee –A form of induction which introduces assumptions and justifies them

24. 24 Abstraction  Change variables to free input variables  Add all transitions that write to a variable to the submodel  If a read of a variable is self-sourced, this read is conservatively abstract

25. 25 Assume Guarantee Reasoning  Assume reads of an observable variable v – Spec_v = Impl_v  Guarantee this for all writes to v

26. 26 Additional Checks Needed for Abstraction & A/G  Write-write conflicts  Serializability check  Read-write dependencies between transactions  Currently performed on the monolithic model  Only involve the control logic

27. 27 Outline Our approach of refinement check Compositional refinement check  Experimental results and related work

28. 28 Experiment Results with SixthSense Verification Time 1-bit 10-bit 1-day Datapath 30 min Monolithic approach Compositional approach * Configuration: Node = 2, Addr = 2

29. 29 Related Work  Bluespec –Arvind et al.  Aggregation of distributed actions –Park and Dill  Compositional verification –Many previous works: McMillan[97], C. B. Jones[83], etc.

30. 30 Conclusion  Developed a formal theory of refinement  Developed the monolithic refinement check  Developed a compositional approach  Obtained promising experimental results

31. 31 Future Work  Simulation-based check –VHDL design + Hardware Murphi test cases  Planned Work –Mechanize assertion generation of refinement in muv –More case studies, eg. pipelining

32. 32  IBM SixthSense, RuleBase  Cadence IFV Thanks

33. 33 Questions?

34. 34 Project Summary  This paper –Basic refinement theory and implementation –Preliminary experiment results  More experiment results –A complete case study on a benchmark protocol – Bugs found – Verification time: over a day  30 min