ECE260B – CSE241A Winter 2005 Verification

ECE 260B – CSE 241A Verification 1 http://vlsicad.ucsd.edu

ECE260B – CSE241A

Winter 2005

Verification

Website: http://vlsicad.ucsd.edu/courses/ece260b-w05


Verification

Functional verification Testing Emulation Simulation Symbolic simulation Formal verification

Timing verification Testing Simulation STA

Physical verification DRC ERC LVS

Misc Fanout constraints, etc.


Functional Verification


Design Verification

RTLSynthesis

HDL

netlist

logicoptimization

netlist

Library/modulegenerators

physicaldesign

layout

manualdesign

specification

Is design consistentwith original spec?

Courtesy K. Keutzer, UCB


Implementation Verification

RTLSynthesis

HDL

netlist

logicoptimization

netlist


physicaldesign

layout

manualdesign

Is implementationconsistent with original design intent?

a

b

s

q0

1

d

clk

a

b

s

q0

1

d

clk



Manufacture Verification (Test)

RTLSynthesis

HDL

netlist

logicoptimization

netlist


physicaldesign

layout

manualdesign

Is manufacturedcircuit consistentwith implemented design?

a

b

s

q0

1

d

clk

a

b

s

q0

1

d

clk



Implementation Verification for ASICs

RTLSynthesis

HDL

netlist

logicoptimization

netlist


physicaldesign

layout

manualdesign

Apply gate-level simulation at each step to verify:

(1) functionality: 0-1 behavior on regression test set

(2) timing:maximum delay of circuit on critical paths

a

b

s

q0

1

d

clk

a

b

s

q0

1

d

clk

ASICsignoff



Advantages of gate-level simulation verifies timing and functionality simultaneously approach well understood by designers

Disadvantages of gate-level simulation? computationally intensive - only 1 - 10 clock cycles of 100K gate design per 1 CPU second incomplete - results only as good as your vector set - easy to overlook incorrect timing/behavior

Simulationdriver

(vectors)

Simulationmonitor(yes/no)

Software Simulation

a

b

s

q

0

1

d

clk



Alternative - Static Signoff

RTLSynthesis

HDL

netlist

logicoptimization

netlist


physicaldesign

layout

manualdesign

a

b

s

q0

1

d

clk

a

b

s

q0

1

d

clk

ASICsignoff

Use static analysis techniques to verify:

(1) functionality:formal equivalence-checking techniques

(2) timing:static timing analysis



Problem: RTL to RTL Verification

After verification RTL may still be modified for: performance power area testability

Need to verify that new RTL is correct

Specification Implementation



Problem: RTL to Gates Verification

Verify the gate level implementation is consistent with the RTL level design

Errors may have occurred due to Logic synthesis Manual intervention

HDL Design Implementation



Problem: Gates to Gates Verification

Verify the modified gate level implementation is consistent with the RTL level design

Errors may have occurred due to Incorrect logic synthesis or module generation Test insertion Scan chain reordering Clock tree synthesis Post layout “tweaks”

Netlist Implementation



Problem: Layout to Gates Verification (LVS)

Verify that physical implementation is consistent with the above gate and RTL level design representations

Errors may have occurred due to Errors in physical design tools Manual changes in layout

Verification is primarily graphical or ``topological’’: gate identification from transistor networks, subgraph isomorphism

netlist physical layout



Solving Layout to Gates Verification (LVS)

Extract gate level models from physical level

Graphically compare extracted model against gate-level schematic (layout versus schematic)

Flag any discrepancies

netlist physical layout



The Verification Gap

Verification determines whether a design satisfies its requirements (a.k.a. its specification): Does it satisfy its functional requirements? Does it satisfy its speed requirements? etc.

There is a growing gap between the amount of verification that is desired, and the amount that can be done

The gap is caused by Inadequate coverage with simulation Approximate models (wire delays, for example) etc.

Coutesy, A. Nardi, UCB


Formal Verification Reduces the Gap

Formal verification can give complete coverage Mathematical techniques used to analyze all possible simulation vectors, without

simulating them one by one No test cases needed

But formal verification cannot replace simulation Current technology only effective for certain verification subtasks

Using formal verification effectively requires understanding its strengths and weaknesses



Formal Verification vs Informal Verification

Formal Verification

Complete coverage

Effectively exhaustive simulation

Cover all possible sequences of inputs

Check all corner cases

No test vectors are needed

Informal Verification

Incomplete coverage

Limited amount of simulation

Spot check a limited number of input seq’s

Some (many) corner cases not checked

Designer provides test vectors (with help from tools)



Complete Coverage Example

For these two circuits:f = ab(c+d)

= abc + abd

= g So the circuits are equivalent for all inputs

Such a proof can be found automatically

No simulation needed abc

abd

g = abc+abd

a

b

c

d

f = ab(c+d)



Using Formal Verification

No test vectors

Equivalent to exhaustive simulation over all possible sequences of vectors (complete coverage)

Formal Verification Tool

“Correct” or aCounter-Example:

Requirements

Design



Types of Specifications

Requirements design should satisfy

Requirements are precise: a must for formal verification

Is one design equivalent to another?

Design has certain good properties?

Informal

Specification

Equivalence Properties

Formal



Formal vs Informal Specifications

Formal requirement No ambiguity Mathematically precise Might be executable

A specification can have both formal and informal requirements Processor multiplies integers correctly (formal) Lossy image compression does not look too bad (informal)



Types of Formal Verification

Different comb. equiv. methods give different market opportunities; must be understood for FV strategy

Property Checking

Formal Verification

Sequential Combinational

Equivalence Checking

Capacity

Distinction between property checking and equiv. checking is becoming common knowledge

Similarity Required



Equiv. Checking vs Property Checking

Equivalence checking Is one design equivalent to another? One of the designs (the specification) is trusted In practice, most useful at low levels of abstraction

Property checking Does the design have a given desirable property? Properties are relatively small and easy to state, e.g.

- Each packet sent is eventually acknowledged

- Never more than one bus master Do not need complete set of properties

- Set of properties can evolve during design process Most useful at high levels of abstraction

- Finds bugs early



Types of Equivalence Checking

Layout

Trans. netlist

Gate level netlist

RTL netlist

Behavioral desc.

Layout

Trans. netlist

Gate level netlist

RTL netlist

Behavioral desc.

Structure of the designs is important If the designs have similar structure, then equivalence checking is much easier

More structural similarity at low levels of abstraction



Degree of Similarity: State Encoding

Two designs have the same state encoding if Same number of registers Corresponding registers always hold the equal values

Register correspondence a.k.a. register mapping Designs have the same state encoding if and only if there exists a register mapping

Greatly simplifies verification If same state encoding, then combinational equivalence algorithms can be used



Producing the Register Mapping

By hand Time consuming Error prone Can cause misleading verification results

Side-effect of methodology Mapping maintained as part of design database

Automatically produced by the verification tool Minimizes manual effort Depends on heuristics



Degree of Similarity: Combinational Nets

Corresponding nets within a combinational block Corresponding nets compute equivalent functions

With more corresponding nets Similar circuit structure Easier combinational verification

Strong similarity If each and every net has a corresponding net in the

other circuit, then structural matching algorithms can be used



Degree of Similarity: Summary

Different state encodings

General sequential equivalence problem Expert user, or only works for small designs

Same state encoding, but combinational blocks have different structure

IBM’s BoolsEye Compass’ VFormal

Same state encoding and similar combinational structure

Chrysalis (but weak when register mapping is not provided by user)

Nearly identical structure: structural matching

Compare gate level netlists (PBS, Chrysalis) Checking layout vs schematic (LVS)

Weak Similarity

Strong Similarity



Capacity of a Comb. Equiv. Checker

Matching pairs of fanin cones can be verified separately How often a gate is processed is equal to the number of registers it

affects Unlike synthesis, natural subproblems arise without manual partitioning “Does it handle the same size blocks as synthesis?” is the wrong

question “Is it robust for my pairs of fanin cones?” is a better question

Structural matching is easier Blocks split further (automatically) Each gate processed just once



User Needs

Gate vs Gate (structural) Post-synthesis step: verify netlist updates (scan insertion, buffers, etc) ASIC designer, ASSPs, ASIC vendor, Design Factories Limited debugging support required

Gate vs Gate (nonstructural) Manual optimization following synthesis High performance, high volume design (microProc, fabless, ASSPs) Requires good debugging support No current robust commercial offering



User Needs (cont.)

RTL vs Gate Simulation mostly at RTL level, reduce simulation at gate level ASIC designers, ASSPs, Design Factories and future DSM signoff Sophisticated debugging support required (source level) Methodology support required

- Hierarchy and black boxes required for IP

- Synthesis/simulation mismatch due to Synopsys don’t cares Capacity and robustness are critical No dominant player yet



User Needs (cont.)

RTL vs RTL IP resurrection and multiple revisions Similar to RTL vs gate

Gate or RTL vs Transistor Processor companies, library development Key issue is robustness of automatic transistor extraction



Techniques

Random simulation Finds many unequal nets (but not all)

OBDDs Construct OBDDs representing all or part of a combinational block Canonical form: cheap to compare Potentially expensive to build

Structural matching Specialized techniques to quickly verify identical structure

Decomposition points Find matching internal nets, if they exist



Techniques (cont.)

Pattern matching Transform circuits to increase similarity Examples: remove inverter pairs and buffers, use de Morgan’s laws

Case splitting Exhaustively consider all combinations of inputs to a block A given case may leave some inputs undetermined Therefore, many fewer than 2# inputs cases may be sufficient



Equivalence Checking: Research

Early academic research into tautology checking A formula is a tautology if it is always true Equivalence checking: f equals g when (f = g) is a tautology Used case splitting Ignored structural similarity often found in real world

OBDDs [Bryant 1986] Big improvement for tautology checking [Malik et. al 1988, Fujita et. al 1988, Coudert and Madre et. al 1989] Still did not use structural similarity

Using structural similarity Combine with ATPG methods [Brand 1993, Kunz 1993] Continuing research on combining OBDDs with use of structural similarity



Equivalence Checking: Tools

Internal tools from processor companies IBM (sold as BoolsEye), Motorola, DEC, Intel, BULL, etc.

VFormal from Compass OBDD-based, licensed from BULL

CheckOff-E from Abstract Hardware OBDD-based sequential equivalence checker

Design VERIFYer from Chrysalis No OBDDs, but “symbolic logic” is only a slight extension of the netlist data structures used in synthesis



Equivalence Checking Summary

Routinely verify complex (>1M gate) integrated circuit designs

Commercial (e.g., Synopsys, Cadence (Verplex)) and proprietary (e.g., IBM) solutions exist

Static sign-off methodology more widely used

Successful equivalence checkers orchestrate several different approaches

syntactic equivalence automatic test pattern generation-like approaches BDD-based techniques pattern-reduction methods

Open issues retimed circuits circuits with differing state assignments



Physical Verification


Overview

What is Physical Verification (PV)?

General PV topics Design Rule Check (DRC) Logical Versus Schematic (LVS) Verification Algorithms

- Flat and Hierarchical

Approaches DRC

- Place and Route, Flat and Hierarchical

LVS- Place and Route, Flat and Hierarchical

Courtesy Cadence Design Systems, Inc.


What is Design Rule Checking?

Verification that layout geometry is legal obeys set of design rules minimum widths and spacings extensions, overlaps circuit-dependent rules

Goal verify that all rules are met highlight places that rules fail and why use minimum CPU time, memory integrated DRC + layout editor

- use existing data structures

- check incrementally

A

B

Smin = 3 if VAB < 2.5V,

Smin = 4 otherwise

Slide courtesy, H. Walker, TAMU


Why Design Rule Checking?

Manufacturing resolution limits can only pattern line widths and spacings

above Wmin and Smin

limits of photolithography, optics, etc.

Manufacturing alignment limits overlay registration varies slightly repeatability of mechanics, sensors

Manufacturing disturbances line over/under etching furnace temperature variations particles

Layout design rules obey them to get high manufacturing yield a compromise between yield and density rules are local in nature

vs.

vs.vs.

vs.

vs.



Geometry Representation Polygon

rectangles as special case most natural representation simple specification of most design rules requires good polygon package

Raster at design rule resolution memory hog

Tile corner-stitched rectangles, trapezoids good for incremental analysis local connections already stored

Edge requires connectivity information minimal memory

00 10 00

01 11 01

00 10 00



Polygon DRC

Design rules in terms of boolean operations Met-Met spacing > 3 lambda

- MetI = inflate(Met, 1.5)

- Error = MetI MetI

Issues inflation of oblique angles robustness of polygon package speed

- O(nm) operation for n and m-edge polygons memory

- many auxiliary structures for each edge

- 2 floats, 5 points in DMW polygon package must merge electrically connected polygons must restrict checks to neighboring polygons

- avoid O(n2) checks for n polygons

A

B

A B A - B A B



Polygon Operations

Find edge intersections O(nm) time for n and m edge polygons use neighborhood check to reduce average to (nlogn) split edges at intersections

Walk the edges keeping to edges that are on outside of result polygon use wrap/winding number to compute inside/outside

- edge crossings of horizontal ray

+1 -1 +1

sum = +1 => insideworst-case



Neighborhood Checking Design rules are local - only check neighborhood

objects spread evenly across chip

- number of neighbors roughly constant

Bin sorting divide chip into c x c bins bin points to all objects that intersect it O(1) time to check nearby bins for objects

Quad tree search tree - log(n) time to find neighbors

Scan line only hold objects within design rule of scan line cutline on n-object chip hits ~sqrt(n) objects n*log(n) time to scan all objects

Corner-stitching inherent neighborhood relationships



Raster DRC Scan window over raster

d x d for maximum design rule of d units table lookup of d x d window

- window passes/fails

- precompute tables one bit per layer

- layer combinations via bit operations

- very fast

Issues fine grid design rules => large raster

- I/O time, memory consumption

- rasterization time

- use scan line to select polygons to rasterize large d => large tables limited to Manhattan geometry works best on simple MOSIS design rules

space 2ok



Line Scanning Algorithm

• O(nlgn) runtime

• Many applications, e.g., edge based DRC

Input: layout features represented in non-vertical edges

Output: geometric Boolean operation results

1. Sort the edge endpoints in x-coordinates into Q

2. While(Q not empty) {

3. Pop up edge endpoints E with smallest x-coordinates

4. Insert E into active edge set A

5. Merge sort A in y-coordinates

6. Remove an edge e from A if both endpoints of e are in A

7. Compute possible crosspoints, merge sort to Q

8. Perform Boolean operation

9. }

00

10

11

01

00


Design Rule Checks (DRCs)

Goals:

Manufacturability

Yield

Analysis Inputs:

Foundry Rules

Design data Mask data, Layer information

Typical checks performed:

For Manufacturing

Width, Spacing, Minimum Area, Enclosed Area, Overhang, etc.

For Yield

Antenna, Electromigration, Latch-up, Electrostatic Discharge, Density

DRC

Violations Report

Violations Markers

Rules Deck

Design

(Layout)



Design Rule Waivers

Well tested special structures Memory macros

Special permissions with the cost of reduced yield Antenna rules Density rules EM rules



Layout Versus Schematic (LVS)

Goals:

Functionality

Analysis Inputs:

Foundary or Library Vendor Library Spice Netlist

Design data Mask data, Logic Netlist

Typical checks performed:

Connectivity Recognition

Device Recognition

LVS

Violations Report

Violations Markers

Spice Netlist

Design (Layout &Netlist)



Design Transistors:Design Layout:

Analysis Process

Steps: Design Netlist:

I1 I3

I2 I4

IN1 IN1O1 O1

Net2Net1 Net3

IN1 O1

• From Gates to Transistors

• Primary I/Os Identified

• Connectivity Traced

• Device Recognition

Net1

Net2Net3

BA

VDD

GND

BA

VDD

GND

2/1

1/1

2/1

1/1

I1

I2

I3

I4

Net3Net1Net2



Flat Verification

Verification Performed on a Flat Database

T1

C1 C2 C1 C1

H2 H1

C2 C1

H2

T1

H1

All Levels Flattened to a Single Level

Schematic Netlist

Layout Netlist

T1

C1 C2 C1 C1

H2 H1

C2 C1

H2

T1

H1

T1

C1 C2 C1 C1

H2 H1

C2 C1

H2

T1

H1

T1

C1 C2 C1 C1

H2 H1

C2 C1

H2

T1

H1

T1

C1 C2 C1 C1

H2 H1

C2 C1

H2

T1

H1



Hierarchical Verification

T1

C1 C2 C1 C1

H2 H1

C2 C1

H2

T1

H1

Schematic Netlist

Layout Netlist

Check Check

Check

Check Check

Cells VerifiedCells not verified since

C1 already checked

Cells VerifiedCells Verified

Top Level Verified

Skip Skip

T1

C1 C2

H2H1

Cells Verified



Approaches

DRC Place and Route Environment Flat Hierarchical

LVS Place and Route Environment Flat Hierarchical



DRC: In Place and Route

Advantages:

Fast

Small database

Problems can be debugged and fixed fast.

Disadvantages:

Checking is only as accurate as the abstracts.

No checks at different hierarchy levels.

Connection to pins could have violations.

Description:

All cells are modeled with abstracts. No detailed layout is available.

IO Pad modeled with abstracts

Sub blocks modeled with abstracts

Hard Macro modeled with abstracts



DRC: Flat

Advantages:

Single run for entire chip, simple to setup

Has to be performed prior to every tape out

No modeling requirements

Disadvantages:

Entire design completed

Long run times

Resource requirements

Harder to debug

Description:

All cells are flattened. All geometric shapes visible. No black boxes.

IO Pad Flattening

Sub blocks merged at the top

Hard Macro Flattening



DRC: Hierarchical

Advantages:Start before entire chip

completedSmaller data size = shorter run

times, simpler debugging, easier to fix

Early density, EM, wide metal checks and repair

Effects seen on timing, SI early when it can still be addressed

Disadvantages:

Proper modeling of over the block and through the block routes

Full flat chip analysis is still required

Density checks may be inaccurate

Assumptions made at hierarchy boundaries

Description:

Bottom-up checking starting at block/hard macro level

Blocks verified separately

Top level verified using black box models for sub-blocks



LVS: In Place and Route

Advantages:

Fast

Small database

Problems can be debugged and fixed fast.

Disadvantages:

Only connectivity check of the nets.

No checks at different hierarchy levels.

Description:

All cells are modeled with abstract. No cell layout and netlist available.

IO Pad modeled with abstracts

Sub blocks modeled with abstracts

Hard Macro modeled with abstracts



LVS: Flat

Advantages:

Simple setup, implementation

No modeling requirement

Run before all tape outs regardless

Disadvantages:

Large data yielding long run times

Hard to debugging

Late in design cycle hard to accommodate changes

Description:

Design flattened to one level.

Primary I/Os and supply I/Os labeled

Entire IC layout compared to transistor level schematic.



LVS: Hierarchical

Advantages:Reduced amount of data

yielding faster run times

Easier to debug

Data maturity (incomplete block)

Fixing problems early in design easier

IP issues, verification reuse

Disadvantages:

Full flat chip analysis still required

Modeling errors possible

Description:

Bottom-up checking starting at block/hard macro level

Blocks verified separately

Top level verified w/black box models for sub-blocks

Connections to black boxes checked but not content



Hierarchical Filling Problem

Filling geometries are added only to master cells

Two instances of a master cell

Original layout

features

Flat fill solution Hierarchical fill solution

Each cell of the filled layout is a filled version of the corresponding original master cell


Why Hierarchical Filling?

Hierarchy characteristics of custom and semi-custom design flows

Enables and faster verification of the filled layout

Decreases data volume for standard cell designs


Difficulties of Hierarchical Filling

Density constraints for all instances of the master

Interactions / interferences at master cell boundaries

Always worse than flat solutions


C1

Ci

C2

C2`C1`C1` C2`

Ci

C2C1

Ci,1Ci,2

C1` C2`

C2C1

C1` C2`

Ci,1 Ci,2

Create k copies of master cell Ci

k : hierarchical layout flat layout

C2`C1` C2`C1`

Link all contained master cell C` with the new copies of Ci

C1 C2

Randomly replace Ci in any master cell with one of the new copies

K Way Master Cell Splitting


Hybrid Hierarchical / Flat Filling

Purely hierarchical fill phase

Flat fill `cleanup` phase

Split-hierarchical phase

features

three instances of a master cell


Physical Verification Summary

Tool modes Hierarchical vs. Flat

Examining DRC and LVS errors Design rule waivers

DRC and LVS approaches Place and Route Flat Hierarchical

Dummy fill insertion Flat Hierarchical



Thanks

Documents

ECE260B – CSE241A Winter 2005 Verification