Hardware/Software Co-design Formal Verification Techniques - PowerPoint PPT Presentation

Loading...

PPT – Hardware/Software Co-design Formal Verification Techniques PowerPoint presentation | free to download - id: 4581f8-NmU0N



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Hardware/Software Co-design Formal Verification Techniques

Description:

Formal Verification Comparison with simulation Simulation Input output compare expected result Formal Expected behavior property prove What is ... – PowerPoint PPT presentation

Number of Views:62
Avg rating:3.0/5.0
Slides: 98
Provided by: RicHu150
Category:

less

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

Title: Hardware/Software Co-design Formal Verification Techniques


1
Hardware/Software Co-design Formal 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.
About PowerShow.com