A Framework on Synchronization Verification in System-Level Design

A Framework on Synchronization Verification in System-Level Design Thanyapat Sakunkonchak Satoshi Komatsu Masahiro Fujita Fujita Laboratory University of Tokyo

Contents • Introduction • System-level design VS Verification • Counterexample-guided abstraction refinement (CEGAR) • Why synchronization verification? • Verification flow • Preliminary experimental results • Summary & Future direction

System-Level Design & Verification System-Level 30 minutes delay Modify source & re-compile System synthesis High-level synthesis 3 days delay Modify RTL & re-synthesis RTL Logic synthesis Layout synthesis 3 weeks delay Re-layout Layout Cost due to the delay/late time-to-market Revenue loss Bugs fix time Recover as many bugs as possible in the earlier stages is necessary  Verification in system-level design

Basic Idea • To increase productivity and fast prototype • Apply formal verification at system-level • Counter-Example Guided Abstraction Refinement (CEGAR) paradigm • Apply abstraction to the design • Verify the abstracted design • Property hold • Property does not hold + abstract counter-example • Abstraction refinement: validate the abstract counter-example • Valid: the real counter-example is given • Invalid: refine abstraction

Formal Verification with Abstraction Refinement (CEGAR) The abstract design’s size is enough to be handled Property Model checker Design Abstract Design Widely used verification philosophy: Counter-Example Guided Abstraction Refinement (CEGAR) + abstract counterexample Refine Check abstract counterexample + real counterexample

Why synchronization verification? • Usually the abstracted design is still too large • There are many parallel processes in system-level design • To operate properly, those parallel processes must be properly synchronized • Targeting only synchronization verification, the problem size can be significantly reduced

A void A() { } void A() { } A B void B() { } void B() { } B void C() { } void C() { } C C void main() { A(); B(); C(); } void main() { par{ A.main(); B.main(); } C.main(); } Concurrency: Par Statement in SpecC C Language SpecC Language

void A() { } Process B stops and wait until e1 is notified notify e1; wait e2; A B void B() { } wait e1 notify e1 wait e1; notify e2; Process A stops and wait until e2 is notified wait e2 B resumes notify e2 void main() { par { A.main(); B.main(); } } A resumes Synchronization in SpecC • Add notify/wait of event e for sync. • ‘wait’ will stop process until it is ‘notify’

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

O riginal SpecC program behavior A(out event e, inout int x, inout int y) { void main() { if(x > 0) { notify e; y = x – 1; Sync. p rope rty } if(y < 3) (Deadlock) : : B oolean SpecC 1 2 behavior A( ) { void main() { if(C0) { Mathematical model notify e; S et of predicates P redicate abstraction ... Equality/Inequality } if(C1) : : 3 Property proved MILP Solver (correct result) 5 4 Abstract error trace Predicate discovery Reasoning tool C oncrete counter - example Synchronization verification

Synchronization property • Synchronization is completed if ‘wait’ was notified • A deadlock occurs once ‘wait’ is reached but ‘notify’ is not Process A Process B notify wait Deadlock in B

/* Barber */ void main() { while(1) { if (!waitCustomer) DayDreaming(); else { if (chairOccupied) { notify call; chairOccupied = false; } else { KeepCutting(); chairOccupied = true; } }; /* Barber */ void main() { while(a0) { if (a1) ... else { if (a2) { notify call; ... } else { ... ... } }; /* Barber */ void main() { while(a0) { if (a1) ... else { if (a2) { notify call; ... } else { ... ... } }; /* Customer */ void main() { while(1) { if (!waitCustomer) waitCustomer = true; else { waitCustomer = false; if (!chairOccupied) wait call; } }; /* Customer */ void main() { while(b0) { if (b1) ... else { ... if (b2) wait call; } }; /* Customer */ void main() { while(b0) { if (a1) a1_1 = true; else { a1_1 = false; if (b2) wait call; } }; ‘notify’ is not reached: ‘wait’ is reached Check path feasibility Check path feasibility a1 = true & b1 = false & b2 = true a1 = false & a2 = false & b1 = false & b2 = true !waitCustomer = true & !waitCustomer = false & !chairOccupied = true !waitCustomer = false & chairOccupied = false & !waitCustomer = false & !chairOccupied = true NOT FEASIBLE FEASIBLE Refine#1 Refine#0

Verification conditions • Real applications are verified • Focusing only synchronization (notify/wait under par{ }), problem size can be significantly reduced • Running on linux machine, P4 1.7GHz & 512 MB RAM, deadlock can be detected within few minutes

Preliminary experimental result • Check all designs with properties “there is no deadlock” • There is no such a case where ‘wait’ is executed while ‘notify’ is not • Property1,2,3 are the different pairs of notify/wait • Simulation results • All properties hold • No deadlock • Abstraction refinement is not conducted in this experiments

Summary & Future Direction • A framework for synchronization verification of SpecC was described • Abstraction/abstraction refinement algorithm was presented • Abstraction • Insertion of deadlock property • Verification • Abstraction refinement • Now targeting only for synchronization property, but we can further extend to verify other properties, e.g. safety • Implementation of abstraction refinement

A Framework on Synchronization Verification in System-Level Design