S. Ramesh

1

CFDVS

Formal Verification:Projects & Case Studies

S. Ramesh

CSE Dept.

IIT Bombay

S. Ramesh

2

CFDVS

Assertion Checking Environment

(ACE)

S. Ramesh

3

CFDVS

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

S. Ramesh

4

CFDVS

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

S. Ramesh

5

CFDVSFormal Verification

Methodology

S. Ramesh

6

CFDVS

Program Verification Methodology

• Important Features– Abstract Models

– Formal Specification

– Verification Engine

S. Ramesh

7

CFDVS

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

S. Ramesh

8

CFDVS

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

S. Ramesh

9

CFDVS

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

S. Ramesh

10

CFDVS

S. Ramesh

11

CFDVS

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..

S. Ramesh

12

CFDVS

C2SPL• Important Component of ACE• converts MISRA C program to SPL

programs• converts pre, post conditions and

assertions into SPEC file in STeP format

c2splPre-conditions

Assertions/

Post-conditions

SPL Model

axioms

Properties

MISRA C

S. Ramesh

13

CFDVSCompositional Verification

S. Ramesh

14

CFDVS

Examplestruct 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*/ }

S. Ramesh

15

CFDVS

SPL Programget_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 ]

S. Ramesh

16

CFDVS

SpecificationSPECAXIOM 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)

S. Ramesh

17

CFDVS

Industrial Experience

• Verification of many real programs• Safety-critical Applications

– Control– Process Interlock– Data Acquisition and Display

S. Ramesh

18

CFDVS

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

S. Ramesh

19

CFDVS

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

S. Ramesh

20

CFDVS

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

S. Ramesh

21

CFDVS

Current Status

• I version completely implemented and working

• Works only on the sequential segment

• II version under development– Automatic error detection– Concurrency – Range checking

S. Ramesh

22

CFDVS

Verification Environment for

Distributed Control Applications

S. Ramesh

23

CFDVS

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

Editor Verifier

Simulator

CRSM

SPIN

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

S. Ramesh

24

CFDVS

Example : ATM

GetPin

PIN!p

GetAmt

Amt!c

IdlecardValid/pin

pinCode/!x/keepCard

x/enterAmount

amount/

a/delMoney.ejectCard

exit/ejectCard

PIN?q

Auth!y

amtChk!b

amtChk?a

Auth?x

!a/ejectCard

(y==valid)/

(y!=valid)/

Amt?d

Teller Bank

S. Ramesh

25

CFDVS

S. Ramesh

26

CFDVS

Editor

S. Ramesh

27

CFDVS

Simulator

S. Ramesh

28

CFDVS

Verification Engine

• Observer-based verification

• Observer also another CRSM component

• Distributed Observers

• Model + Observers translated to Promela

• Verification using SPIN

• No temporal logic specification

S. Ramesh

29

CFDVS

Efficient Verification

• I version of the tool is ready

• II version under development

• Efficient Verification– Refinement Based verification– Program slicing techniques– Compositional Verification

S. Ramesh

30

CFDVS

Example: Mutual Exclusion

Idle

C1?

turnA

C3! turnA

C5! turnA

Critical Section

enterA /

leaveA /

[turnnA==1]/

Processor

Idle BUG(in_C3.in_C4)

Property

C5?

turn

C3?

turn

C1! turn

C6?

turn

C4?

turn

C2! turn

Memory

[turn==1]/[turn==1]/

Idle

C2?

turnA

C4! turnA

C6! turnA

Critical Section

enterB /

leaveB /

Printer

S. Ramesh

31

CFDVS

START

Printer enterB, Memory

Printer, Printer , Memory

Printer leaveB, Printer, Memory

Printer enterB, Processor enterA

Processor, Memory

Memory, Memory in_C3 in_C4

END

Error Trace

S. Ramesh

32

CFDVS

PCI Verification

S. Ramesh

33

CFDVSPCI Protocol Verification

PCI Local Bus

HDD controllerSound Card

Display

CPU

Memory

Common bus arch. for all PCI compatible devices

S. Ramesh

34

CFDVSPCI Protocol

S. Ramesh

35

CFDVS Methodology

Formalcheck Verification

PCI Protocol Specification

VHDL Implementation

FQL Specification VHDL Monitors

Resources Verification Effort

S. Ramesh

36

CFDVS Verification and Results

• FQL properties from CTL spec• Code Compilation• Constraint identification• Query compilation

PCI Core

Full ModulePCI Code

Monitor

Flags

Iterative Seeding Monitor Style Environment Modelling

PCI Code

Arbiter

Sla

ve

• 65% of specification satisfied• Environmental conditions dynamically identified• Attempted different verification styles

S. Ramesh

37

CFDVSFormalCheck

• Commercial Model Checker (Cadence Toolset)

• Takes VHDL and Verilog as inputs.

• Properties specified in FormalCheck Query Language (FQL).

S. Ramesh

38

CFDVS

Cache Controller Verification

S. Ramesh

39

CFDVS Cache Controller Verification

• Study the controller• Formal Specification

• Formal Verification using Cadence FormalCheck

L1I

L2

L1D

L1D

-CTR

LL1

I-C

TR

L

XDMA Test Logic I/O

CPU

Memory SubSystem

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

Aim:

S. Ramesh

40

CFDVS

System Study• No stall for cache miss

• Servicing all requests

• Cache coherency

• Providing Valid data

Methodology

Study of architecture

Functional behaviour

Timing behaviour

Protocols involved

LTL formulae from Spec

Model CPU behaviour

Environmental constraints

Probe design heirarchy

FQL specification

Precompile libraries

Compile design

Create Queries

Verification and debugging

Verification

Issues of Interest

Formal Specification

S. Ramesh

41

CFDVSResults

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

Stage Study Spec. Verification

Man Hours 50 35 130

Verification

Engineers

4 2 1

S. Ramesh

42

CFDVS

FormalCheckHome 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

S. Ramesh

43

CFDVSFormalCheck

TargetBlocks

SystemBlocks

Inte

rfac

e

=

=

System Properties

SystemConstraints

BlockProperties

BlockConstraints

S. Ramesh

44

CFDVSFormalCheck Architecture

Gates

QueryTemplateLibrary

QueryCapture

Formal Model

Query-SpecificReduction

RTL

Autorestrict

Probabilistic

Large Model

Early Model

Results &Error Traces

Inputs Outputs

Template-BasedQuery Inputs

Chip, Blocks, IP ModelsIn Verilog or VHDL

Results Display

S. Ramesh

45

CFDVS

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

S. Ramesh

46

CFDVS

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 }

S. Ramesh

47

CFDVS

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

S. Ramesh

48

CFDVS