Hardware/Software Co-design Formal Verification Techniques

1
Hardware/Software Co-designFormal Verification
Techniques

• Chung-Yang (Ric) Huang ???
• http//cc.ee.ntu.edu.tw/ric
• April 20, 2004

2
What is Design Verification?

• To verify the correctness of your design
• (Find as many design bugs as possible)

3
Where are the Bugs?

• Functional specification
• English/Algorithms
• ? Timing diagrams, system or behavior-level
• descriptions
• Design creation
• Inconsistent with spec
• RTL coding error (typo, X, logical error)
• Assumption on the environment
• Design/Physical implementation
• Synthesis tools
• Manual optimization

4
What is Design Verification?

• To verify the correctness of your design
• (Find as many design bugs as possible)

5
Verification vs. Testing
High-level spec
RTL design
Synthesis/PR
ICs
Testing
Verification

• Object ? design
• Methodologies
• Simulation
• Emulation
• Formal techniques

• Object ? chip
• Methodologies
• ATPG
• Fault Simulation
• Scan / BIST

6
Types of Verification

• Functional (Focus in todays lecture)
• Consider functional correctness only
• Usually doesnt consider timing (i.e. 0-delay
  model)
• Sequential circuit (i.e. multi-cycles)
• Timing
• Reg-to-reg timing constraints
• Clock domain checking
• Physical
• Layout vs. Schematics (LVS)
• Design Rule Checking (DRC)
• Signal integrity

7

• How do you verify/debug your design?

8
A Typical Verification Practice

• Defining spec --- Chief architect or manager (or
  sometimes designer)
• Verified by proof-reading
• Write a behavior model and verify by simulation
• RTL coding
• Designer writes the testbench for his blocks
• Designer writes/copies the behavior level model
  of the surrounding blocks
• Verification engineer creates the verification
  environment (tool integration, scripts, etc)
• Designer/Verification engineer runs the RTL
  simulation
• Designer fixes the bugs
• (maybe) Designer/Verification engineer writes
  more testbenches

9
A Typical Verification Practice

• Synthesis to gates
• Designer/Verification engineer runs the gate
  level simulation
• Very slow (e.g. 2 frames a week)
• Designer/Verification engineer maps the design to
  emulator (FPGA) and run the simulation
• Very expensive

10

• Yes, most people verify their designs by
  simulation and debug by looking at the waveforms

11
Verify by Simulation
0 1 0 1 1 0 1 1 0 0 1
1 0 0 0 1 1 1 0 1 0 0
Circuit
01100011
11000011
11000011
01100011
expected result
12
Any Problem? Whose Problem?

• My biggest problem about design verification is
  that the time is never enough. I can only do my
  best to run more simulation, but I dont know
  whether it is sufficient.
• --- Broadcom designer (similar comments from many
  others)
• It is very hard to write the testbenches and
  assertions for the design, since I am not a
  designer. Ask the designer to do it more? No
  way!!
• --- Sun Microsystems verification engineer
  (similar comments from many others)

13
What are the problems?

• Gap between designers and verification engineers
• (For designers) I thought I have fixed all the
  bugs
• (For verification engineers) Find ways to
  understand the design better
• Verification methodologies are not optimal
• Need to learn more alternatives
• Verfication usually takes up to 70 of resource
  during the design flow

14
Lets do some math

• Suppose a circuit has 100 registers (this is
  considered tiny in modern design)
• Total number of states 2100 1030 1024M
• Requires (in the worse case) at least 1024M
  cycles to exhaust all the possible states
• Let alone the input combinations
• Running simulation (million cycles per second)
  can only cover a very small portion of state space

15
100 Verification

• Question is there 100 verification?
• Try Run the simulation for a very long time
• Coverage the entire state space?
• Eventuality type of properties
• e.g. At the crossroad, every car should see the
  green light eventually
• More about 100 verification later

in 2 minutes
16

• Any alternative to simulation?

17
Formal Verification

• Comparison with simulation
• Simulation
• Input ? output ? compare expected result
• Formal
• Expected behavior ? property ? prove

18

• What is expected behavior?
• What is a property?

19
Observability Problem

• Bugs are detected at the observation points like
  POs and registers

assert always (count lt 16)
P
P
P
P
P
P
P
0
assertion
Output
1
0
1
20
Observability Problem

• Insert assertions in the middle of the circuit,
  and flag the simulator whenever the violation
  occurs
• Increase the observability of the bugs
• The difference between
• hardware and software simulations

21
Properties in a Circuit

• Describe the expected behavior of signals in a
  circuit
• Assertion (always) something bad should never
  happens
• Witness (eventually) something good should
  eventually happens
• Temporal logic (property in general)
• Logic temporal operators (always, eventually,
  until, etc)
• Can be nested
• e.g. eventually (always (req ? ack within 0
  12))
• However, 90 of important properties are
  assertions!!

22
Assertion-Based Verification (ABV)

• An emerging methodology in design community to
  boost verification efficiency
• Requires designers to write assertions in the
  design
• Assertions can be reused as verification IPs
  (VIPs)
• Also a good way to document the design
• Simulators and formal verification tools to
  support the assertion languages

23
Objectives of Writing Assertions

• To find as many bugs as possible
• 100 verification?
• ? Do I write enough assertions? (Forget it!!)
• Which one is golden? Spec?
• ? What if there is a bug in spec?
• (Who knows)
• A difficult-to-prove assertion is a good
  assertion? (NO!!)
• Write assertions to facilitate bug hunting

24

• Where am I going to find time to write
  assertions? I dont even have time to write
  comments!
• --- Conexant design engineer

25
Open Verification Library (OVL)

• A HDL library containing predefined assertion
  modules
• Assert_always
• Assert_never
• Assert_next
• Assert_frame
• Assert_handshaking
• Assert_cycle_sequence
• etc

26
OVL Example

• module assert_always (clk, reset_n, test_expr)
• input clk, reset_n, test_expr
• always _at_(posedge clk) begin
• if (reset_n ! 1'b0) begin
• if (test_expr ! 1'b1) begin
• ovl_error("")
• end
• end
• end
• endmodule

27
OVL Usage

• Instantiate OVL assertions in your design
• assert_always short_is_smaller_longer
• (clk, reset_n,(short_timer_v lt long_timer_v))
• Can use define to bypass synthesis of OVL
• Can run OVL with both simulation and formal
  verification tools
• Synthesizable subset
• (http//www.verificationlib.org/)

28
Assertion Languages

• OVL is easy to use, but not flexible enough for
  general temporal properties
• Lack of temporal constructs/keywords
• Property specification language
• To describe assertions in temporal logic
• e.g.
• PSL/Sugar (IBM origin, picked as IEEE standard by
  Accellera EDA Standards)
• OpenVera/ForSpec (Synopsys/Intel)

29
PSL/Sugar Simple Examples

• Boolean expression
• ena enb
• Sequential expression
• reqack!cancel
• sequence BusArb (boolean br, bg const n) br
  (br !bg)0n br bg
• endpoint ActiveLowReset (boolean rb, clk const
  n) rb!1'b1ninf rb1'b1 _at_(posedge
  clk)
• Assertion
• assert always reqack!cancel (next2 (ena
  enb))

30
PSL/Sugar Availability

• A very complete (yet, very complex) property
  specification language
• Ref websites
• http//www.haifa.il.ibm.com/projects/verification/
  sugar/
• http//www.pslsugar.org/
• Many companies have announced to support
  PSL/Sugar for simulation or formal verification
  tools

31
OpenVera

• Fully supported in Synopsys verification tool
  flow
• VCS simulator
• Formal verification tools
• Originally Vera
• Bought from a startup company
• Testbench authoring
• Verilog-like language

32
OpenVera (contd)

• Not just a property specification language, but a
  high-level verification language
• Testbench authoring
• Specify input stimuli
• Expected output response can be computed at
  high-level of abstraction (circuit model)
• Test fixture for generating tests and checking
  results
• Random or constrained testbench generation
• Support coverage metrics
• Interfaces to HDL and C
• Able to specify various temporal properties
• Object oriented encapsulation and inheritance

33
Property Added to a Circuit
0 1 0 1 1 0 1 1 0 0 1
Circuit
01100011
-
01100011
diff ?
expected result
34
Formal Verification

• No testbench required
• Expected behavior ? property ? prove
• Using logic and mathematic algorithms (formal
  verification engines) to prove that the
  property always holds w.r.t. circuit under test
• If property passes, a complete verification
• If property fails, generate a counter-example for
  debugging

35
For example

• Proving always (a gt b c)
• Simulation needs to enumerate all the possible
  combinations of a, b, and c
• But, consider circuit is just a set of logic
  relations of input signals
• Imagine in a math test, given a set of logic
  relations and asked to prove (a gt b c)
• Try to use logic and math reasoning (e.g.
  induction)

36

• Solving logic / temporal relations between
  circuit signals
• A constraint satisfaction problem

37
Constraint Satisfaction Problems

• Constraints
• Logic y a b
• Mux y310 en? a310 b6332
• Arithmetic y (a gt b)? (c d) (c d)
• Relational (x1 ltlt 1) x0 gt 256
• Constraint Satisfaction
• Find an input assignment that satisfies all the
  constraints
• Note solutions in modular number systems

38
Constraint Satisfaction Solver

• Solving techniques
• Boolean SAT, ATPG, BDD, etc.
• General arithmetic solvers
• Examples of Applications
• Testbench generation (Find a solution)
• Assertion validation (Prove no solution)
• Optimization problems ( Cost functions)

39
Sequential vs. Combinational Properties

• In general, the counter-example for a property is
  a sequence of input assignments
• One assignment for each clock cycle
• Need to solve constraints multiple times
• Iteratively, or
• Recusively

Property
40

• To simplify discussion
• Lets focus on
• combinational property first
• (i.e. logic functions only, no temporal
  relationship)

41
How to solve the logic constraints?

• Substitution / elimination method
• Starting from constraints containing primary
  inputs (PIs)
• ? substitute variables with input constraints
• Continue the substitutions until get a conflict
  or result in a single constraint (i.e. only PIs)
• Find an input assignment
• The problem is
• Substitution is not always possible
• Step 3 is still very difficult

42

• Represent the combinational property (a logic
  function) using PIs

43
Function Representation

• In general
• f (a b ((c d) gt e)) !g (a gt b)?...
• Not canonical
• Enumeration (Truth table)
• e.g. a1 a0 b1 b0 f
• -------------------
• 0 0 0 0 0
• 0 0 0 1 1
• 1 1 1 0 1
• 1 1 1 1 0
• Exponential growth in size (like simulation)
• But, once we have the table, finding an
  assignment is easy
• Canonical

44

• A better data structure to
• represent truth table?

45
Binary Decision Tree
f
a
b
b
0
1
1
0
1
1
0
0

• Still exponential in size

46
Binary Decision Diagram
f
a
b
b
0
1
1
0
47
Reduced Binary Decision Diagram
f
a
b
b
c
c
48
Binary Decision Diagram (BDD)

• A graphical representation of truth table
• f func(a, b, c, d, ) is a logic function
• Each level corresponds to an input variable
• ? Set of inputs is called support
• Functions with identical functions are merged
  together
• Always canonical
• Each node (and its sub-graph) represents a
  function
• Each path represents a cube of the function

49
Basic BDD Operations

• Shannon expansion of f
• f x fx x fx
• f g
• (x fx x fx)
• (x gx x gx)
• x (fx gx) x (fx gx)
• f g
• x (fx gx) x (fx gx)
• Operation perform on cofactors individually

fx
_
-
x
fx
_
_
_
_
_
_
_
_
_
1
0
_
_
50
Basic BDD Operations
f c
OR
OR
f a (b c) f (a b) (a c)
f b c
51

• In short,
• f a (b c)
• f (a b) (a c)
• ? will result in same BDD
• ? independent of building orders

52

• Therefore, to build BDDs for a circuit
• Order circuit topologically from PIs to target
  gate
• Build BDDs from PIs to target

53

• To prove combinational property by BDDs ? Build
  BDDs for f

54

• Sounds too good to be true
• Any problem ??

55
BDD Complexity

• In general, the size of BDD nodes is still
  exponential to the size of input supports
• Usually can only build BDDs for circuit with
  input 100 200
• The problem?
• BDDs find all the counter-examples at once
• ? while we only need one

56
Consider.

• Building BDDs one path at a time
• ? Until find one path that evaluates f 0
• ? Whats the difference from simulation??

Binary decision tree
57
Branch-and-Bound Algorithm

• Branch
• Making decisions (0 or 1) on input variables a,
  b,
• One decision at a time evaluate f immediately
• Bound
• If the decisions evaluate f to be 0
• ? a counter-example is found (END)
• Otherwise, undo the last decision and make the
  decision on its inverted value

58
Branch-and-Bound Algorithm (contd)
f 1
Whats the difference from simulation??
59
Simulation vs. Branch-and-Bound

• Min-term vs. cube (to generate 1 for 3-AND)
• 8 min-terms (simulation)
• 000 111
• 4 cubes (Branch-and-bound)
• 0 - -
• 10
• 110
• 111
• Branch-and-bound
• Can bound with partial decisions

0
0
60
Simulation vs. Branch-and-Bound
Simulation
Binary decision tree
61

• Do you still remember
• why we talk about
• BDDs,
• Branch-and-bound,
• and all these ??

62

• They are all techniques
• to solve
• constraint satisfaction problems
• And we need that to
• PROVE a property

63
Solving Constraints with Branch-and-Bound

• If solution exists
• Making good decision can find the solution
  earlier
• If no solution
• Need to traverse the entire decision tree

64
Factors on Branch-and-Bound Performance

• Decision order and values
• Good decisions find solution earlier
• Able to bound earlier
• Apply value on target f
• Make decision on internal nodes
• Learning (not covered in todays lecture)

65
Apply value on target f
? 0
1 1 1
0

• Backward implications
• More implications
• ? produce conflict earlier
• ? bound earlier

66
Make decision on internal nodes

• Making decisions on internal nodes can lead to
  conflict earlier

? 0
67
More Advanced Solving Techniques

• BDD
• Partitioning
• Approximation
• Branch-and-bound (ATPG, SAT)
• (Conflict) learning
• Induction
• Constraint modeling
• Word-level (arithmetic)
• Abstraction / Refinement
• Sequential problems
• Combined engine

68
Course to Offer

• 93 ?????
• ?????? (SoC Verification)
• In general, the constraint-solving techniques can
  be applying to many other EE and non-EE problems

69
Constraint Solvers in EDA Tools

• HDL parser
• (Quick) Synthesis

• Flattening
• Problem formulation

• Constraint solvers

• User I/O
• Debugging utilities

70
Constraint Solvers in EDA Tools
Front-end
Modeling
Modeling
Modeling
Modeling
Engines
GUI
GUI
GUI
GUI
71
(Formal) Verification Applications
Equivalence Checking
Property Checking
72
Equivalence Checking (EC)
Golden circuit
INPUTS
OUTPUTS
Combinational Logic
OUTPUTS
Combinational Logic
Revised circuit
73
Why do we need equivalence checking?

• Gate-level simulation is too slow
• Once RTL simulation (speed OK) is done, no need
  to run gate level simulation
• No need to repeat the verification effort spent
  in RTL
• Synthesis tool may have bugs
• Manual optmizations (e.g. ECO)

74
EC Problem Definition

• Starting from the same state in both circuits,
• ? input sequences
• ? Outputs of golden and revised circuits are
  always the same
• What about the register values (states)?
• Complexity?

75
Commercial Equivalence Checking Tools

• First came out in early 90s
• Boost in late 90s
• Compare any two circuits from RTL to layout
• Synthesizable subset not for behavior level
• Incorporate formal verification techniques
• Often can finish million-gate (e.g. RTL-to-gate)
  comparison in a few hours
• Impossible and incomplete by simulation
• Note simulation cannot prove EQ
• Adopted in mainstream design flow now

76
What Makes Equivalence Checking Practical?

• Assuming combinational equivalence
• Compare outputs, registers
• Valid for most of the optimizations

Goto EC fig
77
Equivalence Checking
Golden circuit
INPUTS
OUTPUTS
Combinational Logic
Always equivalent?
?
REGs
OUTPUTS
Combinational Logic
Always equivalent?
?
Revised circuit
78
What Makes Equivalence Checking Practical?

• Assuming combinational equivalence
• Compare outputs, registers
• Valid for most of the optimizations
• Internal equivalence (Structure similarity)
• Divide and conquer
• Use simulation to identify internal EQ candidates

Goto EC fig
79
Internal Equivalence
?
?
PIs
80
Internal Equivalence
?
New PIs
81
What Makes Equivalence Checking Practical?

• Assuming combinational equivalence
• Compare outputs, registers
• Valid for most of the optimizations
• Internal equivalence (Structure similarity)
• Divide and conquer
• Use simulation to identify internal EQ candidates
• Advance in logic reasoning techniques
• Automatic Test Pattern Generation (ATPG) /
  Boolean Satisfiability (SAT)
• Binary Decision Diagram (BDD)

82
Incisive Conformal Equivalence Checker

• Original Verplex Conformal LEC now Cadence
• Usage model
• Read design / library
• Mixed language
• Add constraints (optional)
• E.g. Scan enable
• Set renaming rules (optional)
• Gate level may have different naming conventions
  from RTL
• Flatten the circuits
• Output functions of inputs
• Compare
• Report and debug

83
Incisive Conformal EC in NTUEE

• Not available now (no one used it before)
• CIC just passed application. Will install in Lab
  231
• Hopefully can be available this week
• Will have some students to test and write a
  report (for SoC Design Overview class)

84
Formal Verification Applications
Equivalence Checking
Property Checking
85
What is Property Checking?

• Do I correctly implement my spec?
• Spec (English)
• ? Properties (Formal/Temporal functions)
• Assert always (a gt b)
• Request ? eventually Acknowledge
• Request ? Acknowledge in (3, 12) cycles

86
Objectives of Property Checking

• To find as many bugs as possible
• 100 verification?
• ? Do I write enough properties? (Forget it!!)
• Which one is golden? Spec?
• ? What if there is a bug in spec?
• (Who knows)
• A difficult-to-prove assertion is a good
  assertion? (NO!!)
• Write properties to facilitate bug hunting

87
Property Checking vs. Equivalence Checking

• Flow
• Property checking ? Equivalence checking
• Try ideas from equivalence checking
• Combinational reduction?
• (No, most properties are sequential)
• Internal equivalence?
• (No. Equivalence to what?)
• In reality, property checking is much more
  difficult than equivalence checking

88
What Makes Property Checking Practical?

• (Fact) Property formal specification of design
  intent
• Reasonably local
• More than 90 of properties are assertions
• Most simple properties can be exhaustively
  proven, or some bugs can be found
• Advance in ATPG/SAT, BDD

89

• Remember
• Where am I going to find time to write
  assertions? I dont even have time to write
  comments!
• --- Conexant design engineer

90

• In reality
• Designers are too busy and lazy to learn new
  assertion languages and write assertions
• --- Verplex market validation

91
Pre-defined Checks

• Some properties can be automatically identified
  and extracted during the synthesis process
• Bus contention
• X propagation
• FSM checks
• Range overflow
• Race condition
• Designers dont need to learn how to write
  assertions
• ? Close to push-button solution

92
Conclusion

• Review design verification practices and problems
• Simulation is still the main stream
• Assertion-Based Verification
• Formal technique constraint satisfaction
  problems
• BDD
• Branch-and-bound
• Applications on verification tools
• Equivalence checking
• Property checking

93
Simulation vs. Formal Verification
User Friendly Acceptance Easy bugs Difficult bugs
Simulation
Equivalence Checking
Property Checking
94

• Is it possible to combine simulation and formal
  techniques?

95
Simulation vs. Formal

• Simulation
• Easy to use
• Can run on large circuit
• Can detect easy bugs quickly
• Almost impossible to handle corner case bug
• Formal (property checking)
• Higher learning curve for designers
• Cannot perform exhaustive search on large designs
• Can target on corner case bug
• Semi-formal --- combines the advantages of both

96
Simulation-based Semi-formal Approach
Simulation trace
Apply formal techniques (state space
exploration) around the simulation state
97

• Thank you.