In The Name of God

1
In The Name of God

• Introduction to Formal Verification Methods

By Bijan Alizadeh
2
Outline of Lectures

• Lecture1 Why and Where Formal Verification
  presented by B. Alizadeh (Wed. 1381/12/7)
• Lecture2 General overview of Formal Verification
  Methods presented by B. Alizadeh (Mon.
  1381/12/12)
• Lecture3 Introduction to Solidify as a
  commercial verification tool presented by Z.
  Navabi (Wed. 1381/12/14)
• Lecture4 Examples in Solidify presented by Z.
  Navabi (Mon. 1381/12/19)

3
Outline of Lectures

• Lecture5 Property Languages presented by
  Shojaee (Wed. 1381/12/21)
• Lecture6 Property Languages presented by
  Shojaee (Mon. 1381/12/26)
• Homeworks
• Lecture7 Introduction to BDDs presented by B.
  Alizadeh (Mon. 1382/1/18)
• Lecture8 Introduction to BDD Package presented
  by Afshar (Wed. 1382/1/20)
• Lecture9 Other representation methods presented
  by Afshar (Mon. 1382/1/25)
• Homeworks

4
Outline of Lectures

• Lecture10 Equivalence Checking presented by B.
  Alizadeh (Wed. 1382/1/27)
• Lecture11 Theorem Proving presented by B.
  Alizadeh (Mon. 1382/2/1)
• Lecture12 Property (Model) Checking presented
  by B. Alizadeh (Wed. 1382/2/3)
• Lecture13 High Level Formal Verification
  presented by B. Alizadeh (Mon. 1382/2/8)
• Lecture14 High Level Formal Verification
  presented by B. Alizadeh (Mon. 1382/2/15)
• Lecture15 VIS as a semi-commercial tool
  presented by Shojaee and Afshar (Wed. 1382/2/17)
• Homeworks

5
Outline of Lectures

• Lecture16 Soc Verification (Mon. 1382/2/22)
• Lecture17 Symbolic Simulation (Wed. 1382/2/24)
• Lecture18 Automata method (Language Containment)
  (Wed. 1382/2/31)
• Lecture19 Satisfiability methods (Mon. 1382/3/5)

6
Outline of Lectures

• Lecture20 Petri Nets versus BDDs (Wed. 1382/3/7)
• Lecture21 Advanced Theorem Proving (Mon.
  1382/3/12)
• Lecture22 How to verify by using HOL Theorem
  Prover (Mon. 1382/3/19)
• Homeworks
• Lecture23 Set theory in Verification (Wed.
  1382/3/21)

7
Outline of Lectures

• Lectures Time
• From 18 To 1915 on Sunday
• From 1530 To 1645 on Wednsday
• Class Number
• Class 2

8
Grading Scheme

• Studying work 15
• Home works 15 (3 5)
• Design and Verification by VIS (as a
  semi-commercial tool) 15
• Pre-design and Verification by Solidify (as a
  commercial tool) 15
• Programming activity Implement some parts of
  Theorem Proving method 20 - 25
• Final Exam 15 - 20

9
References

• E.M. Clarke, O. Grumberg, D. Peled Model
  Checking, MIT Press, 2000.
• T. Kropf. Introduction to Formal Hardware
  Verification, Springer Verlag, 1999.
• T.F. Melham Higher Order Logic and Hardware
  Verification, Cambridge Tracts in Theoretical
  Computer Science, No 31, Cambridge University
  Press, 1993.

10
Outline
11
State of the Art

• Program Proving
• McCarthy, Dijkstra (1960)
• Theorem Proving
• Floyd, Hoare, Gordon (1968-1970)
• Model Checking Clarke, McMillan, Dill (1975)
• Equivalence Checking Touati, Coudert
  (1975-1980)

12
Introduction

• Our goal develop awareness of formal
  verification methods as complement to simulation
  to improve design quality.
• Formal Methods mathematically- based languages,
  techniques, and tools for specifying and
  verifying systems.
• Formal Verification Versus Simulation

13
Introduction

• Correctness is classically viewed as two separate
  problems, validation and verification
• Validation answers are we building the right
  system?
• Verification answers are we building the system
  right?
• Why formal methods might work well for hardware
  verification?
• - Hardware is often regular and hierarchical
• - Primitives are simpler, e. g., behavior of an
  NAND- Gate easier to describe than the semantics
  of a while- loop
• - Cost of design error can mean a 6 months delay
  and a costly set of lithography masks

14
Industry Forces

• Time-To-Market
• Design Complexity
• Shortage Of Skilled Engineers

• Improved Fab Technology
• Rising Fab Costs

15
Abstraction Levels in Circuit Design
16
Complexity of different abstraction Levels

• Qualitative Complexity
• abstract data type (numbers, bitvectors, bits)
• Gate least complexity (propositional logics)
• Architecture most complexity (multi-value
  logics)
• Quantitative Complexity
• number of object elements (processes, REG,
  gates, Transistors)
• Architecture least complexity
• Transistor most complexity

17
Behavioral Specification
Compute the greatest common divisor of numbers x
and y While(x?y) if(xgty) xx-y else
yy-x gcdx
18
RT level Design
process begin Variable gtr,equbit
wait until clockevent and clock1
if(rst1) then xltxi yltyi rstlt0
else gtr xgty if(gtr1) then
xlt x-y else equ xy
if(equ1) then gcd lt x rst lt 1
else y lt y-x end if end if
end if end process
19
Gate Level Design
20
Transistor Layout Level Design
21
Formal Logic

• A method is formal if its rules for manipulation
  are based on form ( syntax ) and not on content (
  semantics )
• Every logic comprises a formal language for
  making statements about objects and reasoning
  about properties of these objects.
• Statements in a logic language are constructed
  according to a predefined set of formation rules
  (depending on the language) called syntax rules .

22
Types of Logic

• Propositional logic traditional Boolean algebra,
  variables Î 0,1
• First-order logic (Predicate logic) quantifies
  for all ( ") and there exists ( ) over variables
• Higher-order logic adds reasoning about
  (quantifying over) sets and functions
  (predicates)
• Modal/ temporal logics reason about what must or
  may happen
• HOL is very expressive

23
Where Formal Verification

• Faults in Design Flow
• Design Steps
• Local Optimization
• Implementation Inherent Faults

24
Verification in Different Levels

• Module Level
• Chip Level
• Board Level
• System Level

• Is the basic functionality correct?
• Did I connect the blocks right?

25
Traditional Methods

• White Box Testing
• Validate the implementation details with a
  knowledge of how the unit is put together.
• Check all the basic components work and that they
  are connected properly.
• Give us more confidence that the adder will work
  under all circumstances.
• Example Focus on validating an adder unit inside
  the controller.

26
Traditional Methods

• Black Box Testing
• Focus on the external inputs and outputs of the
  unit under test, with no knowledge of the
  internal implementation details.
• Apply stimulus to primary inputs and the results
  of the primary outputs are observed.
• Validate the specified functions of the unit were
  implemented without any interest in how they were
  implemented.
• This will exercise the adder but will not check
  to make sure that the adder works for all
  possible inputs
• Example Check to see if the controller can count
  from 1 to 10.

27
Traditional Methods

• Static Testing
• Examine the construction of the design
• Looks to see if the design structure conforms to
  some set of rules
• Need to be told what to look for
• Dynamic Testing
• Apply a set of stimuli
• Easy to test complex behavior
• Difficult to exhaustively test
• It does not show that the design works under all
  conditions

28
Traditional Methods

• Random Testing
• Generate random patterns for the inputs
• The problems come from not what you know but what
  you don't know
• You might be able to do this for data inputs, but
  control inputs require specific data or data
  sequences to make the device perform any useful
  operation at all

29
Formal Verification

• Complete with respect to a given property (!)
• Correctness guaranteed mathematically, regardless
  the input values
• No need to generate expected output sequences
• Can generate an error trace if a property fails
  better understand, confirm by simulation
• Formal verification useful to detect and locate
  errors in designs
• Consideration of all cases is implicit in formal
  verification

30
Simulation vs. Formal Verification

• Common difficulty in all verification methods
• lack of golden reference
• what properties to verify .....?
• Simulation and Verification are
  complementary-formal verification gives
  additional confidence,
• 1. Apply formal verification of abstract model
• 2. Obtain error trace if bug found
• 3. Simulate error trace on the real model

31
Formal Verification Methods

• Interactive (deductive) Methods
• Theorem Proving relationship between a
  specification and an implementation is a theorem
  in a logic, to be proven within the context of a
  proof calculus
• Automated Methods
• Combinational Equivalence Checking proof of
  structural equivalence of logic designs
• Sequential Equivalence Checking proof of
  behavioral equivalence of FSMs
• Model Checking proof of (temporal) logic
  property (safety liveness) against a semantic
  model of the design

32
Theorem Proving

• Prove that an implementation satisfies a
  specification by mathematical reasoning.
• Implementation and specification expressed as
  formulas in a formal logic .
• Relationship (logical equivalence/ logical
  implication) described as a theorem to be proven.
• A proof system
• A set of axioms(facts) and inference(deduction)
  rules (simplification, rewriting, induction, etc.)

33
Theorem Proving

• Some known theorem proving systems
• HOL PVS Lambda
• Advantages
• High abstraction and powerful logic
  expressiveness
• Unrestricted applications
• Useful for verifying datapath- dominated
  circuits
• Limitations
• Interactive (under user guidance)
• Requires expertise for efficient use
• Automated for narrow classes of designs

34
Application of logic to T.P.

• Specification represented as a formula
• Implementation represented as a formula
• Formula x, ?x, x ? y, x? y,
• ?x. f(x), ?x. f(x)
• ?f. f(x), ?f. f(x)
• Formula -- Formula
• Verification as theorem proving, i. e.,
  relationship (implication or equivalence) between
  the specification and the implementation is a
  theorem to be proven.

35
Issues of proof systems

• Consistency (Soundness) all provable formulas (
• theorems ) are logically ( semantically ) true
• Completeness all valid formulas ( semantically
  true ) are provable ( theorems )
• Decidability there is an algorithm for deciding
  the ( semantical ) truth of any formula(theorems)

36
Equivalence Checking

• Combinational Circuits
• Sequential Circuits

37
Combinational Circuits

• Technique 1 tautology/ satisfiability checking
• Technique 2 Stålmarcks method
• Technique 3 ROBDD- based method

38
Sequential Circuits

• Technique 1 Prove equivalence of transition and
  output functions
• Technique 2 Produced a product machine and
  create set of illegal states
• Reachability Analysis Check if any illegal state
  can be reached starting from initial states.

39
Sequential Circuits

• Reachability AnalysisStart from initial state
• repeat
• Apply transition relation to determine next
  state
• In each reached state, check equivalence of
  corresponding outputs of M1 , M2
• until all reachable states visited

40
Property Checking

• Equivalence Checking may not be feasible for
  large circuits and can not check any properties
• Model Checking
• Symbolic Model Checking

41
Property Language

• Temporal Operators
• X Next Time F Eventually
• G Always U Until
• Path Quantifiers
• A For all computation path
• E For some path

42
Application of logic to M.C.

• Specification represented as a formula
• Implementation represented as a semantic model
• Formula x, ?x, x ? y, x? y,
• ?x. f(x), ?x. f(x)
• EF(x), EG(x), EX(x),
• Model -- Formula
• Model checking deals with the semantic
  relationship shows that the implementation is a
• model for the specification formula (property).

43
Model Checking

• Property described by temporal logic formula.
• System modeled by Labeled Transition Graph (LTG,
  LTS, Finite Kripke structure).
• Exhaustive search through the state space of the
  system ( Reachability Analysis ) to determine if
  the property holds (provides counterexamples for
  identifying design errors).
• Problem State explosion, e.g. N-bit REG ? 2N
  states
• Partial Solution Symbolic Model Checking
• Represent transition/ output relations and sets
  of states symbolically using ROBDD

44
Symbolic Model Checking

• State Explosion Problem
• Boolean formulas represent sets and relations
• Use fixed point characterizations of CTL
  operators
• Model Checking without building state graph
• Problem again State explosion (max 400
  Boolean variables), low abstraction level.

45
S.M.C. Top View
Design Description
Property Description
FSM Extraction
Subformula Fi
Next States Output Functions
BDD of Fi
BDD of Design
Symbolic Model Checking
46
Theorem Proving vs. Model Checking

• Theorem Proving useful for architectural design
  and verification
• Process Implementation description Formal
  logic
• Specification description Formal logic
• Correctness Imp Þ Spec (implication) or
• Imp Û Spec (equivalence)
• High abstraction level possible, expressive
  notation, powerful logic and reasoning
• Interactive and deep understanding of design and
  higher- order logic required
• Need to develop rules (lemmas) and tactics for
  class of designs
• Need a refinement method to synthesizable VHDL /
  Verilog

47
Theorem Proving vs. Model Checking

• Model Checking at RT- level (or below) with at
  most 400 Boolean state variables
• Process Implementation description Model as
  FSM
• Specification description Properties in
  temporal logic
• Correctness Impl -- Spec (property holds in
  the FSM model)
• Easy to learn and apply (completely automatic),
  properties must be carefully prepared
• Integrated with design process, refinement from
  skeletal model
• State space explosion problem (not scalable to
  large circuits)
• Increase confidence, better verification coverage

48
Verification Tools
49
FormalCheck Verification Cycle
50
Property Panel
51
Advanced Options
52
Revenue of Growth
53
High Level Verification
54
Design Flow and Formal Verification

• RT level
• Simulation of RTL
• () efficient for less interacting concurrent
  components
• (-) incomplete for complicated control parts
  and difficult error trace
• Model checking of RTL
• () efficient for complicated interacting
  concurrent components
• () counter-examples can trace design errors

55
Design Flow and Formal Verification

• Netlist (Gate level)
• Equivalence checking of netlist vs. RTL
• () check the equivalence of submodules to
  ensure the correctness of synthesis
• () trace synthesis errors using counter-
  examples
• Model checking of netlist
• () correctness of the entire gate- level
  implementation
• (-) unpractical state space explosion

56
References
1. T. Kropf. Introduction to Formal Hardware
Verification , Springer Verlag, 1999. 2. C. Kern
and M. Greenstreet. Formal Verification in
Hardware Design A Survey, ACM Transactions on
Design Automation of E. Systems , Vol. 4, April
1999, pp. 123- 193. 3. A. Gupta. Formal hardware
verification methods a Survey. Formal Methods
in System Designs , Vol. 1, pp. 151- 238,
1992. 4. Carl- Johan Seger. An Introduction to
Formal Verification, Technical Report 92- 13,
UBC, Department of Computer Science, Vancouver,
B. C., Canada, June 1992. 5. M. Yoeli. Formal
Verification of Hardware Design, IEEE Computer
Society Press, 1991.
57
References

• 6. M. C. McFerland. Formal Verification of
  Sequential Hardware a Tutorial. IEEE
  transaction on CAD , 12( 5), May 1993.
• 7. E. M. Clarke and J. M. Wing. Formal Methods
  State of the Art and Future Directions. ACM
  Computing Surveys , December 1996.
• 8. R. P. Kurshan, Formal Verification in a
  Commercial Setting, Proc. Design Automation
  Conference , Anaheim, California, June 9- 13,
  1997, pp 258- 262.
• 9. Various Contributors, Survey of Formal
  Verification, IEEE Spectrum , June 1996, pp. 61-
  67.
• 10. K. Keutzer. The Need for Formal Verification
  in Hardware Design and What Formal Verification
  has not Done for Me Lately. Proc. HOL Theorem
  Proving System and its Application , Miami,
  Florida, USA, 1991.