Synchronization Verification in System-Level Design with ILP Solvers

Synchronization Verification in System-Level Design with ILP Solvers Thanyapat Sakunkonchak Satoshi Komatsu Masahiro Fujita VLSI Design and Education Center (VDEC)

Contents • Introduction • System-level design VS Verification • SpecC language & concurrency • Related work & verification flow • Verification based on equalities/inequalities interpretation • Preliminary experimental results • Summary & Future direction MEMOCODE'05

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 MEMOCODE'05

IF FSM Control Pipeline IP Netlist RAM State PC IR Control Datapath IF FSM Memory Mem RF Processors IPs Memories Busses Registers ALUs/FUs Memories Gates State State ALU Functional specification + constraints RTL/IS Implementation + results Design methodology: From system-level design • Requirement analysis • Functional specification to architecture and then to implementation • Behavior to structure • Appropriately introduce “analog devices” for higher performance Requirement analysis Analog parts µProcessor IP Memory Comp. Interface Interface Bus Interface Interface Analog parts Memory Custom HW System architecture + estimates MEMOCODE'05

Proposed design methodology:From verification point of view • SoC System-level design/verification Equivalence Checking Specification (C language) Refined C Descriptions Design descriptions w/ concurrency (SpecC) Use behavior synthesis RTL descriptions Pointers & recursive functions are not considered in the HW design Synchronization Verification • Many designers • Many modifica- • tions in designs ・Highly possible for bugs to be inserted・High cost for fixing bugs in lower level Efficient formal verification methods are necessary MEMOCODE'05

Concurrency or parallelism SpecC language • System-level specification/design language based on C • Supports System-on-a-Chip (SoC) design • Can describe both hardware and software seamlessly • SpecC  C + [par{ } + notify + wait + waitfor] semantics • Notes: • There are various of C-based verification researches & tools • (SLAM, BLAST, MAGIC) • Since it’s C-based  sequential • We apply the verification for C + “parallel behaviors” MEMOCODE'05

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 MEMOCODE'05

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’ MEMOCODE'05

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 MEMOCODE'05

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 MEMOCODE'05

Why synchronization verification? • Checking property, e.g. “● will be executed after●,” in parallel processes is difficult • It is easier once the execution order is guaranteed (correctly sync.) • Now targeting only “synchronization verification” • Other properties, e.g. safety, can also be verified Process A Process B Process C N W N W N ? W N W MEMOCODE'05

Related work • Predicate abstraction • Graf & Saidi ’97 • Abstraction refinement • Kurshan ’93 • Clarke et al ’00 • Ball & Rajamani ’00 • C-based software verification • SLAM • MAGIC • BLAST MEMOCODE'05

Related work • SpecC-based verification • Difference Decision Diagrams (DDDs) [Sakunkonchak & Fujita ’02] • SAT-based predicate abstraction [Jain et al ’04] MEMOCODE'05

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 MEMOCODE'05

Synchronization verification MEMOCODE'05

while (1) { while (1) { if stmnt switch stmnt if stmnt switch stmnt wait e1 notify e1 notify e2 wait e2 } } Verification of 2 parallel behaviors (1/3) • Inside ‘while’ loops which contain notify/wait, we eliminate the loop • Verification is fast but limit to concept ‘synchronization must (not) occur in the same iteration while (1) { while (1) { if stmnt switch stmnt if stmnt switch stmnt wait e1 notify e1 notify e2 wait e2 } } MEMOCODE'05

while (1) { while (1) { while (1) { while (1) { while (1) { if stmnt switch stmnt if stmnt switch stmnt if stmnt switch stmnt if stmnt switch stmnt if stmnt switch stmnt wait e1 wait e1 wait e1 notify e1 notify e1 notify e2 notify e2 notify e2 wait e2 wait e2 } } } } } Verification of 2 parallel behaviors (2/3) • N and M times unrolling • Synchronization can occur in different iterations while (1) { while (1) { if stmnt switch stmnt if stmnt switch stmnt wait e1 notify e1 notify e2 wait e2 } } MEMOCODE'05

Verification of 2 parallel behaviors (3/3) • Translate ‘while’ loop into FSMs (can apply to nested loops) • Ordinary model checkers can be applied but the computation is expensive while (1) { while (1) { if stmnt switch stmnt if stmnt switch stmnt switch stmnt if stmnt wait e1 notify e1 wait e1 notify e1 notify e2 switch stmnt notify e2 wait e2 wait e2 if stmnt } } MEMOCODE'05

Example (1) • Par behavior1 {notify e1; a; wait e2; b} behavior2 {wait e1; c; notify e2; d} • e1 < a, a < e2, e2 < b, e1 < c, c < e2, e2 < d • Are there exist a, b, c, d, e1, e2 > 0 ? Yes → the result is correct • Par behavior1 {wait e2; a; notify e1; b} behavior2 {wait e1; c; notify e2; d} • e2 < a, a < e1, e2 < b, e1 < c, c < e2, e2 < d • Are there a, b, c, d, e1, e2 > 0 ? No, due to conditions a < c and c < a → Deadlock notify e1 a wait e2 b wait e1 c notify e2 d wait e2 a notify e1 b wait e1 c notify e2 d MEMOCODE'05

Example (2) • Par behavior1 {notify e1; a; waitfor(10); wait e2; b} behavior2 {wait e1; waitfor(10); c; notify e2; d} • e1 < a, a + 10 < e2, e2 < b, e1 + 10 < c, c < e2, e2 < d • Are there exist a, b, c, d, e1, e2 > 0 ? Yes → the result is correct • Can we tell that b < c ? No → actually c < b • Par behavior1 {notify e1; a; wait e2; waitfor(10); b} behavior2 {wait e1; waitfor(10); c; notify e2; d} • e1 < a, a < e2, e2 + 10 < b, e1 + 10 < c, c < e2, e2 < d • Are there exist a, b, c, d, e1, e2 > 0 ? Yes → the result is correct • Can we tell that b – e1 < 20 ? No notify e1 a 　ｗaitfor(10) wait e2 b wait e1 　ｗaitfor(10) c notify e2 d notify e1 a wait e2 　ｗaitfor(10) b wait e1 　ｗaitfor(10) c notify e2 d MEMOCODE'05

Example (3) Predicate: P1 => (x == y) A < B < w_e2; P1 -> (A < n_e1 < B); C < D < n_e2; P1 -> (C < w_e1 < D); P1 -> (n_e1 < w_e1); n_e2 < w_e2; Q: This design is OK? A: Yes Q: A < D? A: Not necessary Q: (x == y) & (A < D)? A: Yes par A; if (x==y) notify e1; B; wait e2; C; if (x==y) wait e1; D; notify e2; par Predicate: P1 => (x == y); P2 => (x < y) A < B < w_e2; P1 -> (A < n_e1 < B); C < D < n_e2; P2 -> (C < w_e1 < D); (P1 & P2) -> (n_e1 < w_e1); n_e2 < w_e2; Q: This design is OK? A: No Counterexample: P1 & ~P2 A; if (x==y) notify e1; B; wait e2; C; if (x>y) wait e1; D; notify e2; par Predicate: P1 => (x == y) A < W4_x; W4_x + 10 < B < w_e2; P1 -> (A < n_e1 < W4_x); C < W4_y; W4_y + 10 < D < n_e2; P2 -> (C < w_e1 < W4_y); P1 -> (n_e1 < w_e1); n_e2 < w_e2; Q: This design is OK? A: No Q: A < D? A: Not necessary Q: (x == y) & (A < D)? A: Yes A; if (x==y) notify e1; waitfor(10); B; wait e2; C; if (x==y) wait e1; waitfor(10); D; notify e2; MEMOCODE'05

Synchronization verification MEMOCODE'05

Synchronization verification • Boolean SpecC is automatically generated • Expression statements other than synchronization ones (notify/wait/waitfor) are abstracted away • For conditional statements, the guarded predicates are replaced with boolean (or control) variables • Abstraction refinement • Analyze the false counterexample path according to the control variables • Synchronization property • Synchronization is completed if ‘wait’ was notified • A deadlock occurs once ‘wait’ is reached but ‘notify’ is not MEMOCODE'05

Verification conditions • Real applications are verified • Focusing only synchronization (notify/wait/waitfor 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 MEMOCODE'05

Experimental results • The designs were prepared such that they do not contain the followings • Recursive functions • Pointers • Synchronization of multiple events MEMOCODE'05

Summary • Synchronization verification of SpecC based on equalities/inequalities interpretation was described • Abstraction • Verification • Abstraction refinement • This work illustrates the verification based on synchronization property, but other properties, e.g. safety, can also be verified MEMOCODE'05

Future directions • Once the synchronization is guaranteed (for some parallel behaviors), can we generate an equivalent sequential behavior? This is one of the important issues in system-level design, “the equivalence checking” MEMOCODE'05

Thank You MEMOCODE'05

Synchronization Verification in System-Level Design with ILP Solvers