1. Formal Verification Theory
and Practice
Tim Blackmore

2. Theory

3. Considerations for formal verification
When writing properties need to consider
1. Complexity
2. Level of abstraction
3. Completeness
4. Consideration of reachable states
October 2008 Copyright © Infineon Technologies 2008. All rights reserved. Page 3

4. 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 model
May be issues due to property complexity
¬ Very long properties may need to be split into shorter properties
¬ Large multipliers will need special consideration
October 2008 Copyright © Infineon Technologies 2008. All rights reserved. Page 4

5. 2. Level of abstraction
Properties should be closer to the specification than RTL
Use of temporal languages (PSL, SVA, …)
Whole transaction described in single property
Bus 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)
October 2008 Copyright © Infineon Technologies 2008. All rights reserved. Page 5

6. 3. Completeness
A complete set of properties describes
All 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 all
possible input sequences
Write
Read
No-op
All the slave outputs are described in each property
October 2008 Copyright © Infineon Technologies 2008. All rights reserved. Page 6

7. 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 simulation
1-2 weeks work
Also 1-2 weeks work to write a complete set of transaction-level
properties to check protocol adherence exhaustively but …
October 2008 Copyright © Infineon Technologies 2008. All rights reserved. Page 7

8. 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 state
Not 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 verification
BUT not always e.g. combinatorial designs
October 2008 Copyright © Infineon Technologies 2008. All rights reserved. Page 8

9. 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 metric
Unlikely to be exhaustive – not formal verification
October 2008 Copyright © Infineon Technologies 2008. All rights reserved. Page 9

10. Practice

11. Where we apply formal verification
In theory could formally verify a complete system
Large undertaking requiring many experts
In practice tends to be targeted - based on RFE
10-20% of verification effort spent on formal
Lower effort blocks
Combinatorial blocks – see next slide
Can still provide high return
Higher effort blocks with high return
Critical 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
October 2008 Copyright © Infineon Technologies 2008. All rights reserved. Page 11

12. Combinatorial Blocks
Combinatorial ALUs can be (almost) exhaustively verified quickly
E.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 codes
Encoder/decoder pair can be showed to function correctly for
all data values and error conditions in hours (including
property development)
Can be safety-critical
October 2008 Copyright © Infineon Technologies 2008. All rights reserved. Page 12

13. Results we achieve
Formal verification always finds bugs
Number found depends on
¬ Block complexity
¬ Extensiveness of simulation-based verification
¬ How long block has been in the field
Formal verification rarely misses a bug
Bugs can be missed due to human error
¬ Property set incorrect and matches RTL (very rare)
¬ Incomplete property set (now tool assisted)
October 2008 Copyright © Infineon Technologies 2008. All rights reserved. Page 13

14. 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 verification
Clock domain crossing
Simplification of coverage closure
…
Often reduce effort and increase confidence
October 2008 Copyright © Infineon Technologies 2008. All rights reserved. Page 14