Formal Verification Theory and Practice

Formal Verification Theoryand PracticeTim Blackmore

Theory

Page 3Copyright © Infineon Technologies 2008. All rights reserved. October 2008

Considerations for formal verification

When writing properties need to consider1. Complexity2. Level of abstraction3. Completeness4. Consideration of reachable states


1. Complexity

For a good property checker complexity is not normally a major issue

May be compilation issues e.g. for memories¬ Black box and modelMay be issues due to property complexity¬ Very long properties may need to be split into shorter properties¬ Large multipliers will need special consideration


2. Level of abstraction

Properties should be closer to the specification than RTLUse of temporal languages (PSL, SVA, …)

Whole transaction described in single propertyBus access (request, address and data phase)Instruction execution (not individual pipe stages)

Utilise built-in operators (e.g. arithmetic and logic operators to verify an ALU)


3. Completeness

A complete set of properties describesAll interactions of DUV with system (outputs, registers)For all valid input sequences

E.g. to verify a bus slave may need 3 properties to describe allpossible input sequences

WriteReadNo-op

All the slave outputs are described in each property


Assertions

Level of abstraction and completeness of properties applies equally to assertions to be checked during simulation

E.g. a good way to develop bus protocol checkers is to write a complete set of transaction-level assertions

Ensure that checking bus agents are obeying protocol in every cycle of simulation1-2 weeks work

Also 1-2 weeks work to write a complete set of transaction-level properties to check protocol adherence exhaustively but …


4. Reachable states

… they would all fail

E.g. read, write and no-op properties need to start in general reachable state so can be placed end-on-end

Property checkers cannot determine the reachable states of a design

False failures due a property starting in an illegal stateNot a problem for simulation - starts at reset and drives only legal inputs

Property checker requires user input to exclude such false failures

Often the major effort for formal verificationBUT not always e.g. combinatorial designs


Semi-formal verification

Property checker can be used from reset (semi-formal verification, hybrid, ‘bug-hunting’)

Can be effective at finding bugs but no practical, meaningful coverage metricUnlikely to be exhaustive – not formal verification

Practice


Where we apply formal verification

In theory could formally verify a complete systemLarge undertaking requiring many experts

In practice tends to be targeted - based on RFE10-20% of verification effort spent on formal

Lower effort blocksCombinatorial blocks – see next slideCan still provide high return

Higher effort blocks with high returnCritical sub-blocks e.g. complex blocks where bugs lead to unavoidable data corruption (fetch unit, cache controller)Highly re-usable blocks (bus MIFs and SIFs)Effort comparable to developing stand-alone test bench and applying coverage-driven verification


Combinatorial Blocks

Combinatorial ALUs can be (almost) exhaustively verified quicklyE.g. arithmetic in processor (most integer and floating point arithmetic, load and store address calculation, branch address calculation)Ensures instruction set compliance between different core versions

Error-correction codesEncoder/decoder pair can be showed to function correctly for all data values and error conditions in hours (including property development)Can be safety-critical


Results we achieve

Formal verification always finds bugsNumber found depends on¬ Block complexity¬ Extensiveness of simulation-based verification¬ How long block has been in the field

Formal verification rarely misses a bugBugs can be missed due to human error¬ Property set incorrect and matches RTL (very rare)¬ Incomplete property set (now tool assisted)


Use of formal verification grows …

Once you start using a formal tool you see new uses Register access verification – push button solution from register database to formal verificationClock domain crossingSimplification of coverage closure…

Often reduce effort and increase confidence

Technology

Formal Verification Theory and Practice