1 / 19

Equivalence Checking in C-based System-Level Design by Sequentializing Concurrent Behaviors

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. Outline. Introduction Background Proposed verification method

sheldonc
Download Presentation

Equivalence Checking in C-based System-Level Design by Sequentializing Concurrent Behaviors

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Equivalence Checking in C-based System-Level Design by Sequentializing Concurrent Behaviors T. Sakunkonchak1, T. Matsumoto1, H. Saito2, S. Komatsu1, M. Fujita1 1University of Tokyo 2University of Aizu

  2. Outline • Introduction • Background • Proposed verification method • Experimental results • Conclusion and future directions

  3. 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 Refined Description w/ concurrency SpecC, SystemC Refined Description C Specification C RTL Equivalence checking Equiv… Equivalence checking

  4. Outline • Introduction • Background • SpecC language • Synchronization verification • Equivalence checking by symbolic simulation • Proposed verification method • Experimental results • Conclusion and future directions

  5. A1 void A1() { } void A1() { } A1 B1 void B1() { } void B1() { } B1 void C1() { } void C1() { } C1 C1 void main() { A1(); B1(); C1(); } void main() { par{ A1.main(); B1.main(); } C1.main(); } Background • Our work is based on SpecC, a C-based system-level design language • SpecC supports HW/SW design, concurrency and synchronization notify wait

  6. These equations can be solved with Integer Linear Programming Solver Synchronization in SpecC (cond) • Tas=Tbs, Tae=Tbe • Tas<=T1s<T1e<=T2s<T2e<=Tas • Tbs<=T3s<T3e<=Tbe • T2e<=T3s

  7. 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. 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. Outline • Introduction • Background • Proposed verification method • Synchronization check • Race condition check • Sequentialization • EC by symbolic simulation • Experimental results • Conclusion and future directions

  10. Proposed verification method (1) SpecC Design 1 SpecC Design 2 Fail Sync. & Race Condition Check Sequentialization Terminate With Error Pass Sequential Design 1 Sequential Design 2 Equivalence Check Result: Equiv or Inequiv

  11. 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(BB1starttime) < T(BB2endtime) • Cond2: T(BB1endtime) > T(BB2starttime) (Infeasible) Cond1 is false Cond2 is false BB1 BB2 Dependency check BB1 BB2 timeline BB2 BB1 BB2 BB1 Cond1 is true Cond2 is false Cond1 is false Cond2 is true Cond1 is true Cond2 is true

  12. 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  <EQV> Seq 

  13. are at the same level. We need dependency check. Interleaving can cause different behaviors and it is not possible to generate Seq  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  c1 = a1 + b1; c2 = a2 + b2; notify e1; wait e2; if(d1 != 0) d2 = (c2-c1)/d1; Par 1 d1 = c1 * c2; wait e1; notify e2; if(d1 == 0) ERROR: Par 2 Seq  <NOT EQV> Seq  ??

  14. Outline • Introduction • Background • Proposed verification method • Experimental results • Conclusion and future directions

  15. 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. Experimental results

  17. Outline • Introduction • Background • Proposed verification method • Experimental results • Conclusion and future directions

  18. 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. Thank you Q & A

More Related