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. Library/ module generators 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. a 0 d q Library/ module generators 1 b s clk a 0 d q 1 b s clk 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. a 0 d q Library/ module generators 1 b s clk a 0 d q 1 b s clk 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. a 0 d q Library/ module generators 1 b s clk a 0 d q 1 b s clk 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. a 0 d q 1 b s clk 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. a 0 d q Library/ module generators 1 b s clk a 0 d q 1 b s clk 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. netlist physical layout 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. 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 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 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) Formal Verification vs Informal Verification Coutesy, A. Nardi, UCB

18. a b f = ab(c+d) c d a b c 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 g = abc+abd a b d Coutesy, A. Nardi, UCB

19. Requirements “Correct” or a Counter-Example: Formal Verification Tool Design Using Formal Verification • No test vectors • Equivalent to exhaustive simulation over all possible sequences of vectors (complete coverage) Coutesy, A. Nardi, UCB

20. Requirements design should satisfy Specification Requirements are precise: a must for formal verification Informal Formal Equivalence Properties Is one design equivalent to another? Design has certain good properties? 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. 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 Behavioral desc. Behavioral desc. RTL netlist RTL netlist Gate level netlist Gate level netlist Trans. netlist Trans. netlist Layout Layout Types of Equivalence Checking 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 • 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 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 don’t 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 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 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 (>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 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 < 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 > 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 => 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 • n*log(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 => 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 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. Goals: Manufacturability Yield Analysis Inputs: Foundry Rules Design data Mask data, Layer information Rules Deck Design (Layout) Violations Markers Violations Report Design Rule Checks (DRCs) 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. Goals: Functionality Analysis Inputs: Foundary or Library Vendor Library Spice Netlist Design data Mask data, Logic Netlist Spice Netlist Design (Layout &Netlist) Violations Markers Violations Report Layout Versus Schematic (LVS) Typical checks performed: • Connectivity Recognition • Device Recognition LVS Courtesy Cadence Design Systems, Inc.