ECE260B CSE241A Winter 2005 Verification

1
ECE260B CSE241AWinter 2005Verification
Website http//vlsicad.ucsd.edu/courses/ece260b-
w05
2
Verification

• Functional verification
• Testing
• Emulation
• Simulation
• Symbolic simulation
• Formal verification
• Timing verification
• Testing
• Simulation
• STA
• Physical verification
• DRC
• ERC
• LVS
• Misc
• Fanout constraints, etc.

3
Functional Verification
4
Design Verification
HDL
specification
manual design
RTL Synthesis
netlist
Is design consistent with original spec?
logic optimization
netlist
physical design
layout
Courtesy K. Keutzer, UCB
5
Implementation Verification
HDL
manual design
RTL Synthesis
netlist
logic optimization
Is implementation consistent with original design
intent?
netlist
physical design
layout
Courtesy K. Keutzer, UCB
6
Manufacture Verification (Test)
HDL
manual design
RTL Synthesis
Is manufactured circuit consistent with
implemented design?
netlist
logic optimization
netlist
physical design
layout
Courtesy K. Keutzer, UCB
7
Implementation Verification for ASICs
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
HDL
manual design
RTL Synthesis
netlist
logic optimization
netlist
ASIC signoff
physical design
layout
Courtesy K. Keutzer, UCB
8
Software Simulation
Simulation driver (vectors)
Simulation monitor (yes/no)

• 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

Courtesy K. Keutzer, UCB
9
Alternative - Static Signoff
Use static analysis techniques to verify (1)
functionality formal equivalence-checking
techniques (2) timing static timing analysis
HDL
manual design
RTL Synthesis
netlist
logic optimization
netlist
ASIC signoff
physical design
layout
Courtesy K. Keutzer, UCB
10
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

Courtesy K. Keutzer, UCB
11
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
Courtesy K. Keutzer, UCB
12
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
Courtesy K. Keutzer, UCB
13
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

Courtesy K. Keutzer, UCB
14
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

Courtesy K. Keutzer, UCB
15
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
16
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

Coutesy, A. Nardi, UCB
17
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 seqs
• Some (many) corner cases not checked
• Designer provides test vectors (with help from
  tools)

Coutesy, A. Nardi, UCB
18
Complete Coverage Example

• For these two circuits
• f ab(cd)
• abc abd
• g
• So the circuits are equivalent for all inputs
• Such a proof can be found automatically
• No simulation needed

g abcabd
a
b
d
Coutesy, A. Nardi, UCB
19
Using Formal Verification

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

Coutesy, A. Nardi, UCB
20
Types of Specifications
Coutesy, A. Nardi, UCB
21
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)

Coutesy, A. Nardi, UCB
22
Types of Formal Verification
Distinction between property checking and equiv.
checking is becoming common knowledge
Formal Verification
Property Checking
Equivalence Checking
Sequential
Combinational
Different comb. equiv. methods give different
market opportunities must be understood for FV
strategy
Capacity
Similarity Required
Coutesy, A. Nardi, UCB
23
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

Coutesy, A. Nardi, UCB
24
Types of Equivalence Checking

• 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

Coutesy, A. Nardi, UCB
25
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

Coutesy, A. Nardi, UCB
26
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

Coutesy, A. Nardi, UCB
27
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

Coutesy, A. Nardi, UCB
28
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
• IBMs 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
Coutesy, A. Nardi, UCB
29
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

Coutesy, A. Nardi, UCB
30
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

Coutesy, A. Nardi, UCB
31
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
  dont cares
• Capacity and robustness are critical
• No dominant player yet

Coutesy, A. Nardi, UCB
32
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

Coutesy, A. Nardi, UCB
33
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

Coutesy, A. Nardi, UCB
34
Techniques (cont.)

• Pattern matching
• Transform circuits to increase similarity
• Examples remove inverter pairs and buffers, use
  de Morgans 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

Coutesy, A. Nardi, UCB
35
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

Coutesy, A. Nardi, UCB
36
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

Coutesy, A. Nardi, UCB
37
Equivalence Checking Summary

• Routinely verify complex (gt1M 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

Courtesy K. Keutzer, UCB
38
Physical Verification
39
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.
40
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
Smin 3 if VAB lt 2.5V, Smin 4 otherwise
B
Slide courtesy, H. Walker, TAMU
41
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.
Slide courtesy, H. Walker, TAMU
42
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
Slide courtesy, H. Walker, TAMU
43
Polygon DRC

• Design rules in terms of boolean operations
• Met-Met spacing gt 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
Slide courtesy, H. Walker, TAMU
44
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 gt inside
worst-case
Slide courtesy, H. Walker, TAMU
45
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
• nlog(n) time to scan all objects
• Corner-stitching
• inherent neighborhood relationships

Slide courtesy, H. Walker, TAMU
46
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 gt large raster
• I/O time, memory consumption
• rasterization time
• use scan line to select polygons to rasterize
• large d gt large tables
• limited to Manhattan geometry
• works best on simple MOSIS design rules

space 2 ok
Slide courtesy, H. Walker, TAMU
47
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

00
10

• Sort the edge endpoints in x-coordinates into Q
• While(Q not empty)
• Pop up edge endpoints E with smallest
  x-coordinates
• Insert E into active edge set A
• Merge sort A in y-coordinates
• Remove an edge e from A if both endpoints
  of e are in A
• Compute possible crosspoints, merge sort
  to Q
• Perform Boolean operation

11
01
00
48
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
Courtesy Cadence Design Systems, Inc.
49
Design Rule Waivers

• Well tested special structures
• Memory macros
• Special permissions with the cost of reduced
  yield
• Antenna rules
• Density rules
• EM rules

Courtesy Cadence Design Systems, Inc.
50
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
Courtesy Cadence Design Systems, Inc.
51
Analysis Process

• Steps

• Design Netlist

• From Gates to Transistors

• Primary I/Os Identified

• Connectivity Traced

• Device Recognition

Design Transistors
Design Layout
I1
I3
I2
I4
Courtesy Cadence Design Systems, Inc.
52
Flat Verification
Courtesy Cadence Design Systems, Inc.
53
Hierarchical Verification
T1
H2
H1
C1
C2
Courtesy Cadence Design Systems, Inc.
54
Approaches

• DRC
• Place and Route Environment
• Flat
• Hierarchical
• LVS
• Place and Route Environment
• Flat
• Hierarchical

Courtesy Cadence Design Systems, Inc.
55
DRC In Place and Route
Description All cells are modeled with
abstracts. No detailed layout is available.

• Disadvantages
• Checking is only as accurate as the abstracts.
• No checks at different hierarchy levels.
• Connection to pins could have violations.

• Advantages
• Fast
• Small database
• Problems can be debugged and fixed fast.

Courtesy Cadence Design Systems, Inc.
56
DRC Flat
Description All cells are flattened. All
geometric shapes visible. No black boxes.

• 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

Courtesy Cadence Design Systems, Inc.
57
DRC Hierarchical

• Description
• Bottom-up checking starting at block/hard macro
  level
• Blocks verified separately
• Top level verified using black box models for
  sub-blocks

• 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

• Advantages
• Start before entire chip completed
• Smaller 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

Courtesy Cadence Design Systems, Inc.
58
LVS In Place and Route
Description All cells are modeled with abstract.
No cell layout and netlist available.

• Disadvantages
• Only connectivity check of the nets.
• No checks at different hierarchy levels.

• Advantages
• Fast
• Small database
• Problems can be debugged and fixed fast.

Courtesy Cadence Design Systems, Inc.
59
LVS Flat

• Description
• Design flattened to one level.
• Primary I/Os and supply I/Os labeled
• Entire IC layout compared to transistor level
  schematic.

• Disadvantages
• Large data yielding long run times
• Hard to debugging
• Late in design cycle hard to accommodate changes

• Advantages
• Simple setup, implementation
• No modeling requirement
• Run before all tape outs regardless

Courtesy Cadence Design Systems, Inc.
60
LVS Hierarchical

• 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

• Disadvantages
• Full flat chip analysis still required
• Modeling errors possible

• 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

Courtesy Cadence Design Systems, Inc.
61
Hierarchical Filling Problem

• Filling geometries are added only to master cells

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

62
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

63
Difficulties of Hierarchical Filling

• Density constraints for all instances of the
  master

• Interactions / interferences at master cell
  boundaries

• Always worse than flat solutions

64
K Way Master Cell Splitting

• k ? ? hierarchical layout ? flat layout

65
Hybrid Hierarchical / Flat Filling
Purely hierarchical fill phase
Split-hierarchical phase
66
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

Courtesy Cadence Design Systems, Inc.
67
Thanks