1 / 43

Advancements in Formal Methods for Hardware Design

This document discusses the application of formal methods in hardware design, emphasizing their role in improving system reliability and reducing development time. Formal methods, including mathematical and logical techniques, enhance the verification process, enabling automatic test case generation and bug detection. The paper reviews various approaches, such as model checking and interactive theorem proving, highlighting their industrial applicability and cost-saving benefits. Additionally, it outlines strategies for integrating these methods into the design flow, addressing the complexities involved in both low-level and high-level abstractions.

linus
Télécharger la présentation

Advancements in Formal Methods for Hardware Design

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Formal Methods in Hardware Design Mary Sheeran, Chalmers www.cs.chalmers.se/~ms

  2. Formal Methods • Mathematical and logical methods used in system development • Aim to increase confidence in riktighet of system • Apply to both hardware and software

  3. Formal methods • Complement other analysis methods • Are good at finding bugs • Reduce development (and test) time • Should ideally be automatic

  4. The main point is NOT • correctness proof of entire systems • replacing test entirely

  5. BUT • one proof can replace many test cases • formal methods can be used in automatic test case generation

  6. Successful formal methods • Integrated in the design flow • Avoid new demands on the user • Work at large scale • Save time or money in getting a good quality product out

  7. Some fundamental facts Low level of abstraction, Finite state systems => automatic proofs possible High level of abstraction, Fancy data types, general programs => automatic proofs IMPOSSIBLE

  8. Two main approaches • Squeeze the problem down into one that can be handled automatically • industrial success of model checkers • automatic proof-based methods very hot • Use powerful interactive theorem provers and highly trained staff • for example Harrison’s work at Intel on floating point algorithms

  9. G(p -> F q) yes property MC algorithm no p p q q counterexample finite-statemodel Model Checking (Ken McMillan)

  10. Model checkers usually based on BDDs • Binary Decision Diagrams • Data structure for representing and manipulating boolean functions • More later...

  11. High level requirements High level design Compilation Compilation Proof Logical formula Logical formula Proof-based method

  12. Interactive theorem proving • Formalise system and requirements in a suitable logical language • Gradually construct a proof that the system meets the requirements • Computer checks all steps • Slow, expensive, divorced from production • Sometimes the only way! • HOL, PVS, Coq, Isabelle ....

  13. Refinement • Formal method used during design • Start with abstract specification • Decompose into communicating parts • Refine parts, adding details, and check each step (proofs) • stop at components that are already implemented • B method (Paris Metro driverless train)

  14. Concentrate on hardware • An easier application for formal methods • Price of getting it wrong is high! • Stronger tradition of analysis methods (e.g. use of boolean algebra in synthesis, need to do ATPG)

  15. Nov. ’94 Intel FPU bug • 824633702441.0 times (1/824633702441.0) = 0.99999999274709702 • Fault in look-up table • COST $475.000.000

  16. $15 per transistor!! • Answer ?? IP blocks and system level design language • ”We are heading for a brick wall” • ”We can’t fill the fabs” • ”A first requirement is a formal semantics”

  17. Interactive methods • Hawk (Haskell in top level design of pipelined superscalar processors, OGI/Intel) • IBM and AMD both do processor verification using the interactive theorem prover ACL2

  18. Automatic methods • Finite state • BDD based verification widespread • emphasison cost saving • not on guaranteed correctness • used in production 50% verification engineers

  19. Binary Decision Diagrams • Idea from 70s (maybe earlier) • Adapted by Bryant ’86 • Take a formula • Make decision tree for fixed variable order • Reduction rules • merge duplicate nodes • both children point to same node -- remove redundant node

  20. Plus points • Efficient algorithms exits (and, or, not, exists, forall …) • For given variable order, BDD is canonical • Many common functions have small BDDs

  21. Minus points • Some functions are exponential (independent of variable ordering) • multipliers 16 by 16 bit around 3.300 Mbytes • Variable order essential • change order : linear to exponential • packages use dynamic reordering • Injecting error can cause BDD to explode

  22. Exercise • Make BDD for x xor y xor z

  23. Rest of lecture • Some selected BDD based methods (Alan Hu paper) • What actually happens at Intel • A glimpse of our research

  24. Combinational equivalence checking • Build BDDs of outputs in terms of (same) primary inputs. Build up gradually and just compare • Even for suitable circuits, limit is a few hundred primary inputs -- need tricks

  25. Symbolic simulation • Constants 1 0 • unknown X • symbolic values a,b,c… • Adapt logic simulation to represent values on wires • BDDs represent functions of symbolic values

  26. X halves # simulation runs but loses info. • a halves # runs but makes BDDs bigger • Tradeoff • See also Lava, ACL2 (Rockwell)

  27. = & = Sequential equivalence checking • Compare sequential circuits by symbolic simulation (regard as finite state machines) • Is out always high (safety property) for all reachable states? out

  28. Compute reachable states • Set of states as BDD • ex. 3 bool vars (one per latch) • a + b represents {100,101,110,111,010,011} • T represents all 8 states • Image (applying the transition relation R) • AND (BDDs for present state and R) • Existentially quantify out vars for primary inputs and present state

  29. Fixed point iteration • R0 = BDD for reset state • R1 = R0 + Image(R0) • … • R(i+1) = Ri + Image(Ri) • Ri set of states reachable in i or fewer clock ticks • Eventually Ri = R(i+1) • Copes with ~200 latches

  30. Model checking • Clarke/Emerson/Sistla et al ’83 • Express properties in temporal logic • Check if state machine satisfies property • AG EF (reset) • AG (req => AF ack) • Generalisation of reachability analysis • Same limits

  31. Symbolic Trajectory Evaluation • Symbolic simulation + temporal stuff • Limit expressiveness >> automation • Trajectory formula • can specify values of circuit nodes for bounded # of events into the future • no negation or disjunction • Unique symbolic simulation vector captures all behaviours satifying formula >> one run gives verification

  32. Problem is writing down the necessary specifications in this funny language • Too many symbolic variables >> BDD blowup • Can instead use a SAT solver (e.g. Recent work at Compaq by Bjesse from our group)

  33. General problem • BDD blowup • verify subsystems (eg Ericsson) • use abstractions (ie verify a simplified and smaller version) • Still, BDD based verification very successful! • Alternative is SAT based methods (our speciality) or combinations of methods

  34. Large scale hardware verification at Intel • Formal verification methodology for datapath-dominated hardware • Algorithmic developments in basic tools not enough • Need a systematic approach to organising activities in large scale verification

  35. Forte: a formal verification environment • Efficient model checker (STE) • Lightweight theorem prover • Interfaced to and tightly integrated with FL, a general purpose functional programming language • FL is both specification language and scripting language

  36. Phases • Understanding the circuit and its operating environment • FL circuit description (API) • Simple checking of circuit against specification • functional spec., improved circuit API, concrete test vectors for regression testing

  37. Phases • STE • improved specification, detailed info. for model checker, characterisation of parts of input space for which MC works • all of the above are FL programs • most bugs found in this phase

  38. Theorem proving • Check correctness of specification and soundness of decomposition into MC cases • Final functional specification, perhaps proofs of properties of the specification • top-level correctness statement, collection of MC runs and a mechanized proof conneting these two

  39. Results • Used in production (large scale) • Use of a functional language vital • Stresses usability (but more work needed) • Aims at reuse of proofs • Similar methods used at Motorola

  40. Formal methods at Chalmers • Lava: an FPGA design system based on the functional progamming language Haskell • state of the art formal verification methods combined with advanced programming language features • Haskell used as scripting language • a version that gives fine control of layout developed and used at Xilinx Inc. • interesting for prototyping on FPGA

  41. Butterfly Layout on an FPGA

  42. Shameless advertising • Course in LP4 • Hardware description and verification • What is a HDL? • VHDL + model checking • Lava (Haskell plus automatic verification)

  43. Future Trends • Design methods and coding rules that make necessary proofs easier • Combining automatic verification methods using simple theorem provers • Combining test and formal verification

More Related