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 Flow • Verification Results • Conclusion & Future Work T. SAKUNKONCHAK and M. FUJITA University of Tokyo

3. Introduction • What is SpecC? • Why verification of synchronization? T. SAKUNKONCHAK and M. FUJITA University of Tokyo

4. What is SpecC? • Standard system design language for adoption in industry and academia • Handling system design • specification->implementation, • hardware/software co-design • Build based onANSI-C T. SAKUNKONCHAK and M. FUJITA University of Tokyo

5. Why verification of synchronization? • Concurrency (parallel execution) is commonly exist in system design • A kind of scheduling scheme (synchronization) is succinctly needed • In many cases, sophisticated ones will be come up, takes developers lots of time and efforts to verify T. SAKUNKONCHAK and M. FUJITA University of Tokyo

6. Content • Introduction • Background • Verification Flow • Verification Results • Conclusion & Future Work T. SAKUNKONCHAK and M. FUJITA University of Tokyo

7. Background • Timing diagram of statements execution • Concurrency in SpecC with ‘par’ semantic • Sequentiality of each behavior in ‘par’ • Synchronization semantics ‘notify/wait’ • The use of Difference Decision Diagrams (DDDs) T. SAKUNKONCHAK and M. FUJITA University of Tokyo

8. Timing diagram of statements execution • Tas<=T1s<T1e<=T2s<T2e<=Tae (sequentiality in a) • Tbs<=T3s<T3e<=Tbe (sequentiality in b) • Tas=Tbs, Tae=Tbe (concurrency between a and b) T. SAKUNKONCHAK and M. FUJITA University of Tokyo

9. Synchronization Example Ambiguous results of y causing from x = 10; /*st1*/ x = 20; /*st3*/ y = 20 (always) T. SAKUNKONCHAK and M. FUJITA University of Tokyo

10. Difference Decision Diagrams • Symbolic representation of non-boolean with BDD seem to be less efficient • DDDs represent different constraints,e.g. x-y≤c, x and y are integers, c is constant Represents graph for ¬(x−z<1)Λ(x−y≤0)Λ(y−z≤2) T. SAKUNKONCHAK and M. FUJITA University of Tokyo

11. Content • Introduction • Background • Verification Flow • Verification Results • Conclusion & Future Work T. SAKUNKONCHAK and M. FUJITA University of Tokyo

12. Verification Flow • Goal: check whether the given SpecC codes with ‘par’, ‘notify/wait’ are properly synchronized • Use the idea of ‘Boolean Program’ [Ball and Rajamani] T. SAKUNKONCHAK and M. FUJITA University of Tokyo

13. Boolean Program • is a subset of the original program • obtained by abstracting any conditionals in ‘if’ statements of the original program with a proportional variable, e.g. if(x > y) -> if(c0) • All statements other than ‘notify/wait’, ‘if’ statements are abstracted away T. SAKUNKONCHAK and M. FUJITA University of Tokyo

15. From SpecC to Boolean SpecC • The event manipulation statements are sustained • The conditional or predicates of all ‘if-else’ statements are automatically replaced by dummy variables, e.g. if(x>0)->if(c0), if(x>4)->if(c1) • Other statements are abstracted away by replacing with SKIP (“…”) T. SAKUNKONCHAK and M. FUJITA University of Tokyo

16. From SpecC to Boolean SpecC T. SAKUNKONCHAK and M. FUJITA University of Tokyo

17. Header Branching func. for DDD Declare timing variables Setup DDD graphs Verify From Boolean SpecC to C++ with DDD T. SAKUNKONCHAK and M. FUJITA University of Tokyo

18. Content • Introduction • Background • Verification Flow • Verification Results • Conclusion & Future Work T. SAKUNKONCHAK and M. FUJITA University of Tokyo

19. Verification Results • SpecC->Boolean SpecC->C++ with DDD the process are automatic • Using C++ compiler and DDD package to verify the synchronization of SpecC T. SAKUNKONCHAK and M. FUJITA University of Tokyo

20. Verification Results • SATISFIED • UNSATISFIED • DON’T KNOW In the case of UNSATISFIED, the counter-example is given to track the unsatisfied source T. SAKUNKONCHAK and M. FUJITA University of Tokyo

21. Verification Result • Let see an example There is no chance for the event e to be satisfied if the conditions (x<y) and (x>=y) must be true at the same time T. SAKUNKONCHAK and M. FUJITA University of Tokyo

22. Content • Introduction • Background • Verification Flow • Verification Results • Conclusion & Future Work T. SAKUNKONCHAK and M. FUJITA University of Tokyo

23. Conclusion • The verification of synchronization in SpecC description was proposed • The idea of Boolean program is used to abstract away some details • Collaborate with DDD, we can verify for synchronization in original SpecC • Counter-example and verification of it is considered to be accomplished (on-going work) T. SAKUNKONCHAK and M. FUJITA University of Tokyo

24. Future Work • for users to interactively input constraints • provide counter-example when the synchronization is not satisfied • to be able to automatically generate ‘predicates’ • refining predicates or add constraints on predicates T. SAKUNKONCHAK and M. FUJITA University of Tokyo