370 likes | 381 Views
Formal Verification of SpecC Programs using Predicate Abstraction. Himanshu Jain Daniel Kroening Edmund Clarke Carnegie Mellon University. System. Behavioral. Structural. …………. Introduction. System on chip design Increase in complexity. Number of components. Level. 10 0. 10 3.
E N D
Formal Verification ofSpecC Programs usingPredicate Abstraction Himanshu Jain Daniel Kroening Edmund Clarke Carnegie Mellon University
System Behavioral Structural ………… Introduction • System on chip design • Increase in complexity Number of components Level 100 103 Abstraction 105 Gate level (netlists) 107
Introduction • Emergence of system design languages • HardwareC, SpecC, Handel-C, and SystemC • Based on C / C++ • Allows joint modeling of both hardware and software components of a system • Support for bit vectors, concurrency, synchronization, exception handling
Verification support • Current model-checkers used in hardware industry work at netlist or RTL level • Languages like SpecC are more closer to concurrent software • Verification tools must reason about: • Programming languages constructs • Concurrency • Pointers, Objects • Bit vector operations like concatenation, extraction
Talk outline • Introduction and motivation • SpecC • Our approach • Abstraction • Handling of concurrency constructs • Model checking and refinement • Experimental results • Conclusion
SpecC Behaviors Event Declaration event e; int x; behavior A () { void main() { x = 42; notify e; } }; behavior B () { void main() { wait e; printf("Got %d\n", x); } }; behavior Main { A a1(); B b1(); int main () { par { a1.main(); b1.main(); } } }; Generate Event Wait for Event Object Instances parallel execution
SpecC • Asynchronous interleaving semantics • No atomicity is guaranteed • SpecC provides multiple synchronization constructs
More SpecC operators Bit vectors bit[7:0] a; unsigned bit[16] b; bit[31:0] SpecExample (bit[32] y) { bit [31:0] r; a = 11001110b; b[7:0] = a; b = a @ y[7:0]; r = b@b; return r; } Extraction Concatenation
Talk outline • Introduction and motivation • SpecC • Our approach • Abstraction • Handling of concurrency constructs • Model checking and refinement • Experimental results • Conclusion
Abstraction Refinement Loop Initial Abstraction Verification No erroror bug found SpecCProgram ModelChecker Concurrent BooleanProgram Property holds Refinement Simulator Simulation sucessful Abstraction refinement Bug found [Kurshan et al. ’93] [Clarke et al. ’00] Spurious counterexample [Ball, Rajamani ’00]
Example for Predicate Abstraction void main(){ bool p1, p2; p1=TRUE; p2=TRUE; while(p2) { p1=p1?FALSE:nondet(); p2=!p2; } } behaviormain() { int i; i=0; while(even(i)) i++; } + = p1 i=0 p2 even(i) SpecC program Predicates Boolean program [Graf, Saidi ’97] [Ball, Rajamani ’00]
Predicate Abstraction for SpecC • Use predicate abstraction to prove assertions or safety properties • Successfully applied for verification of C programs (SLAM, MAGIC, BLAST) • Predicate abstraction produces an over-approximation
Our approach • Abstract each thread seperately (we assume no recursion) • Let the modelchecker handle the interleavings between various abstract threads Tn T1 || T2 || || || || B1 B2 || Bn
Abstracting a single thread • Identify basic blocks and abstract each block separately a = a + b[2:0]; i = 0; while (i < 10) { wait e1; x[2:0] = y; i++; notify e2; } a = a + b[2:0]; i = 0; x[2:0] = y; i++;
Abstracting a single thread • Wait and notify translated to the abstract model directly a = a + b[2:0]; i = 0; while (i < 10) { wait e1; x[2:0] = y; i++; notify e2; } wait notify
Problems with existing tools • Large number of expensive theorem prover calls – slow (2n£ 2n ) • Over-approximation yields additional,unnecessary spurious counterexamples • Theorem prover works on natural numbers, but SpecC uses bit-vectors false positives • Most theorem provers support only few operators(+, -, <, ≤, …), no bitwise operator
Abstraction of a basic block • Use a SAT solver for computing abstraction of a basic block • Successfully used for abstraction of C programs (Clarke et al, 2003) • Create a SAT instance which relates initial value of predicates, basic block, and the values of predicates after the execution of basic block
Computing abstract transitions Abstraction of a basic block + +
Abstract transitions Equation passed to the SAT solver (!p1 & !p1 & !p1 & !p’1 & !p’2 & p’3) 000 ) 001 (!p1 & !p2 & p3 & p’1 & !p’2 & !p’3) 001 ) 100 …………………….
Abstraction of a basic block Use SAT solver! • Generate query equation withpredicates as free variables • Transform equation into CNF usingBit Vector LogicOne satisfying assignment matchesone abstract transition • Obtain all satisfying assignments= most precise abstract transition relation
Abstraction of a basic block Use SAT solver! • Generate query equation withpredicates as free variables • Transform equation into CNF usingBit Vector LogicOne satisfying assignment matchesone abstract transition • Obtain all satisfying assignments= most precise abstract transition relation
Advantages of using SAT Use SAT solver! • Generate query equation withpredicates as free variables • Transform equation into CNF usingBit Vector LogicOne satisfying assignment matchesone abstract transition • Obtain all satisfying assignments= most precise abstract transition relation This solves two problems: • Now can do all SpecC operators, including *, /, %, <<, @, [ x:y] etc. • Sound with respect to overflow No moreunnecessary spurious counterexamples!
Talk outline • Introduction and motivation • SpecC • Our approach • Abstraction • Handling of concurrency constructs • Model checking and refinement • Experimental results • Conclusion
Handling concurrency constructs t1{ 1: wait start1; ………….. notify done1; goto 1; } • Replace the par statements using wait and notify. t1{ …….. } t2 { ……. } main() { notify start1, start2; wait done1 & done2; } main() { par{ t1; t2} }
Wait and Notify • Introduce a boolean variable for each thread and event pair t1 { 1: wait e; } t2 { 1: notify e; }
Wait and Notify boolean e1, e2; t1 { (e1 == 1) ) e1 = 0; } t1 { 1: wait e; } t2 { 1: notify e; } t2 { e1 ,e2 := (1,1); }
Abstraction Refinement Loop Initial Abstraction Verification No erroror bug found SpecCProgram ModelChecker Concurrent BooleanProgram Property holds Refinement Simulator Simulation sucessful Abstraction refinement Bug found Spurious counterexample
Abstraction Refinement Loop Initial Abstraction Verification No erroror bug found SpecCProgram ModelChecker Concurrent BooleanProgram Property holds Counterexample Refinement Simulator Simulation sucessful Abstraction refinement Bug found Spurious counterexample
Simulating the Counterexample • Check if the abstract counterexample exists in the concrete model • Thread interleavings : • T1[1] T2[1] T1[2] T1[3] ……… • Simulation corresponds to a series of Bounded Model Checking instances
Abstraction Refinement Loop Initial Abstraction Verification No erroror bug found ActualProgram ModelChecker Concurrent BooleanProgram Property holds Refinement Simulator Simulation sucessful Abstraction refinement Bug found Spurious counterexample
Talk outline • Introduction and motivation • SpecC • Our approach • Abstraction • Handling of concurrency constructs • Model checking and refinement • Experimental results • Conclusion
Experimental Results • Property: Relation between data put in pipeline and data coming out of pipeline • Each stage is a thread • Runtime dominated by NuSMV
Experimental Results • PRED: artificial benchmark that requires a known number of predicates • ALUPIPE: Arithmetic properties of pipelined ALU
Summary of Results • Concurrent system-level models can be abstracted in a thread-modular way • In contrast to sequential models,the verification of the abstract model is the bottleneck
Future Work • Use partial order reduction • Object oriented languages: System-C based on C++ • Better decision procedures for large programs • Translation to arithmetic circuits can sometimes be expensive
References • SpecC Language tutorial. Available at http://www.ics.uci.edu/~specc/ • Predicate Abstraction of ANSI-C Programs using SAT. Formal Methods in System Design. Edmund Clarke, Daniel Kroening, Natasha Sharygina, Karen Yorav.