1 / 48

Formal Verification: Projects & Case Studies

Formal Verification: Projects & Case Studies. S. Ramesh CSE Dept. IIT Bombay. Assertion Checking Environment (ACE). Verification Environment. For industrial software Assertion Checking Environment (ACE) Static Checking of assertions about program units safety properties of program units

jerold
Download Presentation

Formal Verification: Projects & Case Studies

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. Formal Verification:Projects & Case Studies S. Ramesh CSE Dept. IIT Bombay

  2. Assertion Checking Environment(ACE)

  3. Verification Environment • For industrial software • Assertion Checking Environment (ACE) • Static Checking of assertions about program units • safety properties of program units • Safety Subsets of Programming languages • MISRA C • Checking Procedure • Static • Theorem Proving Techniques

  4. Static vs Dynamic checking • Classical Code Verification methods based on Dynamic Testing & Assertion Checking • Effectiveness determined by test cases • more testing, more confidence in Verification • Static Assertion Checking equivalent to exhaustive testing • leads to higher level of assurance of code correctness • Static Assertion Checking not new! • Classical Hoare Logic, Manna’s inductive assertion method • The Central issue • Applying to industrial systems

  5. Formal Verification Methodology

  6. Program Verification Methodology • Important Features • Abstract Models • Formal Specification • Verification Engine

  7. Models • Abstract, High Level descriptions • Modeling an error-prone activity • Major bottleneck in using formal methods • Real Languages pose several problems • Our proposal • Language Subsets • Consistent with Safety considerations • Safe subset of C • MISRA C • Motor Industry Standard • Safe features of C

  8. Specification • Formal Specification using mathematical Logic • Assertions at specific program control points • Conditions satisfied by program variables • Input Constraints or Pre-Conditions • Output Properties or Post-Conditions • Loop Invariants • Compositional Specifications • Individual and independent specification of program units

  9. Verification • Formal Procedures to check correctness of assertions • Theorem Proving Capabilities • STeP • Powerful Theorem Prover from Stanford U. • Strategies for Verification • Programmable using tactics and tacticals • Translation tools • STeP uses SPL models • MISRA C programs need to be translated

  10. MISRA C • Safe subset of C for embedded automotive systems • General C has a lot of problems • complex operator prec. rules, side effecting expressions, run-time checks, pointer arithmetics • MISRA recommends a set of rules • No dependence on operator precedence rules • goto statement shall not be used. • Every case clause terminated with a break statement • A function should have a single point of exit. • Pointer arithmetic not to be used. • Unions shall not be used to access the sub-parts of larger data types..

  11. C2SPL • Important Component of ACE • converts MISRA C program to SPL programs • converts pre, post conditions and assertions into SPEC file in STePformat MISRA C SPL Model Pre-conditions c2spl axioms Assertions/ Properties Post-conditions

  12. Compositional Verification

  13. Example struct RCD3_data { double X, Y; }; void get_inputsXY(struct RCD3_data *final_data) { ret1 = read_from_reg( 1, &InputX ); /*postfunc ( InputX >= 0 /\ InputX <= 4095 ) end*/ change_to_v(InputX, input_src, &tempX ); /*assert !(tempX < 0 \/ tempX > 5) end*/ final_data->X= tempX; convert_to_d(1, tempX, final_data); /*post (#X final_data >= -180) /\ (#X final_data <= 180) end*/ }

  14. SPL Program get_inputsXY :: [ local final_data : RCD3_data local InputX, InputY : WORD … ret1 := read_from_reg(1,InputX); postf1 : skip; prefunc2 : skip; void_var := change_to_v(InputX,input_src,tempX); postf3 : skip; assert4 : skip; #X final_data := tempX; prefunc5 : skip; void_var := convert_to_d(1,tempX,final_data); postf6 : skip; assert7 : skip ]

  15. Specification SPEC AXIOM postf1 : postf1 ==> ( InputX >= 0 /\ InputX <= 4095 ) AXIOM prefunc2 : prefunc2 ==> (input_src = 2) \/ (input_src = 3) PROPERTY postf3 : postf3 ==> ((input_src = 3) /\ (tempX = ((5/4096) * InputX))) \/ ((input_src=2) /\ (tempX = ((5/2048) * InputX - 5.0))) PROPERTY assert4 : assert4 ==> !(tempX < 0 \/ tempX > 5) PROPERTY prefunc5 : prefunc5 ==> (1 = 1) \/ (1 = 2)

  16. Industrial Experience • Verification of many real programs • Safety-critical Applications • Control • Process Interlock • Data Acquisition and Display

  17. Process Interlock Software • tool-generated C code (translation validation) • Logic diagrams to code • Annotations derived from input logic diagrams • 6000 lines of code, 54 functions, • roughly 500 assertions proved

  18. Data acquisition system • Manual development of programs and specifications • 4000 lines of code, 40 functions, • 110 assertions proved • Properties Verified • Range Checks • arithmetic computations, • performance of software controlled actions, • intermediate values of variables etc. • one program required slicing to reduce model size

  19. Verification of Flight Software • LCA Software from ADA, Bangalore • Flight parameter computation unit • Programs with RTOS calls • Verified using ACE • Uncovered important bugs left undetected by traditional means • Designers happy with the outcome

  20. Current Status • I version completely implemented and working • Works only on the sequential segment • II version under development • Automatic error detection • Concurrency • Range checking

  21. Verification Environment for Distributed Control Applications

  22. Salient Features: • No temporal logics • No coding • Interactive and guided simulation • Automatic error trace simulation CRSM : A pictorial language for modeling • Concurrent behaviour • Hierarchical structures • Interprocess communication Editor Verifier CRSM SPIN Simulator

  23. Bank Teller cardValid/pin GetPin PIN?q Idle pinCode/ !x/keepCard (y!=valid)/ PIN!p Auth!y (y==valid)/ Auth?x exit/ ejectCard Amt?d x/enterAmount GetAmt amtChk!b amount/ Amt!c !a/ejectCard a/delMoney.ejectCard amtChk?a Example : ATM

  24. Editor

  25. Simulator

  26. Verification Engine • Observer-based verification • Observer also another CRSM component • Distributed Observers • Model + Observers translated to Promela • Verification using SPIN • No temporal logic specification

  27. Efficient Verification • I version of the tool is ready • II version under development • Efficient Verification • Refinement Based verification • Program slicing techniques • Compositional Verification

  28. Printer Processor Memory [turn==1]/ [turn==1]/ Idle Idle C1! C2! turn turn enterB / enterA / C2? C1? turnA turnA [turnnA==1]/ C3? C4? turn turn C4! C3! turnA turnA C5? C6? turn turn Critical Section Critical Section Property leaveB / leaveA / (in_C3.in_C4) Idle BUG C6! C5! turnA turnA Example: Mutual Exclusion

  29. Error Trace START Printer enterB, Memory Printer, Printer , Memory Printer leaveB, Printer, Memory Printer enterB, Processor enterA Processor, Memory Memory, Memory in_C3 in_C4 END

  30. PCI Verification

  31. PCI Protocol Verification CPU Sound Card HDD controller Common bus arch. for all PCI compatible devices PCI Local Bus Display Memory

  32. PCI Protocol

  33. Methodology Resources Verification Effort PCI Protocol Specification FQL Specification VHDL Monitors VHDL Implementation Formalcheck Verification

  34. Verification and Results Iterative Seeding Monitor Style Environment Modelling Full Module PCI Code Slave PCI Code PCI Core Arbiter Monitor Flags • FQL properties from CTL spec • Code Compilation • Constraint identification • Query compilation • 65% of specification satisfied • Environmental conditions dynamically identified • Attempted different verification styles

  35. FormalCheck • Commercial Model Checker (Cadence Toolset) • Takes VHDL and Verilog as inputs. • Properties specified in FormalCheck Query Language (FQL).

  36. Cache Controller Verification

  37. Cache Controller Verification Aim: Memory SubSystem C P U L1D-CTRL L1I L2 L1I-CTRL L1D Study the controller Formal Specification Formal Verification using Cadence FormalCheck XDMA Test Logic I/O A new audio signal processor chip that has been deployed by JVC ..only days ago, was realised by the Bangalore R&D unit. -- The Hindu, Oct 4th 2002

  38. Methodology System Study Issues of Interest Study of architecture Functional behaviour Timing behaviour Protocols involved • No stall for cache miss • Servicing all requests • Cache coherency • Providing Valid data Formal Specification Verification LTL formulae from Spec Model CPU behaviour Environmental constraints Probe design heirarchy FQL specification Precompile libraries Compile design Create Queries Verification and debugging

  39. Results • Verified 12 of 13 properties • Discovered design constructs not supported • Identified incompletely understood design behavior

  40. FormalCheck Home page: http://www.cadence.com/datasheets/formalcheck.html • Commercial model-checking tool (Cadence), based upon COSPAN (Bell Labs.) • Modeling languages: synthesizable subsets of Verilog and VHDL • Specification Language: FQL – FormalCheck Query language (A variant of LTL, Syntax same as HDL) • Verification Approach: Automata Containment • Powerful compositional reduction strategies • Clever representation for specifications

  41. System Properties Block Constraints = Target Blocks Interface System Blocks = Block Properties System Constraints FormalCheck

  42. Chip, Blocks, IP Models In Verilog or VHDL Gates Autorestrict RTL Probabilistic Template-Based Query Inputs Large Model Query Capture Formal Model Early Model Query-Specific Reduction Results & Error Traces Query Template Library Results Display Inputs Outputs FormalCheck Architecture

  43. Example Specifications • after { Req == 1 } - eventually { Ack == 1 } • after { Timer.Start == 1 } always { Timer.counting == 1 } unless { Timer.Restart == 1 } - After timer starts, counting is on unless it is restarted

  44. Example contd. • never { TAP.State == TRST } within -delay 0 -duration 6 { Clock.rising } • States that it is not possible to reach the TRST state in 5 steps. • after { Counter.bit[0] == 1 } eventually { Counter.bit[0] == 0 } within -delay 0 -duration 2 {Clock.rising }

  45. FQL Formulae • after( ) always/never( ) [unless[ after]( )] [within(m,n)] • always/never( ) [unless[ after]( )] • after( ) eventually( ) [unless( )] [within(m,n)] • eventually( ) [unless( )] • after( ) eventually always( ) [unless( )] [within(m,n)] • eventually always( ) [unless( )] • if repeatedly( ) eventually always( )

More Related