fv 11w 01 intro

8/3/2019 FV 11W 01 Intro

http://slidepdf.com/reader/full/fv-11w-01-intro 1/74

8/3/2019 FV 11W 01 Intro


Embedded Systems: Everywhere!

Three future key technologies (NSF):

Embedded systems

Bioinformatics Nanotechnology

mpac o oc e y:

Wireless networks of embedded computers

Energy Conservation

Emergency Response and Homeland Defense

Transportation Efficiency

Monitoring Health Care

Land and Environment

……

2011-1-4 2

8/3/2019 FV 11W 01 Intro


Embedded Systems: Everywhere!

Integral with physical processes

Reactive

a e ee o e env ron en

Heterogeneous

ar ware so ware, m xe arc ec ures

Networked

s are , a ap ve

2011-1-4 3

8/3/2019 FV 11W 01 Intro


Embedded Software

80% of all software is embedded

Demands for increased functionality with minimal

resources

Software construction

Hardware latforms

Communication

Automation

Testing & Verification

Goal: Give a qualitative lift to current industrial

practice

8/3/2019 FV 11W 01 Intro


Design Challenges: Complexity

From the recent NASA’s data, the size of software code is doubling every 3-4 years.

With the rapidly increasing demand for the large scale and complex embedded software,

The likely number of design errors grow exponentially with the number of interacting.

A major challenge of software engineering:

enable developers to construct systems that operate reliably despite this complexity.

2011-1-4 5

8/3/2019 FV 11W 01 Intro


Software is Full of Bugs !

2011-1-4 6

8/3/2019 FV 11W 01 Intro


Software is Full of Bugs !

“Software easily rates as the most poorly constructed,

,

invented by man” Paul Strassman, former CIO of Xerox

In the NASA critical mission software error statistics,

. errors w t , 0.4 errors with 100K,

6.3 errors with 1Mb code

100 mission critical errors with 10Mb. Clearly, it presents an unacceptable trend.

2011-1-4 7

8/3/2019 FV 11W 01 Intro


Hardware is Everywhere

2011-1-4 8

8/3/2019 FV 11W 01 Intro


The number of transistors doubles around every 18 months

100001.8B

100

s ( M T ) 900M

425M

200M

Moore’s Law

386

486Pentium ® proc

P6

1 n s i s t o r

80088080

8085 8086 2860.01

0.1 T

r

0.001

1970 1980 1990 2000 2010

200M--1.8B transistors on the Lead Microprocessor

2011-1-4 9

8/3/2019 FV 11W 01 Intro


The Verification Problem

Moore's Law:

Complexity of integrated circuits doubles every 18 months

The International Technology Roadmap for Semiconductors

(ITRS) estimates that

there will be around 5,000,000,000 transistors on a singlechip by 2010

State-space explosion:

a desi n with around 200 memor elements has more statesthan the number of protons in the universe

January 4, 2011 10

8/3/2019 FV 11W 01 Intro


Frequency Will Increase

100000 30GHz

1000 ( M

h z ) 6.5GHz

3 GhzDoubles every

2 yearsP6

Pentium ® proc486

38610

100

e q u e n c

8086

80808008

1

F r

55M

0.1

1970 1980 1990 2000 2010

Year

ra s s ors

146mm2

0.13μm process

3 - 30Ghz Frequency 3.2GHz

2011-1-4 11

8/3/2019 FV 11W 01 Intro


Functional Validation of Microprocessors

Functional validation is a major bottleneck

Deeply pipelined complex micro-architectures

Logic bugs increase at 3-4 times/generation Bugs increase (exponential) is linear with design complexity

growth

2011-1-4 12

8/3/2019 FV 11W 01 Intro


Bugs

What is a "bug"?

When the design does not match the specification Problem is that complete (and consistent) specifications may not

exist for many products

January 4, 2011 13

8/3/2019 FV 11W 01 Intro


Design Bug Distribution in Pentium 4

Type of Bug Percentage

42 Million transistors,

"Goof" 12.7

Miscommunication 11.4

1+ Million lines of RTL

100 high-level logic bugs

croarc ec ure .

Logic/microcode changes 9.3

Corner cases 8oun roug orma

verificationPowerdown 5.7Documentation 4.4

Source: EE Times, Jul 4, 2001

.

Initialization 3.4

Late definition 2.8

Incorrect RTL assertions 2.8

Design mistake 2.6

January 4, 2011 14

8/3/2019 FV 11W 01 Intro


8/3/2019 FV 11W 01 Intro


Verification Challenges

Functional Correctness Problem:

71% of Re-spins (Source: 2002 Collett

International) e rs cause o e-sp ns

For ASIC Designs

verification

30% of time devoted to the desi n

Leading microprocessor design groups:

One half of the design resources of aproject, including computers and manpower,to be devoted to verification.

2011-1-4 16

8/3/2019 FV 11W 01 Intro


Verification Effort

Over 50% of the design effort is in verification

January 4, 2011 17

8/3/2019 FV 11W 01 Intro


Bugs are Expensive!

Exam les:

Y2K bug: Estimated cost: >$500 Billion

A programming error identified as the cause of alarm

Estimated cost: $6-$10 Billion

Intel Pentium FDIV Bug: Estimated cost: $500 Million

“The cost of software bugs to the U.S. economy is estimated

at $60 B/year” NIST, 2002

2011-1-4 18

8/3/2019 FV 11W 01 Intro


Bugs are Catastrophic!

On June 4, 1996 an Ariane V rocket launched by the rocket

launched by the European Space Agency European Space Agency

exploded just forty seconds exploded just forty seconds after

-

Damage: half a billion dollars

2011-1-4 19

8/3/2019 FV 11W 01 Intro


Bugs are Catastrophic!

Therac-25 was a radiation thera machineproduced by Atomic Energy of Canada Limited

(AECL) and CGR of France after the Therac-6.

It was involved with at least six knownaccidents between 1985 and 1987, in which

patients were given massive overdoses ofradiation.

eas ve pa en s e o e over oses.

These accidents highlighted the dangers of

software control of safet -critical s stemsand they have become a standard case study inhealth informatics.

2011-1-4 20

8/3/2019 FV 11W 01 Intro


Design Process

2011-1-4 21

8/3/2019 FV 11W 01 Intro


Verification

Verification methods are generally divided into two paradigms

Formal verification and dynamic verification (testing). Within each paradigm, different algorithms and techniques are

used for hardware and software systems.

Yet, at their core, all of these techniques aim to achieve thesame goal of ensuring the correct functionality of a complicated

system.

2011-1-4 22

8/3/2019 FV 11W 01 Intro


Simulation

(x+1)2 = x2 + 2x +1 ?

.

From a technical point of view just a

"walk" in the reachabilit ra h.

By making many "walks" or a very "long

walk" behavior, it is possible to make

reliable statements about properties/performance indicators.

Used for validation and performance

analysis.

anno e u e o rove correc ne

2011年1月4日星期二 23

8/3/2019 FV 11W 01 Intro


How About Testing/Simulation?

vectors observe output

10101 ...01011 ...

ong es runs. ee o s mu a e ons o cyc es

Effective test sequences hard to generate

ua y o npu pa erns m s re a y

Incomplete: no guarantee for sequences not simulated

g -coverage, orner cases

Errors often occur where not anticipated

2011-1-4 24

8/3/2019 FV 11W 01 Intro


Exhaustive Testing/Simulation?

=

<

32

32 584,942 ears>

A fast computer: 1 micro second per vector

264 (all input patterns) × 10−6

---------------------------------------------------3600 (seconds) × 24 (hours) × 365 (days)

2011-1-4 25

8/3/2019 FV 11W 01 Intro


When Do You Tapeout?

Motorola criteria

40 billion random cycles without finding a bug Directed tests in verification plan are completed

Source code and/or functional covera e oals are met

Diminishing bug rate is observed

2011-1-4 26

8/3/2019 FV 11W 01 Intro


Formal Verification Methods

Properties

(specification)

yes/no (Error trace)verifier

Complete with respect to a given property

Can generate a short trace if a property fails

Consideration of all cases is implicit in formal verification.

2011-1-4 27

8/3/2019 FV 11W 01 Intro


The Most Cited Exam le

2011-1-4 28

8/3/2019 FV 11W 01 Intro


A Correct Transition Arbiter?

according to

simulation usingrandom delays.

(231

transitions)

2011-1-4 29

8/3/2019 FV 11W 01 Intro


A Correct Transition Arbiter?

Symbolic model checking says n < m nu e

Error trace:

r1,d1,g1, ... ,g2,d2,r2

0000000100110010000000->

r ->s ->u ->v ->r ->s ->u ->

w2->v2->x2->y2->t2->z2->g2->

d2->r2->u2->z2->t2->w2->v2->

x2->s2->u2->w2->v2->x2->y2->

g2->u2->w2->v2->w1->x1->y1->

t1->z1->g1->1011111011010010001010

Client 1 ranted resource Client 2 ranted resource

2011-1-4 30

8/3/2019 FV 11W 01 Intro


mu a on, em - orma , orma er ca on

2011-1-4 31

8/3/2019 FV 11W 01 Intro


Simulation/Test vs. FV

Simulation FV

Simulation: complete model, partial verification

er cat on: part a mo e , comp ete ver cat on

Formal verification cannot replace simulation

Current technology only effective for certain verification

subtasks

Two techniques are complementary

Formal verification gives additional confidence

2011-1-4 32

8/3/2019 FV 11W 01 Intro


Formal Verification

Mathematically-based techniques

Provides a framework for Specifying systems (and thus notion of correctness)

Ensurin correctness

implementation w.r.t. the specification

Reasoning is based on logic

Amenable to machine analysis and manipulation

Can verify everything that is true in the system!

2011-1-4 33

8/3/2019 FV 11W 01 Intro


Formal Verification

Techniques and tools for specifying and verifying such systems.

Greatly increase our understanding of a system by revealing inconsistencies,

ambi uities and

incompletenesses

2011-1-4 34

8/3/2019 FV 11W 01 Intro


Design and Implementation Verification

January 4, 2011 35

8/3/2019 FV 11W 01 Intro


Design Verification

Ensuring correctness of the design

Typically compare against

re erence mo e

an implementation (at different levels)

An alternative desi n at the sa e level

January 4, 2011 36

8/3/2019 FV 11W 01 Intro


Equivalence Checking

Checks equivalence of two models

RTL vs. gate

Before optimization vs. after optimization

Before test insertion vs. after

Reference model vs. implementation

Advantage

Guarantee functional equivalence of two models for all input values

Disadvantage

Needs golden reference model

Targets implementation errors rather than design bugs

January 4, 2011 37

8/3/2019 FV 11W 01 Intro


Equivalence Checking

Two circuits are functionally equivalent if they exhibit the same

behavior

Combinational circuits

for all possible input values

Sequential circuits for all ossible

states & input values

January 4, 2011 38

8/3/2019 FV 11W 01 Intro


Combinational Equivalence Checking

(Boolean functions B1 and B2)

ow can we prove t at s sn t equ va ent to ,

in a reasonable amount of time?

January 4, 2011 39

8/3/2019 FV 11W 01 Intro


Equivalent?

A

O 1

T 1

A T 3

B T

B

C

O 2

Lo ic Circuit Com arison

Do circuits compute identical function?

Compare new design to “known good” design

January 4, 2011 40

E b l P

8/3/2019 FV 11W 01 Intro


Extract Combinational Portions

January 4, 2011 41

F l V ifi i

8/3/2019 FV 11W 01 Intro


Formal Verification:

o ware-> ar ware-> o ware In t e - s, g expectat ons or so tware ver cat on ,

but hopes gradually fizzled out by the late 1970’s.

Theorem proving approaches have “cultural roots” in software

verification in 1970’s.

Why formal methods might work for hardware?

Hardware is often regular and hierarchical

Re-use of desi n is common ractice Primitives are simpler

2011-1-4 42

N t bl E l

8/3/2019 FV 11W 01 Intro


Notable Examples

Protocol verification

m e e so tware veri ication

Security validation

Program verification ………

2011-1-4 43

St t f Th A t

8/3/2019 FV 11W 01 Intro


State of The Art

In the past the use of formal methods in practice seemed

hopeless.

The notations were too obscure the techniques did not scale and

the tool support was inadequate or too hard to use.

There were only a few nontrivial case studies and together they

still were not convincing enough to the practicing software or

ar ware eng neer

2011-1-4 44

S ifi ti d V ifi ti

8/3/2019 FV 11W 01 Intro


Specification and Verification

Specification: Modeling

Temporal Logics Verification

Model checkin

Theorem Proving

2011-1-4 45

Sp ifi ti n

8/3/2019 FV 11W 01 Intro


Specification

precisely.

The main benefit in so doin is intan ible: gaining a deeper understanding of the system being specified.

design laws

inconsistencies

incompletenesses

2011-1-4 46

Formal Specification

8/3/2019 FV 11W 01 Intro


Formal Specification

Specification is the process of describing a system and its

desired properties.

Formal specification uses a language with a mathematically

defined syntax and semantics.

The system properties might include

functional behavior

timing behavior

erformance characteristics or internal structure

2011-1-4 47

Linear Temporal Logic

8/3/2019 FV 11W 01 Intro


Linear Temporal Logic

s1 s2 s3

x:

L(s0) = {p},

L(s1) = {p, q},

=

s0

,

L(s3) = {u, v},

…...L: S → 2AP

Pnueli, 1977:

focus on ongoing behavior,

rather than input/output behavior: temporal logic

2011-1-4 48

Propositional Linear Temporal Logic

8/3/2019 FV 11W 01 Intro


Propositional Linear Temporal Logic

LTL = Classical propositional logic + temporal operators

Basic te oral o erators:

F p ( ◊p, “sometime p ”, “eventually p ”)

G “alwa s ” “henceforth ”

X p ( Op, “next time p ”)

U “ until ”

Fp Gp p p p p p

Xp pUq

p p p p q

2011-1-4 49

Safety Properties

8/3/2019 FV 11W 01 Intro


Safety Properties

i

Safety properties represent requirements that should be

continuousl maintained b the s stem.

They often express invariance properties.

xamp es:

G ~(ack1 & ack2) “mutual exclusion”

G (req→(req W ack)) “req must hold until ack”

A safety property corresponds to partial correction which doesnot ensure termination, but only that all terminatingcomputations produce correct results.

2011-1-4 50

Liveness Properties

8/3/2019 FV 11W 01 Intro


Liveness Properties

A liveness property states that some good thing eventually

happens.

Liveness ro erties re resent re uirements that need not holdcontinuously but those eventual (or repeated) realization must

be ensured.

Examples:

req -> ac req, even ua y ac

Liveness properties correspond to total correctness which

guarantees termination.

2011-1-4 51

8/3/2019 FV 11W 01 Intro


Exam le: A sim le interface rotocol ulses one clock eriod wide

Safety property:

+.

G ( Validated → X ¬ Validated )

Liveness:

∀ t . ( Ready ( t ) → ∃( t ' ≥ t +1) . Accepted ( t ) )

G( Ready →

F Accepted )

Fairness constraint:

G( Accepted ⇒ F Ready ) ( it models a live environment of System)

2011-1-4 52

Branching Time Temporal Logic

8/3/2019 FV 11W 01 Intro


Branching Time Temporal Logic

Structure of time

an n n te tree

each instant may have many successor instants

,isomorphic to N

State quantifiers:

Xp, Fp, Gp, pUq (like in linear temporal logic)

Path quantifiers

“ ” E = “for some future path”

2011-1-4 53

Assertion Languages

8/3/2019 FV 11W 01 Intro


Assertion Languages

Standardization efforts of the early 2000s by Accellera

PSL: temporal logic extended with regular events SVA: less temporal and more regular

2011-1-4 54

Formal Verification

8/3/2019 FV 11W 01 Intro


Formal Verification

Two well established a roaches to verification are

model checking

.

25 years of model checking

Increasing acceptance by HW industry

Significant recent progress in applications to SW.

Main challen e: state-ex losion roblem

2011-1-4 55

Model Checking

8/3/2019 FV 11W 01 Intro


Model Checking

A specific model-checking problem is defined by

I = Smore detailed more abstract

“implementation”(s stem model)

“specification”(s stem ro ert )

“ ” “ ” “ ”, ,(satisfaction relation)

2011-1-4 56

Model Checking

8/3/2019 FV 11W 01 Intro


Model Checking

Model checking is a technique that relies on building a finite

model of a system and checking that a desired property holds in

a o e

The check is performed as an exhaustive state space search

w c s guaran ee o erm na e s nce e mo e s n e.

The technical challenge in model checking is in devising

a gor ms an a a s ruc ures a a ow us o an e arge

search spaces.

2011-1-4 57

Model Checking: I

8/3/2019 FV 11W 01 Intro


g

The first temporal model checking is a technique developed

independently in the 1980s by [Clarke and Emerson 1981] and by

ue e an a .

specifications are expressed in a temporal logic [Pnueli 1981]

systems are modeled as finite state transition systems.

An efficient search procedure is used to check if a given finite

state transition system is a model for the specification.

2011-1-4 58

Model Checking: II

8/3/2019 FV 11W 01 Intro


g

The specification is given as an automaton, then the system alsomodeled as an automaton is compared to the specification todetermine whether or not its behavior conforms to that of the

.

Different notions of conformance have been explored including

anguage nc us on urs an

refinement orderings [Cleaveland 1993]

observational equivalence [Cleaveland 1993]

Vardi and Wolper [1986] showed how the temporal logic model

c ec ng pro em cou e recas n erms o au oma a, usrelating these two approaches

2011-1-4 59

Model Checking

8/3/2019 FV 11W 01 Intro


g

In contrast to theorem proving model checking is completely

automatic and fast sometimes producing an answer in a matter

o nu e .

Model checking can be used to check partial specifications and

so it can provide useful information about a systems

correctness even if the system has not been completely

spec e .

The tour de force is that it produces counterexamples which

usua y represen su e errors n es gn an us can e use oaid in debugging

2011-1-4 60

Model Checking

8/3/2019 FV 11W 01 Intro


g

The main problem of model checking is the state explosion

problem.

In 1987, McMillan used Bryant’s ordered binary decision

diagrams BDDs [Bryant 1986] to represent state transition

systems efficiently, thereby increasing the size of the systems

a cou e ver e .

Other approaches to alleviating state explosion include

the exploitation of partial order information [Peled 1996]

localization reduction [Kurshan 1994] and semantic

minimization [Elseaidy 1996] to eliminate unnecessary states

from a system model.

2011-1-4 61

Model Checking

8/3/2019 FV 11W 01 Intro


g

with between 100 and 200 state variables.

120 states [Burch 1994].

systems with an essentially unlimited number of states [Clarke1994 .

As a result, model checking is now powerful enough that it is

beco in widel used in industr to aid in the veri ication onewly developed designs

2011-1-4 62

Example: Java PathFinder

8/3/2019 FV 11W 01 Intro


p

NASA: Automated Software Engineering Group

Java PathFinder:

a new Java Model Checker, JPF2 , built on a custom-made

Java Virtual Machine.

They built a translator from Java to the Promela input languagefor the Spin model checker.

They are collaborating with the Advanced Architectures and

Agents Group at NASA Goddard and Global Science and

Technology to apply the tool to analyze a satellite down-link

protocol.

2011-1-4 63

Example: SPIN

8/3/2019 FV 11W 01 Intro


Spin is a popular software tool that can be used for the formal

verification of distributed software systems.

The tool was developed at Bell Labs in the original Unix group of

the Computing Sciences Research Center, starting in 1980.

The software has been available freely since 1991, and continues

to evolve to keep pace with new developments in the field.

In April 2002, the tool was awarded the prestigious System

Software Award for 2001 by the ACM.

2011-1-4 64

Example: Microsoft SLAM

8/3/2019 FV 11W 01 Intro


The SLAM project originated in Microsoft Research in early. p: www.researc .m croso .com s am

Its goal was to automatically check that a C program correctly

.

The project used and extended ideas from symbolic model,

address this problem. T i i

Static Driver Verifier (SDV) that systematically analyzes thesource code of Windows device drivers against a set of rules

that define what it means for a device driver to properlyinteract with the Windows operating system kernel.

2011-1-4 65

Example: Microsoft SLAM

8/3/2019 FV 11W 01 Intro


" ,

Holy Grail of computer science for many decades but now in

some very key areas, for example, driver verification we're building tools that can do actual proof about the software

and how it works in order to guarantee the reliability "

Bill Gates, April 18, 2002. Keynote address at WinHec 2002

2011-1-4 66

Example: Microsoft Zing

8/3/2019 FV 11W 01 Intro


Zing is a new software model checking project at Microsoft

Research.

The goal is to build a flexible and scalable systematic statespace exploration infrastructure for software.

They believe that such an infrastructure can be used for

verifying and finding bugs in software at various levels: high-

level protocol descriptions, work-flow specifications, web

services, device drivers, and protocols in the core of the

operating system.

http://research.microsoft.com/zing/

2011-1-4 67

State Space Explosion

8/3/2019 FV 11W 01 Intro


A small design (or program) that can use a mere 250 bits of

data has at least 2250 states

⇒ More states than particles in the Universe!

The model is too large to store in available memory!

22250250

s0

s1 2

s3

s5 s4

2011-1-4 68

Symbolic Image Computation

8/3/2019 FV 11W 01 Intro


2011-1-4 69

Symbolic Model Checking

8/3/2019 FV 11W 01 Intro


Explicit State Representation

⇒ State Explosion Problem (about 108 states maximum)

Breakthrough:Implicit State Representation using BDD (about 1020 states).

Finite State Machine CTL Formula

OK/Counter-example

2011-1-4 70

Advances in Model Checkin

8/3/2019 FV 11W 01 Intro


–

Symbolic Model Checking with Binary Decision Diagrams (1991 – )

Sym o ic oun e Mo e ec ing wit SAT so vers –

Model Checking using SAT and Induction (2000 – )

Unbounded SAT-based Model Checking (2003, July)

2011-1-4 71

Between Spec and Imp

8/3/2019 FV 11W 01 Intro


Imp ≡ Spec

implementation is equivalent to specification

implementation logically implies specification

mp = pec

implementation is a semantic model in which specification is

rue

2011-1-4 72

Issues in Verification Methods

8/3/2019 FV 11W 01 Intro


proof generation process automatic, semi-automatic or user

Compositional

cons ruc e rom proo s o componen par s

Hierarchical

system organized hierarchically at various levels of

abstraction

Inductive

reason inductively about parameterized descriptions

2011-1-4 73

Where to Go?

8/3/2019 FV 11W 01 Intro


2011-1-4 74

fv 11w 01 intro

Documents