Formal Methods in Hardware Design
Mary Sheeran, Chalmers
www.cs.chalmers.se/~ms
Formal Methods
• Mathematical and logical methods used in system development
• Aim to increase confidence in riktighet of system
• Apply to both hardware and software
Formal methods
• Complement other analysis methods
• Are good at finding bugs
• Reduce development (and test) time
• Should ideally be automatic
The main point is NOT
• correctness proof of entire systems
• replacing test entirely
BUT
• one proof can replace many test cases
• formal methods can be used in automatic test case generation
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
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
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
Model Checking
MC
G(p -> F q)yes
nop
q
p
q
property
finite-state model
algorithm
counterexample
(Ken McMillan)
Model checkers usually based on BDDs
• Binary Decision Diagrams
• Data structure for representing and manipulating boolean functions
• More later...
Proof-based method
High levelrequirements
High leveldesign
Logicalformula
Logicalformula
Compilation
Proof
Compilation
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 ....
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)
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)
Nov. ’94 Intel FPU bug
• 824633702441.0 times (1/824633702441.0) = 0.99999999274709702
• Fault in look-up table
• COST $475.000.000
$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”
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
Automatic methods
• Finite state
• BDD based verification widespread
– emphasison cost saving– not on guaranteed correctness– used in production 50% verification engineers
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
Plus points
• Efficient algorithms exits (and, or, not, exists, forall …)
• For given variable order, BDD is canonical
• Many common functions have small BDDs
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
Exercise
• Make BDD for x xor y xor z
Rest of lecture
• Some selected BDD based methods (Alan Hu paper)
• What actually happens at Intel
• A glimpse of our research
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
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
• X halves # simulation runs but loses info.
• a halves # runs but makes BDDs bigger
• Tradeoff
• See also Lava, ACL2 (Rockwell)
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
Compute reachable states
1 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
2 Image (applying the transition relation R)– AND (BDDs for present state and R)– Existentially quantify out vars for primary
inputs and present state
• 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
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
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
• 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)
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
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
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
Phases
1 Understanding the circuit and its operating environment– FL circuit description (API)
2 Simple checking of circuit against specification– functional spec., improved circuit API, concrete
test vectors for regression testing
Phases
3 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
Theorem proving
4 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
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
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
Butterfly Layout on an FPGA
Shameless advertising
• Course in LP4
• Hardware description and verification– What is a HDL?– VHDL + model checking– Lava (Haskell plus automatic verification)
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