190 likes | 203 Views
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
E N D
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
Outline • Introduction • Background • Proposed verification method • Experimental results • Conclusion and future directions
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
Outline • Introduction • Background • SpecC language • Synchronization verification • Equivalence checking by symbolic simulation • Proposed verification method • Experimental results • Conclusion and future directions
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
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
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.
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.
Outline • Introduction • Background • Proposed verification method • Synchronization check • Race condition check • Sequentialization • EC by symbolic simulation • Experimental results • Conclusion and future directions
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
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
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
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 ??
Outline • Introduction • Background • Proposed verification method • Experimental results • Conclusion and future directions
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
Outline • Introduction • Background • Proposed verification method • Experimental results • Conclusion and future directions
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
Thank you Q & A