Formal Methods in Hardware Design - PowerPoint PPT Presentation

Loading...

PPT – Formal Methods in Hardware Design PowerPoint presentation | free to download - id: 6c91ea-ODM4M



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Formal Methods in Hardware Design

Description:

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 ... – PowerPoint PPT presentation

Number of Views:5
Avg rating:3.0/5.0
Date added: 30 April 2020
Slides: 44
Provided by: Prove7
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Formal Methods in Hardware Design


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
  • gt automatic proofs possible
  • High level of abstraction, Fancy data types,
    general programs
  • gt 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 Harrisons work at Intel on floating
    point algorithms

9
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
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 cant 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(i1) Ri Image(Ri)
  • Ri set of states reachable in i or fewer clock
    ticks
  • Eventually Ri R(i1)
  • 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 gt AF ack)
  • Generalisation of reachability analysis
  • Same limits

31
Symbolic Trajectory Evaluation
  • Symbolic simulation temporal stuff
  • Limit expressiveness gtgt 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 gtgt one run gives
    verification

32
  • Problem is writing down the necessary
    specifications in this funny language
  • Too many symbolic variables gtgt 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
About PowerShow.com