Bristol 2009 q1_blackmore_tim

338 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
338
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Bristol 2009 q1_blackmore_tim

  1. 1. Formal Verification Theory and Practice Tim Blackmore
  2. 2. Theory
  3. 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. 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. 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. 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. 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. 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. 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. 10. Practice
  11. 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. 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. 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. 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

×