Reasoning about Embedded System Correctness

Embedded Systems

Entertainment

Polar Lander logic-error

Rover (2004) file-system error

Everywhere

Alice

Hall of Shame Therac-25 Radiation error

Control systems, hardware and software, with many sensors, signal & data processing algorithms, communications over networks

Airbus

Rigorous Verification and Validation indispensable

Generic structure of an Embedded System today

Analog Digital Analog

Memory

Coprocessors

Controllers

Converters

Processor

Interface

Software(Application Programs)

ASIC

Embedded Systems Design Flow

ConceptSpecification

HW/SWPartitioning

Hardware Components

Software Components

Estimation -Exploration

Hardware

Software

System Type Formal

specsCore

Problems

DiscreteContinuousHybrid

Boolean LogicTemporal Logic

FSM

Equations

Hybrid AutomataSatisfiability

Coverage

Synthesizability

Formal Verification

Dimensions of the challenge

Non-Linear

• Task: Verify if a system design meet its specification• Standard Testing methods losing steam (system dynamics,

stochastic, non-linear, mixed, thousands of states….)• Formal Verification showing much promise in recent times

Architecturevalidation

Microcodevalidation

Timingvalidation

Powervalidation

Protocolvalidation

System

Unit

Cluster

Reliabilityvalidation

The promise of Formal Verification

An algorithm which takes as input■ (a) a model of a system A and ■ (b) a property P

and terminates with output ■ (c) a proof that all the behaviors of A satisfy P OR■ (d) a particular behavior of A that violates P

Examples: 1. A: model of autonomous vehicle P: always stays on the road2. A: model of a traffic control system P: vehicles do not collide

Is completely automatic

P

Verification Algorithm

A A satisfies P

Trace of A violating P

Design and Verification

Specification Implementation

Design

Equivalent?

Verification

7

Agenda for this talk

A guided tour of digital design verification■ Different approaches to verification

A brief overview of software verification

A brief overview of security verification

Gate LevelBoolean LogicFinite State Machines

Digital Design: Abstraction Levels

Transistor Level

Formalisms introducedat the Entry-Level

Schematic

always @( posedge clk )beginif (!rst) begin a1 <= a2;

a2 <= ~a1; end;end

Register Transfer Level

Restricted semantics ofProgramming Languages,Communicating Concurrent State Machines (CSM)

Exponential growthin circuit size(Moore’s Law)

9

Design and Verification

specifications

micro-architecture

RTL

gate netlist

layout

design

does it meet the specs?

does it implement the µ-arch?

are they equivalent?

are they equivalent?

propertychecking

equivalencechecking

verification

10

Design Cycle: Implementation

Specs Document

RTL implementation

Gate Level NetlistVerilog, VHDL

English documents

Transistor Level(Schematic)

Design integration

Synthesis

Technology mapping

Mask

Layout

Equivalence checking

Implementationvalidation

(Specvs

RTL)

11

Objective: eliminate design defects before a product is shipped

Specification Implementation=~?

The Verification Challenge

The Verification task is becoming more complex:

Micro-architecture complexities grow Market requirements get tougher Technologies change

Simulation-based Verification

Design

Test Plan Test Bench

Stimulus Generation Simulation

Coverage Metrics Debug Bug Tracking

13

Exhaustive Simulation is Infeasible

Consider a sequential circuit having N FFs and M inputs

Exhaustive verification by simulation■ Reach each state from the initial state■ At each state verify the behavior for each input vector

Upper-bound:■ Number of states: S = O(2N)■ Number of input vectors at a state: R = O(2M)■ To reach a state we may have to pass through O(S) states, where each

transition requires an input vector■ Total number of input vectors = O(S X R) = O(2M+N)

14

What’s the Alternative? The design must be simulated using a well selected subset of input patterns

Well selected?■ Test plans and test scenarios■ Coverage

What do we observe?■ Detecting errors by comparing a design’s primary outputs with the desired

responses may not be the most efficient● Internal error may take many cycles to propagate to a primary output

to be detected● It may not always propagate to the primary output

■ We must carefully choose the signals to be observed

15

Simulation-based Verification: State of technology

Tool Support: ■ VCS, Modelsim, NC■ University tools: Veriwell, Icarus

State of technology■ Constrained random test generation frameworks■ Layered test architectures■ Test-bench design languages

● Specman e, SystemVerilog, SystemC Object oriented test support Can model concurrency

■ Good coverage monitoring● Can be used to generate test harness for uncovered areas

And then came formal■ Explicit■ SAT-based■ BDD-based■ …

The advent of Formal…..

There is a mathematical way of checking

everything

The overall picture

system model

M

property

ψ

Formal Engine

(Does M satisfy ψ ?)

Yes!

No! +“counterexample”

Where do we get the system model?

hardware

e.g., Verilog or VHDL, source code

System model

abstraction & other (semi-)automated transformations

software

e.g., C, C++ , or Java, source

code

Extended design models

Where do we get the properties?

requirements documentation

+(insight)

formal properties

(typically based on temporal logic or

automata)

canned standard properties & templates

(e.g., “deadlock-freedom”)

Formal Verification

System A mathematical model M

Desired behavior A formal specification ψ

The system has the required

behaviorM satisfies ψ

Model checking

Formal Property Verification (FPV)

always !g1 || !g2

always r2 && !r1 next g2

Formal Properties

Temporal Logics (Timed / Untimed, Linear Time / Branching Time): LTL, CTL

Early Languages: Forspec (Intel), Sugar (IBM), Open Vera Assertions (Synopsys)

Current IEEE Standards: SystemVerilog Assertions (SVA), Property Specification Language (PSL)

22

Model checking

Input: a system M and a specification ψ.

Output: does M satisfy ψ?

Fully automatic.

Does not scale

Counter example

Advantage of Model CheckingSimulation Checks Only the Values We Select

Even Small Systems Have Trillions (of Trillions) of Possible Tests!

Advantage of Model CheckingModel Checker Tries Every Possible Input and State!

Model Checking: State of technology HDL Formal tools:

■ IFV, Magellan, Jasper, OneSpin■ University tools: SMV, VIS, SPIN

State of technology■ Explicit state model checking

● Impractical for large circuits

■ Symbolic model checking● Uses implicit representation of states and transitions● BDD, SAT, ATPG● Scales well to moderate circuits

Emerging validation flow

Architectural Specification[Assertions]

Executable Specification[SAL, Lustre, SystemC, etc]

Module implementation[Module level assertions]

Formal-V Simulation

Consistencychecks

Simulation, Customization,

Perf. Eval.Design intent verification

Implementation verification

Design integration[System-level assertions]

Simulation,Dynamic/Semi-FormalProperty Verification

Dynamic Property Verification

Verify the properties during simulation

Compromise: Exhaustive simulation is impractical – bugs can escape if the simulation does not cover the buggy run

AssertionMonitor

Test Bench

ModuleunderTest

Semi-Formal Verification Method to leverage formal algorithms in resource-bounded way

• Used to find bugs too complex / deep for pure formal search

Often iterates between random simulation, formal algorithms

Tool Support: Magellan from Synopsys

Success stories reported from processor verification teams at IBM: The IBM Sixth Sense tool

Formal Verification: A Deeper look inside

30

31

Advent of Formal Methods in EDA

always @( posedge clk )beginif (!rst) begin a1 <= a2;

a2 <= ~a1; end;end

Register Transfer Level

Gate Level

Transistor Level

Formal Properties

LogicalEquivalenceChecking

Design Intent

ModelChecking

Goal: Exhaustive verification of the design intent within feasible time limits

Philosophy: Extraction of formal models of the design intent and the implementationand comparing them using mathematical / logical methods

• Temporal Logics(1996: Turing Award: Amir Pnueli)

• Adopted by Accelera / IEEE• Integrated into SystemVerilog• Tools:

Academia: NuSMV, VISIndustry: Magellan (Synopsys)

IFV (Cadence)• 2007: Clarke & Emerson get

Turing Award

What is Formal Verification? Formally checking whether the implementation satisfies the

specification

What are the ways to specify the specification?

Specification

ImplementationFormal checker

Yes

No

Types of specifications The specification may be:

■ Boolean functions (combinational) – adder, multiplier, etc.■ An implementation at a higher level of the design■ A set of temporal properties

■ For the first two:● We convert both specification and implementation into a common

canonical form (BDD, BMD, SAT, etc)● We then do formal equivalence checking

■ The third calls for Formal Property Verification (FPV)

What is Formal Property Verification?

The design intent is expressed in terms of formal properties.

We check formally whether the implementation satisfies these properties.

■ If so, the checker reports success■ Otherwise it produces a counter-example

The formal method is called model checking

Example: A Simple Pedestrian Crossing Control

r1r2

g1g2

Controlr1

r2

g1

g2

35

36

Example: A Simple Traffic ControlProperties:1. Request line r1 has higher priority than request line r2. Whenever r1 goes

high, g1 must be asserted for the next two cyclesalways [ r1 ⇒ next g1 ∧ next next g1 ]

2. When none of the request lines are high, the control parks the grant on g2 in the next cycle

always [ ¬r1 ∧ ¬r2 ⇒ next g2 ]3. The grant lines g1 and g2 are mutually exclusive

always [ ¬g1 ∨ ¬g2 ]

r1r2

g1 g2

Is the specification correct?

1. always [ r1 ⇒ next g1 ∧ next next g1 ]

2. always [ ¬r1 ∧ ¬r2 ⇒ next g2 ]

3. always [ ¬g1 ∨ ¬g2 ]

Consider the case when r1 is high at time t and low at time t+1, and r2 is low at both time steps.■ The first property forces g1 to be high at time t+2■ The second property forces g2 to be high at time t+2■ The third property says g1 and g2 cannot be high together■ We have a conflict !!■ Lets go back to the specification

r1r2

g1 g2

37

Pedestrian Crossing: Revised Specs

Properties:1. Request line r1 has higher priority than

request line r2. Whenever r1 goes high, the grant line g1 must be asserted for the next two cycles

always [ r1 ⇒ next g1 ∧ next next g1 ]2. When none of the request lines are high, the control parks the grant on g2 in

the next cyclealways [ ¬r1 ∧ ¬r2 ⇒ next g2 ] revised to always [ ¬g1 ⇒ g2 ]

3. The grant lines g1 and g2 are mutually exclusivealways [ ¬g1 ∨ ¬g2 ]

r1r2

g1 g2

38

Pedestrian Crossing: Is the specs complete?

1. always [ r1 ⇒ next g1 ∧ next next g1 ]

2. always [ ¬g1 ⇒ g2 ]

3. always [ ¬g1 ∨ ¬g2 ]

Observation: We can satisfy the specification by designing a control which always asserts g1 and never asserts g2!!■ We need to add either of the following types of properties:

● Ones which specify when g2 should be high, or● Ones which specify when g1 should be low

■ Lets go back to the specification

r1r2

g1 g2

39

Pedestrian Crossing: Revised specsProperties:1. Request line r1 has higher priority than

request line r2. Whenever r1 goes high, the grant line g1 must be asserted for the next two cycles

always [ r1 ⇒ next g1 ∧ next next g1 ]2. When none of the request lines are high, the arbiter parks the grant on g2 in

the next cyclealways [ ¬g1 ⇒ g2 ]

3. When r1 is low for consecutive cycles, then g1 should be low in the next cyclealways [ ¬r1 ∧ next ¬r1 ⇒ next next ¬ g1 ]

4. The grant lines g1 and g2 are mutually exclusivealways [ ¬g1 ∨ ¬g2 ]

New!!

r1r2

g1 g2

40

MC

G(p F q)yes

nop

q

pq

temporal formula

finite-state model

algorithm

counterexample

Model Checking

Simplistic view

Formal properties tell us which are the good states / bad states

■ Safety property: Bad states should be unreachable.

■ Liveness property: Some good state is eventually reached.

A model checking tool checks whether bad states are

unreachable / good states are eventually reachable

■ For this they must traverse the state space

■ Main challenge is to perform the traversal symbolically –

without explicitly generating all states

42

How does one use FPV? Things to know:

■ Syntax and semantics of property specification languages■ How to express the intent in terms of formal properties■ Can I express everything in terms of formal properties?■ Can I verify every property that I write?■ Are my properties correct?■ Have I written enough properties?■ Why does the FPV tool run into capacity issues?■ How do I integrate FPV into my validation flow?■ What lies between simulation and FPV?

Why do we need “temporal” logic?

Propositional Logic – Boolean formulas

Temporal Logic■ Properties span across cycle boundaries■ Consider a property of the traffic controller

● If the request bit r1 is true in a cycle then the grant bit g1has to be true within the next two cycles

Half Adder

a1a2

scout

cout ⇔ a1 ∧ a2

s ⇔ a1 ⊕ a2

TLCr1r2

g1g2

What does “temporal” mean?

RRArbiter

r1r2

g1g2 If r1 is true in a cycle then g1 has to be

true within the next two cycles

r1(0)r2(0)g1(0)g2(0)

r1(1)r2(1)g1(1)g2(1)

r1(2)r2(2)g1(2)g2(2)

time:0 time:1 time:2

Temporal worlds

∀t [ r1(t) ⇒ g1(t+1) ∨ g1(t+2) ]

In propositional temporal logic, the time variable t is implicit.• For example, we may write:

always r1 (next g1) or (next next g1)

Property Specification Languages

Temporal Logics■ Linear Temporal Logic (LTL) – linear time■ Computation Tree Logic (CTL) – branching time

Forspec – Intel

PSL – Accellera

Open Vera Assertions (OVA) – Synopsys

System Verilog Assertions (SVA) – Accellera

Open Verification Library (OVL) – Accellera

Temporal Logics Logic extended with the notion of time

■ Reason about propositions qualified in terms of time

Tradeoff between expressibility and complexity of verification

Two popular forms of temporal logic for formal verification■ Linear Temporal Logic (LTL)■ Computation Tree Logic (CTL)

Linear Temporal Logic (LTL) Introduced by Pnueli in 1977

Propositional Logic + discrete time

Time is viewed as a single linear sequence of events

Properties specified over a single path

Temporal operators to represent discrete tim■ p is a proposition – p should hold at current time■ X p – p should hold at next time■ F p – p should hold in the future■ G p – p should hold globally

LTL Formulas

Time

X p

F p

G p

p U q

p W q

LTL - Examples Safety Properties - G ¬(Critical1 ∧ Critical2)

■ Something bad never happens

Liveness - F (Req1 ∨ Req2)■ Something Good will eventually happen

Fairness - G (Req1 F Scheduled1)■ If something is requested, it eventually gets scheduled

The TLC Example

r1

r2

g1

g2

• Either g1 or g2 is alwaysfalse (mutual exclusion)

G[¬g1 ∨ ¬g2]

• Whenever r1 is asserted, g1 is given in the next cycleG[ r1 ⇒ Xg1 ]

• When r2 is the sole request, g2 comes in the next cycleG[ (¬r1 ∧ r2) ⇒ Xg2 ]

• When none are requesting, the controller parks the grant on g2 G[ (¬r1 ∧ ¬r2) ⇒ Xg2 ] Violation!!

Duality between Temporal Operators

G p

p holds always

¬p does not hold eventually

¬( ¬p holds eventually )

¬F( ¬p )

Overview of PSL

Boolean Expressions■ HDL expressions■ PSL functions: rose(), fell(), prev(), ...

Temporal Operators■ always, never, next, until, before, eventually, abort, ...■ @ -> |-> |=> ; { } [* ] [= ] [-> ] && & | :

Verification Directives■ assert, assume, restrict, cover, ...

Modeling Constructs■ HDL statements used to model the environment

WhatWhenHow

Invariants

assert_no_underflow : assert never (read && empty);

TemporalOperator Boolean

Expression

VerificationDirective

How(to apply)

When(expression

shouldbe true)

What(to check)

WhatWhenHow

Something that should never happen!For example: An underflow should never occur

label

The verification method

To prove mathematically that the machine M satisfies its specification P■ M is typically a finite state machine (often called a Kripke structure)■ P is typically a set of formal properties capturing the design intent

State of technology■ Significant body of literature■ Widely used in chip design industry

● Language standards (PSL, SVA) + wide arsenal of tools■ Becoming mandatory in railway and automotive safety standards

Formal properties P

M

Specification

Implementation

Model Checker

True

FalseCounterexample

Model Checking

Developed independently by Clarke and Emerson and by Queille and Sifakis in early 1980’s.

Properties are written in propositional temporal logic.

Systems are modeled by finite state machines.

Verification procedure is an exhaustive search of the state spaceof the design.

Model checking complements testing/simulation

Mutual Exclusion Example

N1 → T1T1 ∧ S0 → C1 ∧ S1 C1 → N1 ∧ S0

N2 → T2T2 ∧ S0 → C2 ∧ S1C2 → N2 ∧ S0

||

• Two process mutual exclusion with shared semaphore

• Each process has three states• Non-critical (N)• Trying (T)• Critical (C)

• Semaphore can be available (S0) or taken (S1)

• Initially both processes are in the Non-critical state andthe semaphore is available --- N1 N2 S0

Mutual Exclusion Example

N1N2S0

C1N2S1T1T2S0

N1T2S0T1N2S0

N1C2S1

T1C2S1C1T2S1

K ╞ AG EF (N1 ∧N2 ∧S0)No matter where you are there is always a way to get to the initial state

Mutual Exclusion Example

N1N2S0

C1N2S1T1T2S0

N1T2S0T1N2S0

N1C2S1

T1C2S1C1T2S1

AG EF (N1 ∧N2 ∧S0

Mutual Exclusion Example

N1N2S0

C1N2S1T1T2S0

N1T2S0T1N2S0

N1C2S1

T1C2S1C1T2S1

AG EF (N1 ∧N2 ∧S0

Mutual Exclusion Example

N1N2S0

C1N2S1T1T2S0

N1T2S0T1N2S0

N1C2S1

T1C2S1C1T2S1

AG EF (N1 ∧N2 ∧S0

Mutual Exclusion Example

N1N2S0

C1N2S1T1T2S0

N1T2S0T1N2S0

N1C2S1

T1C2S1C1T2S1

AG EF (N1 ∧N2 ∧S0

Mutual Exclusion Example

N1N2S0

C1N2S1T1T2S0

N1T2S0T1N2S0

N1C2S1

T1C2S1C1T2S1

AG EF (N1 ∧N2 ∧S0

Model Checking in the HDL world

Hardware is typically synchronous and regular, hence the transition relation can be encoded efficiently■ Execution paths are typically very short

The Intel Pentium bug, was the “disaster” that got model checking on the map in the hardware industry■ What is it going to take in the software world?

Intel, IBM, Motorola, etc. now employ hundreds of model checking experts

Transition System(Automaton, Kripke structure)

Hardware Description(VERILOG, VHDL, SMV)

Informal Specification

Temporal Logic Formula(CTL, LTL, SVA, PSL etc.)

Model Checking

How does LTL Model checking work?

Given a design M and an LTL formula ϕ■ Build an automaton for T¬ϕ (Tableau )■ Compute product P of M and T¬ϕ

■ The product P accept the traces of M that are also traces of T¬ϕ

■ If the product accepts any sequence (non-empty)● We have found a bug in M

66

1

2

3

a

b

c

||n states,

m processes

1,a

2,a 1,b

2,b3,a 1,c

3,b 2,c3,c

nm states

So far so good…

The State Explosion Problem

System Description

State Transition Graph

Combinatorial explosion of system states renders explicit

model construction infeasible.

Exponential Growth of …… global state space in number of concurrent components.… memory states in memory size.

Feasibility of model checking inherently tied to handling state explosion.

Model Checking since 1981

1981 Clarke / Emerson: CTL Model CheckingSifakis / Quielle

1982 EMC: Explicit Model CheckerClarke, Emerson, Sistla

1990 Symbolic Model CheckingBurch, Clarke, Dill, McMillan

1992 SMV: Symbolic Model VerifierMcMillan

1998 Bounded Model Checking using SATBiere, Clarke, Zhu

2000 Counterexample-guided Abstraction RefinementClarke, Grumberg, Jha, Lu, Veith

105

10100

101000

1990s: Formal Hardware Verification in Industry:Intel, IBM, Motorola, etc.

Symbolic Model CheckingBurch, Clarke, McMillan, Dill, and Hwang 90;Ken McMillan’s thesis 92

The Partial Order ReductionValmari 90Godefroid 90 Peled 94(Gerard Holzmann’s SPIN)

Big Breakthroughs

Bounded Model Checking Biere, Cimatti, Clarke, Zhu 99 Using Fast SAT solvers Can handle thousands

of state elements

Can the given property fail in k-steps?

I(V0) Λ T(V0,V1) Λ … Λ T(Vk-1,Vk) Λ (¬ P(V0) V … V ¬ P(Vk))

k-stepsProperty fails in some stepInitial state

BMC in practice: Circuit with 9510 latches, 9499 inputsBMC formula has 4 x 106 variables, 1.2 x 107 clausesShortest bug of length 37 found in 69 seconds

Big Breakthroughs

Big Breakthroughs Localization Reduction

Bob Kurshan 1994

Counterexample Guided Abstraction Refinement (CEGAR) Clarke, Grumberg, Jha, Lu, Veith 2000

Used in most software model checkers

Existential Abstraction: The pillar of CEGAR

M

Mα

Given an abstraction function α : S → Sα, the concrete states are grouped and mapped into abstract states:

α α α

Preservation Theorem

Theorem (Clarke, Grumberg, Long) If property holds on abstract model, it holds on concrete model

Technical conditions Property is universal Atomic formulas respect abstraction mapping

Converse implication is not true !

Spurious Behavior

AGAF red“Every path necessarily leadsback to red.”

Spurious Counterexample:<go><go><go><go> ...

“red”

“go”

Artifact of the abstraction !

Automatic Abstraction

MOriginal Model

Refinement

Refinement

Mα Initial AbstractionSpurious

Spuriouscounterexample

Validation orCounterexample Correct !

CEGAR: CounterExample-Guided Abstraction Refinement

Circuit orProgram

InitialAbstraction

Simulator

No erroror bug found

Propertyholds

Simulationsucessful

Bug foundAbstraction refinement Refinement

ModelChecker

Verification

Spurious counterexample

Counterexample

Abstract Model

Satisfiability Checking

Temporal formula

SATChecker

yes

no

a model of the formula

exists

no model exists for

the formula

unsatisfiable

satisfiable

78

Bounded Model Checking (BMC)

Broad Methodology■ We construct a Boolean formula that is satisfiable iff the underlying state

transition system can realize a finite sequence of state transitions that satisfy the temporal property we are trying to validate

■ We use powerful SAT solvers to determine the satisfiability of the Boolean formula

■ The bound may be increased incrementally until we reach the diameter of the state transition graph

BMC: Translation to SAT

We unfold the property into Boolean clauses over different time steps

We unfold the state machine into Boolean clauses over the same number of time steps

We check whether the clauses are together satisfiable

BMC: Example F (p Λ q) = ( p0 Λ q0 ) V F (p Λ q)

= ( p0 Λ q0 ) V ( p1 Λ q1 )up to 2 time steps

From state machine (up to 2 time steps)(p0 Λ ¬ q0) Λ ((¬ p1 Λ ¬ q1) V (p1 Λ ¬ q1))= (p0 Λ¬ q0) Λ (¬ q1)

The total set of clauses is unsatisfiable

p p

Advantages Able to handle larger state spaces as compared to BDDs.

Takes advantage of several decades of research on efficient SAT solvers.

The witness/counterexample produced are usually of minimum possible length, making them easier to understand and analyze.

Requirements Specification in temporal logic.

System as a finite state machine.

Bound, k, on path length.■ In bounded model checking, only paths of bounded length k or less are

considered.

Limitations of BMC Sound but not complete

■ Works for a bounded depth■ In order to have a complete procedure, we need to run it at least up to the

diameter (unknown) of the transition system

For larger depths the number of clauses can grow rapidly, thereby raising capacity issues

Nevertheless, SAT-based FPV tools can handle much larger designs as compared to BDD-based tools

Digital Formal Verification Tools

Various Commercial Tools■ Cadence – Jasper, Incisive Formal Verifier■ Synopsys – Magellan■ Mentor – 0-in

Various open source academic tools■ VIS■ SPIN■ NuSMV

Formal Verification of Software: A bigger challenge

What makes Software Model Checking different ?

86

What Makes Software Model Checking Different ?

Large/unbounded base types: int, float, string

User-defined types/classes

Pointers/aliasing + unbounded #’s of heap-allocated cells

Procedure calls/recursion/calls through pointers/dynamic method lookup/overloading

Concurrency + unbounded #’s of threads

87

Grand Challenge: Model Check Software !

Early attempts in the 1980s failed to scale.

2000s: renewed interest / demand:Java Pathfinder: NASA AmesSLAM: MicrosoftBandera: Kansas StateBLAST: BerkeleySPIN…SLAM shipped to Windows device driver developers.

In general, these tools are unable to handle complex data structures and concurrency. 88

Today’s Verification problem has newer dimensions….

System Type Formal

specs

CoreProblems

Discrete Models

Continuous Models

Hybrid ModelsBoolean Logic

Temporal Logic

FSM

Equations

Hybrid AutomataConsistency

Formal coverage

Functional Verification

Model Checking

Acknowledgements:

■ Formal-V Group@IIT Kharagpur■ Internet for providing many of the images

References1. A Roadmap for Formal Property Verification, P. Dasgupta2. Model Checking, E. Clarke, O. Grumberg and D. Peled3. Formal Assertion based Verification in Industrial Setting, DAC 20064. Graph Based Algorithms for Boolean Fucntion Manipulation, Randal E.

Bryant, IEEE Transactions on Computers, 1986