1 1 Introduction to Formal Introduction to Formal Verification Verification P. P. P. P. Chakrabarti Chakrabarti Dept. of Computer Sc. & Dept. of Computer Sc. & Engg Engg ., ., & Advanced VLSI Design Laboratory & Advanced VLSI Design Laboratory Indian Institute of Technology Kharagpur Indian Institute of Technology Kharagpur Presented by:
51
Embed
Introduction to Formal Verificationsak/courses/foav/Intro-Formal...Introduction to Formal Verification P. P. Chakrabarti Dept. of Computer Sc. & Engg., & Advanced VLSI Design Laboratory
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
11
Introduction to Formal Introduction to Formal VerificationVerification
P. P. P. P. ChakrabartiChakrabartiDept. of Computer Sc. & Dept. of Computer Sc. & EnggEngg.,.,& Advanced VLSI Design Laboratory& Advanced VLSI Design LaboratoryIndian Institute of Technology KharagpurIndian Institute of Technology Kharagpur
Presented by:
22Formal-V Group, IIT KGP NWCV 2005NWCV 2005
Typical SOC ArchitectureTypical SOC Architecture
ProcessorProcessor
MemoryMemory
BRIDGE
BRIDGE
PowerMgmtPowerMgmt
Analog blocks withDigital interfaces
Digital blocks
33Formal-V Group, IIT KGP NWCV 2005NWCV 2005
Two ExamplesTwo ExamplesLow-power, low-cost embedded
Example: Priority Arbiter [ Schematic and Example: Priority Arbiter [ Schematic and HighHigh--Level Spec ]Level Spec ]
r1
r2
g1
g2
The system requires to The system requires to arbitratearbitrate between requests between requests r1r1and and r2r2 and provide grants and provide grants g1g1 and and g2g2 in such a way in such a way that that r2 r2 isis defaultdefault but but r1r1 is given is given higher priorityhigher priority over over r2. r2. Mutual exclusionMutual exclusion must be guaranteed.must be guaranteed.
2727Formal-V Group, IIT KGP NWCV 2005NWCV 2005
Example: Priority Arbiter [ Verilog Code Example: Priority Arbiter [ Verilog Code and Formal Model ]and Formal Model ]
•• Whenever r1 is asserted, g1 is given in the next cycleWhenever r1 is asserted, g1 is given in the next cycle
•• When r2 is the sole request, g2 comes in the next cycleWhen r2 is the sole request, g2 comes in the next cycle
•• When none of them are requesting, the arbiter parks the grant When none of them are requesting, the arbiter parks the grant on g2 on g2
•• g1 and g2 can not be true at the same time (mutual exclusion)g1 and g2 can not be true at the same time (mutual exclusion)
3434Formal-V Group, IIT KGP NWCV 2005NWCV 2005
c
s
b
a5
3
4
2
1 1
1
1
1
12
9
5
gr
req
req
reqreq
req
gr
grgr
grgrgr
• From s the system always makes a request in future• All requests are eventually granted• Sometimes requests are immediately granted• Requests are not always immediately granted• Requests are held till grant is received
Analyzing Request and GrantsAnalyzing Request and Grants
3535Formal-V Group, IIT KGP NWCV 2005NWCV 2005
Timing PropertiesTiming Properties
• Whenever a hpreq is recorded, the hpgrant should take place within 4 units of time.
• The arbiter will provide exactly 64 units of time to high-priority users in each grant.
3636Formal-V Group, IIT KGP NWCV 2005NWCV 2005
What is temporal logic?What is temporal logic?
•• Logic with Logic with temporaltemporal operators (operators operators (operators that talk about time)that talk about time)
–– EgEg. Tense Logic (A. N. Prior, 1957). Tense Logic (A. N. Prior, 1957)
•• P P “It has at some time been the case that …”“It has at some time been the case that …”
•• F F “It will at some time be the case that …”“It will at some time be the case that …”
•• H H “It has always been the case that …”“It has always been the case that …”
•• G G “It will always be the case that …”“It will always be the case that …”
3737Formal-V Group, IIT KGP NWCV 2005NWCV 2005
Temporal Logic for ValidationTemporal Logic for Validation
•• Formalism for describing sequences of transitions Formalism for describing sequences of transitions between states in a reactive system between states in a reactive system
•• Time is not mentioned explicitlyTime is not mentioned explicitly
–– eventuallyeventually some designated state is reachedsome designated state is reached–– an error state is an error state is nevernever enteredentered–– eventuallyeventually or or nevernever are specified using special temporal are specified using special temporal
operatorsoperators–– temporal operators can also be combined with Boolean temporal operators can also be combined with Boolean
connectives or nested arbitrarilyconnectives or nested arbitrarily
3838Formal-V Group, IIT KGP NWCV 2005NWCV 2005
Informal SemanticsInformal Semantics
•• p holds in the next statep holds in the next state
X pX p
p holdsp holds
3939Formal-V Group, IIT KGP NWCV 2005NWCV 2005
Informal SemanticsInformal Semantics
• p holds always (globally)holds always (globally)alternativelyalternatively
•• ¬¬p does not hold eventuallyp does not hold eventually
G pG p
p holdsp holds
4040Formal-V Group, IIT KGP NWCV 2005NWCV 2005
Informal SemanticsInformal Semantics
•• p holds eventually (in future)p holds eventually (in future)alternativelyalternatively
•• ¬¬p does not hold alwaysp does not hold always
F pF p
p holdsp holds
4141Formal-V Group, IIT KGP NWCV 2005NWCV 2005
Informal SemanticsInformal Semantics
•• q holds eventually q holds eventually andand p holds until q holdsp holds until q holds
p U qp U q
p holdsp holds
q holdsq holds
4242Formal-V Group, IIT KGP NWCV 2005NWCV 2005
Duality between Temporal OperatorsDuality between Temporal Operators
G p
p holds always
¬p does not hold eventually
¬( ¬p holds eventually )
¬F( ¬p )
4343Formal-V Group, IIT KGP NWCV 2005NWCV 2005
Nesting of Temporal OperatorsNesting of Temporal Operators
F G pF G p
G F pG F p
Along the path there exists a state from which Along the path there exists a state from which pp will hold foreverwill hold forever
Along the path for all states there will be eventually some statAlong the path for all states there will be eventually some state e where where pp holds holds
alternativelyalternatively
Along the path p will hold Along the path p will hold infinitely ofteninfinitely often
4444Formal-V Group, IIT KGP NWCV 2005NWCV 2005
ExampleExample
r1
r2
g1
g2
•• Either g1 or g2 is alwaysEither g1 or g2 is alwaysfalse (mutual exclusion)false (mutual exclusion)
G[G[¬¬g1 g1 ∨∨ ¬¬g2]g2]
•• Whenever r1 is asserted, g1 is given in the next cycleWhenever r1 is asserted, g1 is given in the next cycle
G[ r1 G[ r1 ⇒⇒ Xg1 ]Xg1 ]
•• When r2 is the sole request, g2 comes in the next cycleWhen r2 is the sole request, g2 comes in the next cycle
G[ (G[ (¬¬r1 r1 ∧∧ r2) r2) ⇒⇒ Xg2 ]Xg2 ]
•• When none are requesting, the arbiter parks the grant on g2 When none are requesting, the arbiter parks the grant on g2 G[ (G[ (¬¬r1 r1 ∧∧ ¬¬r2) r2) ⇒⇒ Xg2 ]Xg2 ]
4545Formal-V Group, IIT KGP NWCV 2005NWCV 2005
c
s
b
a5
3
4
2
1 1
1
1
1
12
9
5
gr
req
req
reqreq
req
gr
grgr
grgrgr
From s the system always makes a request in future: AFreqAll requests are eventually granted:AG(req → AFgr)Sometimes requests are immediately granted: EF(req → EXgr)Requests are not always immediately granted: ¬ AG(req → AXgr)Requests are held till grant is received: AG(req → AF(req U gr))
Analyzing Request and GrantsAnalyzing Request and Grants
4646Formal-V Group, IIT KGP NWCV 2005NWCV 2005
Timing PropertiesTiming Properties
• Whenever a hpreq is recorded, the hpgrantshould take place within 4 units of time.AG(posedge(hpreq) → A(true U[0,4] posedge(hpgrant)))
• The arbiter will provide exactly 64 units of time to high-priority users in each grant.AG(posedge(hpusing) →
A(¬negedge(hpusing) U[64,64] negedge(hpusing)))
4747Formal-V Group, IIT KGP NWCV 2005NWCV 2005
Model Checking of a Temporal Logic FormulaModel Checking of a Temporal Logic Formula
temporal formula
MC
G(p -> F q)yes
nop
q
finite-state model
algorithm
pq
counterexamplecounterexample
OKOK
4848Formal-V Group, IIT KGP NWCV 2005NWCV 2005
SatisfiabilitySatisfiability Checking of a Temporal Logic FormulaChecking of a Temporal Logic Formula
Temporal formula
SATChecker
yes
no
a model of a model of the formula the formula
existsexists
no model no model exists for the exists for the
formulaformula
unsatisfiableunsatisfiable
satisfiableatisfiable
4949Formal-V Group, IIT KGP NWCV 2005NWCV 2005
AssertionAssertion--Based Verification (ABV) Based Verification (ABV)
•• Design intent is expressed using assertionsDesign intent is expressed using assertions•• Simulation is done as usualSimulation is done as usual
–– Assertions find more bugs fasterAssertions find more bugs faster–– Assertions isolate the source of the problemAssertions isolate the source of the problem
•• Use formal methods to guide simulationUse formal methods to guide simulation
AssertionMonitor
Test Bench
ModuleunderTest
Interface bind
5050Formal-V Group, IIT KGP NWCV 2005NWCV 2005
Design Team
SpecificationDesign
Model Checker
Coverage Estimator Correct the Design
Property Refinement
Refined Property
Design Team
Validation
Correct Incorrect
Identify theportion of the design where it holds
Property IncorrectNot a
correctnessproperty
Property correct
Refine Specwith the property
Add the negationof the property
Property Refinement And Coverage
5151Formal-V Group, IIT KGP NWCV 2005NWCV 2005
Advanced VLSI Design LabAdvanced VLSI Design Lab
Analog / RFDesign
Analog / RFDesign Digital
DesignDigitalDesign
CADCAD
Direct conversion radio
Power management
Analog behavioral models
Formal verification
Test AutomationAnalog CAD
Embedded System Design
Cryptography
Digital Communication
Processor Design
25 chips taped out in the last 3 years!!25 chips taped out in the last 3 years!!