1. Computer Design Aided Computer Design Aided Fujita Lab, University of Tokyo Equivalence Checking in C-based System-Level Design by Sequentializing Concurrent Behaviors T. Sakunkonchak 1, T. Matsumoto 1, H. Saito 2, S. Komatsu 1, M. Fujita 1 1 University of Tokyo 2 University of Aizu 2 University of Aizu

2. Fujita Lab, Department of Electronics Engineering, School of Engineering, University of Tokyo Aided Design Aided Computer Design Outline  Introduction  Background  Proposed verification method  Experimental results  Conclusion and future directions

3. Fujita Lab, Department of Electronics Engineering, School of Engineering, University of Tokyo Aided Design Aided Computer Design Introduction (2)  Equivalence checking role in design flow  From specification to RT level, many refinements/modifications are performed  Keeping every incremental refinement equivalent with each other  This work focuses on checking equivalence of concurrent designs  Sequentialize concurrent designs  Equivalence checking the generated sequential ones Specification C Refined Description C Refined Description w/ concurrency SpecC, SystemC RTL Equivalence checking Equiv …

4. Fujita Lab, Department of Electronics Engineering, School of Engineering, University of Tokyo Aided Design Aided Computer Design Outline  Introduction  Background  SpecC language  Synchronization verification  Equivalence checking by symbolic simulation  Proposed verification method  Experimental results  Conclusion and future directions

5. Fujita Lab, Department of Electronics Engineering, School of Engineering, University of Tokyo Aided Design Aided Computer Design Background  Our work is based on SpecC, a C-based system- level design language  SpecC supports HW/SW design, concurrency and synchronization A1B1 void A1() { } void B1() { } void main() { par{ A1.main(); B1.main(); } C1.main(); } void C1() { } C1 void A1() { } void B1() { } void main() { A1(); B1(); C1(); } void C1() { } A1B1C1 notify wait

6. Fujita Lab, Department of Electronics Engineering, School of Engineering, University of Tokyo Aided Design Aided Computer Design These equations can be solved with Integer Linear Programming Solver  Tas=Tbs, Tae=Tbe  Tas<=T1s<T1e<=T2s<T2e<=Tas  Tbs<=T3s<T3e<=Tbe  T2e<=T3s Synchronization in SpecC (cond)

7. Fujita Lab, Department of Electronics Engineering, School of Engineering, University of Tokyo Aided Design Aided Computer Design Background  Synchronization verification [1]  Focus on verifying communication between concurrent processes  Semantics notify/wait/waitfor are for synchronization  Applying software model checking technique  Predicate abstraction  Counterexample-Guided Abstraction Refinement (CEGAR)  Timing properties can be handled by ILP solver  Several formal properties can be checked formally  Deadlock  Race condition [1] T. Sakunkonchak, et al “ Synchronization Verification in System-Level Design Using ILP Solvers, ” In Third ACM-IEEE International Conference on Formal Methods and Models for Codesign (MEMOCODE ’ 2005), July 2005.

8. Fujita Lab, Department of Electronics Engineering, School of Engineering, University of Tokyo Aided Design Aided Computer Design Background  Equivalence checking by symbolic simulation  A well-known formal method for EC  No test vectors, we formally interpret them symbolically  Recently, EC for C programs by utilizing textual difference was proposed in [2]  However, it supports only for sequential designs [2] T. Matsumoto, et al “ An Equivalence Checking Method for C Description based on Symbolic Simulation with Textual Differences, ” IEICE Transaction on Special Section on VLSI and CAD Algorithms, Vol.E88-A, no.12 December 2005.

9. Fujita Lab, Department of Electronics Engineering, School of Engineering, University of Tokyo Aided Design Aided Computer Design Outline  Introduction  Background  Proposed verification method  Synchronization check  Race condition check  Sequentialization  EC by symbolic simulation  Experimental results  Conclusion and future directions

10. Fujita Lab, Department of Electronics Engineering, School of Engineering, University of Tokyo Aided Design Aided Computer Design Proposed verification method (1) SpecC Design 1 SpecC Design 2 Sequential Design 1 Sequential Design 2 Sync. & Race Condition Check Sequentialization Equivalence Check Result: Equiv or Inequiv Pass Fail Terminate With Error

11. Fujita Lab, Department of Electronics Engineering, School of Engineering, University of Tokyo Aided Design Aided Computer Design Proposed verification method (2)  Synchronization check  Applying model checking and solving constraints of Integer Linear Programming (ILP) problem to find if there is any synchronization error, e.g. a process is waiting without being notified (deadlock)  Check whether every pair of notify/wait is eventually communicate  If such an error is found, terminate  Race condition check  Using timing properties  Cond1: T(BB1 starttime ) < T(BB2 endtime )  Cond2: T(BB1 endtime ) > T(BB2 starttime ) BB1 timeline BB2 Cond1 is true Cond2 is false BB1 BB2 Cond1 is false Cond2 is true Cond1 is true Cond2 is true BB1 BB2BB1 BB2 Dependency check Cond1 is false Cond2 is false (Infeasible)

12. Fujita Lab, Department of Electronics Engineering, School of Engineering, University of Tokyo Aided Design Aided Computer Design Example #1  Consider  2 parallel processes  Only two pairs of notify/wait c1 = a1 + b1; c2 = a2 + b2; d1 = c1 * c2; if(d1 != 0) d2 = (c2-c1)/d1; else ERROR: Seq  c1 = a1 + b1; c2 = a2 + b2; notify e1; wait e2; d2 = (c2-c1)/d1; Par 1 wait e1; d1 = c1 * c2; if(d1 != 0) notify e2; else ERROR: Par 2 c1 = a1 + b1; c2 = a2 + b2; d1 = c1 * c2; if(d1 != 0) d2 = (c2-c1)/d1; else ERROR: Seq  Seq  Seq 

13. Fujita Lab, Department of Electronics Engineering, School of Engineering, University of Tokyo Aided Design Aided Computer Design Example #2  Consider  2 parallel processes  Only two pairs of notify/wait c1 = a1 + b1; c2 = a2 + b2; d1 = c1 * c2; if(d1 != 0) d2 = (c2-c1)/d1; else ERROR: Seq  d1 = c1 * c2; wait e1; notify e2; if(d1 == 0) ERROR: Par 2 c1 = a1 + b1; c2 = a2 + b2; notify e1; wait e2; if(d1 != 0) d2 = (c2-c1)/d1; Par 1 Seq  Seq  ?? are at the same level. We need dependency check. Interleaving can cause different behaviors and it is not possible to generate Seq 

14. Fujita Lab, Department of Electronics Engineering, School of Engineering, University of Tokyo Aided Design Aided Computer Design Outline  Introduction  Background  Proposed verification method  Experimental results  Conclusion and future directions

15. Fujita Lab, Department of Electronics Engineering, School of Engineering, University of Tokyo Aided Design Aided Computer Design Experimental results  Since we focus on verifying HW, the designs must not contain  Pointers  Dynamic memory allocation  Recursive functions  Different levels of implementation of  Inverse Discrete Cosine Transform (IDCT)  Vocoder, provided by University of California Irvine (UCI)  Environment  Linux  Pentium4 2.8GHz  2GB RAM

16. Fujita Lab, Department of Electronics Engineering, School of Engineering, University of Tokyo Aided Design Aided Computer Design Experimental results

17. Fujita Lab, Department of Electronics Engineering, School of Engineering, University of Tokyo Aided Design Aided Computer Design Outline  Introduction  Background  Proposed verification method  Experimental results  Conclusion and future directions

18. Fujita Lab, Department of Electronics Engineering, School of Engineering, University of Tokyo Aided Design Aided Computer Design Conclusion  EC by sequentializing concurrent processes  Synchronization check  Race condition check  Sequentialization  EC by symbolic simulation  Even in large design like Vocoder (~10KLOC), EC can be performed  Less communication  Each level is slightly different from each other

19. Computer Design Aided Computer Design Aided Fujita Lab, University of Tokyo Thank you Q & A

20. Fujita Lab, Department of Electronics Engineering, School of Engineering, University of Tokyo Aided Design Aided Computer Design Introduction (1)  In VLSI, design complexity  By Moore’s law, linearly increasing every year  Move to higher levels of abstractions, e.g. system- level, or system-on-chip 1E0 1E1 1E2 1E3 1E4 1E5 1E6 size abstraction accuracy System level Behavioral level Register-transfer level Gate level Transistor level