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. Model Checking MC G(p -> F q) yes no p q p q property finite-state model algorithm counterexample (Ken McMillan)

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

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

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.99999999 274709702 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 1Set 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 2Image (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 1Understanding the circuit and its operating environment –FL circuit description (API) 2Simple checking of circuit against specification –functional spec., improved circuit API, concrete test vectors for regression testing

37. Phases 3STE –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 4Check 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