formal verification 2003-03-27-bw
TRANSCRIPT
-
7/30/2019 Formal Verification 2003-03-27-Bw
1/14
Formal verification
Overview of methods
Commercial usage
Outline
What is formal verification
Why formal verification
Different types of formal verification
Only address digital functionality
Formal verification in design flow
-
7/30/2019 Formal Verification 2003-03-27-Bw
2/14
Definition
Formal Verifier (stolen from ???):
An automated decision procedure that canprove or disprove statements in some logical
system of reasoning.
Motivation
Find more bugs
Dynamic verification (simulation) always has a
limited coverage
Static verification is complete This has been realized for years for timing
verification
Drawback: Only certain classes of errors can be
caught
-
7/30/2019 Formal Verification 2003-03-27-Bw
3/14
Motivation (2)
Find bugs faster
Static verification is much faster Simulation test benches are complex
Requires lots of man power
Requires more skills than RTL coding
Ideally uses a different language
freeze silicon ECOs are normal part of
time to volume driven design flow
Doesnt work with gate-level simulation
Motivation (3)
Find bugs earlier (property checking)
Automatically check design intent against
implementation
Can be applied to all levels of design
-
7/30/2019 Formal Verification 2003-03-27-Bw
4/14
Types of formal verification
Order by inverse ease of use
Theorem proving Model/Property checking
Equivalence checking
Theorem Proving
Application of mathematical methods
under operator guidance
Implication, Induction ...
High level of abstraction spec to
implementation
High degree of manual interaction with the
tool
-
7/30/2019 Formal Verification 2003-03-27-Bw
5/14
Theorem Proving (possible)
applications
Post design (verification a posteriori)
Formal synthesis (verification a priori) Specification decomposition for a model
checker
HW/SW co-verification
Floating point arithmetic
Fixed point in DSP (rounding)
Theorem Proving (3)
Advantages
Most general proof technique
Correct by construction design-space exploration
Only technique to handle behavioral verification
Disadvantages - Many and severe Computationally unpredictable
No links to HDLs, no specification standards
Need multiple PhDs just to get it out of the box
Has not moved out of R&D - commercial tools rare
-
7/30/2019 Formal Verification 2003-03-27-Bw
6/14
Property Checking
assert statements statically evaluated
Can be inline with code or in separatefile
Can use (extension of) standard HDL or
a custom language
Assertions has time (in clocks) as a
property
Property Checking (2)
Advantages
Highly automated (at least if no pb)
Verifying sequential behaviors
Disadvantages
Limited capacity only at module level
No standard specification language
Difficult to assess property coverage
-
7/30/2019 Formal Verification 2003-03-27-Bw
7/14
Property Checking news
Generate lots of properties automatically
Design Intent properties (examples)
No bus contention
Poorly formed case / if then else
Unreachable code
Structural properties (examples)
Data resynchronization when crossing between clock
domains
Reset properly clocked
Clock gating rules
FSM unreachable states
Property Checking news 2
Hierarchical propagation of constraints in
bottom-up implementation
Block A asserts that certain properties under a certain
set of constraints on its inputs.
When block A is used in block B, block As constraints
become properties for the signals in block B
Benefits
Early verification of submodules (doesn't need to wait for
testbenches)
Reduce compute time explosion
-
7/30/2019 Formal Verification 2003-03-27-Bw
8/14
Equivalence Checking
Check that to implementations of a
design are (logically) identical RTL to RTL
RTL to gate
gate to gate
At all stages in ASIC flow
Easy to use
Equivalence Checking - steps
Read in the two designs
(Constrain the designs)
Map registers and ports (by name or
topology)
Compare equations for each register input
Report results
(Debug)
-
7/30/2019 Formal Verification 2003-03-27-Bw
9/14
Equivalence Checking
gate versus gate
Read step is trivial
Constraints normally easy (or absent) Register mapping is simple if both designs
have
Same synthesis tool
Same library
Compare rarely give a false negative
Fast and memory efficient
Equivalence Checking
RTL versus gate Read in step can be complicated
Synthesis semantics are not defined for VHDL or
verilog
Constraint can be tricky if synthesis includesrescheduling or pipelining
Register mapping also more complicated
Should mimic synthesis tool for name mapping
How register names are formed from variable [index]
How hierarchical names are constructed when flattening
How too long names are truncated
-
7/30/2019 Formal Verification 2003-03-27-Bw
10/14
Equivalence Checking
RTL versus gate (2)
Compare (solve) can be hard
Library cells models too complex Register cells in library doesnt match simple
@(posedge CK or negedge reset_n)
False negative due to dont care semantics
False negatives due to state encoding
Running out of memory / time for some
functions (primarily custom multipliers)
Equivalence Checking
RTL versus RTL
Normally used for
Code cleanup of legacy RTL modules
Code translation from verilog to VHDL
Meets the same challenges as RTL versus
gate except that
Normally used only at block level
Dont have any library issues
Same synthesizer (for same language)
-
7/30/2019 Formal Verification 2003-03-27-Bw
11/14
Formal verification
In commercial design flow
Only Equivalence checking is mature
With few exceptions only combinatorialequivalence checking is used
Used extensively for gate versus gate at
complete chip level
Normally easy to apply even for RTL versus
gate at the block level
Special cases of property checking being
introduced now at block level
IP flow FV usage
Today
Part of the deliverables is a FV script
Applies equivalence checking to verify that
synthesis to a new target library is valid (Just as TV script does for timing)
Has all the issues of debugging RTL vs gate
Tomorrow
Automated property checker (and lint)
Check that the block adheres to coding style and
design rules
-
7/30/2019 Formal Verification 2003-03-27-Bw
12/14
Current SoC flowIP synthesis w / DFT
IP formal verification
(RTL vs gate)
netlists
netlist2
Chip level synthesis
w / DFT
Place & Route
w / Physical Synthesis
gdsii
Test vector format
Gate level simulation
(ATPG and functional)
Chip formal verif.
(gate vs gate)LVS / DRC
Tapeout
netlistsnetlists
netlist3
Selected
funct. TB
ATPG
netlistsnetlistsIP HDL
SoC flow FV usage
RTL versus gate
After IP synthesis
Constrain BIST_MODE_N = 0 and SCAN_MODE=0
Verify that synthesis of normal mode (and functional
test modes) logic
Run IP by IP
Normally fully automated
Was prepared in IP flow
Should be part of incoming inspection for external IP
Own legacy IP is not FV clean
May see library issues of RTL vs gate
-
7/30/2019 Formal Verification 2003-03-27-Bw
13/14
SoC flow FV usage
Gate versus gate
After placement / layout
Normally constrain SCAN_MODE=0 Verify that no functional effect of
Clock tree synthesis
Drive size and buffer insertion
Physical synthesis
Always run on chip complete level
Normally fully automated no debug
Soc flow FV usage
RTL versus gate
Normally after (freeze silicon) ECO
Hand modified netlist is checked against
Old RTL to verify no side effects
New RTL to verify functional equivalence
with what is re-verified
Can be hard to run if not planned for
Often run in multiple steps
Can get away with module level
-
7/30/2019 Formal Verification 2003-03-27-Bw
14/14
Soc flow FV near future
Automated property checking
Chip level Clock domain interfaces
Power domain interfaces
Reset domain rules
3rd party soft IP
Incoming inspection Compliance with clock/reset documentation
Compliance with other good practice (lint)
Other future applications
Validating constraints for other static tools
Multi cycle paths, false paths
Creating higher quality code
What part of the spec is covered Validating IP integration requirements