fv 11w 01 intro
Post on 07-Apr-2018
229 Views
Preview:
TRANSCRIPT
8/3/2019 FV 11W 01 Intro
http://slidepdf.com/reader/full/fv-11w-01-intro 2/74
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
http://slidepdf.com/reader/full/fv-11w-01-intro 3/74
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
http://slidepdf.com/reader/full/fv-11w-01-intro 4/74
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
http://slidepdf.com/reader/full/fv-11w-01-intro 5/74
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
http://slidepdf.com/reader/full/fv-11w-01-intro 6/74
Software is Full of Bugs !
2011-1-4 6
8/3/2019 FV 11W 01 Intro
http://slidepdf.com/reader/full/fv-11w-01-intro 7/74
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
http://slidepdf.com/reader/full/fv-11w-01-intro 8/74
Hardware is Everywhere
2011-1-4 8
8/3/2019 FV 11W 01 Intro
http://slidepdf.com/reader/full/fv-11w-01-intro 9/74
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
http://slidepdf.com/reader/full/fv-11w-01-intro 10/74
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
http://slidepdf.com/reader/full/fv-11w-01-intro 11/74
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
http://slidepdf.com/reader/full/fv-11w-01-intro 12/74
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
http://slidepdf.com/reader/full/fv-11w-01-intro 13/74
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
http://slidepdf.com/reader/full/fv-11w-01-intro 14/74
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
http://slidepdf.com/reader/full/fv-11w-01-intro 16/74
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
http://slidepdf.com/reader/full/fv-11w-01-intro 17/74
Verification Effort
Over 50% of the design effort is in verification
January 4, 2011 17
8/3/2019 FV 11W 01 Intro
http://slidepdf.com/reader/full/fv-11w-01-intro 18/74
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
http://slidepdf.com/reader/full/fv-11w-01-intro 19/74
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
http://slidepdf.com/reader/full/fv-11w-01-intro 20/74
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
http://slidepdf.com/reader/full/fv-11w-01-intro 21/74
Design Process
2011-1-4 21
8/3/2019 FV 11W 01 Intro
http://slidepdf.com/reader/full/fv-11w-01-intro 22/74
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
http://slidepdf.com/reader/full/fv-11w-01-intro 23/74
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
http://slidepdf.com/reader/full/fv-11w-01-intro 24/74
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
http://slidepdf.com/reader/full/fv-11w-01-intro 25/74
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
http://slidepdf.com/reader/full/fv-11w-01-intro 26/74
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
http://slidepdf.com/reader/full/fv-11w-01-intro 27/74
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
http://slidepdf.com/reader/full/fv-11w-01-intro 28/74
The Most Cited Exam le
2011-1-4 28
8/3/2019 FV 11W 01 Intro
http://slidepdf.com/reader/full/fv-11w-01-intro 29/74
A Correct Transition Arbiter?
according to
simulation usingrandom delays.
(231
transitions)
2011-1-4 29
8/3/2019 FV 11W 01 Intro
http://slidepdf.com/reader/full/fv-11w-01-intro 30/74
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
http://slidepdf.com/reader/full/fv-11w-01-intro 31/74
mu a on, em - orma , orma er ca on
2011-1-4 31
8/3/2019 FV 11W 01 Intro
http://slidepdf.com/reader/full/fv-11w-01-intro 32/74
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
http://slidepdf.com/reader/full/fv-11w-01-intro 33/74
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
http://slidepdf.com/reader/full/fv-11w-01-intro 34/74
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
http://slidepdf.com/reader/full/fv-11w-01-intro 35/74
Design and Implementation Verification
January 4, 2011 35
8/3/2019 FV 11W 01 Intro
http://slidepdf.com/reader/full/fv-11w-01-intro 36/74
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
http://slidepdf.com/reader/full/fv-11w-01-intro 37/74
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
http://slidepdf.com/reader/full/fv-11w-01-intro 38/74
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
http://slidepdf.com/reader/full/fv-11w-01-intro 39/74
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
http://slidepdf.com/reader/full/fv-11w-01-intro 40/74
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
http://slidepdf.com/reader/full/fv-11w-01-intro 41/74
Extract Combinational Portions
January 4, 2011 41
F l V ifi i
8/3/2019 FV 11W 01 Intro
http://slidepdf.com/reader/full/fv-11w-01-intro 42/74
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
http://slidepdf.com/reader/full/fv-11w-01-intro 43/74
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
http://slidepdf.com/reader/full/fv-11w-01-intro 44/74
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
http://slidepdf.com/reader/full/fv-11w-01-intro 45/74
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
http://slidepdf.com/reader/full/fv-11w-01-intro 46/74
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
http://slidepdf.com/reader/full/fv-11w-01-intro 47/74
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
http://slidepdf.com/reader/full/fv-11w-01-intro 48/74
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
http://slidepdf.com/reader/full/fv-11w-01-intro 49/74
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
http://slidepdf.com/reader/full/fv-11w-01-intro 50/74
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
http://slidepdf.com/reader/full/fv-11w-01-intro 51/74
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
http://slidepdf.com/reader/full/fv-11w-01-intro 52/74
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
http://slidepdf.com/reader/full/fv-11w-01-intro 53/74
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
http://slidepdf.com/reader/full/fv-11w-01-intro 54/74
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
http://slidepdf.com/reader/full/fv-11w-01-intro 55/74
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
http://slidepdf.com/reader/full/fv-11w-01-intro 56/74
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
http://slidepdf.com/reader/full/fv-11w-01-intro 57/74
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
http://slidepdf.com/reader/full/fv-11w-01-intro 58/74
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
http://slidepdf.com/reader/full/fv-11w-01-intro 59/74
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
http://slidepdf.com/reader/full/fv-11w-01-intro 60/74
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
http://slidepdf.com/reader/full/fv-11w-01-intro 61/74
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
http://slidepdf.com/reader/full/fv-11w-01-intro 62/74
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
http://slidepdf.com/reader/full/fv-11w-01-intro 63/74
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
http://slidepdf.com/reader/full/fv-11w-01-intro 64/74
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
http://slidepdf.com/reader/full/fv-11w-01-intro 65/74
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
http://slidepdf.com/reader/full/fv-11w-01-intro 66/74
" ,
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
http://slidepdf.com/reader/full/fv-11w-01-intro 67/74
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
http://slidepdf.com/reader/full/fv-11w-01-intro 68/74
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
http://slidepdf.com/reader/full/fv-11w-01-intro 69/74
2011-1-4 69
Symbolic Model Checking
8/3/2019 FV 11W 01 Intro
http://slidepdf.com/reader/full/fv-11w-01-intro 70/74
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
http://slidepdf.com/reader/full/fv-11w-01-intro 71/74
–
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
http://slidepdf.com/reader/full/fv-11w-01-intro 72/74
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
http://slidepdf.com/reader/full/fv-11w-01-intro 73/74
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?
top related