hardware software co design formal verification techniques n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Hardware/Software Co-design Formal Verification Techniques PowerPoint Presentation
Download Presentation
Hardware/Software Co-design Formal Verification Techniques

Loading in 2 Seconds...

play fullscreen
1 / 97

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


  • 96 Views
  • Uploaded on

Hardware/Software Co-design Formal Verification Techniques. Chung-Yang (Ric) Huang 黃鐘揚 http://cc.ee.ntu.edu.tw/~ric April 20, 2004. Gate. GDSII. RTL. Design Creation. Design Implementation. Physical Implementation. Functional Specification. Design Flow. RTL. Gate. GDSII.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Hardware/Software Co-design Formal Verification Techniques' - hea


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
hardware software co design formal verification techniques

Hardware/Software Co-designFormal Verification Techniques

Chung-Yang (Ric) Huang 黃鐘揚

http://cc.ee.ntu.edu.tw/~ric

April 20, 2004

what is design verification

Gate

GDSII

RTL

Design

Creation

Design

Implementation

Physical

Implementation

Functional

Specification

Design Flow

RTL

Gate

GDSII

What is Design Verification?

To verify the correctness of your design

(Find as many design bugs as possible)

where are the bugs
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
what is design verification1

Gate

GDSII

RTL

Design

Creation

Design

Implementation

Physical

Implementation

Functional

Specification

Design Flow

RTL

Gate

GDSII

What is Design Verification?

To verify the correctness of your design

(Find as many design bugs as possible)

verification vs testing

Design

Specification

Design

Creation

Design

Implementation

Chip Manufacture

Verification vs. Testing

High-level spec

RTL design

Synthesis/P&R

ICs

Testing

Verification

  • Object  design
  • Methodologies
    • Simulation
    • Emulation
    • Formal techniques
  • Object  chip
  • Methodologies
    • ATPG
    • Fault Simulation
    • Scan / BIST
types of verification
Types of Verification
  • Functional (Focus in today’s lecture)
    • Consider functional correctness only
    • Usually doesn’t 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
a typical verification practice
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
a typical verification practice1
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
verify by simulation

-

diff ?

Verify by Simulation

1

0

0

0

1

1

1

0

1

0

0

0

1

0

1

1

0

1

1

0

0

1

Circuit

01100011

11000011

11000011

01100011

expected

result

any problem whose problem
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 don’t 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)

what are the problems
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

let s do some math
Let’s 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
100 verification
“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

formal verification
Formal Verification
  • Comparison with simulation
    • Simulation
      • Input  output  compare expected result
    • Formal
      • Expected behavior  property  prove
observability problem

P

P

P

P

P

P

0

0

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

assert always (count < 16);

P

P

P

P

P

P

P

0

assertion

Output

1

1

0

observability problem1
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

properties in a circuit
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!!
assertion based verification abv
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
objectives of writing assertions
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

slide24
“Where am I going to find time to write assertions? I don’t even have time to write comments!”

--- Conexant design engineer

open verification library ovl
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
ovl example
OVL Example

module assert_always (clk, reset_n, test_expr);

input clk, reset_n, test_expr;

always @(posedge clk) begin

if (reset_n != 1'b0) begin

if (test_expr != 1'b1) begin

ovl_error("");

end

end

end

endmodule

ovl usage
OVL Usage
  • Instantiate OVL assertions in your design
    • assert_always short_is_smaller_longer

(clk, reset_n,(short_timer_v < 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/)

assertion languages
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)
psl sugar simple examples
PSL/Sugar Simple Examples
  • Boolean expression
    • ena || enb
  • Sequential expression
    • {req;ack;!cancel}
    • sequence BusArb (boolean br, bg; const n) = { br; (br && !bg)[0:n]; br && bg };
    • endpoint ActiveLowReset (boolean rb, clk; const n) = { rb!=1'b1[*n:inf]; rb==1'b1 } @(posedge clk);
  • Assertion
    • assert always {req;ack;!cancel} (next[2] (ena || enb));
psl sugar availability
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
openvera
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
openvera cont d
OpenVera (cont’d)
  • 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
property added to a circuit

a

>

always (a > b)

b

Property Added to a Circuit

0

1

0

1

1

0

1

1

0

0

1

Circuit

01100011

-

01100011

diff ?

expected

result

formal verification1
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
for example
For example
  • Proving “always (a > 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 > b + c)
    • Try to use logic and math reasoning (e.g. induction)
slide36
Solving logic / temporal relations between circuit signals…

A constraint satisfaction problem

constraint satisfaction problems
Constraint Satisfaction Problems
  • Constraints
    • Logic: y = a && b;
    • Mux: y[31:0] = en? a[31:0] : b[63:32];
    • Arithmetic: y = (a > b)? (c + d) : (c * d);
    • Relational: (x1 << 1) + x0 >= 256;
  • Constraint Satisfaction
    • Find an input assignment that satisfies all the constraints
    • Note: solutions in modular number systems
constraint satisfaction solver
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)
sequential vs combinational properties

INPUTS

OUTPUTS

Combinational

Logic

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

slide40
To simplify discussion…

Let’s focus on

combinational property first

(i.e. logic functions only, no temporal relationship)

how to solve the logic constraints
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
function representation
Function Representation
  • In general…
    • f = (a && b || ((c + d) > e)) ^ !g && (a > 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
slide44
A better data structure to

represent truth table?

binary decision tree

target function

a = 1

c

c

c

c

input variables

a = 0

function = 1

function = 0

Binary Decision Tree

f

  • Still exponential in size

a

b

b

1

0

0

1

1

0

0

1

binary decision diagram bdd
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
basic bdd operations

f

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

_

_

_

_

_

_

_

_

_

0

1

_

_

basic bdd operations1

c

1

0

b

a

a

a

1

0

f = b

b

b

b

c

c

c

c

0

0

1

1

1

1

0

0

1

0

f = a && b

f = a && c

Basic BDD Operations

f = c

OR

OR

f = a&& (b || c)

f = (a && b) || (a && c)

f = b || c

slide51
In short,
  • f = a && (b || c)
  • f = (a && b) || (a && c)

 will result in same BDD

 independent of building orders

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

f

f

counter-example

1

Tautology; f is always = 1

 Property is always true

1

0

To prove combinational property by BDDs  Build BDDs for f

bdd complexity
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…

consider

a

b

c

Consider….
  • Building BDDs one path at a time…

 Until find one path that evaluates “f = 0”

 What’s the difference from simulation??

Binary decision tree

branch and bound algorithm
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
branch and bound algorithm cont d

f

a

d

b

c

circuit

a

b

c

Branch-and-Bound Algorithm (cont’d)

f = 1

What’s the difference

from simulation??

simulation vs branch and bound
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

slide61
Do you still remember

why we talk about

BDDs,

Branch-and-bound,

and all these ??

slide62
They are all techniques

to solve

constraint satisfaction problems

And we need that to

PROVE a property

solving constraints with branch and bound
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
factors on branch and bound performance
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 today’s lecture)
apply value on target f

f

1

0

circuit

1 1

a

b

c

Apply value on target f

 0

1 1 1

0

  • Backward implications
  • More implications
  •  produce conflict earlier
  •  bound earlier
make decision on internal nodes

f

circuit

a

b

c

Make decision on internal nodes
  • Making decisions on internal nodes can lead to conflict earlier

 0

more advanced solving techniques
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
course to offer
Course to Offer
  • 93 學年上學期
    • 系統晶片驗證 (SoC Verification)
  • In general, the constraint-solving techniques can be applying to many other EE and non-EE problems
constraint solvers in eda tools

Front-end

Modeling

Engines

GUI

Constraint Solvers in EDA Tools
  • HDL parser
  • (Quick) Synthesis
  • Flattening
  • Problem formulation
  • Constraint solvers
  • User I/O
  • Debugging utilities
constraint solvers in eda tools1
Constraint Solvers in EDA Tools

Front-end

Modeling

Modeling

Modeling

Modeling

Engines

GUI

GUI

GUI

GUI

formal verification applications

Gate

GDSII

RTL

Design

Creation

Design

Implementation

Physical

Implementation

Functional

Specification

Design Flow

RTL

Gate

GDSII

(Formal) Verification Applications

Equivalence Checking

Property Checking

equivalence checking ec

Always

equivalent?

== ?

INPUTS

Equivalence Checking (EC)

Golden circuit

INPUTS

OUTPUTS

Combinational

Logic

OUTPUTS

Combinational

Logic

Revised circuit

why do we need equivalence checking
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)
ec problem definition
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?

commercial equivalence checking tools
Commercial Equivalence Checking Tools
  • First came out in early 90’s
  • Boost in late 90’s
  • 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
what makes equivalence checking practical
What Makes Equivalence Checking Practical?
  • Assuming combinational equivalence
    • Compare: outputs, registers
    • Valid for most of the optimizations

Goto EC fig

equivalence checking

REGs

REGs

Equivalence Checking

Golden circuit

INPUTS

OUTPUTS

Combinational

Logic

Always

equivalent?

== ?

REGs

OUTPUTS

Combinational

Logic

Always

equivalent?

== ?

Revised circuit

what makes equivalence checking practical1
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

what makes equivalence checking practical2
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)
incisive conformal equivalence checker
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
incisive conformal ec in ntuee
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)
formal verification applications1

Gate

GDSII

RTL

Design

Creation

Design

Implementation

Physical

Implementation

Functional

Specification

Design Flow

RTL

Gate

GDSII

Formal Verification Applications

Equivalence Checking

Property Checking

what is property checking
What is Property Checking?
  • Do I correctly implement my spec?
  • Spec (English)

 Properties (Formal/Temporal functions)

    • Assert always (a > b)
    • Request  eventually Acknowledge
    • Request  Acknowledge in (3, 12) cycles
objectives of property checking
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

property checking vs equivalence checking
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…
what makes property checking practical
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
slide89
Remember…

“Where am I going to find time to write assertions? I don’t even have time to write comments!”

--- Conexant design engineer

slide90
In reality…

“Designers are too busy and lazy to learn new assertion languages and write assertions”

--- Verplex market validation

pre defined checks
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 don’t need to learn how to write assertions

 Close to “push-button” solution

conclusion
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
simulation vs formal
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

simulation based semi formal approach
Simulation-based Semi-formal Approach

Simulation trace

Apply formal techniques (state space exploration)

around the simulation state