1. Hardware Verification
Fu Song

2. Main References Hardware Design Verification: Simulation and
Formal Method-Based Approaches
William K Lam
Prentice Hall Modern Semiconductor Design Series
A Roadmap for Formal Property Verification
Pallab Dasgupta
Springer

3. Design, Validation and Testing

4. Digital Design: Abstraction Levels

5. Design Example: 2-bit Gray Counter
Gray Counter: Successive values should differ only in one bit. Reset signal resets the counter to zero.

6. Design Example: 2-bit Gray Counter

7. Design Example: 2-bit Gray Counter

8. Abstractions in Design Flow

9. Design and Verification

10. Functional Verification Challenge
Is the implementation correct?
How do we define correct?
Classical: Simulation result matches with golden output
Formal: Equivalence with respect to a golden model
Property verification: Correctness properties (assertions) expressed in a formal language
 Formal: Model checking
 Semi-formal: Assertion-based verification
Trade-off between computational complexity and exhaustiveness

11. Simulation

12. Advent of Formal Methods in EDA
Goal: Exhaustive verification of the design intent within feasible time limits
Philosophy: Extraction of formal models of the design intent and the implementation and comparing them using mathematical / logical methods

13. Toy example: Priority Arbiter

14. Dynamic Property Verification (DPV)

15. Formal Property Verification (FPV)

16. Equivalence Checking
Two designs are defined to be functionally equivalent if they produce identical output sequences for all valid input sequences

17. Equivalence Checking

18. Combinational Equivalence Checking
Basic Approach
Step-1: Register Correspondence
The register correspondence is either guessed using simple heuristics or computed exactly
Step-2: Functional Comparison
This step involves the actual functional comparison of the individual circuits
This can be done using a variety of methods, including BDDs, SAT and ATPG （automatic test pattern generation ）

19. Regsiter Correspondence
In many practical design flows, a candidate register correspondence is derived from naming conventions
Otherwise, register correspondence can be computed automatically as a greatest fixed point
The algorithm starts with one equivalence class (bucket) containing all the registers
During each iteration:
A unique variable is introduced for the outputs of all registers of each bucket
All next state functions are computed based on these variables
Next the buckets are partitioned into pieces that have identical next-state functions

20. Equivalence Checking with SAT
To check equivalence between f and g, we add the following clauses:
Satisfiable = not equivalent

21. Equivalence Checking with BDD
Two BDDs are same = Equivalent

22. Sequential Equivalence Checking
When register correspondence cannot be found easily or it does not exist, we may compare the state machines
Basic approach
Core problem: Partition the state space into sets of equivalent states
Equivalence can be defined in terms of input/output behavior
Bisimulation equivalence
Stuttering equivalence

23. Sequential Equivalence Checking
Extract designs as finite-state machine M1, M2
Minimize M1 and call the result N1
Minimize M2 and call the result N2
Check if the states of N1 can be renamed so that N1 and N2 are identical

24. Model Checking

25. Model Checking

26. FSM Extraction

27. Transition Relation

28. Computational facts
On On-the the-fly model checking