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

Definition
Formal Verifier (stolen from ???):
An automated decision procedure that can prove 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

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

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

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

Property Checking
assert statements statically evaluated Can be inline with code or in separate file 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

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

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)

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 includes rescheduling 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

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)

Formal verification In commercial design flow

Only Equivalence checking is mature
With few exceptions only combinatorial equivalence 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

Current SoC flow

netlists netlists IP HDL

IP synthesis w / DFT

netlists netlists netlists

IP formal verification (RTL vs gate)

Chip level synthesis w / DFT

Selected funct. TB

netlist2

Place & Route w / Physical Synthesis

ATPG

netlist3

gdsii

Test vector format Chip formal verif. (gate vs gate) LVS / DRC Gate level simulation (ATPG and functional)

Tapeout

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

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

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