Verification of Synchronization in SpecC Description with the Use of Difference Decision Diagrams

1. Verification of Synchronization in SpecC Description with the Use of Difference Decision Diagrams Thanyapat Sakunkonchak Masahiro Fujita Department of Electronic Engineering University of Tokyo

2. Content • Introduction • Background • Verification Flows • Experimental Results • Conclusion and Outlook T. Sakunkonchak and M. Fujita

3. Introduction • More and more complex and larger VLSI must be designed with shorter time-to-market • SoC needs simultaneous development of both HW and SW • Needs ways to describe HW/SW seamlessly • C-based specification/design languages are promising • SpecC [http://www.SpecC.org] • Standardized for HW/SW co-design • Based on ANSI-C and extended T. Sakunkonchak and M. Fujita

4. Content • Introduction • Background • Verification Flows • Experimental Results • Conclusion and Outlook T. Sakunkonchak and M. Fujita

5. Synchronization in SpecC • Two processes a, b are running in parallel • par a.main(); b.main(); • a: <st1> <st2> • b: <st3> • Without scheduling (synchronization), ambiguous results may happen • st1->st2->st3 • st3->st1->st2 ? • st1->st3->st2 Any orderings are allowed ! T. Sakunkonchak and M. Fujita

6. Synchronization in SpecC Ambiguous results on y causing from x = 10; /*st1*/ x = 20; /*st3*/ y = 20 (always) T. Sakunkonchak and M. Fujita

7. Synchronization in SpecC (cont.) • Tas=Tbs, Tae=Tbe • Tas<=T1s<T1e<=T2s<T2e<=Tas • Tbs<=T3s<T3e<=Tbe Ambiguous results on y causing from x = 10; /*st1*/ x = 20; /*st3*/ T. Sakunkonchak and M. Fujita

8. Synchronization in SpecC (cont.) y = 20 (always) • Tas=Tbs, Tae=Tbe • Tas<=T1s<T1e<=T2s<T2e<=Tas • Tbs<=T3s<T3e<=Tbe • T2e<=T3s T. Sakunkonchak and M. Fujita

9. The verification problem • Given SpecC programs, check if specific ordering of executions are guaranteed or not • Along with well-accepted Boolean comparison techniques for logic designs , this could be a basic verification method to check if sequential and parallel version of the same SpecC are equivalent or not (Sequential) C Sequential SpecC Parallel SpecC Equivalence checking T. Sakunkonchak and M. Fujita

10. Boolean Program • Proposed by Ball and Rajamani under SLAM project at Microsoft Research • Think of SW like a model (like FSM in HW) and verify it by first abstracting away unnecessary statements with user-defined predicates • BP abstracts the original program: if properties on BP hold, so as original one T. Sakunkonchak and M. Fujita

11. Our Boolean SpecC based on the original Boolean program • is a subset of original program • ‘if-else’ conditions are replaced by proportional vars. e.g. if(x<y) -> if(c0) • Statements other than ‘notify/wait’ and ‘if’, (ones that don’t effect the sync.) are abstracted away (abstract unnecessary info.) • Only for verification of synchronization T. Sakunkonchak and M. Fujita

12. Difference Decision Diagrams (DDD) • Introduce by MΦller, et al. • Symbolic representation of ‘non-boolean’, such as inequality: less efficient if using BDD • DDD represents difference constraints (x-y≤c), x,y are integers, c is constant Represents graph for ¬(x−z<1)Λ(x−y≤0)Λ(y−z≤2) T. Sakunkonchak and M. Fujita

13. Content • Introduction • Background • Verification Flows • Experimental Results • Conclusion and Outlook T. Sakunkonchak and M. Fujita

14. Verification Flows • Goals: • Check whether given SpecC codes (with ‘par’, ‘notify/wait’) are properly synchronized • If checking fails, counter-examples should be generated (trace to source of errors) • Based on: • Boolean SpecC, DDD, SVC, Program Slicing, ... T. Sakunkonchak and M. Fujita

15. Verification Flows(1) Verification of SpecC synchronization Verifying Stage: (current implementation) SpecC source is parsed and translated into Boolean SpecC and then to C++ accompanied with DDD. Then, check for synchronization whether it is satisfied. If it is, terminates with SATISFIED. Otherwise, go to the next stage. SpecC Source Program Parsed & Translated (1) Boolean SpecC Parsed & Translated (2) Users add some properties to be check C++ with DDD Synchronization is SATISFIED Verify: PASS? Yes No T. Sakunkonchak and M. Fujita

16. T. Sakunkonchak and M. Fujita

17. Verification Flows(1) Verification of SpecC synchronization Verifying Stage: (current implementation) SpecC source is parsed and translated into Boolean SpecC and then to C++ accompanied with DDD. Then, check for synchronization whether it is satisfied. If it is, terminates with SATISFIED. Otherwise, go to the next stage. SpecC Source Program Parsed & Translated (1) Boolean SpecC Parsed & Translated (2) Users add some properties to be check C++ with DDD Synchronization is SATISFIED Verify: PASS? Yes No T. Sakunkonchak and M. Fujita

18. Header Branching func. for DDD Declare timing variables Setup DDD graphs Verify From Boolean SpecC to C++ with DDD T. Sakunkonchak and M. Fujita

19. Verification Flows(1) Verification of SpecC synchronization Verifying Stage: (current implementation) SpecC source is parsed and translated into Boolean SpecC and then to C++ accompanied with DDD. Then, check for synchronization whether it is satisfied. If it is, terminates with SATISFIED. Otherwise, go to the next stage. SpecC Source Program Parsed & Translated (1) Boolean SpecC Parsed & Translated (2) Users add some properties to be check C++ with DDD Synchronization is SATISFIED Verify: PASS? Yes No T. Sakunkonchak and M. Fujita

20. Verification Flows(2) Verification of SpecC synchronization Counter-example & Refinement Stage: (on-going work) ‘SVC’ and ‘Program Slicing’ may be considered to help verifying and refining the condition of predicate Ci. If it is not realizable, it means that the result is concrete enough to use as the COUNTER-EXAMPLE. UNSATISFIED when it is realizable, and DON’T KNOW, otherwise. No Refinement SVC Verify Condition on Ci PASS? Program Slicing … Realizable Not realizable NO COUNTER-EXAMPLE DON’T KNOW COUNTER-EXAMPLE T. Sakunkonchak and M. Fujita

21. Content • Introduction • Background • Verification Flows • Experimental Results • Conclusion and Outlook T. Sakunkonchak and M. Fujita

22. Verification Results • Sleeping barber problem barber • barber: finished cutting->call customer • barber: no customer->wait • customer: barber wait->has hair cut • customer: chairs occupied->come again • customer: a chair empty->wait customer empty chair barber chair T. Sakunkonchak and M. Fujita

23. T. Sakunkonchak and M. Fujita

24. All take only a couple of seconds to verify Verification Results T. Sakunkonchak and M. Fujita

25. Content • Introduction • Background • Verification Flows • Experimental Results • Conclusion and Outlook T. Sakunkonchak and M. Fujita

26. Conclusion and Outlook(1) • Verification of sync. in SpecC is introduced • Boolean SpecC & DDD are accompanied for abstraction and helping verification • Current implementation: • Can handle basic SpecC constructs only • Able to get some properties to be checked • Verify for Satisfied or Unsatisfied (no error trace): “Don’t know” is don’t know (no support) T. Sakunkonchak and M. Fujita

27. Conclusion and Outlook(2) • Future plan: • When verification fails, try to give the counter-examples (error trace) • Based on error traces, plan to develop automatic “refinement of abstractions” • Expand capability to support more complex SpecC structure, e.g. loop, functions, recursive T. Sakunkonchak and M. Fujita

28. Future plan (cont.) Verification of SpecC synchronization Counter-example & Refinement Stage: (on-going work) ‘SVC’ and ‘Program Slicing’ may be considered to help verifying and refining the condition of predicate Ci. If it is not realizable, it means that the result is concrete enough to use as the COUNTER-EXAMPLE. UNSATISFIED when it is realizable, and DON’T KNOW, otherwise. Automatic No Refinement SVC Verify Condition on Ci PASS? Program Slicing … Realizable Not realizable NO COUNTER-EXAMPLE DON’T KNOW COUNTER-EXAMPLE T. Sakunkonchak and M. Fujita