Formal Verification: Projects

1
Formal VerificationProjects 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, Mannas 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
(No Transcript)
11
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..

12
C2SPL

• Important Component of ACE
• converts MISRA C program to SPL programs
• converts pre, post conditions and assertions into
  SPEC file in STeP format

• MISRA C

SPL Model
Pre-conditions
c2spl
axioms
Assertions/
Properties
Post-conditions
13
Compositional Verification

14
Example

• struct RCD3_data double X, Y
• void get_inputsXY(struct RCD3_data final_data)
• ret1 read_from_reg(
  1, InputX )
• /postfunc ( InputX gt 0 /\ InputX lt
  4095 ) end/
• change_to_v(InputX, input_src, tempX )
• /assert !(tempX lt 0 \/ tempX gt 5) end/
• final_data-gtX tempX
  convert_to_d(1, tempX, final_data)
• /post (X final_data gt -180) /\ (X
  final_data lt 180) end/

15
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,temp
  X)
• postf3 skip
• assert4 skip
• X final_data tempX
• prefunc5 skip
• void_var convert_to_d(1,tempX,final_data)
  
• postf6 skip
• assert7 skip

16
Specification

• SPEC
• AXIOM postf1
• postf1 gt ( InputX gt 0 /\ InputX lt 4095 )
• AXIOM prefunc2
• prefunc2 gt (input_src 2) \/ (input_src
  3)
• PROPERTY postf3
• postf3 gt ((input_src 3) /\ (tempX
  ((5/4096) InputX)))
• \/ ((input_src2) /\ (tempX
  ((5/2048) InputX - 5.0)))
• PROPERTY assert4
• assert4 gt !(tempX lt 0 \/ tempX gt 5)
• PROPERTY prefunc5
• prefunc5 gt (1 1) \/ (1 2)

17
Industrial Experience

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

18
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

19
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

20
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

21
Current Status

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

22
Verification Environment for Distributed Control
Applications
23

• Salient Features
• No temporal logics
• No coding
• Interactive and guided simulation
• Automatic error trace simulation

Editor
Verifier
CRSM
SPIN

• CRSM A pictorial language for modeling
• Concurrent behaviour
• Hierarchical structures
• Interprocess communication

Simulator
24
Example ATM
25
(No Transcript)
26
Editor
27
Simulator
28
Verification Engine

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

29
Efficient Verification

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

30
Example Mutual Exclusion
31
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

32
PCI Verification
33
PCI Protocol Verification
CPU
HDD controller
Sound Card
Common bus arch. for all PCI compatible devices
PCI Local Bus
Display
Memory
34
PCI Protocol
35
Methodology
Resources
Verification Effort
PCI Protocol Specification
FQL Specification
VHDL Monitors
Formalcheck Verification
VHDL Implementation
36
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

37
FormalCheck

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

38
Cache Controller Verification
39
Cache Controller Verification
Aim
Memory SubSystem
L1D-CTRL
C P U

• Study the controller
• Formal Specification
• Formal Verification using
• Cadence FormalCheck

L1I
L2
L1I-CTRL
L1D
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 RD unit. -- The
Hindu, Oct 4th 2002
40
System Study
Methodology
Issues of Interest

• No stall for cache miss
• Servicing all requests
• Cache coherency
• Providing Valid data

• Study of architecture
• Functional behaviour
• Timing behaviour
• Protocols involved

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

41
Results
Stage Study Spec. Verification
Man Hours 50 35 130
Verification Engineers 4 2 1

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

42
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

43
FormalCheck
44
FormalCheck Architecture
45
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

46
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.bit0 1
• eventually Counter.bit0 0
• within -delay 0 -duration 2
• Clock.rising

47
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( )

48
(No Transcript)