MIT_IEP_Formal_Verification, 13th Dec 2006 1 Introduction To Formal Verification Subir K. Roy...
-
Upload
kyra-stack -
Category
Documents
-
view
216 -
download
2
Transcript of MIT_IEP_Formal_Verification, 13th Dec 2006 1 Introduction To Formal Verification Subir K. Roy...
MIT_IEP_Formal_Verification, 13th Dec 2006
1
IntroductionTo
Formal Verification
Subir K. Roy
SDTC/SOC-COE
Texas Instruments India Pvt. Ltd.,
Bangalore
MIT_IEP_Formal_Verification, 13th Dec 2006
2
Organization of Presentation
• Motivation
• System on Chips and IPs
• Drawbacks of current verification methodology
using simulation
• Why formal verification?
• Semantics/Models/Specification/Fairness
Constraints
• Temporal Logics/Computational Tree Logic
• Binary Decision Diagrams
MIT_IEP_Formal_Verification, 13th Dec 2006
3
Organization of Presentation
• Model Checking
• Verification Flow
• FV Related Issues – Intrinsic Limitations of FV Tool
• Important Verification Tasks
• Model Generation / Design Abstraction
• Compositional Verification using Assume-
Guarantee
MIT_IEP_Formal_Verification, 13th Dec 2006
4
Organization of Presentation
• IP Verification Issues
• Other Care Abouts
• Other Interesting Approaches
• Verification Hierarchy
• Conclusions
MIT_IEP_Formal_Verification, 13th Dec 2006
5
Motivation
• Pentium SRT Division Bug : $0.5 billion loss to Intel
• Mercury Space Probe : Veered off course due to a
failure to implement distance measurement in
correct units.
• Ariane-5 Flight 501 failure : Internal sw exception
during data conversion from 64 bit floating point to
16 bit signed integer value led to mission failure.
• Exception handling mechanism contributed to
the processor being shutdown (This was part of
the system specification).
MIT_IEP_Formal_Verification, 13th Dec 2006
6
SoCs & IPs
• Typical SoCs consist of different components.
• CPU cores.
• Memory cores.
• DSP cores.
• Different peripherals & Interface buses.
• BIST and DFT Logic insertion.
• SoC realization turn around time (TAT) is rapidly increasing.
• TAT reduction through design re-use.
• Design Re-use : Employ IP blocks from IP vendors
MIT_IEP_Formal_Verification, 13th Dec 2006
7
SoC Implementation Approaches
• Vendor Based Approach : ASIC Vendor/Design
service group carries out implementation
• Partial Integration : System Designer implements
proprietary & application specific logic. ASIC
Vendor integrates above with their cores
• In house : ASIC Vendor designs specialized cores.
System Designer implements proprietary & appli-
cation specific logic, integrates cores & verifies
integrated design
MIT_IEP_Formal_Verification, 13th Dec 2006
8
Multiple Sources for IP Reuse
• Semiconductor houses
• I/O Pad, Processor Core, Custom Logic, Memory,
Peripheral Interface, DFT/BIST Cores
• IP/Core Suppliers
• Processor Core, Peripheral Interface, Analog /Mixed
Signal blocks (DAC, ADC, PLL)
• System Designer
• Controller, Custom Logic, AMS blocks
MIT_IEP_Formal_Verification, 13th Dec 2006
9
Advantages of Core/IP based approach
• Short Time To Market (pre-designed)
• Less Expensive (reuse)
• Faster Performance (optimized algorithms and
implementation)
• Lesser Area (optimized algorithms and
implementation)
MIT_IEP_Formal_Verification, 13th Dec 2006
10
“Where do bugs come from ?”
• Incorrect specifications.
• Misinterpretation of specifications.
• Misunderstanding between designers.
• Missed cases.
• Protocol non-conformance.
• Resource conflicts
• Cycle-level timing errors.
• ……
MIT_IEP_Formal_Verification, 13th Dec 2006
11
Implications on Verification
• Abstraction of verification goals (Eg., Signals to
Transactions, End to End Transactions)
• Rigorous verification of each individual SoC
component seperately
• Extensive verification of full system
• Automation of all verification activities
• Reusability of verification components of unit
Cores/IPs/VCs
MIT_IEP_Formal_Verification, 13th Dec 2006
12
Drawbacks of Simulation
• Test bench creation – manual, error prone and time
consuming.
• Simulation environment not re-usable.
• Large simulation regression run times: Hookup logic
verification is done through long test sequences generated by
controller.
• Simulation based verification can be incomplete.
• Design Errors : Related to asynchronous and concurrent
interactions between components.
• Disadvantages : Exponential number of test vectors to
exercise all possible transitions between components.
MIT_IEP_Formal_Verification, 13th Dec 2006
13
Why Formal Verification?
• Formal Approaches : Model Checking
• Formal Model (Finite State Machine).
• Efficient Representation (Binary Decision Diagrams).
• Exhaustive Search (whenever possible).
• No test bench generation : Reduction in DV cycle time.
• Faster verification : Completion at fraction of time compared
to simulation when no memory blow-up.
• Properties/Assertions when generic can be re-used and
automatically generated.
• Comprehensive verification and coverage : High quality and
confidence. Better ability to detect errors.
MIT_IEP_Formal_Verification, 13th Dec 2006
14
Paradigm Framework
Computational or Formal Logic Model Μ
System Description:Formal Syntactic
Representation OfΜ
Deductive Proof Systems
Formal Verification :Μ Ι= φ ??
Model Checking Algorithms
Property SpecificationLanguage & Logic :
Specification Formulaφ
General Mathematical Models Of System
Mathematical CharacterizationOf System Behavior & Properties
Logic Based Formal
Methods
MIT_IEP_Formal_Verification, 13th Dec 2006
15
Three-step process
– Formal specification– Precise statement of properties– System requirements and environmental constraints– Logic - PL, FOL, temporal logic– Automata, labeled transition systems
– Models– Flexible to model general to specific designs– Non-determinism, concurrency, fairness,– Transition systems, automata
MIT_IEP_Formal_Verification, 13th Dec 2006
16
Three-step process (contd.)
– Verification– Checking that model satisfies specification– Static and exhaustive checking– Automatic or semi-automatic
MIT_IEP_Formal_Verification, 13th Dec 2006
17
Semantics of Finite State Systems
Semantics associates behaviors– Branching Time semantics
• the tree of states obtained by unwinding the state machine graph
• possible choices are explicitly represented • Linear Time Semantics
• the set of all possible `runs' in the system• the set of all infinite paths in the state
machine
MIT_IEP_Formal_Verification, 13th Dec 2006
18
Non-determinism
– This machine is nondeterministic in Idle state when req1 and req2 arrive.
– Non-determinism due to abstraction– More than one behaviour for a given input
IDLE
M2M1
rel2rel1
req1 req2
req2
req1
MIT_IEP_Formal_Verification, 13th Dec 2006
19
Generating Formal Models
– Pre-design activity– Automatic Translation from circuits/HDL
designs– States decided by the latches/registers in the ckt.– Exponential blow-up in the size (State-explosion
problem)– Usually abstractions required
MIT_IEP_Formal_Verification, 13th Dec 2006
20
Formal Specifications
– Verification involves checking that a design model meets its specification.
– Specification states what the system is supposed to do
– Design describes how this is done
MIT_IEP_Formal_Verification, 13th Dec 2006
21
Formal Specifications
Specification– Describes unambiguously and precisely the
expected behavior of a design.– In general, a list of properties.– Includes environment constraints.– Symbolic logic or automata formalisms– Consistency and Completeness
MIT_IEP_Formal_Verification, 13th Dec 2006
22
States, Labels, Transitions & Runs
p,qs0
p,qs0
q,rs1
q,rs1
rs2
rs2
rs2
rs2
rs2
p,qs0
q,rs1
rs2
MIT_IEP_Formal_Verification, 13th Dec 2006
23
Specification of Hardware blocks
– Properties and Constraints specify possible states and transitions
– They state set of possible valid `runs'– Valid runs are infinite sequences (or trees) of
states and transitions– Formal specifications are finitistic and precise
descriptions
MIT_IEP_Formal_Verification, 13th Dec 2006
24
Specification of Hardware blocks
Classification of Properties:– Safety properties
• “Undesirable states are never reached",• “Desirable things always happen".
– Progress or Liveness Properties• “Desirable state repeatedly reached"• “Desirable state eventually reached"
MIT_IEP_Formal_Verification, 13th Dec 2006
25
Examples
Safety Properties– A bus arbiter never grants the requests to two
masters– Message received is the message sent– Elevator does not reach a floor unless it is requested
Liveness Properties– Elevator attends to every request eventually– Every bus request is eventually granted– Every sent message was received
MIT_IEP_Formal_Verification, 13th Dec 2006
26
Fairness Constraints
– In general, not every run in a state machine is a valid behavior
– Arbiter example• the run in which master 2 is never granted the
resource– But all runs are included in transition systems– Fairness constraints rule out certain runs
Example– Every request eventually considered– The clock tick arrives infinitely often
MIT_IEP_Formal_Verification, 13th Dec 2006
27
Properties of Hardware blocks
– Temporal in nature– At any time only one units is accessing the bus– every request to access the bus is granted
ultimately.– Two Kinds of TL
– Linear Temporal Logic (LTL):• Time is a linear sequence of events
– Branching time temporal logic (CTL, CTL*):• Time is a tree of events
MIT_IEP_Formal_Verification, 13th Dec 2006
28
Syntax of CTL
– Every atomic proposition is a CTL formula– If f and g are formulae then so are
– f, (f g), (f g), (f g), (f g)– AG f - in all paths, in all state f (in all future, f)– EG f - in some path, in all states f– AF f - in all paths, in some state f (in every future f)– EF f - in some future f– A(f U g) - in all paths, f holds until g– E(f U g) - in some path, f holds until g– AX f - in every next state, f holds– EX f - in some next state f holds
MIT_IEP_Formal_Verification, 13th Dec 2006
29
Examples
AG ¬ (farm_go high_go_B) AGAF (farm_car AF(farm_go)) AG (mem_wr U mem_ack) EF (req0 U grant0 )
MIT_IEP_Formal_Verification, 13th Dec 2006
30
EXAMPLE
– Which of the following hold ?– AG p, EF!q, AX p, AG !q, EG !q, AX(p q)
!p, !q p, !q
!p, q
MIT_IEP_Formal_Verification, 13th Dec 2006
31
CTL Verification Explicit Enumeration
– Iterative labeling algorithm that labels all the states with sub formulae.
– Start from the initial labels of atomic propositions– Iteratively add sub formulae as labels with each
state based on the following equations:
EF p = p EX p EX(EX p) EG p = p EX p EX(EX p) E (q U p) = p (q EX p)
(q EX(q EX p))
MIT_IEP_Formal_Verification, 13th Dec 2006
32
CTL Verification
E[ !c2 U c1]
n1 n2s0
t1 c2s7
n1 c2s6
t1 t2s8
t2 n1s5
c1 t2s4
t1 t2s3
c1 n2s2
t1 n2s1
1
3
2
1
2
E[ !c2 U c1]
E[ !c2 U c1]
E[ !c2 U c1]
E[ !c2 U c1] n : non-critical sectiont : tryingc : critical section
Phase 1 : Label all states satisfying c1 with E[ !c2 U c1]Phase 2 : Label all states which do not satisfy c2 and have a successor state that is already labeledPhase 3 : Iterate Phase 2 until initial state is reached
MIT_IEP_Formal_Verification, 13th Dec 2006
33
CTL Verification
– Iteration terminates since states and subformulae are finite.
– If initial states are labeled with the given formula then the model checking succeeds
– If it fails, counterexample can be generated
MIT_IEP_Formal_Verification, 13th Dec 2006
34
CTL Verification
– Computation terminates – Computation involves backward breadth first
traversal and calculation of Strongly Connected Subgraphs (cycles)
MIT_IEP_Formal_Verification, 13th Dec 2006
35
Complexity of CTL model checking
– Algorithm involves backward traversal– Linear on the sizes of both formulae and model– Size of the model exponential in size of latches– Reduction Techniques:
– Symbolic Model checking Techniques– Compositional Verification– Symmetry based reduction
MIT_IEP_Formal_Verification, 13th Dec 2006
36
ROBDDs
– Example:
– Properties– Unique representation of f for given
variable ordering• Checking f1 = f2: ROBDD isomorphism
– Shared subgraphs: size reduction– Every path might not have all labels– Every non-leaf vertex has
path(s) to 0 and 1
f = x1.x2 + x3’
10
x1 x2
x3
x1 x2
x3x3
1 0 1 11 0 1 0
x3
x2
MIT_IEP_Formal_Verification, 13th Dec 2006
37
Variable Ordering Problem
1
0 1
3 3
5 5 5 5
2 2 2 2
4 4
6
10
3
5
2
4
6
1
f = x1.x2 + x3.x4 + x5.x6
Order 1,3,5,2,4,6
Order 1,2,3,4,5,6
MIT_IEP_Formal_Verification, 13th Dec 2006
38
Operations on BDDs
– Operators: Take ROBDD arguments, return ROBDD result.– Complexity polynomial in BDD size
– BDD size limiting factor in most applications– Ongoing research on avoiding BDD blowup
• Variable ordering, Partitioned BDDs, Implicitly conjoined BDDs etc.
– Quantification with BDDs
– x1. f(x1, x2, x3) = f(0, x2, x3) + f(1, x2, x3)
– x1. f(x1, x2, x3) = f(0, x2, x3) . f(1, x2, x3)
– Useful in Symbolic Model Checking
MIT_IEP_Formal_Verification, 13th Dec 2006
39
Model Checking Sequential Circuits
– Given: – A sequential circuit
• Finite state transition graph
• Flip-flops with next-state logic
• Transition relation between present and next states
– A property in specialized logic – Prove that MODEL satisfies SPECIFICATION
– In case of failure, counterexample desirable
MODEL
SPECIFICATION
MIT_IEP_Formal_Verification, 13th Dec 2006
40
Example: 3-bit Counter
x2
x1
x0X0
X1
X2
Clk
ModelState transition graphdefined byX0 = NOT(x0)X1 = XOR(x1, x0)X2 = XOR(x2, x0. x1)
Property State x0, x1, x2 = 111 is reached infinitely often starting from state 000
MIT_IEP_Formal_Verification, 13th Dec 2006
41
CTL Properties
AG AF (x1 x2)
• x1 or x2 is satisfied infinitely often in the future
3-bit counter example:
– “ The state x0, x1, x2 = 111 is reached infinitely
often starting from 000”
– x0’ x1’ x2’ AG AF (x0 x1 x2)
MIT_IEP_Formal_Verification, 13th Dec 2006
42
Basic Approaches
– Explicit state model checking– Requires explicit enumeration of states– Impractical for circuits with large state spaces – Useful tools exist: EMC, Murphi, SPIN, SMC …
– Symbolic model checking– Represent transition relations and sets of states
implicitly (symbolically)– BDDs used to manipulate implicit representations– Scales well to large state spaces (few 100 flip flops)– Fairly mature tools exist: SMV, VIS, FormalCheck ...
MIT_IEP_Formal_Verification, 13th Dec 2006
43
Model Checking
– Reachability analysis– Find all states reachable from an initial set S0
of states– Check if a safety condition is violated in any
reachable state– CTL property checking
– Express property as formula in Computation Tree Logic (CTL)
– Check if formula is satisfied by initial state in state transition graph
MIT_IEP_Formal_Verification, 13th Dec 2006
44
Symbolic Model Checking
– For 3-bit counter, set of states x0, x1, x2 = {000, 010, 011, 001} can be represented by S (x0, x1, x2) = S(x) = x0’.
BDD:
– Set of state transitions can be represented
by N (x0, x1, x2, X0, X1, X2) = N (x, X) =
(X0 x0’) (X1 x1 x0)
(X2 x2 (x1. x0))
1 0
ox
x0
1 0
MIT_IEP_Formal_Verification, 13th Dec 2006
45
Forward Reachability
– Start from set S0 of states
– Set of states reachable in at most 1 step:
S1 = S0 { X | x in S0 N(x, X) = 1}
Expressed as Boolean functions:
Given S0 (x0, x1, x2),
S1 (X0, X1, X2) = S0 (X0, X1, X2)
x0, x1, x2 . [S0 (x0, x1, x2)
N(x0, x1, x2, X0, X1, X2)]
Given BDDs for S0 and N, BDD for S1 can be obtained
S0S1
MIT_IEP_Formal_Verification, 13th Dec 2006
46
Forward Reachability
– Compute S1 from S0, S2 from S1, S3 from S2, …
– Predicate transformer F: Si+1 = F (Si)
– Continue until Sk+1 = F (Sk) = Sk
– Least fixed point of F
– Sk = Set of all states reachable from S0
• Computed symbolically -- using BDDs– Very large state sets can be represented compactly
S0
Reachablestates
MIT_IEP_Formal_Verification, 13th Dec 2006
47
Backward Reachability
– Give a set Z0 of states– Compute set of states from which some
state in Z0 can be reached.– Analogous to forward reachability with minor
modificationsZ0
MIT_IEP_Formal_Verification, 13th Dec 2006
48
Checking Safety Conditions
– Safety condition must ALWAYS hold– E.g. Two bits in one-hot encoded state cannot be 1
– Z = set of states violating safety condition– Given S0 = set of initial states of circuit,
– Compute R = set of all reachable states
– Determine if Z intersects R, i.e. (Z R) 0 • If YES, safety condition violated
Satisfying assignment of (Z R): counterexample• If NO, circuit satisfies safety condition
– All computations in terms of BDDs
MIT_IEP_Formal_Verification, 13th Dec 2006
49
Checking Safety Conditions
– Start from Z = set of “bad” states
– Find by backward reachability set of states B
that can lead to a state in Z– Determine if S0 intersects B
S0R
Z
S0
Z
B
Forward Reachability Backward Reachability
MIT_IEP_Formal_Verification, 13th Dec 2006
50
Symbolic Model Checking
– Given a model with set S0 of initial states and a CTL formula f– To determine if f is satisfied by all states in S0
– Convert f to g that uses only EX, EG, E[p U q]– CHECK(g) returns set of states satisfying g
– If g = atomic proposition (e.g., x1. x2 + x3), CHECK returns BDD for g
– If g = EX p, EG p, E[p U q], CHECK uses reachability analysis to return BDD for set of states
– Worst-case exponential complexity– Finally, determine if S0 CHECK(g)
MIT_IEP_Formal_Verification, 13th Dec 2006
51
Model Checkers – State of the Art
• Symbolic model checkers can handle designs with
500 ~ 1000 flip flops
• For specific design domains, larger state spaces
have been analyzed.
• Defining properties in CTL/LTL can be difficult and
error prone
• Simpler property specification languages can
help (E.g., PSL)
• Monitor based model checking.
MIT_IEP_Formal_Verification, 13th Dec 2006
52
Queued Write Request Property of SCR
Wrt_Decode
Wrt_Arbiter
Wrt_Cmd_DecodeMaster
Slave
4 deep fifo where write_cmd_req is queued in
11 deep fifo to queue in the current owner of a processoras a slave.
MIT_IEP_Formal_Verification, 13th Dec 2006
53
Queued Write Request Property
• Property on queuing of write requests from masters
in a split bus transaction mode
• “When write command queue for a given master
is empty, no write data transfers should originate
from that master”.
• Abstraction for above property : Behavior related to
property needed 3 out of a total of 72 submodules
in SCR. 69 sub-modules were abstracted out.
• Property FSM : Assertions in OVL cannot capture
this property. Separate Property FSM was coded.
MIT_IEP_Formal_Verification, 13th Dec 2006
54
Assume-Guarantee Basic Idea
P
Q
i1
+
o2
o1
o1
i2
i2
P Qi1 o2
o1
i2
Global Property defined on o2
Decompose
Assumption
Guarantee
Guarantee
Assumption
P has to satisfy a local property on o1 which is treated as an assumption by Q to prove the global property on o2
MIT_IEP_Formal_Verification, 13th Dec 2006
55
AOF Design
• Multiple Clock Processing (Root Module –
AO_CLK)
• 16 bit Audio Data Processing (Root Module –
AO_CH)
• Interrupt Request Processing (Root Module –
AO_IRQ)
MIT_IEP_Formal_Verification, 13th Dec 2006
56
Essential Module Interaction
AO_CH_DMA
AO_CH_SF
AO_CK_DIV
Global_CLK
IO_CLK
IO_CLK
BCLKDLRCLKULRCLKD
GAT
STANDBY
UDR
DREQ DACK
MIT_IEP_Formal_Verification, 13th Dec 2006
57
AOF Property
• Informal Statement for Property 1
• When writing parallel data, converting them to
serial ones, and outputting, the under-run error
occurs if the next parallel data are not written.
• Precise Statement for Property 1
• As long as DACK (Data Acknowledge) is
received properly in response to DREQ (Data
Requests), UDR (Data Starvation Signal) should
never be asserted.
MIT_IEP_Formal_Verification, 13th Dec 2006
58
Assume-Guarantee Approach
• Possible to use assume and guarantee in real
designs.
• Individual module verification cheaper.
• Can fully exploit multiple clocks.
• Promising for SoC designs and designs based on
IP re-use.
MIT_IEP_Formal_Verification, 13th Dec 2006
59
Verification Flow
Original HDL DescriptionDesign Abstraction
Front-end
Reduced HDL Description
IFVIFV Script for
Properties
VerificationResults
CounterExample
Logic Simulator
FeedbackFor DesignError Correction
Design ErrorNo Design Error
MIT_IEP_Formal_Verification, 13th Dec 2006
60
Problems in FV - Solutions
• Simulation can handle entire designs.
• State explosion in model checking limits designs that can be
verified ( less than 500 ~ 1000 state bits).
• Solutions :
• Design Abstraction
• Reduced description (verification model)
• Fewer state bits ensures completion of state
traversal process.• In FV “Divided we solve, united we blowup” – Partition to
contain state explosion (Compositional Verification).
MIT_IEP_Formal_Verification, 13th Dec 2006
61
Important Verification Tasks
Property Generation and Verification Model
Generation
Property Generation : Identifying and defining
properties that the implementation model has to
satisfy.
Classification of Properties
• Safety
• Liveness
• Fairness
MIT_IEP_Formal_Verification, 13th Dec 2006
62
Formal Verification Issues
Major Efforts
• Reconstruct representations at various levels of
abstraction.
• Data flow graphs.
• Data transfer graphs.
• State transition graphs of controllers.
• Module hierarchies.
• Block diagram of modules and sub-systems.
MIT_IEP_Formal_Verification, 13th Dec 2006
63
Formal Verification Issues
• Reconstruction
• Reveals underlying interaction in modules.
• More abstracted information.
• Aids in defining properties.
• Evolve verification strategies for each design.
MIT_IEP_Formal_Verification, 13th Dec 2006
64
Verification Model Generation
• Implementation Model Transformation
• For example, Multiple Clock Design Single Clock
Design.
• Carried out before verification model generation.
• Design Abstraction
• Implementation Model typically has two behavioral
components,
• Dataflow part and Control Part
• Dataflow Part : Generally easy to debug.
• Control Part : Dominating Source of Error.
• Design abstraction targets dataflow part – Remove as much
as possible.
MIT_IEP_Formal_Verification, 13th Dec 2006
65
Design Abstraction
• Removal or black boxing of module instances.
• Modification of module interface and module declaration.
• Partial removal of data flow behavior from some modules.
• Convert conditional assignments into fixed assignments.
• Reduce widths of some data registers and bit vector
constants.
• Property related design abstraction.
• Conversion of multiple clock design into a single clock
version.
• Automatic generation of properties.
MIT_IEP_Formal_Verification, 13th Dec 2006
66
Areas Of Application For FV
• BIST and DFT Logic Controllers and Hookup Logic
• Buses and Bridges
• VLIW processors – new instructions and pipeline
behavior
• Shared memory controller
• Floating point numeric coprocessor
• Power management unit
MIT_IEP_Formal_Verification, 13th Dec 2006
67
Verification Issues
• Verification Time – 3 man months.
• Design Complexity – 700 state bits in the implementation
model.
• Implementation model in Verilog RTL
• Familiarity – Low.
• Activity break up on 3 man months.
• 2 man months – To understand lowest level signals.
• 1 man month – For actual verification.
• Approach clearly not suitable for SoC designs.
• Concurrent design and verification efforts not possible in the
above scenario.
MIT_IEP_Formal_Verification, 13th Dec 2006
68
Other Care Abouts
• Bug hunting within IPs
• Bug hunting with IPs
• Coverage Issues
• What do the designers want?
• What do the functional verification engineers want?
• What can the formal verification engineers do about
these wants? Where do they position themselves?
MIT_IEP_Formal_Verification, 13th Dec 2006
69
Module Verification Issues
• Verification team develops deep understanding of
implementation model.
• Design team codifies
• Functionality of each module and interaction
between modules in a suitable and easily
understandable format.
• Qualifies the defined set of properties as
adequate.
MIT_IEP_Formal_Verification, 13th Dec 2006
70
Other Interesting Approaches
• Bounded Model Checking
• Unbounded Model Checking
• Symbolic Simulation based Model Checking
• Generalized Symbolic Trajectory Evaluation based
Model Checking
• Theorem Proving
• Formal Verification of Hybrid Systems (Mixed
signal designs - discrete and continuous behavior).
MIT_IEP_Formal_Verification, 13th Dec 2006
71
Verification Hierarchy
Degree of Automation
Coverage/ExpressivePower
Simulation
Equivalence Checking of structurally similar circuits
Equivalence Checking
Assume-Guarantee basedsymbolic simulation/Model Checking
Temporal Logic BasedModel Checking
First-Order Theorem Proving
Higher-Order Theorem Proving
MIT_IEP_Formal_Verification, 13th Dec 2006
72
Conclusions
• Verification and design needs to be done
concurrently.
• Need to influence implementation choices towards
easing the formal verification process.
• Need to capture formally design information at
various levels of abstraction.
• FV can prove properties which are difficult for
simulation.