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. FDL'02 Sep.26T. Sakunkonchak and M. Fujita2Content Introduction Introduction Background Background Verification Flows Verification Flows Experimental Results Experimental Results Conclusion and Outlook Conclusion and Outlook

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

4. FDL'02 Sep.26T. Sakunkonchak and M. Fujita4Content Introduction Introduction Background Background Verification Flows Verification Flows Experimental Results Experimental Results Conclusion and Outlook Conclusion and Outlook

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

6. FDL'02 Sep.26T. Sakunkonchak and M. Fujita6 Synchronization in SpecC Ambiguous results on y causing from x = 10; /*st1*/ x = 20; /*st3*/ y = 20 (always)

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

8. FDL'02 Sep.26T. Sakunkonchak and M. Fujita8 Synchronization in SpecC (cont.) y = 20 (always) Tas=Tbs, Tae=Tbe Tas=Tbs, Tae=Tbe Tas<=T1s<T1e<=T2s<T2e<=Tas Tas<=T1s<T1e<=T2s<T2e<=Tas Tbs<=T3s<T3e<=Tbe Tbs<=T3s<T3e<=Tbe T2e<=T3s T2e<=T3s

9. FDL'02 Sep.26T. Sakunkonchak and M. Fujita9 The verification problem Given SpecC programs, check if specific ordering of executions are guaranteed or not 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 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

10. FDL'02 Sep.26T. Sakunkonchak and M. Fujita10 Boolean Program Proposed by Ball and Rajamani under SLAM project at Microsoft Research 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 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: BP abstracts the original program: if properties on BP hold, so as original one

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

12. FDL'02 Sep.26T. Sakunkonchak and M. Fujita12 Difference Decision Diagrams ( DDD ) Introduce by M Φ ller, et al. Introduce by M Φ ller, et al. Symbolic representation of ‘non-boolean’, such as inequality: less efficient if using BDD 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 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)

13. FDL'02 Sep.26T. Sakunkonchak and M. Fujita13Content Introduction Introduction Background Background Verification Flows Verification Flows Experimental Results Experimental Results Conclusion and Outlook Conclusion and Outlook

14. FDL'02 Sep.26T. Sakunkonchak and M. Fujita14 Verification Flows Goals: Goals: Check whether given SpecC codes (with ‘par’, ‘notify/wait’) are properly synchronized 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) If checking fails, counter-examples should be generated (trace to source of errors) Based on: Based on: Boolean SpecC, DDD, SVC, Program Slicing,... Boolean SpecC, DDD, SVC, Program Slicing,...

15. FDL'02 Sep.26T. Sakunkonchak and M. Fujita15 Verification Flows(1) Yes SpecC Source Program Boolean SpecC C++ with DDD Parsed & Translated (1) Parsed & Translated (2) Verify: PASS? Users add some properties to be check Synchronization is SATISFIED 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. No

16. FDL'02 Sep.26T. Sakunkonchak and M. Fujita16

17. FDL'02 Sep.26T. Sakunkonchak and M. Fujita17 Verification Flows(1) Yes SpecC Source Program Boolean SpecC C++ with DDD Parsed & Translated (1) Parsed & Translated (2) Verify: PASS? Users add some properties to be check Synchronization is SATISFIED 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. No

18. FDL'02 Sep.26T. Sakunkonchak and M. Fujita18 From Boolean SpecC to C++ with DDD Header Branching func. for DDD Declare timing variables Setup DDD graphs Verify

19. FDL'02 Sep.26T. Sakunkonchak and M. Fujita19 Verification Flows(1) Yes SpecC Source Program Boolean SpecC C++ with DDD Parsed & Translated (1) Parsed & Translated (2) Verify: PASS? Users add some properties to be check Synchronization is SATISFIED 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. No

20. FDL'02 Sep.26T. Sakunkonchak and M. Fujita20 Verification Flows(2) No Not realizableRealizable Verify Condition on Ci PASS? Refinement Program Slicing SVC NO COUNTER-EXAMPLEDON’T KNOWCOUNTER-EXAMPLE 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. …

21. FDL'02 Sep.26T. Sakunkonchak and M. Fujita21Content Introduction Introduction Background Background Verification Flows Verification Flows Experimental Results Experimental Results Conclusion and Outlook Conclusion and Outlook

22. FDL'02 Sep.26T. Sakunkonchak and M. Fujita22 Verification Results Sleeping barber problem Sleeping barber problem barber customer empty chair barber chair 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

23. FDL'02 Sep.26T. Sakunkonchak and M. Fujita23

24. FDL'02 Sep.26T. Sakunkonchak and M. Fujita24 Verification Results All take only a couple of seconds to verify All take only a couple of seconds to verify

25. FDL'02 Sep.26T. Sakunkonchak and M. Fujita25Content Introduction Introduction Background Background Verification Flows Verification Flows Experimental Results Experimental Results Conclusion and Outlook Conclusion and Outlook

26. FDL'02 Sep.26T. Sakunkonchak and M. Fujita26 Conclusion and Outlook(1) Verification of sync. in SpecC is introduced Verification of sync. in SpecC is introduced Boolean SpecC & DDD are accompanied for abstraction and helping verification Boolean SpecC & DDD are accompanied for abstraction and helping verification Current implementation: Current implementation: Can handle basic SpecC constructs only Can handle basic SpecC constructs only Able to get some properties to be checked 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) Verify for Satisfied or Unsatisfied (no error trace): “Don’t know” is don’t know (no support)

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

28. FDL'02 Sep.26T. Sakunkonchak and M. Fujita28 Future plan (cont.) No Not realizableRealizable Verify Condition on Ci PASS? Refinement Program Slicing SVC NO COUNTER-EXAMPLEDON’T KNOWCOUNTER-EXAMPLE 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