Formal Verification 2003-03-27-Bw

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


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


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


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


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


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/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


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)


9/14


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


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


10/14


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)


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)


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


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


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


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

Formal Verification 2003-03-27-Bw

Documents

Transcript of Formal Verification 2003-03-27-Bw