Getting Started with Hercules Tutorial

Version W-2004.12-SP1, April 2005

Copyright Notice and Proprietary Information

Copyright 2005 Synopsys, Inc. All rights reserved. This software and documentation contain confidential and proprietary information that is the property of Synopsys, Inc. The software and documentation are furnished under a license agreement and may be used or copied only in accordance with the terms of the license agreement. No part of the software and documentation may be reproduced, transmitted, or translated, in any form or by any means, electronic, mechanical, manual, optical, or otherwise, without prior written permission of Synopsys, Inc., or as expressly provided by the license agreement.

Right to Copy Documentation

The license agreement with Synopsys permits licensee to make copies of the documentation for its internal use only. Each copy shall include all copyrights, trademarks, service marks, and proprietary rights notices, if any. Licensee must assign sequential numbers to all copies. These copies shall contain the following legend on the cover page: This document is duplicated with the permission of Synopsys, Inc., for the exclusive use of __________________________________________ and its employees. This is copy number __________.

Destination Control Statement

All technical data contained in this publication is subject to the export control laws of the United States of America. Disclosure to nationals of other countries contrary to United States law is prohibited. It is the readers responsibility to determine the applicable regulations and to comply with them.

Disclaimer
SYNOPSYS, INC., AND ITS LICENSORS MAKE NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, WITH REGARD TO THIS MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.

Registered Trademarks ()
Synopsys, AMPS, Arcadia, C Level Design, C2HDL, C2V, C2VHDL, Cadabra, Calaveras Algorithm, CATS, CSim, Design Compiler, DesignPower, DesignWare, EPIC, Formality, HSPICE, Hypermodel, iN-Phase, in-Sync, Leda, MAST, Meta, Meta-Software, ModelAccess, ModelTools, NanoSim, OpenVera, PathMill, Photolynx, Physical Compiler, PowerMill, PrimeTime, RailMill, Raphael, RapidScript, Saber, SiVL, SNUG, SolvNet, Stream Driven Simulator, Superlog, System Compiler, Testify, TetraMAX, TimeMill, TMA, VCS, Vera, and Virtual Stepper are registered trademarks of Synopsys, Inc.

Trademarks ()
abraCAD, abraMAP, Active Parasitics, AFGen, Apollo, Apollo II, Apollo-DPII, Apollo-GA, ApolloGAII, Astro, Astro-Rail, Astro-Xtalk, Aurora, AvanTestchip, AvanWaves, BCView, Behavioral Compiler, BOA, BRT, Cedar, ChipPlanner, Circuit Analysis, Columbia, Columbia-CE, Comet 3D, Cosmos, CosmosEnterprise, CosmosLE, CosmosScope, CosmosSE, Cyclelink, Davinci, DC Expert, DC Expert Plus, DC Professional, DC Ultra, DC Ultra Plus, Design Advisor, Design Analyzer, Design Vision, DesignerHDL, DesignTime, DFM-Workbench, DFT Compiler, Direct RTL, Direct Silicon Access, Discovery, DW8051, DWPCI, Dynamic-Macromodeling, Dynamic Model Switcher, ECL Compiler, ECO Compiler, EDAnavigator, Encore, Encore PQ, Evaccess, ExpressModel, Floorplan Manager, Formal Model Checker, FoundryModel, FPGA Compiler II, FPGA Express, Frame Compiler, Galaxy, Gatran, HDL Advisor, HDL Compiler, Hercules, Hercules-Explorer, Hercules-II, Hierarchical Optimization Technology, High Performance Option, HotPlace, HSPICE-Link, iN-Tandem, Integrator, Interactive Waveform Viewer, i-Virtual Stepper, Jupiter, Jupiter-DP, JupiterXT, JupiterXT-ASIC, JVXtreme, Liberty, Libra-Passport, Library Compiler, Libra-Visa, Magellan, Mars, Mars-Rail, Mars-Xtalk, Medici, Metacapture, Metacircuit, Metamanager, Metamixsim, Milkyway, ModelSource, Module Compiler, MS-3200, MS-3400, Nova Product Family, Nova-ExploreRTL, Nova-Trans, Nova-VeriLint, Nova-VHDLlint, Optimum Silicon, Orion_ec, Parasitic View, Passport, Planet, Planet-PL, Planet-RTL, Polaris, Polaris-CBS, Polaris-MT, Power Compiler, PowerCODE, PowerGate, ProFPGA, ProGen, Prospector, Protocol Compiler, PSMGen, Raphael-NES, RoadRunner, RTL Analyzer, Saturn, ScanBand, Schematic Compiler, Scirocco, Scirocco-i, Shadow Debugger, Silicon Blueprint, Silicon Early Access, SinglePass-SoC, Smart Extraction, SmartLicense, SmartModel Library, Softwire, Source-Level Design, Star, Star-DC, Star-MS, Star-MTB, Star-Power, Star-Rail, Star-RC, Star-RCXT, Star-Sim, Star-SimXT, Star-Time, Star-XP, SWIFT, Taurus, Taurus-Device, Taurus-Layout, Taurus-Lithography, Taurus-Process, Taurus-Topography, Taurus-Visual, Taurus-Workbench, TimeSlice, TimeTracker, Timing Annotator, TopoPlace, TopoRoute, Trace-On-Demand, True-Hspice, TSUPREM-4, TymeWare, VCS Express, VCSi, Venus, Verification Portal, VFormal, VHDL Compiler, VHDL System Simulator, VirSim, and VMC are trademarks of Synopsys, Inc.

Service Marks (SM)

MAP-in, SVP Caf, and TAP-in are service marks of Synopsys, Inc. SystemC is a trademark of the Open SystemC Initiative and is used under license. ARM and AMBA are registered trademarks of ARM Limited. All other product or company names may be trademarks of their respective owners. Printed in the U.S.A. Getting Started with Hercules Tutorial, W-2004.12-SP1

ii

Contents
What Is Hercules? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Note to Dracula Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Document Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Learning Schedule. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Related Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Customer Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviii xviii xviii xx xxii xxii xxiii

1.

Installation and Setup About This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating Directories and Getting the Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . Create a Target Directory for Hercules Setup Files . . . . . . . . . . . . . . . . . Download . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Downloading the Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Copy Install and Code Files to Target Directory. . . . . . . . . . . . . . . . . . . . Extracting the Zipped File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Untar File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Install Files in Proper Directory and Execute . . . . . . . . . . . . . . . . . . . . . . Get the Manuals and Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . Get the Tutorial. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ensuring Your Environment Accommodates Hercules . . . . . . . . . . . . . . . . . . Edit Your .cshrc or .profile Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Initialize Your Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Authorize the Synopsys Products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 2 2 2 2 3 3 3 3 4 4 4 4 5 5

iii

Licensing Hercules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Getting Hercules to Run: Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . How to Set Up Your Account . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Whats Next? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5 5 6 6

2. An Error-Free Design for DRC Learning Objectives for This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Before You Start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Learning Method: the Design Example . . . . . . . . . . . . . . . . . . . . . . . . . . Layout Editors in This Tutorial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Overview of the Runset File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Runset File Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example of a Runset File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Runset Header Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . LAYOUT_PATH. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . INLIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BLOCK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OUTLIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OUTPUT_BLOCK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GROUP_DIR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . FORMAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Runset Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . WIDTH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Preprocessing Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CHECK_PATH_90 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Layer Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SNAP Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ASSIGN_LAYERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GRID Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ASSIGN_LAYERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CHECK_45. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DRC Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . EXTERNAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Running Hercules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8 8 8 9 9 9 11 11 11 12 12 12 12 13 13 13 13 14 14 14 14 15 15 15 15 15 16

iv

How to Run Hercules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Run File Results. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . What if My Output Is Not Correct? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Explanation of Error and Summary Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AD4FUL.RESULTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AD4FUL.LAYOUT_ERRORS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AD4FUL.sum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Design Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hierarchical Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Horizontal Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Efficient Versus Inefficient Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . Explanation of Output Tree Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hierarchy Tree Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AD4FUL.tree0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ADFUL.tree1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AD4FUL.tree3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Miscellaneous Output Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AD4FUL.tech and AD4FUL.vcell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . evaccess/ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . evaccess/AD4FUL.ev. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Whats Next? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16 17 17 18 18 19 20 27 27 28 29 30 30 31 35 40 43 44 44 44 47

3. Single Design Error for DRC Summary of Progress to This Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Learning Objectives for This Chapter. . . . . . . . . . . . . . . . . . . . . . . . . . . . Before You Start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Running Hercules on the Runset File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Output Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AD4FUL.LAYOUT_ERRORS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Geometric Representation of Error . . . . . . . . . . . . . . . . . . . . . . . . . AD4FUL.sum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Running Enterprise and Viewing Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . How to run Enterprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The initial Enterprise Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Viewing the EX_ADDER_2 Library File Names . . . . . . . . . . . . . . . . . . . . EX_ADDER Input and Output Files . . . . . . . . . . . . . . . . . . . . . . . . . 49 49 50 50 51 51 52 53 54 55 55 56 58

Viewing Data in Enterprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Layout Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Output Hierarchy Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Whats Next? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

59 64 67 68

4. A Complete Design for DRC Summary of Progress to This Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Learning Objectives for This Chapter. . . . . . . . . . . . . . . . . . . . . . . . . . . . Before You Start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A Summary of Design Rule Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Operations Allowed by Hercules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Examining the Runset Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Writing Output Results to Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Error Hierarchy Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Permanent Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Temporary Output. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . EXTERNAL Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . metal1 to metal1 Spacing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . metal2 to metal2 spacing - longedge Option . . . . . . . . . . . . . . . . . . metal1 to metal2 spacing - touch Option . . . . . . . . . . . . . . . . . . . . . INTERNAL Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . poly width - edge_45 Option. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . metal2 width - corner Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CUT Checks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cut poly by diffusion - cut_outside Option . . . . . . . . . . . . . . . . . . . . AREA Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Via area - range Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DATA CREATION / INTERNAL Checks . . . . . . . . . . . . . . . . . . . . . . . . . . BOOLEAN poly AND tox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BOOLEAN gate AND psel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BOOLEAN gate NOT pgate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Internal pgate Dimension Operator . . . . . . . . . . . . . . . . . . . . . . . . . Internal ngate dimension Operator. . . . . . . . . . . . . . . . . . . . . . . . . . DATA CREATION Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BOOLEAN cont NOT poly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ENCLOSE Check. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ENCLOSE toxcont by tox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ENCLOSE toxcont by metal1 - touch, overlap, and parallel Options 69 70 70 70 70 71 72 72 72 73 73 73 74 74 75 75 76 76 76 77 78 78 78 79 79 80 80 81 81 82 82 82

vi

From Rules to Runsets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Running Hercules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Output Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Error File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Summary File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Viewing Data Creation Layers in Enterprise . . . . . . . . . . . . . . . . . . . . . . . . . . Introducing Hercules-Explorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Running Hercules-Explorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Viewing Errors Using Hercules-Explorer . . . . . . . . . . . . . . . . . . . . . . . . . Using the Checks Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Running Hercules Inside of Hercules-Explorer . . . . . . . . . . . . . . . . . . . . Whats Next? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

82 84 84 85 89 96 99 99 104 105 108 110

5. Hercules DRC Migration Summary of Progress to This Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Learning Objectives for This Chapter. . . . . . . . . . . . . . . . . . . . . . . . . . . . Before You Start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . What Is Drac2He? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using the Migration Tutorials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Learning method: Design Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Getting Started with Drac2He . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -OutType . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -rc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -N . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Other Dracula Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . How to Run Drac2He . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Translation Results for Migration1 Example . . . . . . . . . . . . . . . . . . . . . . . . . . Output from First Dracula Translation . . . . . . . . . . . . . . . . . . . . . . . . . . . Dracula_DEFAULTS, OPTIONS Section . . . . . . . . . . . . . . . . . . . . . OUTPUT Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . COMMENT Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . COMMENTS in the Hercules Runset . . . . . . . . . . . . . . . . . . . . . . . . CASE of LAYERS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CONJUNCTIVE and COPY Commands . . . . . . . . . . . . . . . . . . . . . Output with PERM Omitted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 112 112 112 113 113 113 113 114 114 114 116 117 117 120 120 121 121 121 121 121

vii

-rc and -N Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Running Drac2He with Warnings and Errors . . . . . . . . . . . . . . . . . . . . . . . . . . Translation Results for Migration2 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . Output of Translated migration2.drc File . . . . . . . . . . . . . . . . . . . . . . . . . error.out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Whats Next? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

122 125 125 125 128 129

6. Hercules Migration with Hercules-Explorer Summary of Progress to This Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Learning Objectives for This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Generating a Runset with Drac2He . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Translation Results for Migration3 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . Setting up Hercules in the Opus Environment . . . . . . . . . . . . . . . . . . . . . . . . . Starting Opus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Loading Synopsys SKILL Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Opening Your Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Setting Hercules Startup Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Streaming Out from Virtuoso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Opening Hercules-Explorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Debugging with Hercules-Explorer in the Opus Environment . . . . . . . . . . . . . Whats Next? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 131 132 132 133 133 134 134 135 136 136 138 143

7. Introduction to Hercules HLVS Learning Objectives for This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Before You Start. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Learning Method: the Design Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . What are LVS and Its Components? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . What is Hierarchical LVS? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hierarchical Device Extraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Layers That Make Up a Device Should Be in the Same Block . . . . Hierarchical Texting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Match Text Appropriately at all Hierarchical Levels . . . . . . . . . . . . . Use Different Texting Layers for Different Polygon Layers . . . . . . . . 145 146 146 146 147 147 147 149 149 150

viii

Hierarchical Netlist Comparison. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Designing to Benefit from Hierarchical LVS . . . . . . . . . . . . . . . . . . . . . . . . . . . Match the Hierarchy Between Schematic and Layout . . . . . . . . . . . . . . . Defining the Most Beneficial Equivalence Points . . . . . . . . . . . . . . . . . . Match Layout Block Name to Schematic Block Name . . . . . . . . . . . . . . . Match Block Port Names for Blocks That Will Be Equivalence Points . . . Difficulties Presented by Hierarchy in LVS . . . . . . . . . . . . . . . . . . . . . . . . . . . . Devices Floating Out of Equivalence Points. . . . . . . . . . . . . . . . . . . . . . . Port Swappability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Detecting Swappable Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Equivalence Points That are Resolved in Their Parent . . . . . . . . . . . . . . Different Number of Instances of a Cell in the Layout and Schematic . . . Overview of Required and Optional Input Files for LVS . . . . . . . . . . . . . . . . . . The Runset File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example of an Actual Runset File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . General Runset File Sections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Runset Header Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . General Runset Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Preprocessing Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Texting Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Layer Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . LVS Netlist Extraction Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Device Layer Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Device Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Connectivity Commands and Options . . . . . . . . . . . . . . . . . . . . . . . Texting Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Layout Netlisting Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Graphical Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . LVS Comparison Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . LVS Device Equate Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . LVS Comparison Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Schematic Netlist File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . NetTran. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Executing NetTran as a UNIX Shell Command . . . . . . . . . . . . . . . . Executing NetTran by Specifying a SCHEMATIC_FORMAT . . . . . . The EDTEXT File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Equivalence File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Running Hercules LVS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . How to run Hercules LVS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

150 153 153 154 155 156 156 156 157 157 158 158 159 160 160 164 164 166 168 168 169 170 170 170 171 171 171 171 172 172 173 180 181 181 185 187 188 188 189

ix

Run File Results. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . What if Your Output Is Not Correct? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Overview of Hercules LVS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . LVS Device Extraction Output Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DAC96.LAYOUT_ERRORS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DAC96.acct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DAC96.sum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DAC96.net . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tree Files and Technology Option Files . . . . . . . . . . . . . . . . . . . . . . LVS Comparison Output Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DAC96.LVS_ERRORS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DAC96.cmpsum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DAC96.cmperr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Compare Directory Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ./lvsflow Directory Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Progress Review of Hercules LVS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Whats Next? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

189 190 191 193 193 194 196 207 207 207 208 208 218 228 236 238 239

8. HLVS Advanced Concepts Learning Objectives for This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Before You Start. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . General Requirements of a Strict LVS Flow Comparison . . . . . . . . . . . . . . . . Comparing Top-Block Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Requiring Ports to Match by Name . . . . . . . . . . . . . . . . . . . . . . . . . Requiring All Ports to be Texted . . . . . . . . . . . . . . . . . . . . . . . . . . . . Symmetry: Independent and Dependent Swappability . . . . . . . . . . . . . . Guaranteeing Equivalence Point Matching . . . . . . . . . . . . . . . . . . . . . . . Reuse of IP Blocks and Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . Debugging Large Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Guidelines for a Good Equivalence File . . . . . . . . . . . . . . . . . . . . . . 259 260 260 260 262 262 263 264 264 264 265

Guaranteeing Devices Are Netlisted in the Cell Where They Are Designed 265 MOS_REFERENCE_LAYER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266 PUSH_DOWN_DEVICES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270 Setting up Error and Warning Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hercules Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Running Hercules LVS for Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . Runfile Results for Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Running Hercules LVS for Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 270 271 272 272 286

Runfile Results for Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . EQUATE, EQUIV, and COMPAREWhich Setting Takes Priority? . . . . . . . . . Whats Next? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

286 296 296

9. Hercules HLVS Debugging Learning Objectives for This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Before You Start. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Quick Checklist for LVS Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . LVS Extraction Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . STEP 1: Check for Texting or Device Extraction Errors. . . . . . . . . . . . . . Missing Terminals - Device Extraction Errors . . . . . . . . . . . . . . . . . Too Many Terminals - Device Extraction Errors . . . . . . . . . . . . . . . . Unused Text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Text Opens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Text Shorts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . STEP 2: Review Your TEXT_OPTIONS, ASSIGN, and TEXT Sections, STEP 3: Debug All Device Extraction Errors.. . . . . . . . . . . . . . . . . . . . . . STEP 4: Rerun Your Hercules LVS Job.. . . . . . . . . . . . . . . . . . . . . . . . . . LVS Comparison Debug. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . STEP 5: Review the Equivalence Points. . . . . . . . . . . . . . . . . . . . . . . . . . Filtering Options Missing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Merging Options Missing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . POWER/GROUND Shorts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . LAYOUT POWER or LAYOUT GROUND Definitions Missing . . . . . Schematic Globals Missing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . STEP 6: Fix COMPARE Errors and Rerun Hercules. . . . . . . . . . . . . . . . Running Hercules LVS with Errors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Debugging Your Hercules LVS Run . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . STEP 1: Check for Texting or Device Extraction Errors. . . . . . . . . . . . . . Short Finding in Hercules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Short Finding in Hercules-Explorer . . . . . . . . . . . . . . . . . . . . . . . . . Loading Extract Errors in Hercules-Explorer . . . . . . . . . . . . . . . . . . Loading Text Short Coordinates Into Shortest Path Tool . . . . . . . . . Setting Error Highlight Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Viewing Text Short Errors in Enterprise . . . . . . . . . . . . . . . . . . . . . . Fixing the Short Between DINT15 and ICDOUT15 . . . . . . . . . . . . . Using Hercules-Explorer Shortest Path for VDD/GND Short . . . . . . Selecting Start and Stop Points Manually . . . . . . . . . . . . . . . . . . . . 297 297 298 298 298 298 300 301 302 303 303 304 304 304 304 304 304 305 305 306 306 306 309 309 309 310 312 313 314 315 318 319 324

xi

Correcting the VDD/GND Short . . . . . . . . . . . . . . . . . . . . . . . . . . . . Short Finding with FSPBTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Running Hercules with FSPBTS . . . . . . . . . . . . . . . . . . . . . . . . . . . Viewing the Shortest Path Output . . . . . . . . . . . . . . . . . . . . . . . . . . Running Hercules After All block.LAYOUT_ERRORS Errors Are Fixed . . . . . Step 2: Review your TEXT_OPTIONS, ASSIGN, and TEXT Sections. . . Step 3: Debug All Device Extraction Errors.. . . . . . . . . . . . . . . . . . . . . . . Step 4: Rerun Your Hercules LVS Job . . . . . . . . . . . . . . . . . . . . . . . . . . . Step 5: Review the Equivalence Points.. . . . . . . . . . . . . . . . . . . . . . . . . . Linking Hercules-Explorer to HTML Interface . . . . . . . . . . . . . . . . . Reviewing the LVSDEBUG File . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Hercules-Explorer hxlvs to Debug Specific COMPARE Errors . . . . . . .

326 326 329 330 332 333 333 333 333 333 335 339

STEP 6: Fix COMPARE Errors and Rerun Hercules. . . . . . . . . . . . . . . . 339 Where to Start Debugging LVS Errors . . . . . . . . . . . . . . . . . . . . . . . 341 Loading buf4x for Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342 Files Available in Hercules-Explorer . . . . . . . . . . . . . . . . . . . . . . . . . 344 Reading the sum.block.block File . . . . . . . . . . . . . . . . . . . . . . . . . . . 348 Table on Schematic and Layout Net Relationships . . . . . . . . . . . . . 348 Highlighting Nets and Devices in the Layout . . . . . . . . . . . . . . . . . . 349 Using Information About Matched Devices Connected to Unmatched Nets 351 Analyzing the Highlight Information . . . . . . . . . . . . . . . . . . . . . . . . . 352 Loading cs_add for Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353 Highlighting to Find an Open Between Two Nets . . . . . . . . . . . . . . . 355 An Exercise for the Reader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . When Do You Rerun Hercules? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Whats Next? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356 357 357

10. HLVS Migration with Hercules-Explorer Summary of Progress to This Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Learning Objectives for This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Before You Start. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Overview of HLVS Migration Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Details of Flow Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Generating a Runset with Drac2He . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Translation Results for Migration.lvs Example . . . . . . . . . . . . . . . . . . . . . . . . . Translated Header and Option Sections . . . . . . . . . . . . . . . . . . . . . . . . . Translated EDTEXT and HEDTEXT Files . . . . . . . . . . . . . . . . . . . . . . . . 371 371 372 372 373 374 375 375 376

xii

Netlisting Consistency Between Composer and Hercules-Explorer . . . . Case Sensitivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Setting up Hercules in the Opus Environment . . . . . . . . . . . . . . . . . . . . . . . . . Starting Opus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Loading Synopsys SKILL Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Opening Your Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Connecting Hercules-Explorer to Virtuoso and Composer . . . . . . . . . . . Executing Hercules LVS in the Opus Environment . . . . . . . . . . . . . . . . . . . . . Highlighting in Virtuoso and Composer . . . . . . . . . . . . . . . . . . . . . . . . . . Debugging with Hercules-Explorer Connected to Virtuoso and Composer . . . Opening the sum.block.block File in Hercules-Explorer. . . . . . . . . . . . . . Detailed Flow: Dracula Rule Files to Hercules LVS Output . . . . . . . . . . . . . . . Hercules Parses the Output of Drac2He as Input . . . . . . . . . . . . . . . . . . Reading and Converting the CDL Netlist . . . . . . . . . . . . . . . . . . . . . . . . . Streaming in Your GDSII File with gdsin . . . . . . . . . . . . . . . . . . . . . . . . . Device Extraction and Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Generic Differences in Hercules and Dracula Device Extraction . . . MOSFET Device Extraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BIPOLAR Device Extraction (BJTs) . . . . . . . . . . . . . . . . . . . . . . . . . DIODE Device Extraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CAPACITOR Device Extraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . RESISTOR Device Extraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Layout Netlist Generation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Generating Schematic Globals, Equates, and the Equivalence File . . . . Details on Filter Option Translation . . . . . . . . . . . . . . . . . . . . . . . . . Details of Merging, Gate Formation, and Filtering Options . . . . . . . How the EQUIVALENCE File Is Generated . . . . . . . . . . . . . . . . . . . Comparing the Layout and Schematic Netlists . . . . . . . . . . . . . . . . . . . . Whats Next? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

377 378 378 379 379 380 380 382 385 386 386 391 393 394 395 395 396 396 397 398 398 399 399 400 402 403 404 405 405

11. Runset Debugger About This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Summary of Progress to This Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Learning Objectives for This Chapter. . . . . . . . . . . . . . . . . . . . . . . . . . . . Before You Start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Learning Method: the Design Example . . . . . . . . . . . . . . . . . . . . . . . . . . General Applications of the Runset Debugger. . . . . . . . . . . . . . . . . . . . . . . . . 407 408 408 408 409 409

xiii

The Runset File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DRC Checks in the Runset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . LVS Checks in the Runset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Enterprise Interface Tutorial. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . How to Run the Hercules Runset Debugger with Enterprise . . . . . . . . . . Using the Setup Window in the Runset Debugger . . . . . . . . . . . . . . . . . . Filling in the Setup Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Analyzing the Errors window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Correcting Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Verifying Corrected Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using the Watchpoints and Review Windows in the Runset Debugger . . Selecting Watchpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using the Review Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using the Exec Window to Run Hercules and Generate Debug Data . . . Using the Results Window and Debugging . . . . . . . . . . . . . . . . . . . . . . . Opening the Output Library and Cell . . . . . . . . . . . . . . . . . . . . . . . . Viewing Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Solving the Device Extraction Errors . . . . . . . . . . . . . . . . . . . . . . . . Checking the Updated Runset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adding the DRC Checks as Debug Points . . . . . . . . . . . . . . . . . . . . Solving the DRC Check Errors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Verifying the Debugged Runset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Virtuoso Interface Tutorial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Before You Start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . How to Run the Hercules Runset Debugger with Virtuoso . . . . . . . . . . . Loading Synopsys SKILL Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . Streaming Out the QA Cells. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Starting the Runset Debugger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using the Setup Window in the Runset Debugger . . . . . . . . . . . . . . . . . . Filling in the Setup Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Analyzing the Errors Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Correcting Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Verifying Corrected Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using the Watchpoints and Review Windows in the Runset Debugger . . Selecting Watchpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using the Review Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using the Exec Window to Run Hercules and Generate Debug Data . . . Using the Results Window and Debugging . . . . . . . . . . . . . . . . . . . . . . . Opening the Output Library and Cell . . . . . . . . . . . . . . . . . . . . . . . .

409 413 413 413 413 415 416 417 418 418 420 423 424 427 429 430 432 433 434 437 441 442 443 443 443 444 444 445 446 449 450 455 456 456 458 459 461 464 465 467

xiv

Viewing Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Solving the Device Extraction Errors . . . . . . . . . . . . . . . . . . . . . . . . Looking at NMOS Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A. Using Enterprise With Hercules-Explorer Introduction to Running Enterprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Create Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Open the Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Stream In the Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Open a Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Select a Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Running Hercules from Enterprise. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Hercules-Explorer with Enterprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Close Any Open Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Load Hercules-Explorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fixing the Error. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Rerunning Hercules from Hercules-Explorer . . . . . . . . . . . . . . . . . . . . . . Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Index

468 469 479 484

489 490 491 492 494 495 496 498 498 499 500 501 503

xv

xvi

About This Tutorial

The Getting Started with Hercules Tutorial assists the first-time user of Hercules in installing and running the Hercules software. Using the tutorials, you quickly learn to read Hercules runset files and to debug problems. This tutorial includes a detailed explanation of hierarchical design structure and how Hercules takes advantage of it. You also explore advanced Hercules applications, runset debugging information, and hints on how to get the most out of Hercules. This tutorial contains directions for using Hercules in the Synopsys Milkyway and Cadence Opus environments and includes steps for translating all data from Cadence Dracula. There are examples of input files, output files, and results, all of which can be found in the ./tutor directory of your Hercules installation. (See Chapter 1, Installation and Setup, for a complete description.)

xvii

About This Tutorial What Is Hercules?

What Is Hercules?
Hercules is a powerful software package that speeds the process of verifying integrated circuit layouts. Hercules is not just a single tool, but a suite of programs. Hercules can verify layout Design Rule Checks (DRC), perform Electrical Rule Checks (ERC), extract layout structures and compare them to an original design netlist by using the Layout versus Schematic (LVS) application, and generate or modify data for mask preparation. The hierarchical checking of algorithms make Hercules particularly well-suited for large and complex IC verification.

Note to Dracula Users

Hercules contains a Dracula runset translator, Drac2He. Chapter 5, Hercules DRC Migration, explains how to use this translator and access files. The tutorial shows you how to convert two simple DRC Dracula rule files to Hercules runsets, and then execute Hercules. However, you must first be familiar with Hercules-Explorer, the graphical debug tool that interfaces to Cadence Virtuoso. Follow the recommended learning flow described below.

Document Outline
The tutorial is divided into three sections. The first section covers the Hercules HDRC tool. It is divided into six chapters, outlined in the last section of this preface. The second section covers the Hercules HLVS tool. It is divided into four chapters. The last section covers the Hercules Runset Debugger tool. It has one chapter.

Section 1 - Getting Started with Hercules HDRC

Chapter 1, Installation and Setup, contains the file transfer protocol (ftp) installation and tutorial setup instructions for Hercules and Enterprise. Enterprise is one of the Synopsys layout editors and a view-only version of the layout tool is provided with Hercules-Explorer for looking at errors. Instructions

xviii

About This Tutorial Document Outline

for using Enterprise with Hercules-Explorer are provided in Appendix A, Using Enterprise With Hercules-Explorer. Chapter 2, An Error-Free Design for DRC, discusses the first tutorial design, a very basic, error-free example designed to introduce you to Hercules and the files created. The example is a building block intended to help you understand the more complex examples that follow. You learn about the contents of runset files, how to process runsets, and how to read the output. Chapter 3, Single Design Error for DRC, continues the tutorial with a single design error in the design of an inverter (INV) in a full adder (ADDER). We note the differences between the error-free Hercules run from Chapter 2 and the run with errors in this chapter. We also view the graphical output files in Enterprise, the Synopsys layout tool, provided with Hercules-Explorer for viewing errors. Chapter 4, A Complete Design for DRC, presents a multiple-error design. The activities in this chapter are comparable to the ones in Chapter 3 but here you create layout errors similar to those encountered in real designs and learn how to correct them. This chapter introduces Hercules-Explorer, a Synopsys graphical user interface debugger. Chapter 5, Hercules DRC Migration, shows you how to convert two simple Dracula rule files to Hercules runsets, using various translation options to familiarize you with operational and syntactical differences between the two tools. Chapter 6, Hercules Migration with Hercules-Explorer, has you convert a simple Dracula rule file to a Hercules runset using the translation options you learned in Chapter 5. You then run Hercules on this runset and view the results using Hercules-Explorer interfaced to Virtuoso, the Cadence layout tool.

Section 2 - Getting Started with Hercules LVS

Chapter 7, Introduction to Hercules HLVS, discusses the basic principles of Hercules Hierarchical Layout versus Schematic Checking (LVS). We also review the tutorial design used in this section of the document. You learn about the components of a Hercules LVS job and the contents of runset and output files created for an error-free LVS job. Chapter 8, HLVS Advanced Concepts, introduces you to concepts used in a strict Hercules LVS comparison, as well as to the Hercules LVS advanced options and commands required to make the flow work. We run two examples with a few errors in order to better illustrate the advanced features of Hercules used in this flow.

xix

About This Tutorial Learning Schedule

Chapter 9, Hercules HLVS Debugging, goes through a complete Hercules LVS debugging example. You learn how to use the HTML interface and Hercules-Explorer, a graphical user interface (GUI) debugging tool. Chapter 10, HLVS Migration with Hercules-Explorer, you convert a simple HLVS Dracula rule set to a Hercules runset using the translation options you learned in Chapter 5, Hercules DRC Migration. Then you run Hercules on this runset and view the results using Hercules-Explorer interfaced to Virtuoso and Composer, Cadence layout and schematic tools.

Section 3 - Getting Started with Hercules Runset Debugger

Chapter 11, Runset Debugger, introduces the Hercules Runset Debugger. This tool acts as an interface between Hercules and a graphical editor, and automates the process of creating, storing, and viewing data used to analyze Hercules operation. You learn how to use the Runset Debugger to analyze and correct a Hercules runset containing both DRC and LVS commands.

Learning Schedule
We suggest you complete the chapters of this tutorial in the order given below.

Learning Schedule for DRC

Begin with Chapter 1, Installation and Setup, to ensure that you have the correct installation of the Hercules software and tutorial examples. Complete Chapters 13 on installation, setup, and basic execution of Hercules. Estimated completion time: 30 minutes. If you are currently a Dracula user, once you have completed Chapters 13, go to Chapters 5 and 6. Estimated completion time: 30 minutes. If you are currently a Dracula user and you are learning to write Hercules runsets, after you have completed Chapters 13 and Chapters 5 and 6, go back and complete Chapter 4, A Complete Design for DRC. It is important that you follow this order of study so that you get an understanding of

xx

About This Tutorial Learning Schedule

Hercules in general (Chapters 1 and 2), of how Dracula and Hercules relate to each other (Chapters 5 and 6), and, finally, learn detailed information on Hercules (Chapter4), which you need for debugging the runsets you write. Estimated time to complete Chapter 4: 20 minutes. If you do not use Dracula in any way, go from Chapter 3 directly to Chapter 4 on detailed debugging in the Hercules environment. You can then skip Chapters 5 and 6. Estimated completion time: 20 minutes.

Learning Schedule for LVS

If you plan on using Hercules for LVS and you have not completed Chapters 13, start the tutorial with these chapters. They are necessary for the correct installation of the Hercules code and tutorial directories. They also give you a basic understanding of Hercules. Once you have completed Chapters 13, continue on to Chapter 7, Introduction to Hercules HLVS, for an introduction to Hercules LVS. If you are currently a Dracula user, once you have completed Chapter 7, skip to Chapter 10, HLVS Migration with Hercules-Explorer, for a complete tutorial on migrating from Dracula LVS to Hercules LVS and how to debug in the Opus environment. If you are currently a Dracula user and you plan on learning to write Hercules LVS runsets, go back and complete Chapters 8 and 9. If you are not a Dracula user, continue from Chapter 7 on to Chapters 8 and 9 to learn the advanced features of Hercules LVS and how to use the HTML and Hercules-Explorer interfaces for debugging LVS. You can skip Chapter 10.

Learning Schedule for Runset Debugger

If you have a license for the Hercules Runset Debugger, complete the desired chapters listed above (working through Chapters 13 at a minimum), and then proceed to Chapter 11, which contains an introductory

xxi

About This Tutorial Related Publications

tutorial to the Hercules Runset Debugger. Please note that you must have an Enterprise license and Enterprise installed on your system to complete this tutorial.

Related Publications
For additional information about Hercules, see Documentation on the Web, which provides HTML and PDF documents and is available through SolvNet at http://solvnet.synopsys.com. Synopsys Online Documentation (SOLD), which is included with the software for CD users or is available to download through the Synopsys Electronic Software Transfer (EST) system The Synopsys MediaDocs Shop, from which you can order printed copies of Synopsys documents, at http://mediadocs.synopsys.com.

Conventions
The following conventions are used in Synopsys documentation.
Convention
Courier Courier italic

Description Indicates command syntax. Indicates a user-defined value in Synopsys syntax, such as object_name. A user-defined value that is not Synopsys syntax, such as a user-defined value in a Verilog statement. Indicates user inputtext you type verbatimin Synopsys syntax and examples. User input that is not Synopsys syntax, such as a user name or password you enter in a GUI. Denotes optional parameters, such as
pin1 [pin2 ... pinN]

Regular italic

Courier bold

Regular bold

[]

xxii

About This Tutorial Customer Support

Convention
...

Description Indicates that a parameter can be repeated as many times as necessary Indicates a choice among alternatives, such as
low | medium | high

(This example indicates that you can enter one of three possible values for an option: low, medium, or high.) _ Connects terms that are read as a single term by the system, such as set_annotated_delay Indicates a keyboard combination, such as holding down the Control key and pressing c. Indicates a continuation of a command line. Indicates levels of directory structure. Indicates a path to a menu command, such as opening the Edit menu and choosing Copy.

Control-c

\ / Edit > Copy

Customer Support
Customer support is available through SolvNet online customer support and through contacting the Synopsys Technical Support Center.

Accessing SolvNet
SolvNet includes an electronic knowledge base of technical articles and answers to frequently asked questions about Synopsys tools. SolvNet also gives you access to a wide range of Synopsys online services including software downloads, documentation on the Web, and Enter a Call to the Support Center. To access SolvNet, 1. Go to the SolvNet Web page at http://solvnet.synopsys.com.

xxiii

About This Tutorial Customer Support

2. If prompted, enter your user name and password. (If you do not have a Synopsys user name and password, follow the instructions to register with SolvNet.) If you need help using SolvNet, click SolvNet Help in the Support Resources section.

Contacting the Synopsys Technical Support Center

If you have problems, questions, or suggestions, you can contact the Synopsys Technical Support Center in the following ways: Open a call to your local support center from the Web by going to http://solvnet.synopsys.com (Synopsys user name and password required), then clicking Enter a Call to the Support Center. Send an e-mail message to your local support center. E-mail support_center@synopsys.com from within North America. Find other local support center e-mail addresses at http://www.synopsys.com/support/support_ctr. Call (800) 245-8005 from within the continental United States. Call (650) 584-4200 from Canada. Find other local support center telephone numbers at http://www.synopsys.com/support/support_ctr.

Telephone your local support center. -

xxiv

1
Installation and Setup1
This chapter contains the file transfer protocol (ftp) instructions for installation setup of the product, its documentation, and tutorials. After installation, be sure to read the release notes for important product information. After the tutorial setup, check to see if you have all the correct directories and files, after which you are ready to start the tutorial.

About This Chapter

The following installation instructions assume that you know UNIX operating system commands. You should also have the GNU software to unzip files. Installation has three groups of steps: Creating directories and getting the zipped applications files, documentation, and tutorials. Extracting the zipped files. Ensuring that your environment accommodates Hercules and Enterprise.

Setup also has four groups of steps:

Installation and Setup Creating Directories and Getting the Files

Creating directories and moving files to them Sourcing the setup file. Converting data files to the correct formats. Checking to see if you have the correct directories.

Creating Directories and Getting the Files

In this section, you create the proper directories and download files.

Create a Target Directory for Hercules Setup Files

If you do not have one already, create a single target directory into which you will transfer Hercules installation files. Choose your own directory name. All the installation files will be in this target installation directory. Our example refers to this target directory as your_path. After the installation is complete, the $HERCULES_HOME_DIR environment variable is created, as well as the address your_path, which points to the location where you installed Hercules.

Download
Go to the Synopsys public website (www.synopsys.com) and do the following: 1. Click the SolvNet tab (you must be a registered user). 2. Choose Software and Installation > Electronic Software Transfer.

Downloading the Software

In order to download Hercules binaries from the Synopsys public website, do either of the following: Click REV_VAULT_GUIDE to get ftp path and directory information. Or, Go to http://www.synopsys.com/support/rev_vault_guide.html This page includes Synopsys product directories and their locations. Important:

Installation and Setup Extracting the Zipped File

Copy Install and Code Files to Target Directory

From /rev/hercules_vW-2004.12/ copy the Hercules code: hercules_vW-2004.12_SYS.tar.gz hercules_vW-2004.12_common.tar hercules_Examples-2004.12.tar.gz

where SYS refers to the platform (or platforms) to be used for your installation. For example, if you will be running on the SUN.64 platform, download the file, hercules_vW-2004.12_SUN.64.tar. Note: A contrib directory included with this release provides useful scripts for analyzing Hercules performance. The contrib directory is at the top level of the release install directory. See the README file for basic instructions. These scripts are not supported. Enterprise is the layout editor used in Hercules tutorials and trainings. An Enterprise (view-only) license is part of your Hercules package.

Extracting the Zipped File

Once the tar file is present in your target directory, follow the steps below to extract the installation directory and execute the installation script.

Untar File
At the UNIX prompt, enter:
tar xvf your_path/hercules_vW-2004.12_SYS.tar tar xvf your_path/hercules_vW-2004.12-common.tar

Install Files in Proper Directory and Execute

The Hercules product is installed using the Synopsys Common Installer. You can find an INSTALL_README.txt file on the product CD describing the common installer in more detail or README.1ST file in your_path directory where above tarfile is extracted.

Installation and Setup Ensuring Your Environment Accommodates Hercules

Get the Manuals and Release Notes

Go to your_path/doc to get the manuals and release notes. You will see four directories: html, mif, ps, and pdf. You need to use only one format for the documentation; use the HTML version where available.

Get the Tutorial

The file needed for the tutorial is located in your_path. You should see the file hercules_Examples-2004.12.tar.gz At the UNIX prompt, enter:
gzip -dc your_path/hercules_Examples-2004.12.tar.gz | tar -xvf -

Ensuring Your Environment Accommodates Hercules

Follow the steps below to ensure your environment accommodates Hercules.

Edit Your .cshrc or .profile Files

If you want Hercules and the tutorial to be active in every UNIX shell you create, edit your .cshrc or .profile file to source the hercules_setup.csh (or hercules_setup.sh) configuration file. In your .cshrc file, enter:
source /your_path/setup/hercules_setup.csh

Or, in your .kshrc or .profile file, enter:

. /your_path/setup/hercules_setup.sh

Note: As mentioned earlier, the setup files create the HERCULES_HOME_DIR environment variables, which are set to the target directory you created for your software installation, your_path. Or, rather than edit your .cshrc or .profile files, you can add the applicable environment variables that are defined in the hercules_setup.csh file directly to your .cshrc, .kshrc, or .profile configuration files.

Installation and Setup Licensing Hercules

Initialize Your Configuration Files

Initialize your configuration files by sourcing them. This allows the software to recognize the new Synopsys paths. If you are in the UNIX C-shell (csh), enter:
source .cshrc rehash

Or, if you are in the UNIX Korn-shell (ksh), enter:

. .kshrc

Authorize the Synopsys Products

To license or authorize the Synopsys products, contact Synopsys licensing through the following channels: Click the SolvNet tab. Choose Software and Installation > SmartKeys. Go to http://www.synopsys.com/contactus.html

Licensing Hercules
Synopsys uses the FLEXlm software for licensing. The FLEXlm documentation is located in the /your_path/doc/ps/flexlm or /your_path/html/flexuser/ directory. Print out the postscript file or bring up the HTML file in your browser for complete instructions on licensing. You must start FLEXlm with a valid Synopsys license file to be able to continue with the Hercules tutorials.

Getting Hercules to Run: Setup

You should already have an installation of Hercules on your system before you begin this setup. If not, be sure to load the software, using the instructions provided above. After the Hercules installation, you set up your workstation account, directories, and files.

Installation and Setup How to Set Up Your Account

If you have already set up a Hercules account on your network, go to your home directory. You may already have several files in the account. To keep your design files separate, create a new project directory for each example. Note: When you install Hercules, you automatically install Drac2He, the runset translator. You execute the translator from your UNIX command line using your Dracula DRC, LVS, or ERC rule file as an argument.

How to Set Up Your Account

With the installation package, all the Hercules files needed for the tutorials are found in the following paths to the directories: your_path/tutorial/Getting_Started_Hercules_DRC/addertest1/ your_path/tutorial/Getting_Started_Hercules_DRC/addertest2/ your_path/tutorial/Getting_Started_Hercules_DRC/addertest3/ your_path/tutorial/Getting_Started_Drac2he_DRC/migration1/ your_path/tutorial/Getting_Started_Drac2he_DRC/migration2/ your_path/tutorial/Getting_Started_Drac2he_DRC/migration3/ your_path/tutorial/Getting_Started_Hercules_LVS/dac96lvs1/ your_path/tutorial/Getting_Started_Hercules_LVS/dac96lvs2/ your_path/tutorial/Getting_Started_Hercules_LVS/dac96lvs3/ your_path/tutorial/Getting_Started_Hercules_LVS/dac96lvs4/ your_path/tutorial/Getting_Started_Drac2he_LVS/migration_lvs/ your_path/tutorial/Getting_Started_Runset_Debugger/debugger/ your_path/tutorial/Getting_Started_Runset_Debugger/Virtuoso/

Whats Next?
If you have completed all the steps in this chapter, you are now ready to get started with Hercules. Before you begin Chapter 2, An Error-Free Design for DRC, we suggest that you read Document Outline and Learning Schedule sections in About this Tutorial for a general idea of the tutorials in this manual and how they apply to your design environment.

2
An Error-Free Design for DRC2
In this chapter we start with a very basic, error-free Design Rule Check (DRC) example to introduce you to Hercules and the files created. The example is a building block designed to help you understand the more complex examples that follow. You learn about the contents of runset files, how to process runsets, how to read the output, and how hierarchy processing works.

Learning Objectives for This Chapter

The first DRC orientation example does not contain any errors, but has the following objectives: To learn the major components of a simple, yet complete, runset file To run Hercules on an error-free design and examine file output, in order to establish a reference for clean design files. This step also verifies that your Hercules software installation and licensing are correct To learn to analyze hierarchical design structure and the tree files created by Hercules To examine briefly other Hercules output files

An Error-Free Design for DRC Learning Objectives for This Chapter

Before You Start

Before you start this tutorial, make sure that you have FULLY COMPLETED the installation and setup procedures described in Chapter 1, Installation and Setup.

Learning Method: the Design Example

To learn Hercules, you use a four-bit full adder as the example design. This relatively straightforward circuit is an arithmetic building block that can be used inside a CPU or some other computational function. The adder is built hierarchically, making it well-suited to take advantage of Hercules checking capabilities. As we go through the tutorial, we introduce more information about hierarchical design and the adder in relevant sections. The design is configured so that you can use independent runsets on variations of the full adder. Each variation is in its own directory, to avoid any possible confusion. Since your design copy is in your own account, you are free to experiment with the files. Examine the graphical files not specifically covered in this tutorial and make changes to see what effect they have on the error polygons created. In fact, since this tutorial cannot possibly cover every aspect of the design or the design structures, we encourage you at several points along the way to explore on your own. Independent experimentation reinforces the learning experience.

Layout Editors in This Tutorial

During your Hercules installation, you also should have installed the Synopsys layout editor, Enterprise. As mentioned earlier, all Hercules users who have a Hercules-Explorer license also have an Enterprise view-only license. We use Enterprise as the layout editor in most of our examples.The exceptions include those chapters where Dracula translation is involved. In these cases, directions are given for running Virtuoso. There is also a separate example of viewing error structures with Enterprise in Appendix A, Using Enterprise With Hercules-Explorer.

An Error-Free Design for DRC Overview of the Runset File

Overview of the Runset File

Runset files are ASCII (text) files containing instructions for determining where Hercules gets its files and how it runs. Each runset file has sections with variables and commands defining the functions Hercules performs. The following sections provide explanations of each part of the runset file and its variables and commands.

The Runset File Format

Files with the .ev extension are runset files in this tutorial. Example 1 shows our first runset example, adderdrc1.ev. We go over each line so that you understand the basics of runset file creation.

Example of a Runset File

Study the example of an actual runset file and note the various sections, descriptions of which appear to the right of the series of dashs (----). The keywords for a section appear in the far left margin, followed by a space and an open brace ({). In the sample runset in Example 1, the keywords for each section (listed below) are emphasized to make it easier for you to see them. Runset Header information Runset options Preprocessing options Layer assignments SNAP command GRID checks DRC checks

After Example 1, there is a general discussion of each of these sections, followed by details of the settings. Note that the setting types include: Information Options Commands

An Error-Free Design for DRC Overview of the Runset File

Assignments Checks

Example 1 adderdrc1.ev Runset File

/* HDRC EXAMPLE RUNSET */ /* --------------------------------- Runset Header information */ HEADER { LAYOUT_PATH = ./ INLIB = EX_ADDER_1 BLOCK = AD4FUL OUTLIB = EX_ADDER_1 OUTPUT_BLOCK = TOP_ERR GROUP_DIR = ./run_details/group FORMAT = MILKYWAY } /* ---------------------------------- Runset options */ OPTIONS { WIDTH = 2 } /* --------------------------------- Data Preprocessing options */ PREPROCESS_OPTIONS { CHECK_PATH_90 = false } /* ---------------------------------- Layer assignments */ ASSIGN { tox (1) poly (5) well (31) psel (14) cont (6) met1 (8) text (110) met2 (10) via (19) } /* --------------------------------- SNAP Command */ SNAP { assign_layers = 0.010 } temp = snap_out

10

An Error-Free Design for DRC Runset Header Information

/* ---------------------------------- GRID checks */ GRID_CHECK { assign_layers = true check_45 = true } (100) /* ---------------------------------- DRC checks */ EXTERNAL met1 {SPACING<3.0} (101)

Runset Header Information

The Runset Header information section is defined by the keyword HEADER, found in the left margin of the file. The HEADER section contains variables that define where Hercules can find the layout libraries and other input files. The HEADER section also contains information about where to write intermediate processing files and output files. HEADER information variables that are not shown are set to their default values. Many of these variables are used with other programs in the Synopsys suite of tools; please refer to the Hercules Reference Manual for a complete list.

LAYOUT_PATH
This variable tells Hercules where to find the Milkyway database on your system. If you are reading a GDSII input file, which we do later in the tutorial, this variable is not used. The path you set must match the database path you set for your Milkyway libraries during the installation process. Your libraries should be in the directories your_path/tutorial/Getting_Started_Hercules_DRC/ addertest*. (We use the asterisk [*] as a wildcard to represent multiple files.) Since you will actually execute your Hercules jobs from the same directory in which the libraries are located, the LAYOUT_PATH is set to ./ (the current directory). This line is optional, because you can also set the LAYOUT_PATH environment variable to point to the libraries (this would be set to your_path/ tutorial/Getting_Started_Hercules_DRC/addertest1/ for our first example).

INLIB
The INLIB variable tells Hercules the name of the input library you want to check. EX_ADDER_1 is our first tutorial example library. If you use GDSIIformatted data, the INLIB line needs to specify a complete path and GDSII file

11

An Error-Free Design for DRC Runset Header Information

name, such as your_path/tutorial/Getting_Started_Hercules_DRC/addertest1/ EX_ADDER_1.GDS.

BLOCK
BLOCK tells Hercules the name of the top-level input structure you wish to verify. Our four-bit adder block is named AD4FUL, and we have placed the design in the tutorial library, EX_ADDER_1.

OUTLIB
The OUTLIB setting tells Hercules the name of the output library, which contains all the permanent output layers (created by Hercules), error output, and newly-created graphical layers. (Chapter 4, A Complete Design for DRC, explains permanent layers.) In our example the line is redundant, because Hercules defaults to EX_ADDER_1 (the INLIB library) as the output library if it is not declared. Be aware that there are trade-offs to using the same library for input and output files. We illustrate this with an alternate approach for storing output files later on in the tutorial.

OUTPUT_BLOCK
The OUTPUT_BLOCK setting tells Hercules what to call the top-level output structure that holds all of your error hierarchy and permanent output layer placements. You can use this structure as an overlay on your design block to assess quickly the results of your DRC check run. TOP_ERR is the structure name. The setting is optional, with Hercules defaulting to the name EV_OUTPUT if an explicit name is not declared.

GROUP_DIR
The GROUP_DIR setting tells Hercules where to place all the group files it temporarily creates. Group files contain the data on which Hercules works during runset execution. The setting is optional, with Hercules creating a run_details/group/ directory in the path of the current directory as the default. In our example the line is redundant. The directory should be local to the machine executing Hercules.

12

An Error-Free Design for DRC Runset Options

FORMAT
This setting indicates that we are using Milkyway-formatted input data. We could have used GDSII as an alternative. If you want to try using the GDS data as input: 1) Make sure that the EX_ADDER_*.GDS files are in the appropriate addertest directories. 2) Set FORMAT to GDSII. 3) Use the INLIB path for GDSII input (described in INLIB on page 11). You should try this after you have completed your first Hercules run.

Runset Options
The OPTIONS section allows you to specify global assignments for various Hercules processes. Hercules also has a DRC_OPTIONS section. All variables in the DRC_OPTIONS section may also be placed in the OPTIONS section. For example, WIDTH is a DRC_OPTION, and you find it in the OPTIONS section of the Hercules Reference Manual. To simplify our example, we have placed the WIDTH variable under the OPTIONS section. You need to specify an option value only when you wish to override the Hercules default. In our example, we have selected just a few of the many Hercules options you can use. Refer to the Hercules Reference Manual for a complete OPTIONS list.

WIDTH
This option specifies the path width, in microns, to assign to polygons generated by checks that produce lines rather than rectangles (such as those output by the CUT command). In this design, a setting of 2 makes it easier to see the error polygons than the default setting of 0, which is the width of a drawn line. The appropriate width is determined by the design rules used for the layout, where small geometry layouts require smaller path widths.

Preprocessing Options
The PREPROCESS_OPTIONS section allows you to specify the output of information and the setting of path grid checking options. You can set options

13

An Error-Free Design for DRC Layer Assignments

for increased information in the block.LAYOUT_ERRORS file and the tree files. You can also set options for path grid checking, which is done when the layers are read during the ASSIGN section. The remainder of the grid checking is done during the GRID_CHECK command, which is discussed later in this tutorial.

CHECK_PATH_90
Setting this option to FALSE allows you to have 45-degree path data in your design. If you look at our design in a layout editor, you will notice that we have 45-degree POLY paths. As a result, you must set CHECK_PATH_90 to FALSE to avoid false errors. Although we do not explicitly write the CHECK_PATH_45 option in our runset, it is set to TRUE by default. Therefore, we are checking to make sure these 45-degree paths are on grid.

Layer Assignments
The ASSIGN section assigns names to the database layers found in the design. Our design uses eight polygon layers and one text layer. All input polygon and text layers must be named and defined in this section before they can be used in the remainder of the runset. In our example, there is a one-toone correlation between a layer name and a layer number.

SNAP Command
The SNAP command section forces data to conform to a grid resolution during a run. That resolution is the number following ASSIGN_LAYERS. If a SNAP command is not issued, Hercules automatically creates one using ASSIGN_LAYERS and the RESOLUTION command, which defaults to the database resolution. In this example, we have chosen to define explicitly the SNAP command and its input (temp=snap_out; see Chapter 4, A Complete Design for DRC, for an explanation of temporary files).

ASSIGN_LAYERS
We have set the SNAP command variable, ASSIGN_LAYERS=0.010, causing all of the input layers to be snapped to a resolution of 0.010. The AREF and SREF origins are not snapped. Refer to INSTANCE_RESOLUTION in the

14

An Error-Free Design for DRC GRID Checks

Hercules Reference Manual for snapping of this data. Text is typically not snapped unless the snapping of a polygon causes the text over that polygon to move outside the boundary of the polygon. In such a case, the text is shifted so that it is inside the polygons boundary, but no effort is made to place the relocated text on a grid point.

GRID Checks
The GRID_CHECK command performs grid checking after group file creation and must appear in the runset after the ASSIGN section. We have included two options for this section.

ASSIGN_LAYERS
Setting ASSIGN_LAYERS to TRUE verifies that all layers in the ASSIGN section are grid checked to the database default. The grid check functions that are performed on the ASSIGN layers depend on the rest of the options list. A layer in the ASSIGN section may be grid checked differently from the rest of the ASSIGN layers by assigning that layer a different GRID_CHECK value.

CHECK_45
Setting the CHECK_45 value to TRUE verifies that all layout data is either orthogonal or at 45-degree line angles. This is a requirement for many DRC rule sets. With this option in the file, Hercules performs a line angle check and reports the results.

DRC Checks
For our basic example, we have one command to check a DRC violation, EXTERNAL.

EXTERNAL
The EXTERNAL check is a spacing check between adjacent metal1 polygons that reside on the same layer (Figure 1). The rule creates an error polygon for any metal1 polygons that are spaced less than 3 m apart. Specifying a number in parentheses, for example, (101), at the end of the statement results

15

An Error-Free Design for DRC Running Hercules

in any error vectors or polygons appearing in the error hierarchy for the design output layer 101. The error hierarchy contains all the errors for the entire design. (This concept is demonstrated more thoroughly later in the tutorial.) In addition, data output that is created from design rule statements can be sent to database locations other than the error hierarchy. We explore this in detail when we show examples of statements that create data other than errors. The diagram in Figure 1 illustrates our runset design rule. Figure 1 EXTERNAL Check - 3-m Spacing Rule
metal1 Spacing must be at least 3 m between metal1 objects metal1

Running Hercules
Now that we have explained the contents of the runset file, you need to run Hercules on the adderdrc1.ev runset in order to evaluate AD4FUL in the EX_ADDER library as a check against the design example.

How to Run Hercules

Be sure that you are in the directory where your adderdrc1.ev file is located, your_path/tutorial/Getting_Started_Hercules_DRC/addertest1. Enter: hercules adderdrc1.ev Your active window displays the execution process. While the screen contents may scroll quickly (freeze the screen with Control-s and restart with Control-q), you should be able to note any specific actions or warnings that appear. All of this information appears in the AD4FUL.sum file (see AD4FUL.sum on page 20) for your examination. The sample runset file should take only a few seconds to run.

16

An Error-Free Design for DRC Running Hercules

Run File Results

Now that you have run the adderdrc1.ev file, look in the addertest1 directory to see which files Hercules has added. You will find some files that always appear, and others that appear depending on the statements in your runset file. Enter the command: ls -R at the your_path/tutorial/Getting_Started_Hercules_DRC/addertest1 command line to get a directory listing similar to Example 2 (some directories and files are omitted for clarity). Example 2 Directory Listing After Running Hercules
AD4FUL.LAYOUT_ERRORS EX_ADDER_1 adderdrc1.ev run_details AD4FUL.RESULTS EX_ADDER_1.GDS hercules.log.month_date_hrs_mins ./run_details: AD4FUL.sum AD4FUL.tree0 AD4FUL.tech AD4FUL.tree1

AD4FUL.tree3 AD4FUL.vcell

evaccess group

./run_details/evaccess: AD4FUL AD4FUL.errbin AD4FUL.errstr

AD4FUL.ev

AD4FUL.msg

VA.libs

What if My Output Is Not Correct?

If your directory does not match the one described, here is a list of possible problems and solutions. Problem: Licensing error appears in your hercules.RESULTS file. Solution: Refer to the FLEXlm documentation in the your_path/doc/ps/flexlm or your_path/html/flexuser directories for instructions on verifying that your license daemon is activated correctly. -------------------------------------------------------------------Problem: License daemon is activated incorrectly. Solution: Check your license file to make sure you have an active Hercules DRC license in your Synopsys license. -------------------------------------------------------------------Problem: You get the error message:

17

An Error-Free Design for DRC Explanation of Error and Summary Files

Fatal error #109: Initialization of MILKYWAY input library EX_ADDER_1 failed. Aborting Hercules. Solution: Refer to Creating Directories and Getting the Files on page 2 in Chapter 1. -------------------------------------------------------------------Problem: You get a message saying you do not have permission to write. Solution: Check your licensing rights. -------------------------------------------------------------------Problem: You get a message saying that the disk is full. Solution: Hercules requires 180 MB of disk space. Check your disk space to make sure there is room. If you have a problem that is not listed here, please contact Synopsys support.

Explanation of Error and Summary Files

Now we take a closer look at the Hercules output files. The block.RESULTS and block.LAYOUT_ERRORS files are written to the directory where Hercules run is executed. If your run was aborted before reading the name of the top block and an error is generated, you see the hercules.RESULTS file.

AD4FUL.RESULTS
The AD4FUL.RESULTS file, shown in Example 3, is a high level summary file of the Hercules run. It includes the: version of Hercules path to the executable that was run summary of the class of checks (for example, DRC or LVS) overall runtime for your entire Hercules job path of your Hercules executable in the log file at this time accesses the latest software you installed correct checks were made runtimes were within acceptable limits

Be sure to verify that the

18

An Error-Free Design for DRC Explanation of Error and Summary Files

Example 3 AD4FUL.RESULTS File

Hercules (R) Hierarchical Design Verification, Release ... DATA OMITTED ... RELEASE VERSION OMITTED Synopsys. All rights reserved. Called as: hercules adderdrc1.ev

- Parsing runset "adderdrc1.ev" ... DONE - Checking input conditions ... DONE - Performing DRC checks and/or device extraction ... DONE No layout errors

Hercules Run: Time= Hercules is done.

0:00:14 User=11.42 System=0.43

If the Hercules run results in an error, the block.RESULTS file prints ERROR instead of DONE next to the module where an error was generated and it refers you to a file to get more details on this error.

AD4FUL.LAYOUT_ERRORS
The DRC/ERC/EXTRACT checks on the design block generate this error file. In the example, we specified AD4FUL in the HEADER section of the adderdrc1.ev runset file. There are no errors, so the file contents are minimal and contain only some repeated runset information: Example 4 AD4FUL.LAYOUT_ERRORS File (No Errors)
LAYOUT ERRORS RESULTS: CLEAN #### # # # # # # # #### ##### ##### ## # # # # # ## # #### ###### # # # # # # # ## ##### # # # #

====================================================================== Library name: EX_ADDER_1

19

An Error-Free Design for DRC Explanation of Error and Summary Files

Structure name:

AD4FUL ERROR SUMMARY

ERROR DETAILS

Additional files generated during the Hercules run are stored in the run_details directory. These files include the detailed run summary files, all of the hierarchy related files, and log files. You should first examine the files mentioned above. The following sections contain more information on some of files found under run_details directory.

AD4FUL.sum
The AD4FUL.sum summary file also gets its name from the block (AD4FUL) specified. The summary file contains information about the steps Hercules executed and the resources used in each step. It repeats much of the information that appeared in the runset file, with the addition of a full list of options in the various runset sections, complete with user and default settings. Example 5 shows the summary file AD4FUL.sum, which you should have in your directory after your Hercules run is completed. Various parts of the summary file are explained in the following sections, with notes throughout the file. Notice that many sections and options appear that were not in your original runset file. These are default settings provided for your information. At the end of the file we find the most important information: that no errors were found during the check (shown in emphasized type at the end of the file). Example 5 AD4FUL.sum File (No Errors)
Hercules (R) Hierarchical Design Verification, Release DATA OMITTED Synopsys, Inc. All rights reserved.

The information here shows the source of Hercules, followed by the command you typed (hercules adderdrc1.ev) to process the runset. Called as: hercules adderdrc1.ev The following line shows the version of EV_Engine used to run the DRC checking. All polygon processing is done with EV_Engine. The naming convention for each release of this executable is as follows: year.quarter.compile#. If there is a patch release the naming convention changes to: year.quarter.patch#.compile#

20

An Error-Free Design for DRC Explanation of Error and Summary Files

EV_Engine (R) Hierarchical Design Rule Checker, Release DATA OMITTED Synopsys, Inc. All rights reserved. Running Single-Threaded code The following information shows the names of the input and output files, as well as the sources and destinations of each. Runset file ...................... adderdrc1.ev Current Directory ................ /remote/wwas1/hercules/venu/ HERCULES_DOC/tutorial/Getting_Started_Hercules_DRC/addertest1 Hostname ......................... ddthp40 Platform type .................... HP64_U11 MILKYWAY input library path ...... /remote/wwas1/hercules/venu/ HERCULES_DOC/tutorial/Getting_Started_Hercules_DRC/addertest1 MILKYWAY input file name ......... EX_ADDER_1 MILKYWAY block name .............. AD4FUL MILKYWAY output library path ..... /remote/wwas1/hercules/venu/ HERCULES_DOC/tutorial/Getting_Started_Hercules_DRC/addertest1 MILKYWAY output file name ........ AD4FUL MILKYWAY output_block name ....... TOP_ERR Run details ...................... /remote/wwas1/hercules/venu/ HERCULES_DOC/tutorial/Getting_Started_Hercules_DRC/addertest1/ run_details Group file directory ............. /remote/wwas1/hercules/venu/ HERCULES_DOC/tutorial/Getting_Started_Hercules_DRC/addertest1/ run_details/group Retain group files ............... smart Check reference structures ....... yes The OPTIONS section lists the settings you used to analyze and display data, including the default settings your runset did not alter. OPTIONS { ALL_TEXT_GLOBAL=FALSE ASCII_ONLY=FALSE ATTACH_TEXT=FALSE BOX_CORNER=FALSE CHECK_REF_LIB=TRUE COUNT_TRAPS=FALSE ERR_LIMIT_PER_CHECK = UNLIMITED ERR_PREFIX = ERR EXPLODE_AREFS=FALSE EXPLODE_HOLDING_CELL_LIMIT=0

21

An Error-Free Design for DRC Explanation of Error and Summary Files

EXPLODE_LIMIT=0 FLAG_ALL_AREF_ERRORS=FALSE FLAT_COUNT=FALSE FLAT_ERROR=FALSE GENERATE_INSTANCE_NAME=TRUE HIERARCHICAL_DELIMITER = \ IGNORE_CASE=FALSE INCREMENTAL_CELLS=FALSE INCREMENTAL_CELLS_FILE = INSTANCE_PREFIX = NET_PREFIX = SELECT_CELL_TO_NO_EXPLODE=TRUE EQUIV_TO_NO_EXPLODE=TRUE SCHEMATIC_TO_NO_EXPLODE=TRUE BLACK_BOX_TO_NO_EXPLODE=TRUE PROTOTYPE_PLACEMENTS=FALSE NO_MERGE=FALSE GENERATE_INSTANCE_NAME=TRUE PRINT_ERRSUM_FILE=TRUE MAXIMUM_CELLNAME_LENGTH=32 SIZE_ENDPOINTS=FALSE SNAP_RES=TRUE SQUARE_CORNER=FALSE STOP_ON_GROUP_ERROR=TRUE TEXT_RECT=0.000 USE_EXPLODED_TEXT=FALSE EXPLORER_DATA=FALSE WIDTH=2.000 MAGNIFICATION_FACTOR=1.000 OUTPUT_MAGNIFICATION_FACTOR=1.000 POLYGON_COUNT_IN_ASSIGN = FALSE FLAT_POLYGON_COUNT = FALSE } The PREPROCESS_OPTIONS allow you to specify 1) the printing of information about Hercules' efficiency at processing the design hierarchy; and 2) the setting of options for path grid checking. This section lists all available options. PREPROCESS_OPTIONS { CELL_PROFILE = FALSE CELL_PROFILE_CNT=20 CHECK_PATH_ENDPOINTS = TRUE CHECK_PATH_45 = TRUE CHECK_PATH_90 = FALSE

22

An Error-Free Design for DRC Explanation of Error and Summary Files

DESIGN_STATS = TRUE TREE = TRUE CELL_STATS = TRUE PRINT_PREPROCESS_FILES = TRUE } Because we did not change any of the TECHNOLOGY_OPTIONS in our runset, they are all default hierarchy optimization options. TECHNOLOGY_OPTIONS { VIA_AUTO_EXPLODE = TRUE SUBLEAF_AUTO_EXPLODE = 6 ALLOW_EXPLODE_WITH_TEXT = TRUE POST_VCELL_EXPLODE_CELL_SIZE <= 10 EXPLODE_CELL_SIZE_PERCENT = 70 CELL_SIZE_AUTO_EXPLODE <= 10 EXPLODE_AREFS = FALSE EXPLODE_1XN_AREFS = FALSE EXPLODE_DATA_CELL_LIMIT = 4 POST_VCELL_EXPLODE_DATA_CELL_LIMIT = 12 EXPLODE_CELL_SIZE_PERCENT_OF_TOP = 70 EXPLODE_BIG_SPARSE_CELL = TRUE EXPLODE_HOLDING_CELL_LIMIT = 1 EXPLODE_PLACEMENT_LIMIT = 1 POST_VCELL_EXPLODE_HIER_SPARSE_CELL = TRUE } EVACCESS_OPTIONS are used for viewing errors with EXPLORER. EVACCESS_OPTIONS { PATH = /remote/wwas1/hercules/venu/HERCULES_DOC/tutorial/ Getting_Started_Hercules_DRC/addertest1/run_details/evaccess LIBRARY = AD4FUL CREATE_MSG_VIEW = TRUE CREATE_NETLIST_VIEW = TRUE CREATE_XREF_VIEW = TRUE CREATE_GRAF_VIEW = TRUE } ASSIGN { tox (1) poly (5) well (31) psel (14) cont (6) met1 (8) text(110) met2 (10)

23

An Error-Free Design for DRC Explanation of Error and Summary Files

via

(19)}

DATATYPE_OFFSET=FALSE. There will be no datatype difference between FRAM and CEL views. Using existing technology table! Input Library Format: 127 char cellnames Output Library Format: No output library Preprocessing group files... Warning #190: Adding default TECHNOLOGY_OPTIONS. AD4FUL.tech file to see what options were used.

You can look in the

NOTE: If no options are specified, Hercules uses the default values for the TECHNOLOGY options, as explained above. For each command executed, Hercules reports actual time, user (CPU) time, system time (I/O and other non-CPU events) and memory usage in megabytes (MB). This example uses runset explode and flatten default options from the TECHNOLOGY_OPTIONS section. Later in "Design Structure" on page 29 we will examine the concept of explode and look at the tree1 file for what is exploded. Preprocess Step 1 : Exploding Preprocessing time = 0:00:00

User=0.13 Sys=0.00 Mem=17.982

VCELL_PASS statements are on by default. They manipulate the hierarchy for optimal Hercules processing. TECHNOLOGY_OPTIONS { VCELL_PASS { STYLE = PAIRS ITERATE_MAX = 15 ARRAY_ID = TRUE EXPLODE_INTO_VCELL = SMART MIN_COUNT = 20 TOP_PERCENT_OF_VALUE = 40 } } Preprocess Step 2 : Vcell_pass Arrays and Pairs Iteration 1 Pairs time = 0:00:00 User=0.01 Sys=0.00 Mem=6.951 VCELL_PASS 1, no changes. Combined VCELL time = 0:00:00 User=0.01 Sys=0.01 Mem=6.951

24

An Error-Free Design for DRC Explanation of Error and Summary Files

Preprocess Step 3 : Post-VCell Explodes Post VCell time = 0:00:00 User=0.00 Sys=0.00 Mem=6.873 Performing grid check for path end points... 0 grid violations found. 0 non-45 violations found. Grid Check time = 0:00:00 User=0.00 Sys=0.00 Mem=6.858

The following section creates layer-specific information that is stored in the group directory. Hercules reads this information when processing commands. Creating group files... Create time = 0:00:00

User=0.01 Sys=0.01 Mem=7.497

Sorting group files... Sort time = 0:00:00 User=0.01 Sys=0.01 Mem=7.528 Checking database: SNAP { ASSIGN_LAYERS = 0.010 tox {0.010000}TEMP=tox poly {0.010000}TEMP=poly well {0.010000}TEMP=well psel {0.010000}TEMP=psel cont {0.010000}TEMP=cont met1 {0.010000}TEMP=met1 met2 {0.010000}TEMP=met2 via {0.010000}TEMP=via }TEMP=snap_out No output written. Layer "snap_out" is empty. 1 polygon snapped. Check time = 0:00:00 User=0.01 Sys=0.01 Mem=6.380 GRID_CHECK { ASSIGN_LAYERS=TRUE tox={ CHECK_45=TRUE } poly={ CHECK_45=TRUE } well={ CHECK_45=TRUE } psel={ CHECK_45=TRUE }

25

An Error-Free Design for DRC Explanation of Error and Summary Files

cont={ CHECK_45=TRUE } met1={ CHECK_45=TRUE } met2={ CHECK_45=TRUE } via={ CHECK_45=TRUE } }(100) The number of violations appears here after commands that perform checks. In this case, the GRID_CHECK command and EXTERNAL met1 (testing for a spacing of less than 3 um) yielded no violations. 0 non-45 violations found. No output written. Check time = 0:00:00 smart smart smart smart smart smart smart delete delete delete delete delete delete delete of of of of of of of "via" "met2" "cont" "psel" "well" "poly" "tox" User=0.01 Sys=0.00 Mem=6.302

EXTERNAL met1{ SPACING<3.000 } (101) 0 spacing violations found. Check time = 0:00:00 User=0.01 Sys=0.00 Mem=8.208 smart delete of "met1" Checks complete. The "Total check time" shows the total time and the maximum memory used for completing the checks. Total check time = 0:00:00 User=0.03 Sys=0.01 Mem=8.208

Here is the total time and the maximum memory used for the run (checks, plus preprocessing): Overall ev_engine time = 0:00:12 User=11.44 Sys=0.18 Mem=17.982

Because we did not find any errors in our example, there is no need to look at any graphical output. Hercules does not create any graphical output files for a runset file which produces no errors.

26

An Error-Free Design for DRC Design Structure

Design Structure
So far, we have been discussing individual cells and individual output files. At this point we explain hierarchy so you will better understand the concept of hierarchical output. As noted previously, our test design is a four-bit, full adder, arithmetic building block. The adder is built hierarchically, meaning that cells or blocks are placed inside other cells, thus creating design levels. One significant output is the tree file, that analyzes the design hierarchies, or levels. When examining tree files, you can appreciate the difference between true hierarchical design, and inefficient hierarchical designs. Now we discuss the concept of hierarchical design in order to interpret the tree files.

Hierarchical Design
A hierarchical design has nested cells; a cell contains one or more instances of another cell, which may contain one or more instances of still another cell, and so forth. The top-level structure holds all other structures and represents the overview of the entire design. Any structure at the top level is called Level 0. Any structure nested within the Level 0 structure, but one level down, is called a Level 1 structure. Nested within the Level 1 structure may be other structures, and these are at Level 2. Level 2 may contain Level 3 structures, and so forth. In essence, you develop a tree of structures, with each structure containing other structures. In Figure 2, numbers in parentheses indicate the number of placements, or instances, of a cell in the structure above it. Cell A contains four Cs, as well as three Bs, each of which contain five Ds and four Es. Cell E contains two Cs.

27

An Error-Free Design for DRC Design Structure

Figure 2 Vertical Hierarchy A Level 0

B (3)

C (4)

Level 1

D (5)

E (4)

Level 2

C (2)

Level 3

Note that there are four HIERARCHICAL levels (Level 0 to Level 3) of nested cells. There are five unique cells, A to E. To find the number of HIERARCHICAL cell placements, add all the placements of a cell at all levels. For example, C is 4+2=6. In other words, there are four C cells at Level 1 and two at Level 3. If you wanted to find the TOTAL or FLAT number of C cells, you would 1) multiply the number of C cells found within the holding cell; and 2) add all the instances of this situation. For example, C = two C cells multiplied by four E holding cells, multiplied by three B holding cells, plus four C cells held directly under A, making a total of 28 C cells. That is, (2 x 4 x 3) + 4 = 28.

Horizontal Design
In a horizontal design, you repeat uses of a cell below each level; that is, there is very little nesting. Therefore, only a few levels of hierarchy exist. In Figure 3 there are 30 instances of Cell D directly under A at Level 0. Again, the numbers in parentheses refer to the number of times the cell appears in the structure immediately above.

28

An Error-Free Design for DRC Design Structure

Figure 3 Horizontal Hierarchy A Level 0

B (20)

C (40)

D (30)

E (25)

Level 1

In Figure 3, very little nesting is present, with multiple instances of a cell being directly under Level 0. The more horizontal a hierarchy, the closer the number of hierarchical placements is to the number of flat placements. In contrast, the more vertical a hierarchy, the smaller the number of hierarchical placements are in comparison to flat placements. Notice that if the hierarchical design in Figure 2 were flattened out, the 28 C cells would be directly under A.

Efficient Versus Inefficient Hierarchy

For Hercules, the definition of hierarchy implies a repetition of design structures. A hierarchical tool must check the actual polygon data in each cell, as well as the cell-to-cell interactions. To see performance gains through hierarchical processing, cells of a significant size must be repeated. If all cells are unique, so that the number of unique cells equals the number of flat placements, then the design is not really hierarchical, even if it is built using 15 nested levels. Hercules must check all of the polygons in each of the unique cells. Also, if all of the cells placed consist of only a few polygons, then the tool spends as much time checking cell-to-cell interactions as it does checking the actual polygons. This is considered inefficient hierarchy, and, as you will see in the following sections, Hercules generally explodes for better processing. A word about explosion is in order here, since the concept appears throughout generated text files. Explode means moving all the polygons to the next level of the hierarchy. The cell holding polygons at a certain level is eliminated, and its polygons move to the next level up, as Figure 4 shows.

29

An Error-Free Design for DRC Explanation of Output Tree Files

Figure 4 Exploding a Cell - Cell B

Cell A Cell B Cell C

Cell A

Cell C

After exploding cell B

Explanation of Output Tree Files

In light of the discussion above, we examine the AD4FUL tree files in this section.

Hierarchy Tree Files

Figure 5 shows a graphical equivalent of the information in the run_details/ AD4FUL.tree0 file. The figure contains an extraordinary amount of information, much more than you ever need when analyzing error output. It indicates that the design has five levels of hierarchy, which are chosen by the designer before or during the time the layout is created. It identifies each type of structure in the design, indicating in parentheses how many occurrences of each structure are in AD4FUL. For our tutorial, such a detailed diagram helps you to understand thoroughly all the information Hercules creates. Compare the style of Figure 5 to that of Figure 2, and note the similarities of hierarchical structures. For example, there are four ADFULAH cells in AD4FUL, and two INVH cells in each ADFULAH cell.

30

An Error-Free Design for DRC Explanation of Output Tree Files

Figure 5 AD4FUL Hierarchy Tree

LEVEL 0

AD4FUL

(20)

(4)

LEVEL 1

VIA

ADFULAH

(31)

(3)

(8)

(6)

(2)

LEVEL 2

VIA

DGATE

POLYHD

INV

INVH

(2)

(3)

(2)

(8)

(13)

LEVEL 3

VIA

POLYHD

TGATE

CONT

CONT

(6)

LEVEL 4

CONT

Assume you have an error in the INV cell. Locate INV in Figure 5 at Level 2 in the diagram. The adder uses 24 instances of the INV cell in the design (six INV cells in ADFULAH, and four ADFULAH cells in AD4FUL). But notice that there is really only one structure that contains an error, and this error is repeated in 24 different places on the layout. Hercules checks the design hierarchically, determines that the INV cell has an error, and reports a single error in its output files.

AD4FUL.tree0
The tree0 file lists information about the original hierarchy of the design, such as cell names, and where structures appear in the hierarchy. Detailed placement information is shown for the AD4FUL structure in Example 6; the tree file includes the placement information for all the structures in the design. Only a portion of this file is shown here.

31

An Error-Free Design for DRC Explanation of Output Tree Files

Example 6 Partial AD4FUL.tree0 File

*** AD4FUL PRE_TREE DESIGN STATISTICS DEFINITIONS Hierarchical levels Number of levels in the design. Unique Cells Number of unique cells in the design. Hierarchical placements Total number of placements (srefs and arefs) at each level in the design. Total Design placements Total number of placements (srefs and arefs) in the design. Exploded references Total number of exploded references in the design. Exploded placements Total number of exploded placements in the design. Total Data count Total number of all polygons, paths, vectors, and rectangles in the design. Sref Placements Total number of cell references in the design. Arefs Total number of array references in the design. Aref Placements Total number of references in each array reference in the design. Data Number of data primitives in each cell of the design. Text Number of text primitives in each cell of the design. ********************************************************************** DESIGN STATISTICS FOR "AD4FUL". Compare the number of levels, unique cells, and placements with the layout styles in Figure 7, Figure 9, and Figure 10. Hierarchical levels Unique cells Hierarchical placements Total design placements Exploded references Exploded placements Total rect count Total poly count Total path count = = = = = = = = = 5 9 109 749 0 0 1709 148 204

32

An Error-Free Design for DRC Explanation of Output Tree Files

Total vect count Total data count SREF placements AREFS AREF placements DATA TEXT

= = = = = = =

0 2061 749 0 0 120 2

********************************************************************** HIERARCHICAL TREE FOR BLOCK "AD4FUL". TOTAL 1 4 3 3 2 6 2 6 8 2 13 8 31 20 SREF AREF 1 0 4 0 3 0 3 0 2 0 6 0 2 0 6 0 8 0 2 0 13 0 8 0 31 0 20 0

AD4FUL ADFULAH DGATE POLYHD TGATE CONT VIA INV CONT INVH CONT POLYHD VIA VIA

Level=0 Level=1 Level=2 Level=3 Level=3 Level=4 Level=3 Level=2 Level=3 Level=2 Level=3 Level=2 Level=2 Level=1

Count= Count= Count= Count= Count= Count= Count= Count= Count= Count= Count= Count= Count= Count=

********************************************************************** CELL STATISTICS Notice that you can compare the number of hierarchical placements to the number of flat placements for each cell. For example, AD4FUL has the same number of flat and hierarchical placements, 1. VIA has 53 hierarchical placements and 168 flat placements. CELL = AD4FUL Cell Status = USED MILKYWAY Library = /remote/wwas1/hercules/venu/ HERCULES_DOC/tutorial/Getting_Started_Hercules_DRC/addertest1 MILKYWAY Cell Extents (LL,UR) = (0.000, 0.000) (394.000, 348.000) Cell Area = 137112.00 Hierarchical Placements = 1 Flat Placements = 1

33

An Error-Free Design for DRC Explanation of Output Tree Files

SREFS = 24 AREFS = 0 AREF placements = 0 Exploded references = 0 Exploded placements = 0 DATA = 29 TEXT = 0 Via = 0 Layer Usage of Original Cell: Name Data/Text Layer:Dtype Layer Extents (LL,UR) Lyr Area VIEW ---- -------- ----------- -------------------------- ---met1 20/0 8:0 (0.00, 18.50) (394.00, 337.50) 1458.50 met2 9/0 10:0 (0.50, 0.00) (372.00, 348.00) 3348.00

Ver.Obj -----CEL 1 CEL 1

For the VIA cell, there are 53 hierarchical placements and 163 flat placements, but the cell only has 3 polygons. You will notice in later tree files that the VIA cell is AUTO_EXPLODED. Because of the large number of placements versus the small polygon count, it is considered inefficient hierarchy CELL = VIA Cell Status = USED MILKYWAY Library = /remote/wwas1/hercules/venu/ HERCULES_DOC/tutorial/Getting_Started_Hercules_DRC/addertest1 MILKYWAY Cell Extents (LL,UR) = (0.000, 0.000) (4.000, 4.000) Cell Area = 16.00 Hierarchical Placements = 53 Flat Placements = 168 SREFS = 0 AREFS = 0 AREF placements = 0 Exploded references = 0 Exploded placements = 0 DATA = 3 TEXT = 0 Via = 1 Layer Usage of Original Cell: Name Data/Text Layer:Dtype Layer Extents (LL,UR) Lyr Area VIEW Ver.Obj ---- -------- ----------- -------------------------- ---- -----met1 1/0 8:0 (0.50, 0.50) (3.50, 3.50) 9.00 CEL 1 met2 1/0 10:0 (0.00, 0.00) (4.00, 4.00) 16.00 CEL 1 via 1/0 19:0 (1.00, 1.00) (3.00, 3.00) 4.00 CEL 1 .................... DATA OMITTED ....................

34

An Error-Free Design for DRC Explanation of Output Tree Files

Notice the complete summary of all the polygon and text data found in each cell. If you want to verify that you have read in the correct polygon layer or text layer, you can check this file to make sure that the number of elements matches the number you think are in your design.

ADFUL.tree1
A partial ADFUL.tree1 file in Example 7 describes the structures after explicit explode and flatten operations; see the explode and flatten options in the TECHNOLOGY_OPTIONS section. Since all of the hierarchy changes are made during the tree1 phase, Hercules automatically determines that it would be more advantageous to process this resulting hierarchy than the original hierarchy it was given. The 1 after tree represents the number of preprocess steps that Hercules has performed on your design. In Example 7, we show the salient aspects of the tree1 file. (Sections that are the same as the tree0 file have been omitted.) Pay particular attention to emphasized items and compare the text closely with Figure 5. Example 7 Partial tree1 File
*** AD4FUL POST_TREE DESIGN STATISTICS DEFINITIONS Compare the following to the tree0 file DESIGN STATISTICS FOR "AD4FUL". Hierarchical levels Unique cells Hierarchical placements Total design placements Exploded references Exploded placements Total rect count Total poly count Total path count Total vect count Total data count SREF placements AREFS AREF placements DATA = = = = = = = = = = = = = = = 4 6 18 73 8 91 1709 148 204 0 2061 73 0 0 332

35

An Error-Free Design for DRC Explanation of Output Tree Files

TEXT

= 2

********************************************************************** HIERARCHICAL TREE FOR BLOCK "AD4FUL". TOTAL SREF AREF AD4FUL Level=0 Count= 1 1 0 ADFULAH Level=1 Count= 4 4 0 DGATE Level=2 Count= 3 3 0 TGATE Level=3 Count= 2 2 0 INV Level=2 Count= 6 6 0 INVH Level=2 Count= 2 2 0 ********************************************************************** CELL STATISTICS CELL = AD4FUL Hierarchical Placements Flat Placements SREFS AREFS AREF placements Exploded references Exploded placements DATA TEXT Via Current Data Counts for Cell: Name Data Text --------- ----met1 40 0 met2 29 0 via 20 0 CELL = ADFULAH Hierarchical Placements Flat Placements SREFS AREFS AREF placements Exploded references Exploded placements DATA TEXT Via Current Data Counts for Cell:

= = = = = = = = = =

1 1 4 0 0 1 20 89 0 0

= = = = = = = = = =

4 4 11 0 0 2 39 156 0 0

36

An Error-Free Design for DRC Explanation of Output Tree Files

Name ----poly cont met1 met2 via

Data ----12 8 59 46 31

Text ----0 0 0 0 0

CELL = INV Hierarchical Placements Flat Placements SREFS AREFS AREF placements Exploded references Exploded placements DATA TEXT Via Current Data Counts for Cell: Name Data Text --------- ----tox 2 0 poly 3 0 well 1 0 psel 2 0 cont 8 0 met1 3 0 CELL = DGATE Hierarchical Placements Flat Placements SREFS AREFS AREF placements Exploded references Exploded placements DATA TEXT Via Current Data Counts for Cell: Name Data Text --------- ----poly 7 0 cont 3 0

= = = = = = = = = =

6 24 0 0 0 1 8 19 0 0

= = = = = = = = = =

3 12 2 0 0 2 5 23 0 0

37

An Error-Free Design for DRC Explanation of Output Tree Files

met1 met2 via

8 3 2

0 0 0

CELL = INVH Hierarchical Placements Flat Placements SREFS AREFS AREF placements Exploded references Exploded placements DATA TEXT Via Current Data Counts for Cell: Name Data Text --------- ----tox 2 0 poly 7 0 well 1 0 psel 3 0 cont 13 0 met1 3 0 CELL = TGATE Hierarchical Placements Flat Placements SREFS AREFS AREF placements Exploded references Exploded placements DATA TEXT Via Current Data Counts for Cell: Name Data Text --------- ----tox 2 0 poly 2 0 well 1 0 psel 1 0 cont 6 0 met1 4 2

= = = = = = = = = =

2 8 0 0 0 1 13 29 0 0

= = = = = = = = = =

2 24 0 0 0 1 6 16 2 0

38

An Error-Free Design for DRC Explanation of Output Tree Files

CELL = VIA Hierarchical Placements Flat Placements SREFS AREFS AREF placements Exploded references Exploded placements DATA TEXT Via Current Data Counts for Cell: Name Data Text --------- ----met1 1 0 met2 1 0 via 1 0 CELL = POLYHD Hierarchical Placements Flat Placements SREFS AREFS AREF placements Exploded references Exploded placements DATA TEXT Via Current Data Counts for Cell: Name Data Text --------- ----poly 1 0 cont 1 0 met1 1 0 CELL = CONT Hierarchical Placements Flat Placements SREFS AREFS AREF placements Exploded references Exploded placements

= = = = = = = = = =

0 0 0 0 0 0 0 3 0 1

= = = = = = = = = =

0 0 0 0 0 0 0 3 0 1

= = = = = = =

0 0 0 0 0 0 0

39

An Error-Free Design for DRC Explanation of Output Tree Files

DATA TEXT Via Current Data Counts for Cell: Name Data Text --------- ----cont 1 0 .................... DATA OMITTED

= 1 = 0 = 1

....................

AD4FUL.tree3
The tree3 file lists information about the hierarchy of the design after Hercules has internally optimized the way it processes the hierarchy. Here, as indicated by 3 after tree, Hercules has performed three preprocess steps on your design. For very large designs the number is higher. Hercules does not print out all of these files, but instead prints the first two, tree0 and tree1, and then the final statistics in the last file, which is tree3 in this example. You notice that there are usually fewer levels of hierarchy in the tree3 file than there were in the tree0 file. However, in our example, the tree1 file and tree3 file show the same hierarchy. Hercules automatically runs five preprocessing passes on all designs to optimize hierarchy, but, in the case of this design, Hercules found the hierarchy to be optimal after the first step of preprocessing. For a more detailed explanation of hierarchy processing and how you can control it, refer to the TECHNOLOGY_OPTIONS section in the Hercules Reference Manual. Only a portion of this file is shown in Example 8. Example 8 Partial AD4FUL.tree3 File
*** AD4FUL AFTER removing temp no_explodes & post-vcell processing DESIGN STATISTICS DEFINITIONS Hierarchical levels Number of levels in the design. Unique Cells Number of unique cells in the design. Hierarchical placements Total number of placements (srefs and arefs) at each level in the design. Total Design placements Total number of placements (srefs and arefs) in the design. Exploded references Total number of exploded references in the design. Exploded placements Total number of exploded placements in the design.

40

An Error-Free Design for DRC Explanation of Output Tree Files

Total Data count Sref Placements Arefs Aref Placements Data Text

Total number of all polygons, paths, vectors, and rectangles in the design. Total number of cell references in the design. Total number of array references in the design. Total number of references in each array reference in the design. Number of data primitives in each cell of the design. Number of text primitives in each cell of the design.

********************************************************************** DESIGN STATISTICS FOR "AD4FUL". Compare the following levels to the tree0 file: Hierarchical levels Unique cells Hierarchical placements Total design placements Exploded references Exploded placements Total rect count Total poly count Total path count Total vect count Total data count SREF placements AREFS AREF placements DATA = = = = = = = = = = = = = = = 4 6 18 73 7 71 1709 148 204 0 2061 73 0 0 332

Notice that the DATA count stays the same as it was in the tree0 file. TEXT = 2

********************************************************************* HIERARCHICAL TREE FOR BLOCK "AD4FUL". TOTAL SREF AREF Count= 1 1 0 Count= 4 4 0

AD4FUL ADFULAH

Level=0 Level=1

41

An Error-Free Design for DRC Explanation of Output Tree Files

DGATE TGATE INV INVH

Level=2 Level=3 Level=2 Level=2

Count= Count= Count= Count=

3 2 6 2

3 2 6 2

0 0 0 0

********************************************************************** CELL STATISTICS CELL = AD4FUL Cell Status = USED MILKYWAY Library = /remote/wwas1/hercules/venu/ HERCULES_DOC/tutorial/Getting_Started_Hercules_DRC/addertest1 MILKYWAY Cell Extents (LL,UR)= (0.000, 0.000) (394.000, 348.000) Cell Area = 137112.00 Hierarchical Placements = 1 Flat Placements = 1 SREFS = 4 AREFS = 0 AREF placements = 0 Exploded references = 0 Exploded placements = 0 DATA = 89 TEXT = 0 Via = 0 Current Data Counts for Cell: Name Data Text --------- ----met1 40 0 met2 29 0 via 20 0 CELL = ADFULAH Cell Status = USED MILKYWAY Library = /remote/wwas1/hercules/venu/ HERCULES_DOC/tutorial/Getting_Started_Hercules_DRC/addertest1 MILKYWAY Cell Extents (LL,UR)= (0.000, -18.500) (376.000, 70.500) Cell Area = 33464.00 Hierarchical Placements = 4 Flat Placements = 4 SREFS = 11 AREFS = 0 AREF placements = 0 Exploded references = 2 Exploded placements = 39

42

An Error-Free Design for DRC Miscellaneous Output Files

DATA = 156 TEXT = 0 Via = 0 Current Data Counts for Cell: Name Data Text --------- ----poly 12 0 cont 8 0 met1 59 0 met2 46 0 via 31 0 .................... DATA OMITTED .................... CELL = VIA Cell Status = AUTO_EXPLODED (DATA_CELL_LIMIT CELL) MILKYWAY Library = /remote/wwas1/hercules/venu/ HERCULES_DOC/tutorial/Getting_Started_Hercules_DRC/addertest1 MILKYWAY Cell Extents (LL,UR)= (0.000, 0.000) (4.000, 4.000) Cell Area = 16.00 Hierarchical Placements = 0 Flat Placements = 0 SREFS = 0 AREFS = 0 AREF placements = 0 Exploded references = 0 Exploded placements = 0 DATA = 3 TEXT = 0 Via = 1 Current Data Counts for Cell: Name Data Text --------- ----met1 1 0 met2 1 0 via 1 0 .................... DATA OMITTED ....................

Miscellaneous Output Files

The following sections explain the other output files in the run_details directory.

43

An Error-Free Design for DRC Miscellaneous Output Files

AD4FUL.tech and AD4FUL.vcell

As we mentioned earlier, Hercules automatically analyzes the input hierarchy of your design to determine the best hierarchy and to generate optimal Hercules results. The AD4FUL.tech and AD4FUL.vcell files are summaries of the hierarchy processing that Hercules performed on your design. For details of the options referred to in these files, refer to the TECHNOLOGY_OPTIONS section in the Hercules Reference Manual.

evaccess/
An evaccess/ directory is created for EVACCESS database files and referenced by Hercules-Explorer (discussed later in this tutorial) and other programs in the Synopsys suite of tools. Several layers of directories are created; however, only the main evaccess directory is shown. The only file of general interest to the user is AD4FUL.ev.

evaccess/AD4FUL.ev
Examine the AD4FUL.ev file, shown in Example 9, noting all explicit assignments of variables (such as HEADER variables) and runset programming options. For example, if, in the adder1drc.ev runset, you use an environment variable in an IF/ELSE statement, the AD4FUL.ev file includes only the commands that are executed based on the value of the runset environment variable. Example 9 AD4FUL.ev File
HEADER { INLIB = EX_ADDER_1 INLIB_PATH = ./ /* For Synopsys internal use only! */ OUTLIB = EX_ADDER_1 OUTLIB_PATH = ./ /* For Synopsys internal use only! */ BLOCK = AD4FUL GROUP_DIR = /remote/wwas1/hercules/venu/HERCULES_DOC/tutorial/ Getting_Started_Hercules_DRC/addertest1 FORMAT = MILKYWAY OUTPUT_FORMAT = MILKYWAY LAYOUT_PATH = /remote/wwas1/hercules/venu/HERCULES_DOC/tutorial/ Getting_Started_Hercules_DRC/addertest1 OUTPUT_BLOCK = TOP_ERR COMPARE_DIR = /remote/wwas1/hercules/venu/HERCULES_DOC/tutorial/

44

An Error-Free Design for DRC Miscellaneous Output Files

Getting_Started_Hercules_DRC/addertest1/run_details/compare RUN_DETAILS_DIR = /remote/wwas1/hercules/venu/HERCULES_DOC/ tutorial/Getting_Started_Hercules_DRC/addertest1/run_details } TECHNOLOGY_OPTIONS { EXPLODE_AREFS = FALSE EXPLODE_CELL_SIZE_PERCENT = 70 EXPLODE_CELL_SIZE_PERCENT_OF_TOP = 70 EXPLODE_BIG_SPARSE_CELL = TRUE POST_VCELL_EXPLODE_CELL_SIZE <= 10 VIA_AUTO_EXPLODE = TRUE SUBLEAF_AUTO_EXPLODE = 6 CELL_SIZE_AUTO_EXPLODE <= 10 EXPLODE_DATA_CELL_LIMIT = 4 POST_VCELL_EXPLODE_DATA_CELL_LIMIT = 12 POST_VCELL_EXPLODE_HIER_SPARSE_CELL = TRUE EXPLODE_HOLDING_CELL_LIMIT = 1 EXPLODE_PLACEMENT_LIMIT = 1 VCELL_PASS { STYLE = PAIRS ITERATE_MAX = 15 ARRAY_ID = TRUE EXPLODE_INTO_VCELL = SMART MIN_COUNT = 20 TOP_PERCENT_OF_VALUE = 40 } } EVACCESS_OPTIONS { PATH = /remote/wwas1/hercules/venu/HERCULES_DOC/tutorial/ Getting_Started_Hercules_DRC/addertest1/run_details/compare LIBRARY = AD4FUL CREATE_MSG_VIEW = TRUE CREATE_NETLIST_VIEW = TRUE CREATE_XREF_VIEW = TRUE CREATE_GRAF_VIEW = TRUE CREATE_RUNSET_VIEW = TRUE } OPTIONS { WIDTH = 2.000 } PREPROCESS_OPTIONS { CHECK_PATH_90 = FALSE } ASSIGN {

45

An Error-Free Design for DRC Miscellaneous Output Files

tox (1) poly (5) well (31) psel (14) cont (6) met1 (8) text(110) met2 (10) via (19)} SNAP { ASSIGN_LAYERS=0.010 tox {0.010000}TEMP=tox poly {0.010000}TEMP=poly well {0.010000}TEMP=well psel {0.010000}TEMP=psel cont {0.010000}TEMP=cont met1 {0.010000}TEMP=met1 met2 {0.010000}TEMP=met2 via {0.010000}TEMP=via }TEMP=snap_out GRID_CHECK { ASSIGN_LAYERS=TRUE tox={ CHECK_45=TRUE } poly={ CHECK_45=TRUE } well={ CHECK_45=TRUE } psel={ CHECK_45=TRUE } cont={ CHECK_45=TRUE } met1={ CHECK_45=TRUE } met2={ CHECK_45=TRUE } via={ CHECK_45=TRUE } }(100) EXTERNAL met1 { SPACING<3.000 } (101)

Essentially, the AD4FUL.ev file is exactly what Hercules is executing while it is running. The AD4FUL.ev file, created during the Hercules run, is very similar to the original adderdrc1.ev runset file. Comments are removed. The AD4FUL.ev also includes EVACCESS_OPTIONS and TECHNOLOGY_OPTIONS sections with default assignments. Because these defaults are all acceptable for our tutorial, we do not include these sections in our runset.

46

An Error-Free Design for DRC Whats Next?

Whats Next?
Thus far you have compared runsets and examined output files to learn about the information they contain. In Chapter 3, Single Design Error for DRC, we examine a design with one error and introduce you to the different output formats for viewing this error, including Hercules-Explorer, a graphical debug tool. All users should proceed to Chapter 3.

47

An Error-Free Design for DRC Whats Next?

48

3
Single Design Error for DRC3
In this chapter we introduce a DRC error into the design of an inverter (INV) in a full adder (ADDER). We study the differences between the error-free Hercules run from Chapter 2, An Error-Free Design for DRC, and the run with errors in this chapter. We also view the graphical output files in Enterprise, the Synopsys layout tool provided with HerculesExplorer for viewing errors.

Summary of Progress to This Point

In our first example you became familiar with Hercules and the files created during a run. You also learned the major components of a simple, yet complete, runset file. Finally, you ran Hercules DRC on an error-free design to examine output files and establish a reference for clean design files. In this step you also verified that your Hercules software installation and licensing were correct.

Learning Objectives for This Chapter

For the single rule error example, a design that contains a single DRC rule violation, do the following:

49

Single Design Error for DRC Running Hercules on the Runset File

Run Hercules on the adder design with an error introduced, and then learn how to interpret the output files to locate errors. Examine the graphic output for the Hercules run in Enterprise. This output illustrates how hierarchical checking works and helps you to spot and understand design errors.

Before You Start

Your account should already be set up for this example. If it is not, refer to Chapter 1, Installation and Setup. Otherwise, you will not be able to do this tutorial.

Running Hercules on the Runset File

Be sure that you are in the directory where your adderdrc2.ev file is located, your_path/tutorial/Getting_Started_Hercules_DRC/addertest2. Notice that the adderdrc2.ev runset file is identical to the adderdrc1.ev file, with two exceptions. Two lines in the file are different from adderdrc1.ev: INLIB = EX_ADDER_2 OUTLIB = EX_ADDER_2

The runset file is now referring to our second sample library, EX_ADDER_2, for the input and output libraries. Example 10 Header Section of adderdrc2.ev
/* HDRC SAMPLE RUNSET */ /* --------------------------------- Runset Header information */ HEADER { LAYOUT_PATH = ./ INLIB = EX_ADDER_2 BLOCK = AD4FUL OUTLIB= EX_ADDER_2 OUTPUT_BLOCK= TOP_ERR GROUP_DIR = group FORMAT = MILKYWAY }

50

Single Design Error for DRC Output Results

Hercules now processes the runset file to perform a check on the block AD4FUL in the EX_ADDER_2 library. The block contains a single error. Have Hercules process the runset file, adderdrc2.ev. Enter: hercules adderdrc2.ev As before, your active window displays the execution process.

Output Results
Running Hercules on the runset file adderdrc2.ev creates the AD4FUL.LAYOUT_ERRORS file in the current directory, with a known error that violates the EXTERNAL spacing check. Notice that the directory structure has not changed. However, the files created by Hercules now contain different information (shown emphasized in Example 11).

AD4FUL.LAYOUT_ERRORS
Example 11 AD4FUL.LAYOUT_ERRORS File (with Errors)
LAYOUT ERRORS RESULTS: ERRORS ##### # #### # ##### #### # # #### # # # # #### ### # # # # #### # # # # # # # # ### #### #### # # # #### ### # # # # # ####

====================================================================== Library name: EX_ADDER_2 Structure name: AD4FUL ERROR SUMMARY No Comment EXTERNAL met1 { } (101) ............................ 1 violation found. ERROR DETAILS

#####--- ERR_EXTERNAL ----------------------------------EXTERNAL met1 {

51

Single Design Error for DRC Output Results

SPACING<3.000 WIDTH=2.000 } (101) - - - - Structure - - - - - - - - - - - - - - - - - - - - - - - ( lower left x, y ) ( upper right x, y ) Distance

- - - - - - -- - - - - - - - - - - - - - - - - - - - - - INV (16.500, 5.000) (21.500, 7.000) 2.000

Geometric Representation of Error

The error file shows that an error was generated for the EXTERNAL runset file check, and was written to the AD4FUL.LAYOUT_ERRORS file (Example 11) as error polygon coordinates. An error polygon is a set of coordinates that pinpoints the location and magnitude of the violation. In this case, the coordinate values are measured from the origin (0,0) of the cell, the lower lefthand corner of the whole INV cell. The single-error polygon, represented graphically in Figure 6, describes an error polygon 5 m wide and 2 m high: Figure 6 EXTERNAL Check Error in Cell INV

error polygon

met1 layer

(21.5,7)

2
(16.5,5)

5
met1 layer

The error file tells us that we have only a 2-m spacing between adjacent metal1 objects. The coordinates pinpoint the actual location of the error within

52

Single Design Error for DRC Output Results

the cell INV. Later, we discuss this INV cell with its error as the ERR_INV structure.

AD4FUL.sum
The AD4FUL.sum summary file in the run_details directory provides a quick way to scan through your checks and notice any violations. The summary file looks very similar to the one created for our clean run, except that it warns that an error has been produced. Use your system editor, such as vi (or use the UNIX command more) to view the AD4FUL.sum text file. At the very end of the file you see:
EXTERNAL met1 { SPACING<3.000 } (101) WARNING - 1 spacing violation found. Check time = 0:00:00 User=0.00 Sys=0.02 Mem=8.279

You should locate this error (shown here emphasized) in the AD4FUL.sum file in Example 12. Also, notice at the bottom of the file the emphasized section specifying the time it takes to save the error structure. Because there were no errors in our first example, this line was not in its summary file. Major sections of the AD4FUL.sum file have been omitted from Example 12, because they are identical to those in the AD4FUL.sum for addertest1. Example 12 AD4FUL.sum File (with Errors)
Hercules (R) Hierarchical Design Verification, Release ... DATA OMITTED Synopsys. All rights reserved. Called as: hercules adderdrc2.ev ...RELEASE VERSION OMITTED Synopsys. All rights reserved. Running Single-Threaded code Runset file ...................... adderdrc2.ev Current Directory ................ /remote/wwas1/hercules/venu/ HERCULES_DOC/tutorial/Getting_Started_Hercules_DRC/addertest2 Hostname ......................... ddthp44 Platform type .................... HP64_U11 MILKYWAY input library path ...... /remote/wwas1/hercules/venu/ HERCULES_DOC/tutorial/Getting_Started_Hercules_DRC/addertest2/ MILKYWAY input file name ......... EX_ADDER_2 MILKYWAY block name .............. AD4FUL

53

Single Design Error for DRC Running Enterprise and Viewing Results

MILKYWAY output library path ..... /remote/wwas1/hercules/venu/ HERCULES_DOC/tutorial/Getting_Started_Hercules_DRC/addertest2/ MILKYWAY output file name ........ EX_ADDER_2_OUT MILKYWAY output_block name ....... TOP_ERR Run details ...................... /remote/wwas1/hercules/venu/ HERCULES_DOC/tutorial/Getting_Started_Hercules_DRC/addertest2/ run_details Group file directory ............. /remote/wwas1/hercules/venu/ HERCULES_DOC/tutorial/Getting_Started_Hercules_DRC/addertest2/ group Retain group files ............... smart Check reference structures ....... yes ...........OPTIONS SECTION OMITTED........... EXTERNAL met1 { SPACING<3.000 WIDTH=2.000 } (101) WARNING - 1 spacing violation found. Check time = 0:00:00 User=0.00 Sys=0.02 Mem=8.279 smart delete of "met1" Checks complete. Total check time = 0:00:00

User=0.03 Sys=0.03 Mem=8.279

Overall ev_engine time = 0:00:30 User=25.66 Sys=0.53 Mem=17.982

Running Enterprise and Viewing Results

The following section assumes that you have a copy of Enterprise on your system. Hercules-Explorer, the Synopsys graphical debug tool for Hercules, is packaged with a view-only license for Enterprise to help you view your results easily. The installation instructions for Enterprise are included in your Hercules installation. If you are using Virtuoso from Cadence, refer to Chapter 6, Hercules Migration with Hercules-Explorer, for more details on error viewing. If you are using a different graphical tool, contact Synopsys Technical Support for details on how to import Hercules files into your program. Note: If you are going to use Virtuoso, you should still go through the Enterprise part of this tutorial. No setup is required for the Enterprise editor and it is a quick way to view the results without having to set up Virtuoso. Ultimately, though, you really need to use only one layout editor.

54

Single Design Error for DRC Running Enterprise and Viewing Results

Note: Many of you use Hercules-Explorer, the Synopsys graphical debug tool designed for viewing errors in Hercules. This section of the tutorial is included to make you familiar with the input design hierarchy and the error hierarchy that Hercules generates.

How to run Enterprise

Make sure you are in the your_path/tutorial/Getting_Started_Hercules_DRC/ addertest2 directory. Enter: Enterprise & (The ampersand (&) runs Enterprise as a background process.)

The initial Enterprise Display

You should see the following initial Enterprise display:

55

Single Design Error for DRC Running Enterprise and Viewing Results

Figure 7 Opening Enterprise Display (Windows Not to Scale)

Viewing the EX_ADDER_2 Library File Names

You start by opening a library and its files. In the graphical window, choose Library > Open. (When you select a command, you see it automatically typed in the command window.) You can also invoke the command by placing your cursor in the command window in the lower left corner of the screen and enter: gxwOpenLibrary You see a pop-up window prompting you to enter the library name.

56

Single Design Error for DRC Running Enterprise and Viewing Results

Figure 8

Library > Open

Enter the library name EX_ADDER_2. You can also browse through the directories to select the library. In the graphical window, choose Cell > Open. You can also invoke the command by placing your cursor in the command window in the lower left corner of the screen by entering: gxwOpenCell

57

Single Design Error for DRC Running Enterprise and Viewing Results

Figure 9 EX_ADDER Library Structure Names

You see a pop-up window prompting you to enter the cell name. A list of cells for our design appears on the screen, as shown in Figure 9. Double-click on cell AD4FUL to open the cell.

EX_ADDER Input and Output Files

The next paragraphs explain the input and output files. Following that explanation, we return to Enterprise to view some cells. In our runset, all errors are sent to the error hierarchy. The three files prefixed with ERR are called error hierarchy files because they show the three levels of hierarchy: ERR_AD4FUL, ERR_ADFULAH, and ERR_INV (the cell with the error).

58

Single Design Error for DRC Viewing Data in Enterprise

Note: All error hierarchy files begin with ERR as a default, unless you choose a different prefix and set it in the OPTIONS section of the runset file (ERR_PREFIX option). Locate INV in the hierarchy tree in Figure 5 on page 31 in Chapter 2, An ErrorFree Design for DRC, and notice that the cell occurs in ADFULAH and also in the top level, AD4FUL. Recall from the previous section on design structure that the error occurs in INV (ERR_INV), but Hercules outputs all the structures (ERR_ADFULAH and ERR_AD4FUL) that contain a reference to the cell. These ERR_ files appear only when Hercules finds a design error. TOP_ERR is the holding structure for errors, as defined by OUTPUT_BLOCK in the runset HEADER section, and any other permanent layers that you might create. (Permanent layers are explained in Chapter 4, A Complete Design for DRC.) The TOP_ERR file appears only when Hercules finds a design error. In our layout, you have to fix only the cell INV. Because the design is hierarchical, and because Hercules retains the hierarchy throughout the checking procedure, fixing INV fixes all references to INV throughout the design.

Viewing Data in Enterprise

Now look at the design cell that contains the error, INV:

59

Single Design Error for DRC Viewing Data in Enterprise

Figure 10 INV Cell with Errors

Because you have not looked at the error polygon, you may not be able to spot the area that contains the design rule violation. Also, at this point you are not familiar with the layout, and no dimensioned grid is shown. Open Enterprise in the addertest2 directory by entering the command: Enterprise & Now execute the next series of commands to open the library and reference the output library. This allows you to overlay the dimensional error on your original design. Choose Library > Reference Libraries > Add.

60

Single Design Error for DRC Viewing Data in Enterprise

Figure 11 Add Reference Library

Add the EX_ADDER_2_OUT library as the reference library for the EX_ADDER_2 library as shown in Figure 11. Click OK, which opens the EX_ADDER_2 library and the INV cell. Choose Create > Cell Instance. Figure 12 Create Cell Instance

A Create Cell Instance pop-up window appears, as shown in Figure 12. Click the browse symbol next to the Cell Name field to browse list of cells. Select the EX_ADDER_2_OUT library by choosing the down arrow key of the All Cells option in the Browse Cell window (see Figure 13). Select cell ERR_INV and click Close. This adds the cell name to the Create Cell Instance window.

61

Single Design Error for DRC Viewing Data in Enterprise

Figure 13 Browse Cell

Enter the coordinates (0 0) as shown in Figure 14. Click Apply. This creates a cell instance of the master gate_INV from the reference library EX_ADDER_2_OUT at the coordinates (0, 0). Figure 14 Create Cell Instance

You now have the met1 layer 101 overlaid on your original design. You can reference as many of the other layers as you like.

62

Single Design Error for DRC Viewing Data in Enterprise

Figure 15 Overlay of INV and ERR_INV

With the error polygon overlaid on the INV structure, you see that the metal1 which connects the drains of the N and P channel devices and makes up the inverter is too long. The error polygon in Figure 15 shows that metal1 is only 2 m away from adjacent metal1, instead of the 3 m required by the design rule. If you are the layout person responsible for fixing errors and have a full Enterprise license, the standard methodology at this point is to fix the design error. Enterprise layout edits are beyond the scope of this tutorial; refer to the Enterprise User Guide or the Enterprise Reference Manual. When you make your edits, shorten the metal1 strip by 1 m to allow 3-m spacing between adjacent metal polygons. Otherwise, use your layout editor of choice to correct the error. The corrected INV cell looks like Figure 16.

63

Single Design Error for DRC Layout Topology

Figure 16 Corrected INV Cell

The single error polygon indicates that this is the only error for the design. Fixing metal1 cures the problem in this example. In a real design, of course, you have to make sure that any editing does not affect other design rules on the same or other design layers. Now, to exit the structure: Choose Cell > Save in the graphical window to save the cell.

Layout Topology
For our example, we know that fixing the metal1 error fixes the design. But to see how the INV error manifests itself in the rest of the design, look at the layout topology in Figure 17.

64

Single Design Error for DRC Layout Topology

Figure 17 AD4FUL Layout Topology

DGATE

DGATE

DGATE INV INV

INVH

ADFULAH

ADFULAH

DGATE

DGATE

DGATE

INVH

ADFULAH

ADFULAH

From the hierarchy tree shown in Figure 5 on page 31 in Chapter 2, An ErrorFree Design for DRC, you know that INV is placed six times in the ADFULAH structure, and that ADFULAH is placed four times in the top level structure, AD4FUL. Therefore, you have 24 occurrences of INV, and 24 occurrences of the same design rule error in the design. Figure 18 helps you anticipate where the 24 error polygons are approximately located. Open the AD4FUL structure by selecting Cell > Open in the graphics window. The view of the layout shows the actual polygons, complete with all metal interconnections. While there is too much information to be used effectively in this tutorial, you do see the actual layout from the AD4FUL top level. To get a diagram without labels, in the command window enter: gwxRedraw 1 "g" 0

INVH INV INV

INV

INV

INV

INV

INV

INV

INVH INV

INV

INV

INV

INV

INV

INV

DGATE DGATE

DGATE

DGATE

INVH INVH

INVH INVH

INV INV

INV

INV

DGATE

DGATE

INV

INV

INV

65

Single Design Error for DRC Layout Topology

Figure 18 Actual AD4FUL Layout and Interconnect

Choose Cell > Close in the graphical window to close the cell. Choose Library > Close to close the library. To quit Enterprise, in the command window enter: exit Or, choose Tools > Quit from the command window.

66

Single Design Error for DRC Output Hierarchy Options

Output Hierarchy Options

The check for the INV example, as well as for all the dimensional checks in this document, uses the error hierarchy for output results. Any error polygons produced appear in a file that is prefixed with ERR_ (unless you specify a different prefix for the error hierarchy with the ERR_PREFIX option). You can also write your rule check output to separate hierarchy files in addition to, or instead of, the error hierarchy. For instance, you can specify your design rule in the runset file as:
EXTERNAL met1 {SPACING<3.0} PERM=met1_sp (101)

As indicated by PERM=met1_sp, Hercules output is sent to a permanent set of files prefixed with met1_sp_, with our example producing files named: met1_sp_INV met1_sp_ADFULAH met1_sp_AD4FUL If you had specified the hierarchy with this PERM setting, the polygons would not appear in the error hierarchy cells prefixed by ERR_, but instead in the met1_sp-prefixed cells that are noted above. Also, the text coordinates of the error polygons would not appear in the AD4FUL.LAYOUT_ERRORS file (or in any other file). The graphical output to the TOP_ERR structure and the error message in the AD4FUL.sum file would still appear. Figure 19 shows an example of the hierarchy of the TOP_ERR output block. Figure 19 TOP_ERR Output Block Hierarchy TOP_ERR

ERR_AD4FUL

met_sp_AD4FUL

ERR_ADFULAH

met1_sp_ADFULAH

Another option is to write rule check output to a temporary (TEMP) file. Temporary files are most appropriate when a design rule check creates new information that is temporarily needed for use in another check.

67

Single Design Error for DRC Whats Next?

See Writing Output Results to Files in Chapter 4, A Complete Design for DRC, for more information on how PERM and TEMP files can be used effectively with other types of Hercules runset rules. Note: After each command or check, you may specify a layer number indicating that the output of the command goes to the error hierarchy output at the end of the Hercules run. Or, you can specify a PERM or TEMP file. If you specify TEMP, the polygon data written by the command is stored under the ./group directory as a temporary file that Hercules can read when necessary for other commands. For example, a Boolean command may generate TEMP=foo, and then the data written to the temporary file foo might be used in "BOOLEAN foo AND junk" later in the runset. If you write the data to a PERM file, the data is written to a file under ./group, but it is also written to a graphical file at the end of the Hercules job so you can view the polygon data. Notice that with a slight modification to the design rule the output polygons is written to the AD4FUL.LAYOUT_ERRORS file:
EXTERNAL met1 SPACING<3.0 VERBOSE=TRUE} PERM=met1_sp (101)

Using the VERBOSE option with any command directed to a PERM or TEMP file enables reporting to the block.LAYOUT_ERRORS file (resulting from errors in the file designated by BLOCK in the runset HEADER section).

Whats Next?
After you fix the error, move on to Chapter 4, A Complete Design for DRC, to apply the concepts you have just learned to a more challenging example with a multiple-error design. If you are now using Dracula and trying to transition to Hercules, skip Chapter 4 and go to Chapter 5, Hercules DRC Migration.

68

4
A Complete Design for DRC4
Our final DRC example presents a multiple-error design and builds from the concepts you have learned thus far. The activities in this chapter are comparable to the ones in Chapter 3, Single Design Error for DRC, but here you create and learn how to correct layout errors similar to those encountered in real designs.

Summary of Progress to This Point

In our first two examples, we detailed all the steps required to set up the software to check a simple design for a single runset rule. Although those examples were very basic, the procedures and files created are nearly the same for runsets of any complexity. We go through a more complex example here, and point out any considerations that should be noted for large runset files or complex designs. In all cases, the layouts are checked hierarchically. The properties of a hierarchical design allow even very complex chips to be broken down into small modules that can be easily checked with a hierarchical design rule checker like Hercules HDRC.

69

A Complete Design for DRC A Summary of Design Rule Checks

Learning Objectives for This Chapter

The more realistic runset check example presented in this chapter has a representative sample of checks and procedures that might be encountered in a real design (scaled down to make the Tutorial manageable). With this example you: Learn the types of DRC checks available in Hercules, and create a few to place in the runset file. Run Hercules with the runset file on a design with several errors. Learn how to interpret the errors in the text output files. Examine in Enterprise the derived layers created by the runset file. Create extra layers to perform other types of checks. Examine output files when multiple checks and multiple errors are involved. Run Hercules-Explorer to see how the error detection process can be made easier.

Before You Start

Before you start this section of the tutorial, make sure that you have completely gone through the installation and setup procedure described in Chapter 1, Installation and Setup.

A Summary of Design Rule Checks

Hercules features a wealth of design rule checks that can quickly and efficiently check for any layout spacing, size, relationship, or tolerance. We present a short summary of the types of checks available in this Tutorial, and use some of them as rules for our example. A discussion of all Hercules Data Creation and Dimensional Check operators can be found in the Hercules Reference Manual.

Operations Allowed by Hercules

Hercules DRC rules allow you to perform three types of data operations:

70

A Complete Design for DRC Examining the Runset Rules

Generation of new layers, which can be verified, saved to your database, or dimensionally checked. The new layers can be formed with Boolean operators, SELECT relationships, SIZE operations, hierarchical interactions, and NEGATE commands. Dimensional checks for a single polygon. These include length, width, area, overlap, ratio, and density calculations. Dimensional checks between polygon edges or vertices. These include intersecting polygon spacings, enclosure spacings, and external polygon spacings.

There are variations of these operations that are in a special class of their own. Two such examples include the Hercules extensive corner checking ability and its ability to check device widths and lengths for MOS devices and resistors. For details on further specialized checking and data creation, refer to the Hercules Reference Manual.

Examining the Runset Rules

As previously noted, we cannot describe each and every Hercules rule in this Tutorial. What we can do, however, is provide a representative sampling of the rules you are most likely to encounter in a real design. We thoroughly explain each rule, and then implement each one in our sample runset. We explore the text and graphical file output that results from violation of these rules, and explain how to search for and correct the errors built into our example. By going through this exercise, you gain a good working knowledge of the methodology needed to understand and verify designs. You can then refer to the Hercules Reference Manual for details on the other design rules you encounter or need to implement in your own work. Note: For those of you who are familiar with other physical verification tools, but would like to understand the syntax of Hercules and how to use HerculesExplorer, the debug tool, skip ahead to Running Hercules. This selection of rules is not intended to represent an actual runset that thoroughly checks every polygon rule violation, but rather a reasonable sampling of the more straightforward checks in Hercules. In many cases in an actual runset, several checks might be required to check relationships between polygons on the same or different layers.

71

A Complete Design for DRC Examining the Runset Rules

The description of each rule is specific to the example in our Tutorial. We describe the rule in terms of the actual layers used in the design. In addition, any options that are mentioned are chosen to check specific relationships in the example. Most of the checks described offer other options that are not employed in this design. If you plan to use any of these rules in your design, be sure to read the Hercules Reference Manual for a complete description of all options available for every rule.

Writing Output Results to Files

The results of each of the checks are output to different types of files. Hercules supports three different types of output files: Error hierarchy output Permanent output Temporary output

Error Hierarchy Output

Creating a check with an output layer specified in parentheses, such as,
Check {options} (101)

tells Hercules to send all output from the check to the error hierarchy on the layer specified, in this case, 101. Checks producing error polygons are usually sent to the error hierarchy.

Permanent Output
Permanent means that the layer is written to the PERM hierarchy and can be used later in the runset. Creating a check with an output layer specified in the form
Check {options} PERM=outlayer1 (101)

tells Hercules that a permanent output layer, named outlayer1, is to be created on layer 101. A separate hierarchy of output structures is then created using outlayer1 as the prefix. Specifying a PERM layer also allows you to create a label for the output. This label can be employed within a subsequent check to use the output layer as an input layer for the new check. The PERM layer information is not output to the error file (block.LAYOUT_ERRORS) unless you add VERBOSE = TRUE to the command.

72

A Complete Design for DRC Examining the Runset Rules

Temporary Output
Temporary layers can be used when output created during the check needs to be made available for another check, but does not need to be stored as a permanent result. Temporary files are most often used with Data Creation statements, which we explain in detail in this section. Creating a check with an output layer specified in the form
Check {options} TEMP=outlayer2

tells Hercules that a temporary output layer, named outlayer2, is to be created. Notice that no layer number is specified. The layer created is available only during the run, and deleted when execution is completed. There is a way to view temporary files, even though they are normally deleted after the run. By using the GRAPHICS command, temporary files or permanent layers can be written to a separate output database, with a layer number assigned to the TEMP layer within the GRAPHICS section. For details on the GRAPHICS command, refer to the Hercules Reference Manual.

EXTERNAL Checks
The simple runset of our first two examples has already introduced us to EXTERNAL checks. EXTERNAL checks verify distances between polygons, with the measurement specified for polygons on the same layer or between different layers. When checking spacings, the measurement can be for edge-toedge spacings, corner-to-corner spacings, or corner-to-edge spacings. Spacing checks can also be restricted to polygons that meet specified internal width values. For our sample design, we have selected three specific EXTERNAL checks: metal1 to metal1 spacing metal2 to metal2 spacing - longedge option metal1 to metal2 spacing - touch option

metal1 to metal1 Spacing

EXTERNAL met1{SPACING<3} (101)

This is the familiar check we have already employed. It flags any spacings for metal1 to metal1 distances less than 3 m, and places all error output in the error hierarchy on layer 101.

73

A Complete Design for DRC Examining the Runset Rules

metal2 to metal2 spacing - longedge Option

EXTERNAL met2 {SPACING<3.0 LONGEDGE_TO_EDGE<5.0 LONGEDGE>=50} (102)

The EXTERNAL check syntax allows two separate checks, one for parallel metal2 runs shorter than 50 m, and one for those longer than 50 m. For shorter runs, the command in this form flags metal2 to metal2 spacings less than 3 m. When two parallel metal2 runs maintain a constant spacing for a length of at least 50 m, the command imposes a stricter spacing check of a minimum of 5 m. This type of check is employed in a design when long parallel metal runs need to be farther apart than short runs to meet process specifications.

metal1 to metal2 spacing - touch Option

EXTERNAL met1 met2 {SPACING<1.0 TOUCH} (103)

This check measures spacing between different metal1 and metal2 layers, and also flags any metal1 polygons that touch metal2 polygons. For a two-layer EXTERNAL check (as in our example), a touch is considered either an edge or point touch. For a one-layer EXTERNAL check, only a point touch is flagged. Refer to the drawings in Figure 20.

74

A Complete Design for DRC Examining the Runset Rules

Figure 20 TOUCH Options for EXTERNAL Checks Two-Layer EXTERNAL Touch One-Layer EXTERNAL Touch

INTERNAL Checks
INTERNAL checks measure polygon widths; the check is always for polygons on the same layer. As with EXTERNAL checks, the measurement can be for edge-to-edge spacings, corner-to-corner spacings, or corner-to-edge spacings. For our sample design, we have selected two specific INTERNAL checks: poly width - edge_45 option metal2 width - corner option

poly width - edge_45 Option

INTERNAL poly {SPACING<2.0 EDGE_45<2.5} (104)

This check measures all poly edges and corners against the two-m width value specified. Any poly layer that is thinner than the rule is flagged. The

75

A Complete Design for DRC Examining the Runset Rules

EDGE_45 option applies a 2.5 m width rule to poly segments set at any angle other than 90.

metal2 width - corner Option

INTERNAL met2 {SPACING<4.0 CONVEX_TO_CONVEX<4.5} (105)

This check measures all metal2 edges against the 4-m width value specified. For convex-to-convex corners (as indicated in Figure 21 by the arrows), a different value of 4.5 m is specified. All other corners are checked against the 4.0 m SPACING value. Hercules can check a variety of corner types; refer to the Hercules Reference Manual for a complete discussion. Figure 21 CONVEX-TO-CONVEX Corner Check

CUT Checks
The CUT check selects edges of polygons that intersect by a certain spacing (and, with options, those that TOUCH or are ENCLOSED). For our example, the CUT check provides a way to select a polygon that overlaps portions of another polygon, and must maintain specific distances between polygon edges. We have selected one check.

Cut poly by diffusion - cut_outside Option

CUT poly BY tox {CUT_OUTSIDE<1.5} (106)

This check measures the overlap of poly against diffusion, to be sure that a MOS gate is properly formed. The CUT check itself selects only edges. The

76

A Complete Design for DRC Examining the Runset Rules

edges selected with the rule are the diffusion edges, which are inside the poly edges. To understand this concept, we look at a simple drawing of a gate formed by poly and diffusion (represented by the layer name tox). Figure 22 Illustration of CUT Check
Selected CUT edge

poly

tox

Selected CUT edge

Spacing check

In Figure 22 the heavier, short, horizontal lines are the edges of diffusion, which are inside poly. In other words, poly is cut by diffusion in these two places. The CUT_OUTSIDE option checks that any poly that continues outside the diffusion has an edge parallel to the cut edge, and is outside the cut edge by at least 1.5 m.

AREA Checks
The AREA check is a simple check that checks for a polygon area, flagging areas that are within the range specified. We have selected a single check:

77

A Complete Design for DRC Examining the Runset Rules

Via area - range Option

AREA via {RANGE = [0.0,2.0]} (107)

The check measures areas of via cells, and reports as errors those falling within the specified range of 0 to 2 m.

DATA CREATION / INTERNAL Checks

All the checks we defined previously are dimensional checks. They produce errors based on the spacing values in the runset rules. The dimensional check results are placed in the error hierarchy for the design because we have specified the error hierarchy as the output for each of the runset rules. Data Creation statements can also be included in DRC runsets. These operations either produce data in the form of a polygon shape or manipulate data in some way by moving data to a different hierarchical level. The data can be written to the error hierarchy or to separate TEMP or PERM layers. In our runset we use the Data Creation statements to produce new output polygons written to PERM layers. These layers are then dimensionally checked with INTERNAL checks. Specifically, our example defines MOS gates and then checks those gates for length and width.

BOOLEAN poly AND tox

BOOLEAN poly AND tox PERM=gate (111)

The BOOLEAN operator creates AND, OR, NOT, and XOR relationships between polygons. The PERM statement places the result of the Data Creation operation on a graphical output layer. This step creates a layer from the intersection of poly and tox, which forms a MOS gate structure. A new permanent output layer, gate, is created. (Refer to Figure 23.) Note: Usually the Data Creation output is written to TEMP layers. We are writing them to PERM layers in our example because later in this chapter we demonstrate how to view the layers we create.

78

A Complete Design for DRC Examining the Runset Rules

Figure 23 Identification of Gate

tox

gate

poly

Now look at Figure 24 for how the specific gates pgate and ngate are formed from psel.

BOOLEAN gate AND psel

BOOLEAN gate AND psel PERM=pgate (112)

This Boolean operator looks for all gate polygons inside the psel layer and creates a layer from the intersection of gate and psel. A new output layer, pgate, is formed, as shown in Figure 24. This layer has the same dimensions as any PMOS gate in the design.

BOOLEAN gate NOT pgate

BOOLEAN gate NOT pgate PERM=ngate (113)

This Boolean operator looks for all gate polygons that are not pgate and creates a layer by subtracting the pgate layer from the gate layer. A new output layer, ngate, is formed, also shown in Figure 24. This layer has the same dimensions as any NMOS gate in the design.

79

A Complete Design for DRC Examining the Runset Rules

Figure 24 Identification of pgate and ngate

pgate psel ngate

Internal pgate Dimension Operator

INTERNAL pgate {DIMENSION = [2.0,12.0]} (114)

We have already discussed the INTERNAL check. This particular rule uses the DIMENSION option, which checks polygon widths and lengths against a single or multiple set of values. For our example, the rule checks the pgate layer that was formed by the Boolean operator. The rule states that all pgates must be rectangles of exactly 2 m by 12 m. Any polygons falling outside the check limits are flagged on error layer 114.

Internal ngate dimension Operator

INTERNAL ngate {DIMENSION = [2.0,6.0]} (115)

This check performs a DIMENSION measurement on the ngate layer, with error output on layer 115.

80

A Complete Design for DRC Examining the Runset Rules

DATA CREATION Checks

In this section, we use the Data Creation operators to help perform another taskcreating layers that define metal1 to tox contacts. In the design, two types of contacts are present, metal1 to tox and metal1 to poly (refer to Figure 25). Because the contacts have different process rule requirements, and therefore different geometries, we need to distinguish them. For our example, we separate all the metal1 to tox contacts in the hierarchy toxcont. We then perform spacing checks on those contacts within other polygons with the ENCLOSE statement.

BOOLEAN cont NOT poly

BOOLEAN cont NOT poly PERM=toxcont (121)

This Boolean operator looks for every contact layer that does not have poly underneath. The result is the desired metal1 to tox contact. A permanent output layer, toxcont, is formed that allows you to look at the output, as shown in Figure 25. However, because the output layer is not required for viewing it can be designated a TEMP layer. Figure 25 Metal vs. Poly Contacts

poly contact

metal1 contact (toxcont)

81

A Complete Design for DRC Examining the Runset Rules

ENCLOSE Check
The ENCLOSE Dimensional Check option checks spacings for polygons nested inside other polygons. A spacing measurement determines precisely where one polygon is situated inside another. Both edges and corners can be checked. ENCLOSE checks can also be qualified, based on the characteristics of the polygon. We have two ENCLOSE checks in our runset.

ENCLOSE toxcont by tox

ENCLOSE toxcont BY tox {SPACING<1.5} (122)

This checks our newly formed toxcont layer to ensure that the contact is inside the tox layer by at least 1.5 m.

ENCLOSE toxcont by metal1 - touch, overlap, and parallel Options

ENCLOSE toxcont BY met1 {SPACING<1.0 TOUCH OVERLAP PARALLEL} (123)

This checks our newly formed toxcont layer to ensure that the contact is inside the metal1 layer by at least 1 m. In addition, the TOUCH and OVERLAP options flag any toxcont layers that are not completely surrounded by metal1. The PARALLEL option specifies that only parallel orthogonal edges are checked.

From Rules to Runsets

The preceding sections explain the seven Dimensional Checks and eight Data Creation operations we incorporate in our runset. The runset uses the same HEADER section as in our previous runset files. We have added EXPLORER_DATA = TRUE to the OPTIONS section. This tells Hercules to output the necessary data files needed to use Hercules-Explorer for graphical debug. Finally, the checks we described previously are listed in the runset. One exception in the HEADER section is that a separate output library is created to store error polygons and newly created data. Our next step checks this runset against a new design that contains structures flagged by these rules. Example 13 is a more realistic runset used for checking. Example 13 A More Realistic DRC Runset
/* HDRC SAMPLE RUNSET */

82

A Complete Design for DRC Examining the Runset Rules

/* --------------------------------- Runset Header information */ HEADER { LAYOUT_PATH = ./ INLIB = EX_ADDER_3 BLOCK = AD4FUL OUTLIB= EX_ADDER_3_ref OUTPUT_BLOCK= TOP_ERR GROUP_DIR = group FORMAT = MILKYWAY } /* ---------------------------------- Runset options */ OPTIONS { RETAIN_GROUP = SMART WIDTH = 2 EXPLORER_DATA = TRUE /* added to create the data files for Explorer */ } /* --------------------------------- Data Preprocessing Options */ PREPROCESS_OPTIONS { CHECK_PATH_90 = FALSE } /* ---------------------------------- Layer assignments */ ASSIGN { tox (1) poly (5) well (31) psel (14) cont (6) met1 (8) met2 (10) via (19) } /* ---------------------------------- SNAP Command */ SNAP { ASSIGN_LAYERS = 0.010 } temp = SNAP_OUT

/* ---------------------------------- GRID checks */ GRID_CHECK { ASSIGN_LAYERS = true

83

A Complete Design for DRC Running Hercules

CHECK_45 } (100)

= true

/* ----------------------------------- DRC dimensional checks */ EXTERNAL met1 {SPACING<3.0} (101) EXTERNAL met2 {SPACING<3.0 LONGEDGE_TO_EDGE<5.0 LONGEDGE>=50} (102) EXTERNAL met1 met2 {SPACING<1.0 TOUCH} (103) INTERNAL poly {SPACING<2.0 EDGE_45<2.5} (104) INTERNAL met2 {SPACING<4.0 CONVEX_TO_CONVEX<4.5} (105) CUT poly BY tox {CUT_OUTSIDE<1.5} (106) AREA via {RANGE = [0.0,2.0]} (107) /* ----------------------------------- DRC data creation for gates */ BOOLEAN poly AND tox PERM=gate (111) BOOLEAN gate AND psel PERM=pgate (112) BOOLEAN gate NOT pgate PERM=ngate (113) INTERNAL pgate {DIMENSION = [2.0,12.0]} (114) INTERNAL ngate {DIMENSION = [2.0,6.0]} (115) /* ----------------------------------- DRC data creation for contacts */ BOOLEAN cont NOT poly PERM=toxcont (121) ENCLOSE toxcont by tox {SPACING<1.5} (122) ENCLOSE toxcont BY met1 {SPACING<1.0 TOUCH OVERLAP PARALLEL} (123)

Running Hercules
Be sure that you are in the directory where your adderdrc3.ev file is located; that is, your_path/tutorial/Getting_Started_Hercules_DRC/addertest3. To run Hercules, use the command: hercules adderdrc3.ev As before, your active window displays the execution process.

Output Results
As you can see by the activity during the execution process, our files are much larger and contain more information than in previous examples. We carefully examine the error and sum files, and explain in detail how to correlate the text file results to the graphical files to be reviewed in Enterprise.

84

A Complete Design for DRC Output Results

Error File
The error file, AD4FUL.LAYOUT_ERRORS, has a list of runset rule violations, headed by ERR_. In fact, most of the selected rules trigger at least one error polygon. By understanding how to interpret the results, you can easily scan the file and quickly locate and fix the errors in the graphical database. Example 14 AD4FUL.LAYOUT_ERRORS File for EX_ADDER_3 Library name: EX_ADDER_3
#### ### # # # # #### # # # # # # # # ### #### #### # # # #### ### # # # # # ####

LAYOUT ERRORS RESULTS: ERRORS ##### #### # # # #### #### # # # ##### # #

====================================================================== Library name: EX_ADDER_3 Structure name: AD4FUL

ERROR SUMMARY No Comment EXTERNAL met1 { } (101) ........................... 2 violations found. No Comment EXTERNAL met2 { } (102) ........................... 2 violations found. No Comment EXTERNAL met1 met2 { } (103) ...................... 2 violations found. No Comment INTERNAL poly { } (104) ............................ 1 violation found. No Comment INTERNAL met2 { } (105) ........................... 2 violations found. No Comment CUT poly BY tox { } (106) .......................... 1 violation found. No Comment INTERNAL pgate { } (114) ........................... 1 violation found.

85

A Complete Design for DRC Output Results

No Comment INTERNAL ngate { } (115) ........................... 1 violation found. No Comment ENCLOSE toxcont BY tox { } (122) .................. 4 violations found. No Comment ENCLOSE toxcont BY met1 { } (123) ................. 4 violations found. ERROR DETAILS #####--- ERR_EXTERNAL ----------------------------------EXTERNAL met1 { SPACING<3.000 WIDTH=2.000 } (101) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Structure ( lower left x, y ) ( upper right x, y ) Distance - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - INVH (16.500, 39.000) (21.500, 41.000) 2.000 ADFULAH (207.500, 64.000) (238.000, 66.000) 2.000 #####--- ERR_EXTERNAL ----------------------------------EXTERNAL met2 { SPACING<3.000 LONGEDGE>=50.000 LONGEDGE_TO_EDGE<5.000 WIDTH=2.000 } (102) - - - - - - - - - - - - - - - - - - Structure ( lower left x, y ) - - - - - - - - - - - - - - - - - - ADFULAH (103.500, 17.000) AD4FUL (4.500, 60.000) - - - - - - - - - - - - - - - - ( upper right x, y ) Distance - - - - - - - - - - - - - - - - (104.000, 58.500) 0.500 (8.500, 278.000) 4.000

#####--- ERR_EXTERNAL ----------------------------------EXTERNAL met1 met2 { SPACING<1.000 WIDTH=2.000 TOUCH=TRUE } (103)

86

A Complete Design for DRC Output Results

- - - - - - - - - - - - - - - - - - Structure ( lower left x, y ) - - - - - - - - - - - - - - - - - - DGATE (28.500, 8.000) DGATE (28.500, 23.000)

- - - - - - - - - - - - - - - - ( upper right x, y ) Distance - - - - - - - - - - - - - - - - (28.500, 18.000) 0.000 (28.500, 38.000) 0.000

#####--- ERR_INTERNAL ----------------------------------INTERNAL poly { SPACING<2.000 EDGE_45<2.500 WIDTH=2.000 } (104) - - - - - - - - - - - - - - - - - - Structure ( lower left x, y ) - - - - - - - - - - - - - - - - - - DGATE (21.090, 16.090) - - - - - - - - - - - - - - - - ( upper right x, y ) Distance - - - - - - - - - - - - - - - - (28.910, 23.910) 1.994

#####--- ERR_INTERNAL ----------------------------------INTERNAL met2 { SPACING<4.000 CONVEX_TO_CONVEX<4.500 WIDTH=2.000 } (105) - - - - - - - - - - - - - - - - - - Structure ( lower left x, y ) - - - - - - - - - - - - - - - - - - ADFULAH (204.000, 53.000) AD4FUL (368.000, 268.000) - - - - - - - - - - - - - - - - ( upper right x, y ) Distance - - - - - - - - - - - - - - - - (207.000, 60.000) 3.000 (371.000, 269.000) 3.162

#####--- ERR_CUT ----------------------------------CUT poly BY tox { SPACING<1.500 CUT_OUTSIDE<1.500 } (106) - - - - - - - - - - - - - - - - - - - - - Structure ( lower left x, y ) - - - - - - - - - - - - - - - - - - - - - INV (11.500, 6.500) - - - - - - - - - - - - - ( upper right x, y ) - - - - - - - - - - - - - (13.500, 7.500)

#####--- ERR_INTERNAL -----------------------------------

87

A Complete Design for DRC Output Results

INTERNAL pgate { WIDTH=2.000 DIMENSIONS = [2.000,12.000] } (114) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Structure ( lower left x, y ) ( upper right x, y ) Distance - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - INVH (24.500, 26.500) (27.000, 38.500) 0.000 #####--- ERR_INTERNAL ----------------------------------INTERNAL ngate { WIDTH=2.000 DIMENSIONS = [2.000,6.000] } (115) - - - - - - - - - - - - - - - - - - Structure ( lower left x, y ) - - - - - - - - - - - - - - - - - - TGATE (11.500, 0.000) - - - - - - - - - - - - - - - - ( upper right x, y ) Distance - - - - - - - - - - - - - - - - (14.000, 6.000) 0.000

#####--- ERR_ENCLOSE ----------------------------------ENCLOSE toxcont BY tox { SPACING<1.500 WIDTH=2.000 } (122) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Structure ( lower left x, y ) ( upper right x, y ) Distance - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - TGATE (21.500, 20.500) (22.000, 23.500) 0.500 TGATE (3.000, 1.000) (4.000, 4.000) 1.000 TGATE (4.000, 0.000) (7.000, 1.000) 1.000 TGATE (3.000, 0.000) (4.000, 1.000) 1.414 #####--- ERR_ENCLOSE ----------------------------------ENCLOSE toxcont BY met1 { SPACING<1.000 WIDTH=2.000 PARALLEL=TRUE TOUCH=TRUE OVERLAP=TRUE } (123) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Structure ( lower left x, y ) ( upper right x, y ) Distance - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

88

A Complete Design for DRC Output Results

INV TGATE TGATE TGATE

(14.500, 9.000) (21.500, 20.500) (3.500, 1.000) (4.000, 0.500)

(16.500, 12.000) (21.500, 23.500) (4.000, 4.000) (7.000, 1.000)

0.000 0.000 0.500 0.500

Summary File
Before we begin to explore these errors, we complete our text file examination by looking at the summary file located in the run_details directory. The .sum file appears to repeat the information in the error file, listing each runset rule and summarizing the number of violations for each. However, the .sum file also provides information on the Data Creation layers, which were created by the additional statements in adderdrc3.ev. Combining the information in the two files gives us a fairly complete picture of our design and tells us what we need to observe when we get into Hercules-Explorer. In Example 15, notice the emphasized sections. Example 15 AD4FUL.sum File for EX_ADDER_3

Hercules (R) Hierarchical Design Verification, Release ... DATA OMITTED Synopsys. All rights reserved. Called as: hercules adderdrc3.ev ... RELEASE VERSION OMITTED Synopsys. All rights reserved. Running Single-Threaded code Runset file ...................... adderdrc3.ev Current Directory ................ /remote/wwas1/hercules/venu/ HERCULES_DOC/tutor/TUTORIAL_LAB/Getting_Started_Hercules_DRC/ addertest3 Hostname ......................... ddthp42 Platform type .................... HP64_U11 MILKYWAY input library path ...... /remote/wwas1/hercules/venu/ HERCULES_DOC/tutor/TUTORIAL_LAB/Getting_Started_Hercules_DRC/ addertest3/ MILKYWAY input file name ......... EX_ADDER_3 MILKYWAY block name .............. AD4FUL MILKYWAY output library path ..... /remote/wwas1/hercules/venu/ HERCULES_DOC/tutor/TUTORIAL_LAB/Getting_Started_Hercules_DRC/ addertest3/ MILKYWAY output file name ........ EX_ADDER_3_ref

89

A Complete Design for DRC Output Results

MILKYWAY output_block name ....... TOP_ERR Run details ...................... /remote/wwas1/hercules/venu/ HERCULES_DOC/tutor/TUTORIAL_LAB/Getting_Started_Hercules_DRC/ addertest3/run_details Group file directory ............. /remote/wwas1/hercules/venu/ HERCULES_DOC/tutor/TUTORIAL_LAB/Getting_Started_Hercules_DRC/ addertest3/group Retain group files ............... smart Check reference structures ....... yes OPTIONS { ALL_TEXT_GLOBAL=FALSE ASCII_ONLY=FALSE ATTACH_TEXT=FALSE BOX_CORNER=FALSE CHECK_REF_LIB=TRUE COUNT_TRAPS=FALSE ERR_LIMIT_PER_CHECK = UNLIMITED ERR_PREFIX = ERR EXPLODE_AREFS=FALSE EXPLODE_HOLDING_CELL_LIMIT=0 EXPLODE_LIMIT=0 FLAG_ALL_AREF_ERRORS=FALSE FLAT_COUNT=FALSE FLAT_ERROR=FALSE GENERATE_INSTANCE_NAME=TRUE HIERARCHICAL_DELIMITER = \ IGNORE_CASE=FALSE INCREMENTAL_CELLS=FALSE INCREMENTAL_CELLS_FILE = INSTANCE_PREFIX = NET_PREFIX = SELECT_CELL_TO_NO_EXPLODE=TRUE EQUIV_TO_NO_EXPLODE=TRUE SCHEMATIC_TO_NO_EXPLODE=TRUE BLACK_BOX_TO_NO_EXPLODE=TRUE PROTOTYPE_PLACEMENTS=FALSE NO_MERGE=FALSE GENERATE_INSTANCE_NAME=TRUE PRINT_ERRSUM_FILE=TRUE MAXIMUM_CELLNAME_LENGTH=32 SIZE_ENDPOINTS=FALSE SNAP_RES=TRUE SQUARE_CORNER=FALSE STOP_ON_GROUP_ERROR=TRUE TEXT_RECT=0.000 USE_EXPLODED_TEXT=FALSE EXPLORER_DATA=TRUE WIDTH=2.000

90

A Complete Design for DRC Output Results

MAGNIFICATION_FACTOR=1.000 OUTPUT_MAGNIFICATION_FACTOR=1.000 POLYGON_COUNT_IN_ASSIGN = FALSE FLAT_POLYGON_COUNT = FALSE } PREPROCESS_OPTIONS { CELL_PROFILE = FALSE CELL_PROFILE_CNT=20 CHECK_PATH_ENDPOINTS = TRUE CHECK_PATH_45 = TRUE CHECK_PATH_90 = FALSE DESIGN_STATS = TRUE TREE = TRUE CELL_STATS = TRUE PRINT_PREPROCESS_FILES = TRUE } TECHNOLOGY_OPTIONS { VIA_AUTO_EXPLODE = TRUE SUBLEAF_AUTO_EXPLODE = 6 ALLOW_EXPLODE_WITH_TEXT = TRUE POST_VCELL_EXPLODE_CELL_SIZE <= 10 EXPLODE_CELL_SIZE_PERCENT = 70 CELL_SIZE_AUTO_EXPLODE <= 10 EXPLODE_AREFS = FALSE EXPLODE_1XN_AREFS = FALSE EXPLODE_DATA_CELL_LIMIT = 4 POST_VCELL_EXPLODE_DATA_CELL_LIMIT = 12 EXPLODE_CELL_SIZE_PERCENT_OF_TOP = 70 EXPLODE_BIG_SPARSE_CELL = TRUE EXPLODE_HOLDING_CELL_LIMIT = 1 EXPLODE_PLACEMENT_LIMIT = 1 POST_VCELL_EXPLODE_HIER_SPARSE_CELL = TRUE } EVACCESS_OPTIONS { PATH = /remote/wwas1/hercules/venu/HERCULES_DOC/tutor/ TUTORIAL_LAB/Getting_Started_Hercules_DRC/addertest3/ run_details/evaccess LIBRARY = AD4FUL CREATE_MSG_VIEW = TRUE CREATE_NETLIST_VIEW = TRUE CREATE_XREF_VIEW = TRUE CREATE_GRAF_VIEW = TRUE } ASSIGN { tox (1) poly (5) well (31) psel (14)

91

A Complete Design for DRC Output Results

cont met1 met2 via

(6) (8) (10) (19)}

DATATYPE_OFFSET=FALSE. There will be no datatype difference between FRAM and CEL views. Input Library Format: 127 char cellnames Output Library Format: No output library Preprocessing group files... Warning #190: Adding default TECHNOLOGY_OPTIONS. You can look in the AD4FUL.tech file to see what options were used. Preprocess Step 1 : Exploding Preprocessing time = 0:00:01 User=0.09 Sys=0.05 Mem=14.459 TECHNOLOGY_OPTIONS { VCELL_PASS { STYLE = PAIRS ITERATE_MAX = 15 ARRAY_ID = TRUE EXPLODE_INTO_VCELL = SMART MIN_COUNT = 20 TOP_PERCENT_OF_VALUE = 40 } } Preprocess Step 2 : Vcell_pass Arrays and Pairs Iteration 1 Pairs time = 0:00:00 User=0.01 Sys=0.00 Mem=6.936 VCELL_PASS 1, no changes. Combined VCELL time = 0:00:00 User=0.01 Sys=0.01 Mem=6.936

Preprocess Step 3 : Post-VCell Explodes Post VCell time = 0:00:00 User=0.00 Sys=0.00 Mem=6.858 Performing grid check for path end points... 0 grid violations found. 0 non-45 violations found. Grid Check time = 0:00:00 User=0.00 Sys=0.00 Mem=6.842 Creating group files... Create time = 0:00:00 User=0.02 Sys=0.02 Mem=7.497

Sorting group files... Sort time = 0:00:01 User=0.01 Sys=0.02 Mem=7.528 Checking database:

92

A Complete Design for DRC Output Results

SNAP { ASSIGN_LAYERS = 0.010 tox {0.010000}TEMP=tox poly {0.010000}TEMP=poly well {0.010000}TEMP=well psel {0.010000}TEMP=psel cont {0.010000}TEMP=cont met1 {0.010000}TEMP=met1 met2 {0.010000}TEMP=met2 via {0.010000}TEMP=via }TEMP=snap_out No output written. Layer "snap_out" is empty. 1 polygon snapped. Check time = 0:00:00 User=0.01 Sys=0.01 Mem=6.380 GRID_CHECK { ASSIGN_LAYERS=TRUE tox={ CHECK_45=TRUE } poly={ CHECK_45=TRUE } well={ CHECK_45=TRUE } psel={ CHECK_45=TRUE } cont={ CHECK_45=TRUE } met1={ CHECK_45=TRUE } met2={ CHECK_45=TRUE } via={ CHECK_45=TRUE } }(100) 0 non-45 violations found. No output written. Check time = 0:00:00 User=0.01 Sys=0.00 Mem=6.302 smart delete of "well" EXTERNAL met1 { SPACING<3.000 } (101) WARNING - 2 spacing violations found. Check time = 0:00:01 User=0.01 Sys=0.04 Mem=8.544 EXTERNAL met2 { SPACING<3.000 LONGEDGE>=50.000 LONGEDGE_TO_EDGE<5.000 } (102) WARNING - 2 spacing violations found. Check time = 0:00:00 User=0.00 Sys=0.00 Mem=8.746 EXTERNAL met1 met2 {

93

A Complete Design for DRC Output Results

SPACING<1.000 TOUCH=TRUE } (103) WARNING - 2 spacing violations found. Check time = 0:00:00 User=0.01 Sys=0.00 Mem=7.653 INTERNAL poly { SPACING<2.000 EDGE_45<2.500 } (104) WARNING - 1 width violation found. Check time = 0:00:00 User=0.01 Sys=0.01 Mem=7.590 INTERNAL met2 { SPACING<4.000 CONVEX_TO_CONVEX<4.500 } (105) WARNING - 2 width violations found. Check time = 0:00:00 User=0.00 Sys=0.00 Mem=8.684 smart delete of "met2" CUT poly BY tox { CUT_OUTSIDE<1.500 } (106) WARNING - 1 cut_outside violation found. Check time = 0:00:00 User=0.01 Sys=0.01 Mem=8.887 AREA via { RANGE = [2.000,2.000]} (107) No output written. Check time = 0:00:00 User=0.00 Sys=0.00 Mem=8.512 smart delete of "via" BOOLEAN poly AND tox { } PERM=gate(111) 8 unique polygons written. Check time = 0:00:00 User=0.00 Sys=0.00 Mem=8.715 BOOLEAN gate AND psel { } PERM=pgate(112) 4 unique polygons written. Check time = 0:00:00 User=0.00 Sys=0.00 Mem=8.762 smart delete of "psel" BOOLEAN gate NOT pgate { } PERM=ngate(113) 4 unique polygons written. Check time = 0:00:00 User=0.01 Sys=0.00 Mem=8.746 INTERNAL pgate { DIMENSIONS = [2.000,12.000] } (114) WARNING - 1 violation found. Check time = 0:00:00 User=0.00 Sys=0.01 Mem=8.575

94

A Complete Design for DRC Output Results

INTERNAL ngate { DIMENSIONS = [2.000,6.000] } (115) WARNING - 1 violation found. Check time = 0:00:00 User=0.00 Sys=0.00 Mem=8.622 BOOLEAN cont NOT poly { } PERM=toxcont(121) 27 unique polygons written. Check time = 0:00:00 User=0.01 Sys=0.00 Mem=8.887 smart delete of "poly" smart delete of "cont" ENCLOSE toxcont BY tox { SPACING<1.500 } (122) WARNING - 4 enclose violations found. Check time = 0:00:00 User=0.00 Sys=0.00 Mem=8.887 smart delete of "tox" ENCLOSE toxcont BY met1 { SPACING<1.000 PARALLEL=TRUE TOUCH=TRUE OVERLAP=TRUE } (123) WARNING - 4 enclose violations found. Check time = 0:00:00 User=0.01 Sys=0.01 Mem=8.887 smart delete of "met1" Checks complete. Total check time = 0:00:01 User=0.10 Sys=0.11 Mem=8.887

Dump technology file from milkyway library /remote/wwas1/ hercules/venu/HERCULES_DOC/tutor/TUTORIAL_LAB/ Getting_Started_Hercules_DRC/addertest3/EX_ADDER_3. Use it to create output library Using existing technology table! Technology file /remote/wwas1/hercules/venu/HERCULES_DOC/tutor/ TUTORIAL_LAB/Getting_Started_Hercules_DRC/addertest3/ EX_ADDER_3_ref.tf has been loaded successfully! Overall ev_engine time = 0:00:42 User=26.99 Sys=2.05 Mem=14.459

95

A Complete Design for DRC Viewing Data Creation Layers in Enterprise

Viewing Data Creation Layers in Enterprise

In this section we look at the Data Creation layers generated by the Boolean checks for EX_ADDER_3. These layers are not error polygons, but are used for checking by the Hercules dimensional operators. We do not look at all the generated polygons, but a representative sample that should be sufficient for you to use as a guideline to explore as much of the hierarchy tree as you desire on your own. When you begin writing more complex runsets that include complex layer generation for DRC checking, you might want to view your intermediate Data Creation layers to check the accuracy of your DRC runset coding. Enterprise provides a quick and easy way to do this. If you are a runset writer, you should go through this section of the tutorial. Open Enterprise in the addertest3 directory. Enter the command: Enterprise & Now open the library and reference library. This allows you to overlay the Boolean-generated layers on your original design. Choose Library > Reference Libraries > Add. Figure 26 Add Reference Library

Add the EX_ADDER_3_ref library as the reference library for the EX_ADDER_3 library as shown in Figure 26. Click OK to open the EX_ADDER_3 library and the INV cell. Choose Create > Cell Instance.

96

A Complete Design for DRC Viewing Data Creation Layers in Enterprise

Figure 27 Create Cell Instance

A Create Cell Instance pop-up window appears as shown in Figure 27. Selecting the symbol next to the Cell Name field allows you to browse list of cells. Select the EX_ADDER_3_ref library by using the down arrow button of the All Cells option in the Browse Cell window (see Figure 28). Select the cell gate_INV and click Close. This adds the cell name to the Create Cell Instance window.

97

A Complete Design for DRC Viewing Data Creation Layers in Enterprise

Figure 28 Browse Cell

Enter the coordinates (0 0) as shown in Figure 29. Click Apply. This creates a cell instance of the master gate_INV from the reference library EX_ADDER_3_ref at the coordinates (0, 0). Figure 29 Create Cell Instance

98

A Complete Design for DRC Introducing Hercules-Explorer

You now have the gate layer 111 overlaid on your original design. You can reference as many of the other layers as you like. For example, you can reference pgate_inv. Also, if you would rather look at only INV, replace all instances of INV with DGATE in the previous instructions. If you would like to view the error polygon structures in Enterprise, you can do so now by opening the TOP_ERR block in the EX_ADDER_3_ref library. You should, however, also complete the next part of the tutorial, which uses Hercules-Explorer to view the design errors. Note: Once you have finished viewing the error polygon structures, close the existing library and exit the Enterprise session. To quit Enterprise, in the command window enter: exit

Introducing Hercules-Explorer
Hercules-Explorer, used in combination with Enterprise,Virtuoso, LTL, or ICStation, makes it easy to locate a design error. The following sections introduce the fundamentals of running Hercules-Explorer and provide basic examples to familiarize you with the program. These examples assume you are using Enterprise as your layout viewing tool. For instructions on using other layout tools, refer to the Hercules Reference Manual. The following instructions for using Hercules-Explorer to process runsets assume that you have not run Hercules on adderdrc3.ev in the UNIX shell. If you have run in the UNIX shell, be aware that most of the information in the Hercules-Explorer dialog boxes is filled in automatically.

Running Hercules-Explorer
Begin by making sure you are in the addertest3 directory. Run Enterprise by using the command: Enterprise From the Verification menu choose Explorer > Explorer DRC. The Hercules-Explorer dialog box appears, as shown in Figure 30.

99

A Complete Design for DRC Introducing Hercules-Explorer

Figure 30 Initial Hercules-Explorer Dialog Box

Choose the File button in the upper left of the screen. A pull-down menu appears, as shown in Figure 31.

100

A Complete Design for DRC Introducing Hercules-Explorer

Figure 31 Hercules File Pull-Down Menu

Choose Load from the pull-down menu. The Load Hercules Data dialog box appears. Figure 32 Load Hercules Pop-Up

Choose Block > AD4FUL. Choose Load. All structures in the library load. The main window reappears as shown in Figure 33.

101

A Complete Design for DRC Introducing Hercules-Explorer

Figure 33 HXDRC Main Window after Loading

Choose AD4FUL in the Layout Block window. When the structures load, Enterprise displays the top-level AD4FUL structure. The window appears as shown in Figure 34.

102

A Complete Design for DRC Introducing Hercules-Explorer

Figure 34 Hercules-Explorer Window with EX_ADDER_3 Design Rule Violations

The window contains several sections, including: The Layout Block window, which lists the Enterprise library structures. The Error Check window, which lists a shortened version of the design rule errors for that structure. The number to the left of the colon (:) indicates how many error polygons are created for each design rule. When the count is greater than one, The up and down arrow buttons allow you to examine each error within a design rule violation. The Description window, which lists the selected design rule as it appears in the runset file.

In this example (continued from Figure 34), AD4FUL was selected from the Layout Block window, with INTERNAL met2 selected in the Error Check window. Now follow the steps to choose a structure to select in HerculesExplorer and a design rule to highlight.

103

A Complete Design for DRC Introducing Hercules-Explorer

Choose ADFULAH in the Layout Block window. Choose the INTERNAL met2 command in the Error Check window.

Viewing Errors Using Hercules-Explorer

The rule, indicated in the Error Check window, flags met2 polygons (layer 10) that do not meet the required 4.0 m minimum width spacing, as shown in Figure 35. Figure 35 ADFULAH INTERNAL Error Displayed in Enterprise Using Hercules-Explorer

104

A Complete Design for DRC Introducing Hercules-Explorer

Keep ADFULAH as your selected Layout Block and choose the EXTERNAL met2 rule. Again, a spacing violation is flagged. This time, met2 must have a distance of 3 m from the other met2 (on layer 10), as shown in Figure 36. Figure 36 ADFULAH EXTERNAL Error Displayed in Enterprise Using Hercules-Explorer

Using the Checks Option

Go ahead and continue to explore all the errors in the design. The organization of error polygons is by structure, with a list of error polygons displayed for each structure in the Enterprise library. To organize errors according to design rules, HXDRC allows you to select a rule and list the structures affected by the rule.

105

A Complete Design for DRC Introducing Hercules-Explorer

To view errors with this organization, start by choosing the Options menu button along the top of the main window. Choose Checks from the pull-down menu. A new window opens, as shown in Figure 37. Figure 37 List of Design Rules after Choosing Checks Menu

The window lists all design rules that generate error polygons. Initially the window enables the display of all vectors. Selecting a vector toggles its display status, while globally selecting All Checks On or All Checks Off changes the display status of all vectors. Choose All Checks Off. Choose the EXTERNAL met2 rule to enable the display of only this single vector.

106

A Complete Design for DRC Introducing Hercules-Explorer

Choose ADFULAH from the Layout Block window. The main Hercules-Explorer window appears as shown in Figure 38. Figure 38 Hercules-Explorer Main Window with Single Vector Display Enabled

The window shows only those structures affected by the selected rule. Any single rule or combination of rules can be selected with this method to further aid you in analyzing your design. As these examples show, Hercules-Explorer makes the analysis job much easier than opening structures and analyzing the error polygons that appear. You can also continue to use Hercules-Explorer while editing the design if you have a complete Enterprise editing license or are using Hercules-Explorer with another supported editing tool. To correct all the design errors in this mode, be sure to read the Hercules-Explorer chapter in the General Information on Using Hercules, Chapter 7, which provides a complete list of the HXDRC features and capabilities.

107

A Complete Design for DRC Introducing Hercules-Explorer

Note: The chosen runset rules for the tutorial examples flag errors that cannot easily be fixed.

Running Hercules Inside of Hercules-Explorer

At the top left of the screen, choose File > Execute Hercules. The Execute Hercules dialog box, as shown in Figure 39, appears. Figure 39 Execute Hercules Dialog Box

Choose Options. An extended version of the Execute Hercules window appears. Enter the Runset File (adderdrc3.ev), the Block Name (AD4FUL), and the path to the runset in their respective fields (as shown in Figure 40).

108

A Complete Design for DRC Introducing Hercules-Explorer

Figure 40 Data Entered in Execute Hercules Dialog Box

Click the Execute button to run Hercules on adderdrc3.ev. We are rerunning our EX_ADDER_3 example so you can see how to execute Hercules from the Hercules-Explorer GUI. When Hercules is finished, the Load Hercules Data window automatically appears (briefly) and loads the block name, AD4FUL. The Layout Block window is refreshed.

109

A Complete Design for DRC Whats Next?

Whats Next?
Chapter 5, Hercules DRC Migration, is for Dracula users who need to convert Dracula runsets to Hercules runsets. You learn how to use various translation options in order to become familiar with operational and syntactical differences between the two tools. If you have already completed Chapters 5 and 6, or if you are not a current Dracula user, continue on to Chapter 7, Introduction to Hercules HLVS, for an introduction to Hercules LVS.

110

5
Hercules DRC Migration5
In this chapter we convert two simple DRC Dracula rule files to Hercules runsets, using various translation options to familiarize you with operational and syntactical differences between the two tools. In the next chapter you run Hercules on a design rule check (DRC) database in the Opus environment. The database include some errors, which you view with Hercules-Explorer, the graphical debug tool from Synopsys that interfaces to Virtuoso.

Summary of Progress to This Point

In the first two examples using Hercules, we explained, in detail, all the steps required to set up the software to check a simple design for a single runset rule. Although the examples were very basic, the procedures and files created were nearly the same for runsets of any complexity. Now that you are familiar with Hercules and its syntax, we take you through the process of converting a Dracula rule file into a Hercules runset.

111

Hercules DRC Migration What Is Drac2He?

Learning Objectives for This Chapter

In this part of the tutorial, we try to simulate a real design environment so you have a better understanding of how to apply Hercules to your application. We introduce you to Drac2He, the Dracula rule file translator. We present two simple examples of Dracula rule files, which we translate using different Drac2He options. With these examples you learn the following: The general syntax conversion that occurs between Dracula and Hercules Several common Drac2He command-line options How to run Drac2He with the Dracula rule file using different command-line options, as well as how to interpret the output files from Drac2He using these different options Operational differences between Hercules and Dracula, including ERROR hierarchy and SUBSTRATE or BULK processing for DRC

Before You Start

Your account should already be set up for this example. If it is not, refer to Chapter 1, Installation and Setup. Before starting this chapter, you should complete the exercises in Chapter 2, An Error-Free Design for DRC, and Chapter 3, Single Design Error for DRC.

What Is Drac2He?
Hercules contains a Dracula rule file translator, Drac2He. You execute the translator from your UNIX command line using your Dracula DRC, LVS, or ERC rule file as an argument. Note: Hercules also has the -dracula command-line option, which allows you to give Hercules a Dracula rule file as input instead of a Hercules runset, and run Drac2He as part of Hercules. Because this part of the tutorial concentrates on the output from Drac2He, we do not use the -dracula option to run Drac2He inside of Hercules, but instead run Drac2He separately on the command line.

112

Hercules DRC Migration Using the Migration Tutorials

Using the Migration Tutorials

Before you start the Hercules Migration part of the tutorial, review and execute the tutorials in Chapter 2, An Error-Free Design for DRC, and Chapter 3, Single Design Error for DRC, of this manual. This guarantees that your Hercules installation is correct, and give you some understanding of the Hercules execution and debug process. The earlier tutorials should take you less than 20 minutes to review.

Learning method: Design Example

Throughout this part of the tutorial, we use a four-bit full adder as the sample design, which is the same example used in the Hercules DRC tutorials in previous chapters. This section of the manual concentrates on the actual conversion from Dracula to Hercules, assuming that you have a basic understanding of Hercules and Hercules-Explorer.

Getting Started with Drac2He

In the first example you take the simple Dracula rule file located in the your_path/tutorial/Getting_Started_Drac2he_DRC/migration1/ directory and translate it to a Hercules runset using three different command-line options, OutType, -rc, and -N. These options demonstrate some general differences between Hercules and Dracula conventions and formats. The following is a list of the three options and their purposes: Note: In Other Dracula Options on page 114 we summarize the numerous other options.

-OutType
As you learned in the initial Hercules runset example in Chapter 2, An ErrorFree Design for DRC, you can output PERM layers or ERROR hierarchy or both. When you run Drac2He, the default outputs both PERM layers and ERROR hierarchy. This directly mimics what Dracula requires as output for all dimensional checks. The -OutType option allows you to specify outputting PERM layers or ERROR hierarchy. We demonstrate turning off the output of the PERM layers and only outputting the ERROR hierarchy. Because the

113

Hercules DRC Migration Getting Started with Drac2He

Hercules syntax does not require a PERM layer to be defined, outputting only ERROR hierarchy is the preferred methodology, unless you want to add the layer to your database or view it in a layout editor. For a more detailed explanation of PERM, ERROR, and TEMP layer outputs, refer to Writing Output Results to Files in Chapter 4, A Complete Design for DRC.

-rc
Historically, Hercules runsets use uppercase for input layers and lowercase for derived layers. This is not required, but recommended to help make the runset easier to read. By default, Drac2He automatically generates lowercase derived layers and uppercase input layers. To produce a runset that has the identical case as the input runset, you need to specify the -rc command line option.

-N
All of the Dracula syntax is copied by default into the translated runset and placed in comments. This makes it easy for previous Dracula users to see the correlation between the Dracula and Hercules commands and options. In some cases, however, it makes it harder to read the resulting runsets because they are filled with extraneous comments. The -N option allows you to disable the generation of those comments.

Other Dracula Options

The examples in this chapter demonstrate the most commonly used options for DRC translations. The following is a list of the main Dracula translator options. For a complete explanation of all the options, refer to the Hercules Reference Manual. /l0/synopsys/bin/SUN64_57_hercules/ drac2he[-BaseCell cellname] [-DupDevice] [-E errorfile] [-explorer] [-FE errorfile] [-IncTechDefs] [-LvlSize] [-MinCellOverlap number] [-mosFilter] [-N] [-nofixtemp]

114

Hercules DRC Migration Getting Started with Drac2He

[-outgds] [-OutType perm|error] [-Parse][-rc] [ShareBaseCell] [-Size number] [-text_map textfile] [tsub] [-V][-Version] commandfile
Argument -BaseCell cellname Description Specifies gate array base cell. Uses double quotes around the list when specifying more than one. Turns on LPE_OPTION, MOS_ALLOW_DUPLICATE_DEVICE. Writes errors to file. Sets options for debugging with Hercules-Explorer. Writes only fatal errors to file. Includes default TECHNOLOGY_OPTIONS section in runset. Sets LEVEL_NON_ORTHOGONAL for all SIZE commands.

-DupDevice

-E errorfile -explorer -FE errorfile -IncTechDefs

-LvlSize

-MinCellOverlap number Specifies MIN_CELL_OVERLAP percent for sets vcell pass -mosFilter Turns on filtering for MOS devices. Specifies Hercules MOS filter options. Uses double quotes around the list when listing more than one option. Produces non-commented runset. Turns off optimization of Dracula TEMPORARYLAYERS. Sets output format to GDS. Chooses error hierarchy or PERM output definitions for Dracula OUTPUT cells. Parses only command file. Retains case for all layers as specified in the Dracula rule file.

-N -nofixtemp

-outgds -OutType error | perm

-Parse -rc

115

Hercules DRC Migration How to Run Drac2He

Argument -ShareBaseCell

Description Turns on SHARED_BASE_CELL for gate array designs. Value by which to increment SIZE. Uses a TEXT_MAP file for lower-level text. Uses CELL_EXTENT instead of BUILDSUB to translate Dracula substrate layers. Prints Drac2He version. Prints product and library version. Dracula command file.

-Size number -text_map textfile -tsub

-V -Version commandfile

How to Run Drac2He

Now you run three different Drac2He translations on the first Dracula rule file example, Migration1. We do not review the results of Migration1 examples until you have completed all of them. Be sure that you are in the directory where your migration1.drc file is located, your_path/tutorial/Getting_Started_Drac2he_DRC/migration1. For the default example, enter the command: drac2he migration1.drc > drc1_default.ev No data is displayed on your screen while the translator runs. When the translation is complete, drc1_default.ev contains your Hercules runset ready for execution. You do not run Hercules at this time. First you run some more example translations. The following command turns off the generation of the PERM layers because you specify the -OutType as only ERROR: drac2he -OutType error migration1.drc > drc1_error.ev The following example retains the Dracula rule file case and turns off the generation of comments in the Hercules runset: drac2he -rc -N migration1.drc > drc1_case_nocomments.ev

116

Hercules DRC Migration Translation Results for Migration1 Example

Translation Results for Migration1 Example

Now look at the resulting Hercules runset files. Example 16, Example 17, and Example 18 show excerpts from the output files and briefly explain the files preceding each figure, to help you identify what is important in the files.

Output from First Dracula Translation

Example 16 shows the output from the first Drac2He run. If you completed the tutorial in Chapter 1, Installation and Setup, most of the runset sections should look familiar. There are a few items (which are emphasized) that you should be sure to notice. Example 16 Drac2He Output from Migration1 Example: drc1_default.ev
/*Converted runset drac2he: VERSION DATA OMITTED * Called as: drac2he migration1.drc *//* ;********************************************************************* ; D E S C R I P T I O N B L O C K ;********************************************************************* */ /* *DESCRIPTION PRIMARY = AD4FUL SYSTEM = GDS2 INDISK = DRAC_example.GDS OUTDISK = OUTPUT SCALE = 0.001 MICRONS RESOLUTION = 0.001 MICRONS MODE = EXEC NO PROGRAM-DIR = ~/example/drac/ KEEPDATA = INQUERY LISTERROR = 300 CHECK-MODE = FLAT *END */ HEADER { INLIB = DRAC_example.GDS OUTLIB = EV_OUT BLOCK = AD4FUL GROUP_DIR = group FORMAT = GDSII OUTPUT_FORMAT = LTL

117

Hercules DRC Migration Translation Results for Migration1 Example

OUTPUT_LAYOUT_PATH = . } OPTIONS { IGNORE_CASE=TRUE DRACULA_DEFAULTS=TRUE RESOLUTION=0.001 NET_PREFIX = N_ } EVACCESS_OPTIONS { PATH = evaccess CREATE_VIEWS = FALSE } TEXT_OPTIONS { USE_COLON_TEXT=TRUE TRUNCATE_FLAG=FALSE REMOVE_TEXT_FROM_SHORT=TRUE CONNECT_BY_NAME = MIXED_MODE ATTACH_TEXT = ALL } /* ;********************************************************************* ; I N P U T - L A Y E R B L O C K ;********************************************************************* */ /* BEGIN INPUT LAYER BLOCK */ /* *INPUT-LAYER */ ASSIGN { TOX (1) /* TOX = 1 */ POLY (5) /* POLY = 5 */ WELL (31) /* WELL = 31 */ PSEL (14) /* PSEL = 14 */ CONT (6) /* CONT = 6 */ MET1 (8) text(63)/* MET1 = 8 TEXT = 63 MET2 (10) /* MET2 = 10 */ VIA (19) /* VIA = 19 */} /* /* END BLOCK *END */ */

*/

/* ;********************************************************************* ; O P E R A T I O N B L O C K

118

Hercules DRC Migration Translation Results for Migration1 Example

;********************************************************************* */ /* /* /* BEGIN OPERATION BLOCK *OPERATION */ */

;check contacts are .3x.3

*/

/* WIDTH[L] CONT SELNE 0.3 OUTPUT cont_err1_Out 98 */ INTERNAL CONT { COMMENT = "WIDTH[L] CONT SELNE 0.3 OUTPUT CONT_err1 98 " VERBOSE=TRUE DIMENSIONS = [0.300,0.300] } PERM=cont_err1_Out (98) /* ;metal1 spacing not less than 3.0 */

/* EXT MET1 LT 3 OUTPUT met1_err1_Out 100 */ EXTERNAL MET1 { COMMENT = "EXT MET1 LT 3 OUTPUT MET1_err1 100 " SPACING<3.000 VERBOSE=TRUE } PERM=met1_err1_Out (100) /* EXT MET1 LT 0.4 OUTPUT e02420_Out 80 */ INTERNAL MET1 { POINT_TOUCH=FALSE NON_PARALLEL=FALSE OUTPUT_EDGES=TRUE SEGMENT>10.000} TEMP=met1_edges EXTERNAL met1_edges { COMMENT = "EXT MET1 LT 0.4 &" SPACING<0.400 OUTPUT_EDGES=TRUE } PERM=e02420_Out (80) /* /* /* */ /* EXT[T] MET1 MET2 LT 1 OUTPUT met1_err2_Out 101 */ EXTERNAL MET1 MET2 { COMMENT = "EXT[T] MET1 MET2 LT 1 OUTPUT MET1_err2 101 " SPACING<1.000 TOUCH=TRUE VERBOSE=TRUE } PERM=met1_err2_Out (101) LENGTH COMMAND TRANSLATED ABOVE */ LENGTH MET1 GT 10 OUTPUT e02420_Out 80

*/

;metal 1 to metal 2 spacing not less than 1.0

119

Hercules DRC Migration Translation Results for Migration1 Example

/* ;* ----------------------------------- DRC data creation for contacts* */ /* NOT CONT POLY toxcont OUTPUT toxcont_Out 121 */ BOOLEAN CONT NOT POLY { VERBOSE=TRUE } PERM=toxcont_Out (121) COPY toxcont_Out { } TEMP=toxcont /* ENC toxcont TOX LT 1.5 OUTPUT toxcont_err1_Out 122 */ ENCLOSE toxcont BY TOX { COMMENT = "ENC toxcont TOX LT 1.5 OUTPUT TOXCONT_err1 122 " SPACING<1.500 VERBOSE=TRUE } PERM=toxcont_err1_Out (122) /* ENC[TO] toxcont MET1 LT 1 OUTPUT toxcont_err2_Out 123 */ ENCLOSE toxcont BY MET1 { COMMENT = "ENC[TO] toxcont MET1 LT 1 OUTPUT TOXCONT_err2 123 " SPACING<1.000 TOUCH=TRUE OVERLAP=TRUE VERBOSE=TRUE } PERM=toxcont_err2_Out (123) DISCONNECT

Dracula_DEFAULTS, OPTIONS Section

Look at the OPTIONS section in the drc1_default.ev file. The DRACULA_DEFAULTS option has been added and set to TRUE. Hercules has default settings for all runset options as well as all command options. In order to make your Hercules runset output match the output from Dracula, Hercules has a master option, DRACULA_DEFAULTS, designed to alter the necessary option settings.

OUTPUT Hierarchy
As was mentioned previously, all of the output data from dimensional checks is written to a PERM layer. For example, the first dimensional command, INTERNAL, has the output written to PERM=cont_err1_out (98). The VERBOSE option is also set in the dimensional commands, causing the output of the INTERNAL to be written to the ERROR hierarchy. This is done to match the OUTPUT of Dracula, but is not necessary. In the next translation of migration1.drc, the OUTPUT is written only to the ERROR hierarchy.

120

Hercules DRC Migration Translation Results for Migration1 Example

COMMENT Option
Each Hercules dimensional command contains the COMMENT option. This option adds user comments, which appear in the summary file and in the error file. The comments also appear in the Hercules-Explorer information window with each command. Drac2He automatically copies the original Dracula command into the COMMENT option to help former Dracula users understand the Hercules version of the command they are trying to execute.

COMMENTS in the Hercules Runset

Hercules uses /* */ to designate all comments. When you run Drac2He, all of your Dracula options, commands, and comments are placed by default in comments in the resulting Hercules runset. This helps to teach you how the new Hercules syntax you are reading matches Dracula syntax.

CASE of LAYERS
All ASSIGN_LAYERS are in uppercase and all TEMP layers, or derived layers, are in lower case. For example, MET1, CONT, and MET2 are ASSIGN layers. TEMP layers are met1_edges and toxcont.

CONJUNCTIVE and COPY Commands

Look at the INTERNAL/EXTERNAL MET1 combination for an example of a Dracula CONJUNCTIVE check and how it is translated. There is also an example of how a COPY command is used if you perform a duplicate command, such as the BOOLEAN AND between CONT and POLY. The translator Drac2He uses the COPY command simply to copy the output of the first command to the output layer of the second command instead of performing the command twice.

Output with PERM Omitted

In Example 17, notice the keyword PERM is gone. Now the output from each dimensional command is written only to the ERROR hierarchy. Data Creation commands are still written to TEMP layers, which are deleted after they are used by all of the commands that need them. For a detailed explanation of PERM, ERROR, and TEMP output hierarchy, see the Hercules Reference Manual.

121

Hercules DRC Migration Translation Results for Migration1 Example

Example 17 Drac2He Output when OutType Option is Set to ERROR in Migration1: drc1_error.ev
/*Converted runset drac2he: VERSION DATA OMITTED * Called as: drac2he -OutType error migration1.drc */ .................. DATA OMITTED .................... */ /* WIDTH[L] CONT SELNE 0.3 OUTPUT CONT_err1 98 */ INTERNAL CONT { COMMENT = "WIDTH[L] CONT SELNE 0.3 OUTPUT CONT_err1 98 " DIMENSIONS = [0.300,0.300] } (1;0) /* ;metal1 spacing not less than 3.0 */

/* EXT MET1 LT 3 OUTPUT MET1_err1 100 */ EXTERNAL MET1 { COMMENT = "EXT MET1 LT 3 OUTPUT MET1_err1 100 " SPACING<3.000 } (1;1) /* EXT MET1 LT 0.4 OUTPUT E02420 80 INTERNAL MET1 { POINT_TOUCH=FALSE NON_PARALLEL=FALSE OUTPUT_EDGES=TRUE SEGMENT>10.000} TEMP=met1_edges EXTERNAL met1_edges { COMMENT = "EXT MET1 LT 0.4 &" SPACING<0.400 OUTPUT_EDGES=TRUE } (1;2) /* /* LENGTH COMMAND TRANSLATED ABOVE */ LENGTH MET1 GT 10 OUTPUT E02420 80 */

*/

...................... DATA OMITTED ....................

-rc and -N Options

In our final Drac2He output example, Example 18, we specify the -rc and -N options. All of the layers are in uppercase, just as they are in the Dracula rule file. This is because of the -rc (retain case) option. Also, the runset is much shorter because the -N option specified no comments to the output. You still have the original Dracula syntax in the COMMENT field of each dimensional check for your reference.

122

Hercules DRC Migration Translation Results for Migration1 Example

Example 18

Drac2He Output with -rc and -N Options Specified: drc1_case_nocomment.ev

drac2he: VERSION DATA OMITTED */

/*Converted runset

HEADER { INLIB = DRAC_example.GDS OUTLIB = EV_OUT BLOCK = AD4FUL GROUP_DIR = group FORMAT = GDSII OUTPUT_FORMAT = LTL OUTPUT_LAYOUT_PATH = . } OPTIONS { IGNORE_CASE=TRUE DRACULA_DEFAULTS=TRUE RESOLUTION=0.001 NET_PREFIX = N_ } EVACCESS_OPTIONS { PATH = evaccess CREATE_VIEWS = FALSE } TEXT_OPTIONS { USE_COLON_TEXT=TRUE TRUNCATE_FLAG=FALSE REMOVE_TEXT_FROM_SHORT=TRUE CONNECT_BY_NAME = MIXED_MODE ATTACH_TEXT = ALL } ASSIGN { TOX POLY WELL PSEL CONT MET1 MET2 VIA } (1) (5) (31) (14) (6) (8) text(63) (10) (19)

INTERNAL CONT { COMMENT = "WIDTH[L] CONT SELNE 0.3 OUTPUT CONT_err1 98 " VERBOSE=TRUE

123

Hercules DRC Migration Translation Results for Migration1 Example

DIMENSIONS = [0.300,0.300] } PERM=CONT_err1_Out (98) EXTERNAL MET1 { COMMENT = "EXT MET1 LT 3 OUTPUT MET1_err1 100 " SPACING<3.000 VERBOSE=TRUE } PERM=MET1_err1_Out (100) INTERNAL MET1 { POINT_TOUCH=FALSE NON_PARALLEL=FALSE OUTPUT_EDGES=TRUE SEGMENT>10.000} TEMP=MET1_edges EXTERNAL MET1_edges { COMMENT = "EXT MET1 LT 0.4 &" SPACING<0.400 OUTPUT_EDGES=TRUE } PERM=E02420_Out (80) EXTERNAL MET1 MET2 { COMMENT = "EXT[T] MET1 MET2 LT 1 OUTPUT MET1_err2 101 " SPACING<1.000 TOUCH=TRUE VERBOSE=TRUE } PERM=MET1_err2_Out (101) BOOLEAN CONT NOT POLY { VERBOSE=TRUE } PERM=TOXCONT_Out (121) COPY TOXCONT_Out { } TEMP=TOXCONT ENCLOSE TOXCONT BY TOX { COMMENT = "ENC TOXCONT TOX LT 1.5 OUTPUT TOXCONT_err1 122 " SPACING<1.500 VERBOSE=TRUE } PERM=TOXCONT_err1_Out (122) ENCLOSE TOXCONT BY MET1 { COMMENT = "ENC[TO] TOXCONT MET1 LT 1 OUTPUT TOXCONT_err2 123 " SPACING<1.000 TOUCH=TRUE OVERLAP=TRUE VERBOSE=TRUE } PERM=TOXCONT_err2_Out (123) DISCONNECT

This concludes our first set of simple Drac2He examples. The next section goes into more detail on how substrate processing and Drac2He errors are handled.

124

Hercules DRC Migration Running Drac2He with Warnings and Errors

Running Drac2He with Warnings and Errors

In the next example you translate a Dracula rule file that contains SUBSTRATE processing commands, as well as syntax errors. Go to the directory that contains the second migration test, your_path/tutorial/ Getting_Started_Drac2he_DRC/migration2. Enter the command: drac2he migration2.drc > drc2_default.ev No data is displayed on your screen while the translator runs. When the translation is complete, drc2_default.ev contains your Hercules runset with some translation errors and warnings. You do not run Hercules at this time, but instead run another translation example.

Translation Results for Migration2 Example

You now take a look at the resulting runset files and review how warnings and errors are reported during Drac2He translations.

Output of Translated migration2.drc File

Example 19 shows the output from the first Drac2He translation of the migration2.drc file. Notice that all ERRORS are located at the top of the runset file. The line containing the error is not output in the runset, except in the ERROR comments. Even though an ERROR occurs, Drac2He tries to create a working runset by commenting out the syntax it cannot translate. All WARNING messages are placed throughout the runset at the same location as the actual syntax in question. (Our next example, Example 20, illustrates how you can choose to output the ERRORS and WARNINGS to a separate file.) Example 19 Drac2He Output with ERRORS and WARNINGS Written to Runset File drc2_default.ev

/*parse error*//*PARSE ERROR: Line 121 -> .3*/ /*PARSE ERROR: Line 121 -> .3*/ /*PARSE ERROR: Line 121 -> output*/ /*PARSE ERROR: Line 121 -> co1*/ /*PARSE ERROR: Line 121 -> 54*/ /*************************************************** wid[l] con ***************************************************/ /*Converted runset drac2he: VERSION DATA OMITTED * Called as : drac2he migration2.drc */

125

Hercules DRC Migration Translation Results for Migration2 Example

/* ;**************** /*

DESCRIPTION BLOCK ******************** */

*DESCRIPTION PRIMARY = test2 SYSTEM = GDS2 INDISK = test2.gdsii OUTDISK = test2_out.gds SCALE = 0.001 MICRONS RESOLUTION = 0.001 MICRONS MODE = EXEC NOW PROGRAM-DIR = /apps/cadence/dracula/bin/ FLAG-SELFTOUCH = YES FLAG-ACUTEANGLE = YES FLAG-NON45 = YES FLAG-OFFGRID = YES 0.01 FLAG-SELFINTERS = YES KEEPDATA = INQUERY LISTERROR = YES CHECK-MODE = FLAT TRANSISTOR-NUM = 20000000 *END */ HEADER { INLIB = test2.gdsii OUTLIB = EV_OUT BLOCK = test2 GROUP_DIR = group FORMAT = GDSII OUTPUT_FORMAT = LTL OUTPUT_LAYOUT_PATH = . } ........................ DATA OMITTED .......................... /* ;************************************************************** */ /* BEGIN INPUT LAYER BLOCK */ /* *INPUT-LAYER */ ASSIGN { NWELL(1) /* NWELL = 1 */ PFLD (2) /* PFLD = 2 */ PCOMP(3) /* PCOMP = 3 */ NCOMP(4) /* NCOMP = 4 */ DIFF (5) /* DIFF = 5 */ NP (6) /* NP = 6 */ PP (7) /* PP = 7 */

126

Hercules DRC Migration Translation Results for Migration2 Example

SAL (8) POLY (11) CON (12) GUARD(26)

/* /* /* /*

SAL = 8 */ POLY = 11 */ CON = 12 */ GUARD = 26 */}

/* DRAC2HE WARNING: SUBSTRATE LAYER BEING TRANSLATED WITH CELL_EXTENT COMMAND. */ /* SUBSTRATE = bulk 63 */ CELL_EXTENT { CELL_LIST = { * } }TEMP=BULK /* /* END BLOCK *END */ */

........................ DATA OMITTED .......................... /* /* BEGIN OPERATION BLOCK *OPERATION */ */

/* NOT BULK NWELL pwell */ BOOLEAN BULK NOT NWELL { } TEMP=pwell /* AND DIFF NP ncomp1 */ BOOLEAN DIFF AND NP { } TEMP=ncomp1 /* AND DIFF PP pcomp1 */ BOOLEAN DIFF AND PP { } TEMP=pcomp1 /* OR NCOMP ncomp1 ncomps */ BOOLEAN NCOMP OR ncomp1 { } TEMP=ncomps /* OR PCOMP pcomp1 pcomps */ BOOLEAN PCOMP OR pcomp1 { } TEMP=pcomps /* AND ncomps NWELL ntap */ BOOLEAN ncomps AND NWELL { } TEMP=ntap /* AND pcomps NWELL pdif */ BOOLEAN pcomps AND NWELL { } TEMP=pdif /* AND pcomps pwell ptap */ BOOLEAN pcomps AND pwell { } TEMP=ptap /* AND ncomps pwell ndif */ BOOLEAN ncomps AND pwell { } TEMP=ndif

127

Hercules DRC Migration Translation Results for Migration2 Example

........................ DATA OMITTED .......................... /* AND CON SAL sb08 OUTPUT sb08 54 */ BOOLEAN CON AND SAL { VERBOSE=TRUE } PERM=sb08_Out (54) /* ;---------------------------------------------------------; CONTACT RULES ;-------------------------------------------------------------*/ /* END BLOCK /* *END */ DISCONNECT */

error.out
Example 20 shows the error.out file you created in your second translation of the migration2.drc runset. Notice that all of your error and warning messages are now in this file. You should take a minute to view the drc2_errorout.ev runset. Notice that there are no errors or warnings in the Hercules runset file. Finally, be aware that a detailed explanation accompanies each warning on the SUBSTRATE translation. In general, warnings are just informational messages noting an operation difference between Dracula and Hercules. Example 20
/*parse /*PARSE /*PARSE /*PARSE /*PARSE

Drac2He Error Output File with -E Option: error.out

-> .3*/

error*//*PARSE ERROR: Line 121 ERROR: Line 121 -> .3*/ ERROR: Line 121 -> output*/ ERROR: Line 121 -> co1*/ ERROR: Line 121 -> 54*/

/* DRAC2HE WARNING File migration2.drc Line 37: SUBSTRATE LAYER BEING TRANSLATED WITH CELL_EXTENT COMMAND. */ SUBSTRATE = bulk 63

If you would like to fix the syntax error and re-translate, execute the following steps: 1. Edit the migration2.drc file. 2. Go to line 121, as the ERROR indicates. 3. Change the first command, wide, to width. Leave the rest of the line the same and save the file. Enter:

128

Hercules DRC Migration Whats Next?

drac2he -E error.out migration2.drc > drc2_errorout.ev The error.out file should no longer contain any errors.

Whats Next?
Now that you are familiar with the Drac2He translator, you can move on. In Chapter 5, Hercules DRC Migration, you run another Drac2He translation and then run Hercules on the resulting file. The Hercules run generates some design rule violations that you view using Hercules-Explorer interfaced to Virtuoso.

129

Hercules DRC Migration Whats Next?

130

6
Hercules Migration with Hercules-Explorer6
In this chapter you convert a simple Dracula rule set to a Hercules runset using the translation options you learned in Chapter 5. Then you run Hercules on this runset and view the results using Hercules-Explorer interfaced to Virtuoso, a Cadence layout tool.

Summary of Progress to This Point

If you are completing the exercises in the recommended order, you should now be familiar with Hercules and its associated input and output files, know how to execute Hercules from a UNIX command line, and be familiar with the Hercules to Dracula translator, Drac2He. Now that you have all of the basic information, you can move on to a more realistic example in your design environment.

Learning Objectives for This Chapter

In this part of the tutorial, we try to simulate a real design environment so that you have a better understanding of how to apply Hercules to your application. You will:

131

Hercules Migration with Hercules-Explorer Generating a Runset with Drac2He

Convert a Dracula rule set to a Hercules runset using Drac2He Set up the Hercules and Hercules-Explorer menus in Opus Run Hercules on the output from Drac2He Introduce and run Hercules-Explorer connected to Virtuoso to show how the error detection process can be made easier

Generating a Runset with Drac2He

In the tutorial for this chapter, you translate a Dracula rule set by setting the option on the command line to generate the necessary options for HerculesExplorer and Virtuoso. You also run Hercules and then view the ERROR output with Hercules-Explorer in Virtuoso. Go to the directory that contains the third migration test, your_path/tutorial/ Getting_Started_Drac2he_DRC/migration3. This directory contains the necessary technology files for the Cadence Opus environment, as well as two versions of the AD4FUL library: GDSII: AD4FUL.GDS Cadence 4.4.x library: ./lib4

In both cases the top block is AD4FUL. Enter the command: drac2he -explorer -E error.out migration3.drc > drc3.ev The -explorer option generates the necessary option in the Hercules runset to use Hercules-Explorer for error debug. Your screen does not display data while the translator runs. When the translation is complete, drc3.ev contains the Hercules runset ready for execution. Before you run Hercules on this runset, we review its contents.

Translation Results for Migration3 Example

Example 21 shows the HEADER and OPTIONS sections you should have in the drc3.ev file that Drac2He output. Notice that:

132

Hercules Migration with Hercules-Explorer Setting up Hercules in the Opus Environment

INLIB is AD4FUL.gds and the FORMAT is GDSII. OUTPUT_FORMAT is LTL. The LTL format is for Hercules-Explorer to read. In the OPTIONS section the EXPLORER_DATA option is TRUE. This tells Hercules to generate the extra data necessary for Hercules-Explorer to highlight errors.

Example 21 drc3.ev HEADER and OPTIONS Sections

HEADER { INLIB = AD4FUL.gds OUTLIB = EV_OUT BLOCK = AD4FUL GROUP_DIR = group FORMAT = GDSII OUTPUT_FORMAT = LTL OUTPUT_LAYOUT_PATH = . } OPTIONS { IGNORE_CASE=TRUE DRACULA_DEFAULTS=TRUE EXPLORER_DATA=TRUE RESOLUTION=0.001 NET_PREFIX = N_ }

Setting up Hercules in the Opus Environment

The next section of the tutorial shows you how to set up Hercules-Explorer and the Virtuoso interface in the Opus environment. First, enter the command: setenv XPROBE /tmp/xprobe-$user This sets the XPROBE environment variable. When Hercules-Explorer is started, it creates a file at the XPROBE location. Be sure to set XPROBE to a location where you have read/write privileges. You should choose a location on a local disk drive.

Starting Opus
The icfb command starts the Cadence Opus, version 4.2.2 or higher. See the Hercules Reference Manual for earlier versions. Enter the command:

133

Hercules Migration with Hercules-Explorer Setting up Hercules in the Opus Environment

icfb &

Loading Synopsys SKILL Code

In your CIW window, enter: load "{$HERCULES_HOME_DIR}/bin/{$AVANTI_SYSTYPE}/ skill_menu_4.4.il" A successful setup of the Opus environment with the Synopsys tools results in the following message in your icfb window:
function avntLF redefined function avntLM redefined Done. /***********************************/ t Explorer Msg: Defined <Key>g -- Probe Selected Object. Explorer Msg: Defined <Key>p -- Probe Layout Point. Explorer Msg: Defined <Key>r -- Remove Highlights. Synopsys SKILL environment setup is done t

Note: If your SKILL load fails, include an explicit path. For example: load "/l0/synopsys/bin/SUN32_58/skill_menu_4.4.il" At this time you start a layout window in Opus, begin your Virtuoso session, and then open the AD4FUL library.

Opening Your Layout

From the Tools menu in the CIW window, open the Library Manager. If the library is not in the search path, you have to execute the next three steps: 1. Under Library Manager choose Edit > Library Path. 2. Under Library Path Editor choose Edit > Add Library to add the library path. 3. Use the browser to locate the AD4FUL library and add it to the path.

134

Hercules Migration with Hercules-Explorer Setting up Hercules in the Opus Environment

Now you should have the AD4FUL library in your path and you can continue. 1. Under Library choose AD4FUL. 2. Under Cell choose AD4FUL. 3. Under View double click Layout. Now you should have the AD4FUL layout open in Virtuoso. Finally, before you can run Hercules, you need to bring up the Synopsys GUI-based tools.

Setting Hercules Startup Options

Choose Synopsys Tools > Set Hercules Startup Options. Figure 41 Synopsys Tools Menu

You should be prompted to enter or verify the Hercules run directory and optional remote host for Hercules-Explorer. Complete the following steps: 1. Verify that the Hercules run directory is your_path/tutorial/ Getting_Started_Drac2he_DRC/migration3. 2. Under Hercules Runset, enter drc3.ev. 3. Under GDSII Scale uu/DBU, enter 0.001. 4. Verify that the GDSII unit is set to micron and GDSII case sensitivity is set to preserve. 5. Verify that GDSII User Property Separator is a comma (,) 6. Click OK at the top of the menu.

135

Hercules Migration with Hercules-Explorer Setting up Hercules in the Opus Environment

You have now set up your Hercules/Hercules-Explorer/Opus environment and executed Hercules on the drc3.ev runset. If you had any problems or want a more detailed description of the commands available in the SKILL files supplied by Synopsys, refer to General Information on Using Hercules, Chapter 6, for a complete description of the Hercules-Explorer/Opus interface.

Streaming Out from Virtuoso

From the Synopsys Tools menu, select Stream Out & Run Hercules via ExplorerLVS. Figure 42 Stream Out and Run Hercules via ExplorerLVS

Click OK at the top of the menu. You have now streamed out the Opus library, created a GDS file, and executed Hercules on the drc3.ev runset

Opening Hercules-Explorer
When the run is complete, the Hercules-Explorer LVS window appears with the words Layout Extract Errors in the Schematic Layout box (see Figure 43).

136

Hercules Migration with Hercules-Explorer Setting up Hercules in the Opus Environment

Figure 43 Layout Extract Errors

Select this text with the cursor and the Hercules-Explorer DRC window appears.

137

Hercules Migration with Hercules-Explorer Debugging with Hercules-Explorer in the Opus Environment

Figure 44 DRC Explorer1

Your Hercules job should now be complete and a list of design errors should be loaded in your Hercules-Explorer DRC window.

Debugging with Hercules-Explorer in the Opus Environment

Select the block DGATE in the Layout Block selection box, as shown in Figure 45.

138

Hercules Migration with Hercules-Explorer Debugging with Hercules-Explorer in the Opus Environment

Figure 45 Selecting DGATE

When DGATE is selected, the Virtuoso editing window automatically loads the selected block, as shown in Figure 46 Figure 46 DGATE

139

Hercules Migration with Hercules-Explorer Debugging with Hercules-Explorer in the Opus Environment

All the error categories are displayed in the Error Check selection box. Select 1 : Grid (non-90 path center line) in the Error Check selection box (see Figure 47). Note: This is the first and only error in the DGATE block. The 1 before the colon (:) indicates the number of violations described on the right side of the colon. Figure 47 Error Check Selection Box

When the error is selected, a description of the error appears in the Description box (see Figure 47). The actual error appears in the Virtuoso editing window, as shown in Figure 48.

140

Hercules Migration with Hercules-Explorer Debugging with Hercules-Explorer in the Opus Environment

Figure 48 Grid (non-90 path center line) Error in Virtuoso Editing Window

At this point you can fix the layout. When you have finished fixing the previous error, select ADFULAH in the Layout Block selection box of the Hercules-Explorer DRC window (see Figure 49).

141

Hercules Migration with Hercules-Explorer Debugging with Hercules-Explorer in the Opus Environment

Figure 49 Selecting ADFULAH

The ADFULAH block is then opened in the Virtuoso editing window, as shown in Figure 50. Figure 50 ADFULAH Block Shown in Virtuoso Editing Window

142

Hercules Migration with Hercules-Explorer Whats Next?

Select the first error in the ADFULAH block, EXTERNAL MET1. The description of the error is displayed in the Description box, while the actual error appears in the Virtuoso editing window (see Figure 51). Figure 51 External Met1 Error in Virtuoso Editing Window

To view the next error, EXTERNAL MET2, select it by clicking the cursor on the error, or by clicking the down arrow in the top right-hand corner of the HerculesExplorer DRC window. (The up arrow displays the previous error.) After you have fixed all or some of the errors, you can again choose Stream Out and Run Hercules under the Synopsys Tools menu to rerun Hercules and verify edits.

Whats Next?
You have now completed a Dracula to Hercules translation, job execution, and debug example. If you plan to write Hercules runsets in the future, or if you want more details on Hercules commands, go back and complete the tutorial in Chapter 4. If you have already completed Chapter 4, or if you are not interested in this aspect of Hercules DRC, continue on to Chapter 7 for an introduction to Hercules LVS.

143

Hercules Migration with Hercules-Explorer Whats Next?

144

7
Introduction to Hercules HLVS7
In this chapter we discuss the basic principles of Hercules Hierarchical Layout vs. Schematic checking (LVS). We also review the tutorial design used in this section of the document. You learn about the components of a Hercules LVS job and the contents of runset and output files created for an error-free LVS job.

Learning Objectives for This Chapter

To learn the components of hierarchical LVS. To understand the principles of hierarchical LVS. To learn the benefits of hierarchical LVS and how to take advantage of these benefits. To learn the difficulties presented by hierarchy and how to avoid these difficulties in your designs. To run Hercules on an error-free design and examine file output, establishing a reference for clean design files. (This step also verifies that your Hercules software installation and licensing are correct.)

145

Introduction to Hercules HLVS Before You Start

Before You Start

Before you start this tutorial, make sure that you have completely gone through the installation and setup procedures described in Chapter 1, Installation and Setup, or that your setup files are in order. See Creating Directories and Getting the Files, in Chapter 1 for directory structure and necessary files. You should also, at the very least, have completed the tutorials in Chapters 2 and 3.

Learning Method: the Design Example

To learn Hercules LVS you use a simple 32-bit microprocessor design that includes an 8Kx32 shared Instruction and Data cache. The complete design is 1.6 million transistors. The technology is a 2-level metal, single poly 1 m CMOS design. It is a single N well, P+ substrate with digitized N+ and P+ diffusion layers. The separate diffusion layers avoid the need to include an implant layer, thus simplifying the example. The microprocessor is built hierarchically, making it well-suited to take advantage of the Hercules checking capability. This example is used throughout Chapters 79. As we go through the LVS tutorial, we introduce more detail about the microprocessor as it relates to running LVS. As in the HDRC section of this tutorial, the design is configured so that you can use independent runsets on variations of the chip. Each variation is in its own directory to avoid any possible confusion. Because your design copy is in your own account, you are free to experiment with the files. Examine the graphical files not specifically covered in this tutorial, and make changes to see what effect they have on the output. In fact, because this tutorial cannot realistically cover every possible aspect of the design or the design structures, at several points along the way we encourage you to explore on your own, reinforcing the learning experience with independent experimentation.

What are LVS and Its Components?

LVS verifies the connectivity of a layout netlist against a schematic netlist. The schematic netlist is generated from a Schematic Design tool. For these tutorials, the schematic netlist is considered a required input file. Hercules extracts a hierarchical netlist from the layout that describes the devices and their net connectivity in the layout database. Generating this layout netlist is the first major component of LVS and our tutorial.

146

Introduction to Hercules HLVS What is Hierarchical LVS?

An LVS tool reads in the two netlists, converts them to a network representation, and then determines whether the two networks are identical. This comparison of the two netlists is the second major component of LVS and our tutorial. If the two networks are the same, the LVS result is said to be LVS clean. If not, the tool is designed to diagnose and pinpoint the root of the connectivity differences properly and effectively.

What is Hierarchical LVS?

Hierarchical LVS consists of two phases involving hierarchy: 1. extraction of a hierarchical layout netlist 2. comparison of the hierarchical layout netlist to a hierarchical schematic netlist. (Throughout this chapter we often refer to the comparison phase as COMPARE.) Before discussing the specifics of the LVS runset, we need to review hierarchical texting. The next three sections discuss hierarchical device extraction, hierarchical texting, and hierarchical netlist comparison. These concepts are very important to understand before you try to analyze a hierarchical LVS operation.

Hierarchical Device Extraction

Hercules performs a hierarchical device extraction. Hercules does not require that all the polygon data or device layers be in a single cell. For example, your poly layer and diffusion layers might be in different cells, but Hercules is still able to recognize their interaction and form the gate, source, and drain layers for a MOSFET device. You should, however, try to lay out or design your devices in such a way that all of the terminal layers are in the same cell, in order to guarantee the best performance from Hercules and the easiest debugging.

Layers That Make Up a Device Should Be in the Same Block

Some interaction of data across the hierarchy is to be expected. For example, power rails and nwells from blocks placed side by side abut each other or slightly overlap and interact during verification. Another normal situation is when metal and via polygons connect blocks together. Figure 52 shows an

147

Introduction to Hercules HLVS What is Hierarchical LVS?

example of these situations. Notice that the polygons either abut or only slightly overlap. Figure 52 Interaction of Data Across the Hierarchy Cell A Cell A Cell B Cell A Cell C Metal Well

Overlapping Cells

Abutting Cells

However, layers in a device should be kept in proper hierarchies. There can be exceptions, such as diffusion-programmable ROMs. Consider Figure 53, for example. Figure 53 Structure Crossing Hierarchies in a p-device Block b Instance of Block a

co

pc rx

co bp

m1

Notice that this p-device has an instance of block a within block b. Block a, in turn, has layers pc, rx, co, and m1, each layer having one or more geometries. However, bp is in block b. Because bp is not in block a, there is some data interaction across the hierarchy. Preferably, bp would be a part of block a.

148

Introduction to Hercules HLVS What is Hierarchical LVS?

Chapter 8, HLVS Advanced Concepts, contains details on designing devices for hierarchical extraction. There we examine various situations where designing across the hierarchy is necessary. Chapter 8 outlines how to get the best performance from Hercules, both in the optimal hierarchical situation, where all of the device layers are contained in a single cell, and in the lessthan-optimal situation, where the devices are designed across the hierarchy.

Hierarchical Texting
Hercules looks at text hierarchically. Therefore, text placed in lower level cells, or what many refer to as pin text in library cells, can be read by Hercules and attached to the nets in that cell. This is also true for text placed on pins in memory blocks or other blocks (cells) besides the top one. In some cases, text is placed over a layer or net but at a different level of the hierarchy. You must tell Hercules the rules for attaching this type of text by setting the ATTACH_TEXT option in the TEXT_OPTIONS section of the runset. This option is reviewed later in the chapter, when we go through our Hercules LVS runset in detail.

Match Text Appropriately at all Hierarchical Levels

To achieve the best performance and easiest debug from Hercules it is always best to match text appropriately, at all hierarchical levels between the layout and the schematic. However, it is acceptable to have different text at different levels of the hierarchy. Consider the following diagram. Here, we have text A in block b and TOP_NET at the higher level. It is important to match text between schematic and layout at the different levels.
Schematic { block b { port A { inst m1=n {pin A=GATE... } } {block topblock { inst x1=block b { pin TOP-NET=A... } }
TOP-NET

Layout

block b

m1

149

Introduction to Hercules HLVS What is Hierarchical LVS?

Use Different Texting Layers for Different Polygon Layers

In the first example, the ASSIGN section has text placed in one layer, DATA.TEXT. Based on the following TEXT commands, Metal1 is texted first, then Metal2. There is the risk that text intended for Metal2 gets inadvertently associated with Metal1 if the polygons overlap. In the assign section of your runset, you typically associate a different text layer for each connecting layer. Example 22
ASSIGN{ Metal 1 (8) Metal 2 (12) DATA(255) TEXT (20)

(unsound practice)

TEXT {Metal1 by DATA.TEXT Metal2 by DATA.TEXT}

To avoid mistexting, it is preferable to separate out the text as follows: Example 23

ASSIGN{ Metal 1 (8) TEXT(20) Metal 2 (12) TEXT(30) TEXT {Metal1 by Metal1.TEXT Metal2 by Metal2.TEXT}

Hierarchical Netlist Comparison

Hierarchical netlist comparison is a bottom-up, divide-and-conquer approach. Hercules uses a list of cell or block names, called the equivalence file, as a guide to decide which cell in the layout it should try to match to a particular cell in the schematic. Example 24 shows the form of the equivalence file. See Example 29 for an example of an actual equivalence file

150

Introduction to Hercules HLVS What is Hierarchical LVS?

Example 24 Form Taken by the Equivalence File

EQUIV EQUIV EQUIV EQUIV EQUIV EQUIV EQUIV EQUIV EQUIV A=A B=B C=C I=I J=J F=F G=G K=K L=L { { { { { { { { { } } } } } } } } }

The equivalence file is not a required input file; however, if you do not supply the file, Hercules adds a preprocessing step to analyze quickly the devices and connections of each cell in the layout and schematic, automatically generating this file. For details on the equivalence file and setting its options and variables, refer to the Hercules Reference Manual. Hercules works its way up the hierarchy, comparing each sub-block listed in the equivalence file. Once a sub-block is compared, Hercules creates a model of the port relationship of the sub-block, to be used at the next level of hierarchy. Once the devices in a sub-block are compared, Hercules never needs to process the information on those devices again. If you have a very good hierarchical design, when Hercules reaches the top block it probably compares only port relationships between sub-blocks. In other words, instead of comparing five million transistors in the top block, it compares only a few hundred sub-block port relationships. Figure 54 is an example of how hierarchy might look in a schematic and layout netlist. Following Figure 54 is list of steps describing how Hercules would process the hierarchy and compare the two netlists. For this example, if the names of two cells are the same, they contain the same logic. Remember, you cannot always assume this fact in all designs.

151

Introduction to Hercules HLVS What is Hierarchical LVS?

Figure 54 Schematic and Layout Netlist Hierarchies

Schematic Layout

A B D I K J H L E C F G

A C B I K J L F M G N

1. Hercules reads in the schematic and layout netlists and the equivalence file. 2. Hercules determines which sub-blocks in the equivalence file make up the lowest level of hierarchy. In our example, those are I, K, L, F, and G. The lowest level of hierarchy is defined as the bottom of each branch of a tree. 3. A flat representation of the netlists for each of the sub-blocks is generated. In our example, G is the only sub-block that has hierarchy beneath it. Subblocks M and N would be flattened into the layout netlist of G before the schematic and layout netlists of G are compared. 4. These flat sub-blocks are compared, and, if they match, a port representation of each is created and saved for use in the next level of hierarchy. 5. Next, Hercules reads in the sub-blocks at the next level. In our example, these are J and C. B is not included in this level because it depends on J, so it must wait until J is compared. B is in the next level of hierarchy. 6. Flat netlists are generated for sub-blocks J and C. In order to do this, port relationships for child cells, generated in step 4, are substituted into the netlists in place of the cell definitions and instances of the child cells. 7. The flat sub-blocks are compared and, if they match, a port representation of each of these, J and C, is created. 8. The same process is repeated for the next level, which contains cell B, and finally the top cell, A. This example of hierarchy comparison is a very simple one. Many variations of this hierarchy comparison exist. For example, what if cell K in the schematic did

152

Introduction to Hercules HLVS Designing to Benefit from Hierarchical LVS

not match cell K in the layout? In the following chapters, we go through different flows of hierarchy processing, each of which depends on different ways of telling the Hercules comparison engine to operate. For now, however, our tutorial in this chapter uses a sample flow similar to the one described previously.

Designing to Benefit from Hierarchical LVS

Hierarchical LVS has benefits over flat LVS, during both the extraction and comparison phases. The following is a list of the greatest benefits. Shorter runtimes and lower memory usage, because sub-blocks are processed and their information saved, instead of millions of devices being processed at one time. Easier debug, because you can debug a mismatched net or device in a subblock containing hundreds of devices, instead of the top block, which can contain millions of devices. Smaller netlist generation, because both the layout and schematic netlists are hierarchical. In a System-on-Chip (SOC) environment, hierarchical LVS allows you to define different comparison rules for each sub-block, if necessary. In memory designs, port swappability can be defined for sub-blocks.

Most of your pre-existing designs benefit from a hierarchical LVS extraction and comparison, but by following some simple design rules for your future designs you can drastically improve your benefits. For example, in the previous discussion on Hierarchical Device Extraction we pointed out that you can improve your runtime and debug ability by designing devices so that a single cell contains all of the device layers. Texting correctly also improves the runtime and debug ability. The next few paragraphs specifically address designing to improve the comparison phase of your LVS job.

Match the Hierarchy Between Schematic and Layout

Hercules runs faster when there are commonalities between the layout and the schematic. This allows Hercules to analyze mismatches between the layout and schematic more efficiently, as shown by Figure 55 and Figure 56.

153

Introduction to Hercules HLVS Designing to Benefit from Hierarchical LVS

Figure 55 Recommended Schematic Matches Layout

Schematic Top Layout Top

Figure 56 Poor Hierarchical Correlation

Schematic Top Layout Top

C C

B A E F

Notice the major problem with this design: block names, such as the bottom ones, B and D vs. C and E, are not the same, making it difficult to find the levels in the layout that do correspond to those in the schematic.

Defining the Most Beneficial Equivalence Points

It is not the number of equivalence points that determines the best possible LVS runtime and memory usage, but the choice of these equivalence points. For example, if you have 1,000 devices in your design and you create 100 equivalence points, Hercules spends more time partitioning the netlist and creating the port representation for each of these equivalence points than it would just comparing the 1,000 devices flat.

154

Introduction to Hercules HLVS Designing to Benefit from Hierarchical LVS

Choose your equivalence points based on easy debug points and natural breaks in the design hierarchy. For example, in a standard cell or ASIC design, the library cells or standard cells are natural equivalence points, because most design flows require the schematic and layout blocks to match at this level. Functions built from these standard cells are another natural point for equivalences, but are not required for improved performance and might not be a requirement of your design style. You should include functions as equivalence points to get another level at which to debug errors before you reach the macro block level. Macro blocks are usually required equivalence points in a standard cell design. They should be listed in the equivalence file to improve your runtime, memory usage, and to give you a good intermediate level of hierarchy for debug. In the case of memory blocks, there should be an equivalence point set up for a register level block (8 or 9 bits), or, if that is not available, a bit cell. Also, if possible, there should be one or two intermediate points, below the top memory block and at the top memory block level.

Match Layout Block Name to Schematic Block Name

Equivalent blocks for both the layout and schematic should have the same block name, as illustrated by Table 1. Table 1
Level N

Recommended Schematic Matches Layout

Schematic Layout

Good: block name Bad: block name buffer buf_0 buffer buffer

155

Introduction to Hercules HLVS Difficulties Presented by Hierarchy in LVS

Match Block Port Names for Blocks That Will Be Equivalence Points
Each expected equivalent block should have the port names that match between schematic and layout, if possible, as illustrated by Table 2. Table 2
Level N block A

Matched vs. Unmatched Block Port Names

Schematic Layout

Good: port list Bad: port list PYI PYO YI YO PY PYO Y YO PYI PYO YI YO PYI PYO YI YO

Difficulties Presented by Hierarchy in LVS

Most difficulties presented by hierarchy in an LVS job are due to the third dimension hierarchy adds to connectivity. This extra dimension involves accounting for cell-to-cell interactions for both the extraction and the comparison phases.

Devices Floating Out of Equivalence Points

The major difficulty hierarchy presents in the extraction stage is the possibility of devices crossing hierarchical boundaries, floating out of the cell where they were originally designed and, in some cases, out of a cell you want to define as an equivalence point. In a flat design, all devices are compared at the top, and, therefore, all layout devices are netlisted flat. In a hierarchical design, you want to preserve your hierarchical boundaries wherever possible. Thus, if you have device layers that cross cell boundaries and Hercules is forced to netlist the device in a parent cell, you might lose some of your equivalence points. See Guaranteeing Devices Are Netlisted in the Cell Where They Are Designed in Chapter 8, HLVS Advanced Concepts, for details on preserving equivalence points during hierarchical device extraction.

156

Introduction to Hercules HLVS Difficulties Presented by Hierarchy in LVS

Port Swappability
The major difficulty hierarchy presents in the comparison stage is determining port swappability of sub-blocks. There are two types of swappable ports: Independently swappable ports are logically equivalent ports that can be interchanged without affecting their function within the block. For example, any inputs of an NAND gate can be swapped without changing the function of the gate. Dependently swappable ports rely on their functional relationship within the block and, therefore, cannot be separated from one another.

We go through a simple explanation of each in this chapter.

Detecting Swappable Ports

The LVS COMPARE option offers an advanced algorithm for detecting and handling the comparison of swappable or permutable ports. Placing the DETECT_PERMUTABLE_PORTS command in the COMPARE section of the runset allows you to have swappability rules applied and extracted automatically. In the AND-OR-INVERT cell of Figure 57, A cannot be swapped with C unless B is swapped with D, thus demonstrating dependent swappability. In contrast, the independently swappable ports, A and B, are interchangeable, as are C and D. Figure 57 AND-OR-INVERT
A B X Y

OUT
C D X Y

Hercules has algorithms built into the code to determine the most complex swappability cases, but, in some flows, the designers might want to restrict what blocks are allowed to have swappable ports. You should set DETECT_PERMUTABLE_PORTS to TRUE in the COMPARE options section,

157

Introduction to Hercules HLVS Difficulties Presented by Hierarchy in LVS

and then set the same option to FALSE in the equivalence file for each block whose swapping you want to restrict.

Equivalence Points That are Resolved in Their Parent

In some cases, especially those created by devices floating out of a cell or by swappability issues, a particular cell might not match between the layout and schematic. However, by simply removing the equivalence point the parent cells will compare. For example, a PMOS device is netlisted in the AND-OR-INVERT functional macro instead of in the AND cell in which it was designed. The AND cells in the layout schematic do not compare, but the AND-OR-INVERT cells do compare. You can turn on EXPLODE_ON_ERROR to tell Hercules simply to explode all blocks that do not compare to their parent, and then compare the parent. You will have an error in your results for the sub-block, but as long as the parent compares, your design is considered clean. If you want to have tight control over which blocks compare, turn this option off, and either require that the layout be redesigned (which might be a bit extreme) or that the equivalence point be removed so that no errors are reported.

Different Number of Instances of a Cell in the Layout and Schematic

One other difficulty presented by hierarchy in the comparison phase occurs in designs where parent blocks contain different numbers of child blocks between the layout and the schematic. For example, the schematic has an array of 100 buffers, but in the layout, due to space requirements, only 98 of the buffers are arrayed as cells. The PMOS and NMOS devices, making up the remaining buffer logic, are laid out in the parent as individual devices. Hercules has a COMPARE option, AUTO_EXCLUDE_EQUIV, that is TRUE by default. The child equivalence points would be exploded in this case, because a different number of instances occurs in the schematic than in the layout. If you set this option to FALSE, Hercules would keep the buffer as an equivalence point and explode the two extra instances that did not match in the schematic. For an example look at Figure 58.

158

Introduction to Hercules HLVS Overview of Required and Optional Input Files for LVS

Figure 58 AUTO_EXCLUDE_EQUIV Options

Before AUTO_EXCLUDE_EQUIV Schematic
Block Buffer
INV INV

Layout
Block Buffer
INV INV

Buffer
INV INV INV INV

After AUTO_EXCLUDE_EQUIV Schematic

Block Block

Layout

INV

INV

INV

INV

INV

INV

INV

INV

Overview of Required and Optional Input Files for LVS

Hercules LVS requires two input files, a runset file and a schematic netlist. Hercules LVS also offers two optional input files to help improve the performance of the Hercules LVS run: an equivalence file and an edtext file.

159

Introduction to Hercules HLVS Overview of Required and Optional Input Files for LVS

Before we execute our first Hercules LVS job, we review the format and content of these four files.

The Runset File

Runset files are ASCII (text) files containing instructions that tell Hercules where to get its files and how to run. Each runset file has sections with variables and commands defining the functions Hercules performs. A Hercules LVS runset can be divided into two parts: 1. The commands for hierarchical netlist extraction. 2. The commands for a hierarchical comparison. The following describe each section and the variables and commands in a Hercules LVS runset.

Example of an Actual Runset File

Files with the .ev extension are runset files. Example 25 shows our first runset example, dac96lvs1.ev. We go over each line so that you understand the basics of runset file creation. Study this example of an actual runset file, noting the various sections whose labels appear to the right of the series of dashs (----). The short titles are followed by a space and an open brace ({) and appear in the far left margin. They are emphasized for your convenience. Following Example 25 there is a discussion of each of these sections, including a general description of each section and details of the settings for each of them. Example 25 The dac96lvs1.ev Runset File
/* HLVS SAMPLE RUNSET */ /* -------------------------- Runset Header information */ HEADER{ LAYOUT_PATH= ./ INLIB = dac96 BLOCK = DAC96 OUTLIB = dac96_out FORMAT =MILKYWAY GROUP_DIR = group COMPARE_DIR = compare

160

Introduction to Hercules HLVS Overview of Required and Optional Input Files for LVS

EQUIVALENCE = dac96.eqv SCHEMATIC = dac96.hrc SCHEMATIC_FORMAT = HERCULES } /* ------------------------- Runset options */ OPTIONS { EXPLORER_DATA = TRUE IGNORE_CASE = FALSE SCHEMATIC_GLOBAL = {VDD GND VDDIO VSSIO} SCHEMATIC_GROUND = {GND VSSIO} SCHEMATIC_POWER = {VDD VDDIO} LAYOUT_POWER = {VDD VDDIO} LAYOUT_GROUND = {GND VSSIO} EDTEXT=dac96.text NET_PREFIX = XX_ } /* --------------------------- Data Preprocessing options */ PREPROCESS_OPTIONS { CHECK_PATH_90 = false } /* --------------------------- Text Processing options */ TEXT_OPTIONS{ ATTACH_TEXT = ALL } /* --------------------------- Layer assignments */ ASSIGN{ NDIFF (1) PDIFF (2) NWELL (3) POLY (5) TEXT (25) CONT (6) M1 (8) TEXT (28) V1 (9) M2 (10) TEXT (30) PAD (15) TEXT (35) DIFF (1-2) RESP (50) } /*=====================================================*/ /* LVS NETLIST EXTRACTION SECTION OF RUNSET */ /*=====================================================*/ /* MOSFET extraction layer generation*/

161

Introduction to Hercules HLVS Overview of Required and Optional Input Files for LVS

BOOL PDIFF AND NWELL BOOL NDIFF NOT NWELL BOOL PDIFF NOT NWELL BOOL NDIFF AND NWELL BOOL POLY AND ndev BOOL POLY AND pdev BOOL ndev NOT ngate BOOL pdev NOT pgate BOOL BOOL BOOL BOOL

temp=pdev temp=ndev temp=subtie temp=welltie temp=ngate temp=pgate temp=nsd temp=psd

POLY NOT ngate temp= temp_field temp_field NOT pgate temp= tmp_field_poly tmp_field_poly AND RESP temp = rpoly tmp_field_poly NOT rpoly temp = field_poly

/* Resistor Extraction layer generation */ SELECT field_poly touching rpoly temp = res_term /* Diode Extraction layer generation */ SELECT NDIFF interacting POLY temp = nodiode BOOL NDIFF NOT nodiode temp = pos_ndiffdio BOOL pos_ndiffdio NOT NWELL temp = ndiffdio /* ------------------------------- Diode Device Definition */ DIODE ndio ndiffdio ndiffdio substrate {DIODE_TYPE=NP;} temp = ndiode /* ------------------------------- Resistor Device Definition */ RES rp rpoly res_term res_term {EV_RESVAL = 1.0; } temp = pdevice /* ------------------------------- NMOS Device Definition */ NMOS n ngate nsd nsd SUBSTRATE { MOS_CALC_NRS_NRD = true } temp = ndevice /* ------------------------------- PMOS Device Definition */ PMOS p pgate psd psd NWELL { MOS_CALC_NRS_NRD = true } temp = pdevice /* -------------------------------- Define Connectivity Rules */ CONNECT { ngate pgate BY field_poly M2 BY PAD M1 M2 BY V1 M1 ndiffdio res_term field_poly nsd psd welltie subtie BY CONT NWELL by welltie

162

Introduction to Hercules HLVS Overview of Required and Optional Input Files for LVS

SUBSTRATE by subtie } /* -------------------------------- Define Text Attachment Rules */ TEXT { M1 BY M1 M2 BY M2 field_poly BY POLY PAD BY PAD NWELL BY "VDD" SUBSTRATE BY "GND" } /* ----------------------- Layout Netlist Generation */ NETLIST /* -------------------------- Output Layer assignment */ GRAPHICS{ explorer_layers(100) NDIFF (1) PDIFF (2) NWELL (3) POLY (5) PAD (15) RESP (50) M1 (8) M2 (10) CON (6) V1 (9) } /*=====================================================*/ /* LVS COMPARISON SECTION OF RUNSET */ /*=====================================================*/ /* ------------------- Define Schematic Diode equal to layout diode */ EQUATE DIODE NDIO = ndio A B { check_properties = {area} rel_tolerance[area] = {5} } /* --------------- Define Schematic Resistor equal to layout resistor */ EQUATE RES RP1 = rp A B { } /* -------------- Define Schematic N Mosfet equal to layout N mosfet */

163

Introduction to Hercules HLVS Overview of Required and Optional Input Files for LVS

EQUATE NMOS N = n G S D VBB { check_properties={l,w} rel_tolerance[l]={5} rel_tolerance[w]={5} filter_options={nmos-3 nmos-8} } /* --------------- Define Schematic P Mosfet equal to layout P mosfet */ EQUATE PMOS P = p G S D VBB { check_properties={l,w} rel_tolerance[l]={5} rel_tolerance[w]={5} filter_options={pmos-3 pmos-8} } /* --------------- Layout verse Schematic Global Comparison Options */ COMPARE { COMPARE_PROPERTIES = TRUE PROPERTY_WARNING = FALSE EXPLODE_ON_ERROR = TRUE RETAIN_NEW_DATA = TRUE STOP_ON_ERROR = FALSE FILTER = TRUE MERGE_SERIES = FALSE MERGE_PARALLEL = TRUE MERGE_PATHS = FALSE EQUATE_BY_NET_NAME = TRUE REMOVE_DANGLING_NETS = TRUE PUSH_DOWN_PINS = TRUE PUSH_DOWN_DEVICES = TRUE DETECT_PERMUTABLE_PORTS = TRUE }

General Runset File Sections

The first group of runset sections described are similar to those described in the Hercules DRC error-free example in Chapter 2, An Error-Free Design for DRC. These are found in all types of Hercules runs, with different options set depending on the type of Hercules job.

Runset Header Information

The Runset Header Information section is defined by the keyword HEADER, found in the left margin of the file. HEADER contains variables defining where

164

Introduction to Hercules HLVS Overview of Required and Optional Input Files for LVS

Hercules can find the layout libraries and other input files, as well as where to write intermediate processing files and output files. A description of LAYOUT_PATH, INLIB, BLOCK, OUTLIB, FORMAT, and GROUP_DIR can be found in Chapter 2, An Error-Free Design for DRC.. These variables are generally set for all types of Hercules jobs. We describe the remaining variables listed in the HEADER section. These four are unique to Hercules LVS jobs: COMPARE_DIR. This setting tells Hercules where to place all the COMPARE output files it temporarily or permanently creates. The default value for the COMPARE_DIR variable is run_details/compare/. The COMPARE directory contains all of the intermediate files Hercules uses during the actual layout netlist versus schematic netlist comparison. This directory also contains debug information for each cell that Hercules LVS uses as a comparison point. We describe this in more detail when we examine the output files written to this directory. EQUIVALENCE. This variable specifies the location and name of the equivalence file. The equivalence file is a comparison input file that lists the structures to be compared. It is generally referred to as the EQUIV file. For example, the top block, DAC96, and sub-blocks, such as AND2, NOR2, and IOBUF, would be listed in this file. Specifying the equivalence file is optional. Hercules automatically produces an equivalence file if none is specified here. Later we discuss the advantages and disadvantages to specifying this file. We also discuss the COMPARE options later in this chapter. Most options that can be specified in the COMPARE section can also be specified in the EQUIV file for individual blocks. For example, in the COMPARE section you can set the FILTER option to TRUE, and in the EQUIV file you can set FILTER to FALSE for CELL A. SCHEMATIC. This variable is set to the file name, including the path, of the schematic netlist file. This variable is required to execute a Hercules LVS run. If you do not specify this file, or if Hercules cannot find the file you specify, the Hercules job terminates with an error indicating that the schematic file is not specified or that Hercules cannot open the schematic netlist for reading. SCHEMATIC_FORMAT. This variable is set to the format type of the input schematic netlist. Hercules supports CDL, Hercules, SPICE, EDIF, EDIF3, VERILOG, and SILOS. This variable is required if the input schematic netlist specified is not in the Hercules format. If this format is set to something other

165

Introduction to Hercules HLVS Overview of Required and Optional Input Files for LVS

than Hercules, Hercules calls NetTran, the netlist translation utility. See the section NetTran later in this chapter.

General Runset Options

The OPTIONS section allows you to specify global assignments for various Hercules processes. You need to specify an option value only when you wish to override the Hercules default. In our example we selected just a few of the many Hercules options you can use to control your LVS run. Refer to Chapter 4 of the Hercules Reference Manual for a complete OPTIONS list. EXPLORER_DATA. The EXPLORER_DATA option tells Hercules to output the necessary graphical data files needed to use Hercules-Explorer for graphical debug. This includes the graphics properties of instant_name (1), and net_name (4). For more details on these properties, see the GRAPHICS_PROPERTY command in the Hercules Reference Manual. For the Hercules-Explorer graphical debug you must also include the GRAPHICS_NETLIST command in your runset variable. That command is discussed later in this chapter. IGNORE_CASE. The IGNORE_CASE option applies only to LVS. This includes the way the LVS layout netlist is generated and the case sensitivity of the schematic netlist, equivalence definitions, and equate definitions. In our example we use the default of FALSE so that all cases are preserved and considered when writing and comparing the layout and schematic netlists. SCHEMATIC_GLOBAL. The SCHEMATIC_GLOBAL option specifies a list of schematic net names that are treated as global during netlist comparison. Typically, you define power and ground nets that are assumed to be globally connected throughout the schematic netlist. These names are used by COMPARE during merging and filtering operations. If no SCHEMATIC_GLOBAL nets are specified in an LVS runset, Hercules attempts to create them based on global net information in the schematic netlist and typical global net names. Some of the typical names for which Hercules does a string search are: VDD VCC POWER PWR VPP

166

Introduction to Hercules HLVS Overview of Required and Optional Input Files for LVS

VBB VEE VSS GND GROUND SCHEMATIC_GROUND. The SCHEMATIC_GROUND option specifies a list of schematic net names that are considered to be connected to the ground rails in the schematic netlist. These names are used by COMPARE during merging and filtering operations. If no SCHEMATIC_GROUND nets are specified in an LVS runset, Hercules attempts to create them based on global net information in the schematic netlist and typical ground net names (see the list under SCHEMATIC_GLOBALS). SCHEMATIC_POWER. The SCHEMATIC_POWER option specifies a list of schematic net names that are considered to be connected to the power rails in the schematic netlist. These names are used by COMPARE during merging and filtering operations. If no SCHEMATIC_POWER nets are specified in an LVS runset, Hercules attempts to create them based on global net information in the schematic netlist and typical power net names (see the list under SCHEMATIC_GLOBALS). LAYOUT_POWER. The LAYOUT_POWER option specifies a list of layout net names that are considered to be connected to the power rails in the layout. These names are used by COMPARE during merging and filtering operations. In our example we have defined our LAYOUT_POWER nets as VDD and VDDIO. LAYOUT_GROUND. The LAYOUT_GROUND option specifies a list of layout net names that are considered to be connected to the ground rails in the layout. These names are used by COMPARE during merging and filtering operations. In our example we have defined our LAYOUT_GROUND nets as GND and VSSIO. EDTEXT. The EDTEXT option specifies a path and file name that contains text placement information. The text from this file is placed in the extracted netlist along with any text found in the layout. If there is text in the layout and text in an EDTEXT file located on the same net, the text in the EDTEXT file takes priority over the layout text and is applied to the net. We review the dac96.text file later in this chapter. An EDTEXT file is not required for Hercules LVS.

167

Introduction to Hercules HLVS Overview of Required and Optional Input Files for LVS

NET_PREFIX. Hercules generates unique numbers for all nets that are not texted in the layout or in an EDTEXT file. The NET_PREFIX option allows you to specify a string that is added to the front of the numeric net names. This helps you distinguish nets named by Hercules and nets with numeric text. In our example, NET_PREFIX is set to XX_. Another typical NET_PREFIX is NET_. If a NET_PREFIX is not specified and numeric text is found in the layout, the text is discarded to avoid shorts between the numeric text and a net number Hercules assigns. If a NET_PREFIX is specified and text is found that begins with the NET_PREFIX and contains only numeric text, the text is discarded to avoid shorts between the text and a net number.

Preprocessing Options
The PREPROCESS_OPTIONS section allows you to specify the printing of information to show the Hercules efficiency at processing the design hierarchy, as well as to specify the setting of path grid checking options. You can set options for increased information in the block.LAYOUT_ERRORS file and the tree files. You can also set options for path grid checking, to be done when the layers are read during the ASSIGN section. The remainder of the grid checking is done during the brace command, discussed in Chapter 2, An Error-Free Design for DRC.. You may also want to use the CHECK_PATH_90 option; refer to Chapter 2.

Texting Options
The TEXT_OPTIONS section allows you to define how your text is attached to polygon data, and to replace text strings or text characters, if necessary. There is also a section where you can define nets for FIND_SHORTEST_PATH_BETWEEN_TEXT_SHORTS. We have an example of this option later in the tutorial. In this example, we define only one of the TEXT_OPTIONS. ATTACH_TEXT. The ATTACH_TEXT option defines how the text in the layout is attached to the polygon data across the hierarchy. In our example we define ATTACH_TEXT as ALL. This tells Hercules to create new ports and nets, if necessary, for attaching text. When text from a cell is being applied, if no polygon in the cell interacts with the text origin, this option checks to see if polygons on the lower level cells interact with the text origin. If these polygons exist and do not form a physical port to the cell containing the text, this option creates a port, from a polygon of a lower level cell to the cell containing the text.

168

Introduction to Hercules HLVS Overview of Required and Optional Input Files for LVS

This new port connects to a newly created net in the cell containing the text. It is named by that text. In Figure 59 we give an example of how this might occur in a design. Figure 59 Attaching Text Individual Look at Cell A and Cell B * A1 * A2 * A3 Cell B Cell A Cell B placed inside of Cell A; Text A2 and A3 are attached to the two polygons in Cell B. * A1 * A2 * A3

Layer Assignments
The ASSIGN section assigns symbolic names to the database layers found in the design. Our design uses 11 polygon layers and 4 text layers. All input polygon and text layers must be defined in this section before they are used in the remainder of the runset. In our example, notice that we have merged layers 1 and 2 together and defined a new layer, DIFF. You can read in a single layer and assign it to different names or combine layers, as we have done. We do not actually process the DIFF layer in our example, but have done this just to give an example of syntax.

169

Introduction to Hercules HLVS Overview of Required and Optional Input Files for LVS

LVS Netlist Extraction Section

We group the next set of commands together for discussion. They include device layer generation, device definitions, connectivity, texting, layout netlisting, and graphical output. Together, these make up the first phase of the Hercules LVS job, the extraction of a hierarchical layout netlist.

Device Layer Generation

This section of the runset contains the BOOLEAN and SELECT commands used to define the layers that make up the devices Hercules extract and netlists. Our example includes MOSFETs, a resistor, and a diode. Other types of devices you might define include bipolar transistors, capacitors, and other generic devices.

Device Definitions
This section of the runset contains the designed device commands for PMOS, NMOS, RES, and DIODE extraction. Hercules extracts and netlists these devices based on the layers defined in the commands and the type of command used. Hercules also supports a CAPACITOR command for capacitor extraction, DEVICE and GENDEV commands for generic device extraction, and an NPN or PNP command for bipolar transistor extraction. A complete definition of each of these commands and their options is in Chapter 5 of the Hercules Reference Manual. In general, each design device command is followed by a device name, in our example, ndio, rp, n, and p. The next argument is the device layer used to define the body of the device. In the case of the diode and resistor, the device layer should interact with one polygon from each terminal layer. For the MOSFETs, the device layer polygon must edge touch exactly one polygon of each of the terminals, unless the MOS_SINGLE_SD or MOS_MULTITERM_EXTRACT options are set to TRUE. The two terminal layers follow the device layer, and, finally, in the case of the MOSFETs and diode, the last layer listed is the bulk layer. The bulk layer must completely enclose the device layer. Example 26 is a general example of syntax for a designed device command. Later in the tutorial we go into more graphical detail on designed device extraction. Example 26
NMOS device_name device_layer terminal options....} temp = output_definition terminal bulk {

170

Introduction to Hercules HLVS Overview of Required and Optional Input Files for LVS

Connectivity Commands and Options

The CONNECT command is used to define electrical connectivity for all layers. Each polygon in a layer that is specified to the left of the BY keyword is connected independently to each polygon with which it interacts in the layer specified to the right of the BY keyword. The default interaction is defined as OVERLAP and TOUCH, but can also be defined exclusively as OVERLAP or TOUCH. For complete details on the CONNECT command, refer to the Hercules Reference Manual.

Texting Commands
The TEXT command defines how the text files defined in the ASSIGN section or from text files (for example, EDTEXT) are associated with polygon layers. For example, all text defined for M1 in the ASSIGN section should be attached to the M1 layer, and all of the text defined by POLY in the ASSIGN section should be attached to the field_poly layer (defined as texting). You can also text a layer with a string. In our example we text NWELL with the VDD string and SUBSTRATE with the GND string. The origins of TEXT placements in the text layer must overlap the polygons in order to be applied.

Layout Netlisting Command

The NETLIST command tells Hercules to generate a layout netlist (block.net) that is used by Hercules for the next phase of the LVS job, the comparison of the hierarchical layout netlist to a hierarchical schematic netlist. Up until this point in the netlist extraction phase, all of the device data was stored in an internal database. If you omit the NETLIST command, Hercules is not be able to continue to the next phase of the LVS job.

Graphical Output
The GRAPHICS command contains layer assignments for the special graphic database, which can be created from the extracted database. The database is identical to the internal database from which the netlist was extracted. This database includes any modification caused by TECHNOLOGY_OPTIONS, Boolean commands, or any other commands specified in the runset file. Netlist information is attached to the graphic data in the form of properties. This information includes net number, net text (if any), whether the net is an I/O for the block, instance number, device number, and device type. The NET_PREFIX is added to the net numbers, the instance numbers are prefixed with I, and the device numbers are prefixed with the device name.

171

Introduction to Hercules HLVS Overview of Required and Optional Input Files for LVS

This database can be viewed in any layout editor to aid in the debugging of the netlist extraction. Hercules-Explorer, a graphical debugger, can also be used to read this database for easy graphical debug of extraction problems. Any layer generated in the Hercules runset can be output to this database. To automatically generate a list of the layers required by Hercules-Explorer, we have used the explorer_layers (100) option. This outputs all of the layers used to generate devices and connectivity starting at layer 100. The block.sum file we discuss later contains a complete list of the layers and layer numbers generated by this option.

LVS Comparison Section

We group the next set of commands together for discussion. They include the device equate options and compare options. Together they make up the second phase of the Hercules LVS job, the comparison of the hierarchical layout netlist to a hierarchical schematic netlist.

LVS Device Equate Options

The EQUATE command is used to associate schematic primitive devices with their corresponding extracted layout primitive devices. An EQUATE command entry must be included for every non-parasitic extracted device in the design. There are many options associated with the EQUATE command. The ones that we have set in this example are listed here. For a complete list, refer to the Hercules Reference Manual. If you do not include EQUATE commands, Hercules attempts to generate the EQUATE commands automatically. CHECK_PROPERTIES. The CHECK_PROPERTIES option names the properties compared for the equated devices. In our example, we are comparing the l and w properties for the NMOS and PMOS devices, as well as the area property for the DIODE. These properties are compared if the COMPARE_PROPERTIES option is set to TRUE in the COMPARE section of the runset. (We discuss the COMPARE section later.) For a complete list of properties you can compare, see the CHECK_PROPERTIES command in Chapter 5 of the Hercules Reference Manual. REL_TOLERANCE. The REL_TOLERANCE (or TOLERANCE) option allows different relative tolerances to be set for each property. The property name is the same as the properties specified by the CHECK_PROPERTIES option. The value can be either one or two numbers, which are used as percentages. If one

172

Introduction to Hercules HLVS Overview of Required and Optional Input Files for LVS

value is given, as in our sample runset, it is used as the allowed percentage difference by which the layout property value can vary from the schematic property value. If two values are given, the first is the percentage the layout value can exceed, and the second is the percentage the layout value can be less than the schematic value for the same property. Hercules offers an ABS_TOLERANCE option as well. For more information on tolerances, see the Hercules Reference Manual. FILTER_OPTIONS. The FILTER_OPTIONS control filtering in the schematic and in the layout. There are filtering options available for each device type; they are specified in a table in the Hercules Reference Manual, Chapter 5, under the EQUATE command section. In our example, we have set the NMOS-3, PMOS3, NMOS-8, and PMOS-8 options. NMOS-3 tells Hercules to filter all NMOS devices whose gate pin is connected to ground. PMOS-3 filters all PMOS devices whose gate pin is connected to power. NMOS-8 and PMOS-8 filter all MOSFETs whose gate, source, or drain pin is floating.

LVS Comparison Options

The COMPARE section defines all of the options associated with the actual comparison of the layout and schematic netlists. The following sections describe some of the available options. For a complete list, see the Hercules Reference Manual. COMPARE_PROPERTIES. The COMPARE_PROPERTIES option is TRUE, telling Hercules to check device properties for matching values. A warning is issued when a property is contained in one netlist but not the other. The percent difference allowed between the layout and schematic properties is determined by the REL_TOLERANCE, TOLERANCE, or ABS_TOLERANCE variables in the EQUATE statements, or by the PROPERTY_TOLERANCE variable in the COMPARE options section. Using the PROPERTY_WARNING options in the COMPARE section, you can choose to make mismatched properties a warning or an error. By default, if COMPARE_PROPERTIES is TRUE, an error is generated. If you set PROPERTY_WARNING to TRUE (the default is FALSE), warnings are generated for mismatched properties. PROPERTY_WARNING. The PROPERTY_WARNING is set to FALSE. We did not need to include this option, because its default is FALSE, but it is helpful to include it in the runset with the COMPARE_PROPERTIES option. The option reminds you that because COMPARE_PROPERTIES is TRUE and

173

Introduction to Hercules HLVS Overview of Required and Optional Input Files for LVS

PROPERTY_WARNING is FALSE, all mismatched properties generate an error. EXPLODE_ON_ERROR. When EXPLODE_ON_ERROR is set to TRUE, modules or blocks that have errors are exploded upward into their parent. Remember that we are reviewing the COMPARE options, so the explode is done in the context of the layout and schematic netlists, not in the layout extraction. In Chapter 8, HLVS Advanced Concepts, we discuss the Hercules process of comparing the individual blocks of the layout and schematic netlists and how Hercules works its way up the hierarchy. This option should be used with caution because, as the blocks with errors are exploded, the netlist becomes flatter and the COMPARE less efficient. For designs with less than 5 million transistors, however, there is probably no need to worry about how flat the design gets. Some users have a design methodology requiring each equivalence point (the blocks you tell Hercules to compare) to match, and this option is not allowed in such a flow. RETAIN_NEW_DATA. As we described in the HEADER section, files resulting from the netlist comparison are written into the COMPARE directory specified by the COMPARE_DIR option. When RETAIN_NEW_DATA is set to TRUE, all of these files are retained. We discuss the contents of all of these files later in the chapter. This option is set to FALSE by default to minimize the amount of disk space used by the Hercules LVS tool. When this option is FALSE, files associated with modules that matched without warnings or errors are deleted after the comparison is complete. STOP_ON_ERROR. We have set the STOP_ON_ERROR option to FALSE to allow Hercules to continue the netlist comparison even if an error has occurred in a sub-block. This option defaults to TRUE unless EXPLODE_ON_ERROR is TRUE. Because we have already set EXPLODE_ON_ERROR to TRUE, we did not need to specify this option. If you were to set EXPLODE_ON_ERROR to FALSE and STOP_ON_ERROR to FALSE, Hercules would continue its comparison for all levels of the hierarchy, but would not compare modules containing submodules with errors. FILTER. We have set the FILTER option to TRUE so that devices that are unused in either the layout or schematic are removed before comparison. The types of unused devices filtered out depend on the FILTER_OPTIONS specified in the EQUATE for each device.

174

Introduction to Hercules HLVS Overview of Required and Optional Input Files for LVS

MERGE_SERIES. In our example we have set MERGE_SERIES to FALSE. The majority of design styles, however, require MERGE_SERIES to be TRUE, so we are providing here a complete explanation of how MERGE_SERIES works in Hercules. Capacitors and resistors in series can be merged into a single device having the same net connections as the terminal pins on the chain. NMOS and PMOS devices are in a series chain when their drain and source pins are connected consecutively. All devices in the chain must be of the same device type. In addition, the nets connecting the drain/source pins of neighboring devices cannot have any other connections or be ports of the block. A single merged device is created having drain/source pin connections to the terminal drain/source pins of the chain and multiple Gate pin connections corresponding to the number of devices in the chain. The Gate pins on the merged device are automatically designated as interchangeable. As a result, net connections to the Gate pins are allowed to be in any order. All bulk or substrate pin connections must be tied to the same point in order for devices to be classified as series devices. For capacitors and resistors, the merged device type is the same as that of the physical device members. However, a new device type must be created for NMOS and PMOS devices, because the merged device has multiple gate pins. The name for the new device type is the name of the member device type, followed by two dashs (--) and ending with the number of gate pins in the chain. For example, in a series chain where drain and source pins are connected consecutively, four devices with type name nmos would result in a merged device type of nmos--4. Newly created series chain devices are assigned instance names of SerChain#1, SerChain#2, and so on. An example of series merging is shown in Figure 60.

175

Introduction to Hercules HLVS Overview of Required and Optional Input Files for LVS

Figure 60 Series Merging D G1 G2 G3 S A A D G1 G#1 SD#1 G2 G#2 G3 G#3 SD#2 S

B B

MERGE_PARALLEL. In our example, we have set MERGE_PARALLEL to TRUE. Most design methodologies, except for full custom, highly specialized circuits, require MERGE_PARALLEL to be activated. A complete description of how Hercules merges parallel devices follows. Devices are parallel if every corresponding pin pair between the devices is connected to the same net. Two or more parallel devices are combined into a single merged device with the same device type and net connections. Bulk or substrate pin connections must also correspond in order for devices to be classified as parallel devices. Parallel merging applies only to devices specified in the EQUATE commands. Higher level blocks that satisfy the criteria for parallel devices are not parallel merged. Newly created parallel devices are assigned instance names of Parallel#1, Parallel#2, and so on.

176

Introduction to Hercules HLVS Overview of Required and Optional Input Files for LVS

An example of parallel merging is shown in Figure 61. Figure 61 Parallel Merging D G S G S D

MERGE_PATHS. In our example we set MERGE_PATHS to FALSE. Not as commonly used as MERGE_SERIES, MERGE_PATHS is probably the most complicated merging option in Hercules. The following is an explanation of how MERGE_PATHS works in Hercules. Paths of NMOS or PMOS devices are an extension of series chains. Path merging can be used for more complex structures where groups of devices are stacked. This type of structure is commonly found in AND-OR-INVERT logic. The series components of the stacked structure provide the AND function, while the parallel components result in an OR operation. While series chains have only two terminating drain/source pins, path structures can have two or more terminating drain/source pins. The stacked structure is expanded into non-duplicate series chains between the terminating drain/source pins. This results in more than one merged device being created for each stacked structure. Be aware that this differs from all other merging operations, which replace multiple physical devices with a single merged device. In addition, a single physical device can be a member of many merged devices created from a path structure. All bulk or substrate pin connections must be tied to the same point in order for devices to be classified as series devices. Because path merging is an extended version of series chain merging, the naming conventions are the same as described previously. An example of path merging is shown in Figure 62.

177

Introduction to Hercules HLVS Overview of Required and Optional Input Files for LVS

Figure 62 Path Merging

D G1
G1 SD#1 G#1 G#2 G#3 SD#2 G1 G3 G4 SD#1 G#1 G#2 G#3 SD#2 D

G2

G3

G2 G4

G4 S

A G1 SD#1 G#1 G2 B G#2 SD#2 G1 SD#1 G#1 G3 G#2 SD#2

A G1

G2 B

G3 C

G2 SD#1 G#1 G3 G#2 SD#2 C

EQUATE_BY_NET_NAME. When the EQUATE_BY_NET_NAME option is set to TRUE, net names that are the same in the schematic and layout are set equivalent before the comparison begins. However, nets found to have a different number of connections are not equated, even though their names match. For designs where texting methodology is known, this can greatly improve the comparison stage of the Hercules LVS run. However, in highly symmetrical designs where equating nets by name is the most beneficial, it can also be the most detrimental. If pins are swapped so ENA actually equals EN and vice versa, or the circuit has very little uniqueness and the names are

178

Introduction to Hercules HLVS Overview of Required and Optional Input Files for LVS

incorrect, Hercules might spend unnecessary processing time trying to determine that nets you said are equated are actually not. REMOVE_DANGLING_NETS. REMOVE_DANGLING_NETS is set to TRUE, so that preprocessing of the input layout netlist finds all cases where a port net in a cell never connects to any extracted device throughout the hierarchy. In our design example we have some gate array logic that assumes unnecessary ports are created when the base layers and programming layers are combined to form a new cell. (This is done automatically during the hierarchy preprocessing, as was discussed in Chapter 2, An Error-Free Design for DRC.) Because the same cells are created in a standard cell format, without having the extra ports, we must turn this option on so the port list of the gate array cells and the port list of the standard cells match and both can be equated to a single schematic cell in the schematic netlist. PUSH_DOWN_PINS. The PUSH_DOWN_PINS option is set to TRUE, so both the schematic and layout netlists are preprocessed to determine all cases where two or more pins on a given cell are connected above the hierarchy across all instances of that cell. In such cases, the COMPARE algorithm replaces these pins with a single merged pin as the connection is pushed down into the cell. This resolves cases in which cells are equivalent between the schematic and layout but, for example, two devices are connected inside the cell in the schematic but outside the cell in the layout. In addition, PUSH_DOWN_PINS propagates power and ground information down the hierarchy to any net that ultimately connects to power and ground across all instances. This power and ground information is particularly useful for merging and filtering operations. Power and ground nets are defined by the LAYOUT_POWER, LAYOUT_GROUND, SCHEMATIC_POWER, and SCHEMATIC_GROUND options in the OPTIONS section of the runset. Although this option defaults to FALSE, you should always set this option to TRUE to get the most accurate connectivity information down into your lower level cells, which results in a higher number of equivalent lower level cells. PUSH_DOWN_DEVICES. The PUSH_DOWN_DEVICES option is set to TRUE so that both the schematic and layout netlists are preprocessed to determine all cases where devices existing up in the hierarchy of the netlists can be moved down legitimately. This helps preserve lower level equivalence points, particularly in cases where the hierarchical extract moved devices up the hierarchy. For example, in the layout most of the source/drain region of a

179

Introduction to Hercules HLVS The Schematic Netlist File

MOSFET is in cell B and all of the gate is in cell B. However, there is a portion of the source/drain region that is also in cell A, the parent of B. When the Boolean operations are performed to generate the MOSFET layers in the layout extraction, and there are instance specific interactions across the hierarchy, the device is generated in cell A (the parent), even though it was intended to be placed in cell B. An instance-specific interaction would be a case where one placement of cell A interacts with cell B differently than the other placements. A device must have all terminals directly connected to ports on a cell, and this connectivity must be consistent across all instances of that cell. In such a case, those devices would be removed from the higher level and replaced in the cell. The default for this option is FALSE. In general, for designs that were not designed with hierarchical verification in mind (in other words, they do not follow the guidelines of good hierarchical design given in Chapter 8), you should set PUSH_DOWN_DEVICES = TRUE. DETECT_PERMUTABLE_PORTS. DETECT_PERMUTABLE_PORTS automatically extracts and applies swappability rules. The default is FALSE, but you should set this option to TRUE to avoid miscompares due to swappability issues. It handles dependent or independent swappability without additional input. The option can be set in the COMPARE section, as we have done here, or in the EQUIV file for individual cells. The DETECT_PERMUTABLE_PORTS option extracts the symmetries for each block, and then the information is applied when determining equivalence for the parent cell of the block. Therefore, when DETECT_PERMUTABLE_PORTS is specified globally, it does not operate on the top-level block. To extract symmetries for the top-level block, you must explicitly invoke DETECT_PERMUTABLE_PORTS in the entry for the top-level block in the EQUIV file.

The Schematic Netlist File

The Schematic Netlist file is a required input file when executing a Hercules LVS job. You must provide a properly formatted schematic netlist so that Hercules has something to compare with the layout netlist it generates in the first phase of the Hercules LVS job. As discussed previously, Hercules supports all of the major formats of schematic netlists. The Hercules executable, however, reads only a Hercules-formatted schematic netlist, so all other formats must be converted to the Hercules format. An example of this format is shown in Example 27. The conversion to the Hercules format is done by the

180

Introduction to Hercules HLVS The Schematic Netlist File

utility NetTran (executed as nettran). To avoid too much confusion, our first example starts with a Hercules-formatted netlist. The following is a brief overview of NetTran and its functionality. For more details see the Hercules Reference Manual.

NetTran
NetTran is a netlist translation utility. There are two ways to execute NetTran.

Executing NetTran as a UNIX Shell Command

The first way is by executing the nettran command on a UNIX shell command line. The command-line options are: nettran [-V] [-Version] [-usage] [-cdl file ...] [-edif file ...] [-edif3 file ...] [-hercules file ...][-silos file ...] [-sp file ...] [-verilog file ...] [-cdl-a] [-cdl-chop] [-cdl-chopDev] [-cdl-fopen model_name ...] [-cdl-fshort model_name ...] [-cdl-M file] [-cdl-p] [cdl-P] [-cdl-R] [-cdl-renameDev] [-cdl-s] [-cdl-U][edif-f] [-edif-globalNets netName ...] [-edif-p][-edifpa] [-edif-U] [-sp-fopen model_name ...][-sp-fshort model_name ...] [-sp-finst inst_name ...][-sp-fp delimiter] [-sp-od pattern] [-sp-m number] [-sp-S] [sp-topCell cell] [-sp-topCellPorts portName][-sp-U] [sp-voltThresh number] [-verilog-b0 netName][-verilog-b1 netName] [-verilog-R] [-verilog-U][-verilog-busLSB] [acct] [-acctFile file] [-dup][-equiv file] [forceGlobalsOn] [-herc-globalNets netName ...] [-logFile file] [-mprop][-msgError NTR-# ...] [-msgId][msgSuppress model_name ...] [-msgTable] [-namePrefix prefix] [-noflatten] [-rootCell cell] [-slash] [-undef] [-wireLog file][-outType netlist_type] -outName file
Argument -V -Version -usage -cdl file ... Description Print product version. Print product and library version. Print NetTran usage. Input CDL format netlist(s).

181

Introduction to Hercules HLVS The Schematic Netlist File

Argument -edif file ... -edif3 file ... -hercules file ... -silos file ... -sp file ... -verilog file ... -cdl-a

Description Input EDIF 2 0 0 format netlists. Input EDIF 3 0 0 format netlists. Input Hercules format netlists. Input SILOS format netlists. Input Spice format netlists. Input Verilog format netlists. Preserve all passive devices (resistors, capacitors, diodes). Remove first character of all instance names. Remove first character of all device names. Filter-out devices with specific model-name.

-cdl-chop -cdl-chopDev -cdl-fopen model_name...

-cdl-fshort model_name ... Filter-out R&C devices with specific model-name, the two pins will be shorted. -cdl-M file -cdl-p CDL map file. Translate instance param to prop if the model has no instances. Multiply scale_factor by param_global. Include unused parameters in the Hercules netlist. Prefix device names with type to resolve identical name conflict. Don't treat slash as delimiter. Convert cdl input to upper case. Force EDIF primitives in Hercules netlist.

-cdl-P -cdl-R

-cdl-renameDev

-cdl-s -cdl-U -edif-f

182

Introduction to Hercules HLVS The Schematic Netlist File

Argument -edif-globalNets netName ... -edif-p -edif-pa -edif-U -sp-fopen model_name ... -sp-fshort model_name ...

Description List of EDIF global nets.

Convert EDIF properties. Convert all EDIF properties. Convert edif input to upper case. Filter-out devices with specific model-name. Filter-out R&C devices with specific modelname, the two pins will be shorted. To filter out devices with specific inst_name (accept wildcard '*'). Filters out parasitic resistors. Define the order of the output ports from Verilog to Spice. Device property multiplication factor. Set '.options scale=1u' Set name of top cell. Add ports to Spice/CDL topcell portslist. Must use option -sp-topCell to specify topcell. Convert spice input to upper case. Voltage source threshold value for shorts. Verilog global ground net. Verilog global power net. Retain backlashes on verilog net names. Convert verilog input to upper case.

-sp-finst inst_name

...

-sp-fp delimiter -sp-od pattern

-sp-m number -sp-S -sp-topCell cell -sp-topCellPorts portName

-sp-U -sp-voltThresh number -verilog-b0 netName -verilog-b1 netName -verilog-R -verilog-U

183

Introduction to Hercules HLVS The Schematic Netlist File

Argument -verilog-busLSB -acct -acctFile file -dup -equiv file -forceGlobalsOn -herc-globalNets netName ... -logFile file

Description Verilog bus starts with least significant bit (0) first. Write accounting file nettran.acct. Write accounting file file. Choose the nearest one of duplicate cells. Output skeletal equivalence filename. Forced global ports connect to global nets. List of Hercules global nets.

NetTran summary log filename. (default is nettran.log) Expand M property in Hercules netlist. List of messages to upgrade to error. Include message ID in message. List of messages to suppress reporting. Print message table and exit. Prefix for names used in output netlist (default is NT_ ). Do not flatten cell to instantiate parameters Set root cell for netlist output. Use slash (/) as the hierarchical delimiter. Write undefined cells to the file undef.log. Dissolved Nets log filename. Output netlist type: edif, edif3, spice, verilog, milkyway, and hercules (default).

-mprop -msgError NTR-# ... -msgId -msgSuppress NTR-# ... -msgTable -namePrefix prefix

-noflatten -rootCell cell -slash -undef -wireLog file -outType netlist_type

184

Introduction to Hercules HLVS The Schematic Netlist File

Argument -outName file

Description Output netlist name.

Executing NetTran by Specifying a SCHEMATIC_FORMAT

The second way to execute NetTran is by specifying a SCHEMATIC_FORMAT other than Hercules in the Hercules runset. You then use the NETTRAN_OPTIONS variable (under the OPTIONS section in the Hercules runset) to specify the NetTran options necessary to translate your netlist. This way of executing NetTran is shown in Example 27. Example 27 Hercules Schematic Netlist Format
{NETLIST DATBIDIR {VERSION 1 0 0} {PROP_DEFAULT} {CELL INVA {PORT IN OUT} {INST $1I1=N {PROP L=1}{PROP {PIN OUT=D IN=G {INST $1I2=P {PROP L=1}{PROP {PIN VDD=D IN=G }

W=13} GND=S GND=VBB}} W=20.5} OUT=S VDD=VBB}}

{CELL DATBIDIR {PORT DIN DIO DOUT EN} {INST $1I10=INVA {PIN DIN=IN $1N15=OUT}} {INST $1I11=INVA {PIN DIO=IN $1N34=OUT}} {INST $1I3=N {PROP L=1}{PROP W=13} {PIN DIO=D $1N23=G GND=S GND=VBB}} {INST $1I4=P {PROP L=1}{PROP W=20.5} {PIN VDD=D $1N19=G DIO=S VDD=VBB}} {INST $1I49=INVA {PIN $1N15=IN $1N17=OUT}} {INST $1I5=NAND2 {PIN $1N19=QN $1N17=A $1N66=B}} {INST $1I50=INVA {PIN $1N74=IN $1N66=OUT}}

185

Introduction to Hercules HLVS The Schematic Netlist File

{INST $1I51=INVA {PIN $1N34=IN DOUT=OUT}} {INST $1I53=INVA {PIN $1N34=IN DOUT=OUT}} {INST $1I55=NOR2 {PIN $1N23=QN $1N74=A $1N17=B}} {INST $1I61=INVA {PIN EN=IN $1N74=OUT}} } {CELL NAND2 {PORT QN A B} {INST $1I1=N {PROP L=1}{PROP W=13} {PIN $1N20=D A=G GND=S GND=VBB}} {INST $1I25=N {PROP L=1}{PROP W=13} {PIN QN=D B=G $1N20=S GND=VBB}} {INST $1I3=P {PROP L=1}{PROP W=20.5} {PIN VDD=D B=G QN=S VDD=VBB}} {INST $1I4=P {PROP L=1}{PROP W=20.5} {PIN VDD=D A=G QN=S VDD=VBB}} } {CELL NOR2 {PORT QN A B} {INST $1I1=N {PROP L=1}{PROP W=13} {PIN QN=D A=G GND=S GND=VBB}} {INST $1I2=N {PROP L=1}{PROP W=13} {PIN QN=D B=G GND=S GND=VBB}} {INST $1I3=P {PROP L=1}{PROP W=20.5} {PIN $1N5=D B=G QN=S VDD=VBB}} {INST $1I4=P {PROP L=1}{PROP W=20.5} {PIN VDD=D A=G $1N5=S VDD=VBB}} } }

186

Introduction to Hercules HLVS The EDTEXT File

The EDTEXT File

The Edtext file, optional for Hercules LVS, contains a list of text placements to be included in the extracted layout netlist, along with the text found in the layout. The text is specified for a specific structure and (x, y) coordinate. Comments enclosed by /* */ are allowed in this file, but nested comments are not. Blank lines are allowed. After the structure, there are four numbers. They are the values for layer number, data type, x-coordinate, and y-coordinate. Example 28 EDTEXT File Syntax
STRUCTURE lowdec8 VDD 28 0 2.5 46.5 VDD 28 0 2.5 132.5 STRUCTURE meddec8 VDD 28 0 2.5 -590.5 VDD 28 0 2.5 -418.5 VDD 28 0 2.5 -246.5 VDD 28 0 2.5 -74.5 VDD 28 0 2.5 528.5 VDD 28 0 2.5 356.5 VDD 28 0 2.5 700.5 VDD 28 0 2.5 183.5 .................. DATA OMITTED .................... STRUCTURE ce64kd BL0 30 0 2.5 5.5 BLN0 30 0 10.5 5.5 BL128 30 0 1666.5 5.5 BLN128 30 0 1673.5 5.5 WL255 25 0 13 3.5 WL127 25 0 13 2755.5 VDD 28 0 2.5 21.5 VDD 28 0 2.5 2773.5

The layer number and data type must be the same as those in a corresponding ASSIGN section TEXT entry. The data type defaults to zero (0). The x- and ycoordinate values should be the absolute local coordinates within the named structure where the text is placed. The path to the Edtext input file must be specified in the runset file OPTIONS section with the EDTEXT option. An EDTEXT text placement option at the exact coordinates of an existing layout text placement overrides the layout text placement.

187

Introduction to Hercules HLVS The Equivalence File

The Equivalence File

The Equivalence file, optional for Hercules LVS, contains a list of EQUIV or BLACK_BOX command entries that associate schematic block (cell) names and layout block (cell) names. These entries determine which schematic block to compare to which layout block. (BLACK_BOX is discussed later.) Comments enclosed by /* */ are allowed in this file, but nested comments are not. Blank lines are allowed. Hercules reads the equivalence file entries during the second phase, the hierarchical schematic to layout netlist comparison. If there are specific COMPARE options that apply only to specific cells, you can turn these on or off in the equivalence file. This file is optional. Hercules LVS automatically creates this file if you do not supply it. Example 29 shows sample the equivalence file syntax. Example 29 Equivalence File Example
/* Equivalence File Example for DAC96 */ /* EQUIV schematic_cell = layout_cell { options } */ EQUIV COREHI=corehi {} EQUIV CORELOW=corelow {} EQUIV CS_ADD1=cs_add {} EQUIV IBUF=IPAD {} EQUIV ADD4=add4 {} EQUIV OBUF=OPAD {} EQUIV IOBUF=IOBUF {} EQUIV INVA = inva {} EQUIV NOR2 = nor2 {} .................. DATA OMITTED .................... EQUIV DOUT8=dout8 {} EQUIV RAM64K=ram64k {} EQUIV RAM128K=ram128k {}

Running Hercules LVS

Now that we have explained the contents of the runset file, schematic netlist, edtext file, and equivalence file, you need to run the runset as a check against the design example, dac96.

188

Introduction to Hercules HLVS Running Hercules LVS

How to run Hercules LVS

Be sure that you are in the directory where your dac96lvs1.ev file is located, your_path/tutorial/dac96lvs1/. Enter the commend: hercules dac96lvs1.ev Your active window displays the execution process. While the screen contents might scroll quickly (freeze the screen with Control-s and restart with Controlq), you should be able to notice any specific actions or warnings that appear. All of this information appears in a file for your examination. The sample runset file should take only a few minutes to run.

Run File Results

Now that you have run the dac96lvs1.ev file, take a look in the dac96lvs1 directory and see the files Hercules has added. You find some files that always appear, and others that appear depending on the statements in your runset file. To get a directory listing similar to the one in Example 30, enter the command: ls -R Example 30 Directory Listing After Running Hercules
DAC96.LAYOUT_ERRORS DAC96.LVS_ERRORS DAC96.RESULTS DAC96.net compare dac96 compare: DAC96 Device IOBUF IPAD / buf4x4 buf4x8 corehi corelow dac96.eqv dac96.gds dac96.hrc dac96.text dac96_out dac96_out.tf mux mux16 mux4 nand2 dac96lvs1.ev dac96lvs1_gds.ev group hercules.log.01_06_15_18 run_details

or3_ga or3b or3c pc_256

........... SOME FILES IN THIS DIRECTORY OMITTED .......... bsel bsel8 bsel_a1 bsel_a2 buf4x invc latr lowdec8 meddec8 membidir nor3c or2 or2_ga or2b or2c wdec256 xfer

189

Introduction to Hercules HLVS Running Hercules LVS

compare/DAC96: lay.DAC96 sch.DAC95 compare/IOBUF: lay.IOBUF sch.IOBUF compare/IPAD: lay.IPAD sch.IBUF

sum.DAC95.DAC96 sum.IOBUF.IOBUF sum.IBUF.IPAD

.......... SUBDIRECTORIES OF compare/ OMITTED .......... compare/xfer: lay.xfer sch.XFER group: dac96_out HOUT lib run_details: DAC96.acct DAC96.bbox DAC96.cmperr DAC96.bbox lvsflow sum.XFER.xfer

lib_1 DAC96.cmpsum DAC96.sum DAC96.tech DAC96.cmpsum

lib_bck DAC96.tree0 DAC96.vcell DAC96.tree1 evaccess DAC96.tree3 lvsflow evaccess DAC96.tech DAC96.tree1 DAC96.vcell

run_details/evaccess: DAC96 DAC96.errstr DAC96.errbin DAC96.ev

DAC96.msg DAC96.net

VA.libs

run_details/evaccess/DAC96: #1 #3 #5 #7 #2 #4 #6 #8 . run_details/lvsflow: lay.tree sch.tree

#9 cellTOC

compare viewTOC

.................. DATA OMITTED ....................

What if Your Output Is Not Correct?

If your directory does not match the one shown in Example 30, refer to this list of possible problems and solutions. If you have a problem that is not listed here, contact Synopsys support. Problem: Licensing error appears in your block.RESULTS or hercules.RESULTS file.

190

Introduction to Hercules HLVS Overview of Hercules LVS

Solution: Refer to the FLEXlm documentation in the your_path/doc/ps/flexlm or your_path/html/flexuser directories for instructions on verifying your license daemon. -------------------------------------------------------------------Problem: License daemon is activated incorrectly. Solution: Check your license file to make sure you have an active Hercules LVS license in your Synopsys license. -------------------------------------------------------------------Problem: You get a message saying you do not have permission to write. Solution: Check your licensing rights. -------------------------------------------------------------------Problem: You get a message saying that the disk is full. Solution: Check your disk space. Hercules requires 70 MB of disk space. -------------------------------------------------------------------Problem: You get an error writing a file, but your disk is not full. Solution: The UNIX variable Descriptors need to be set to 256 to allow Hercules to read and write more than the default of 64 files. To fix this problem, execute the following command in your UNIX shell: descriptors limit 256

Overview of Hercules LVS

Hercules LVS runs in two phases, as described earlier in this chapter. For a better idea of how these phases are executed, we first look at the DAC96.RESULTS file. This file details the following information: version of Hercules path to the executable that was run summary of the class of checks (for example, DRC or LVS) overall runtime for your entire Hercules job

In Example 31, notice the two major phases of the Hercules LVS job emphasized), as well as the minor phase (netlist file generation).

191

Introduction to Hercules HLVS Overview of Hercules LVS

Be sure to verify the path of your Hercules executable in the log file to ensure that you are accessing the latest software you installed. Example 31 DAC96.RESULTS File
Hercules (R) Hierarchical Design Verification, Release DATA OMITTED Synopsys. All rights reserved. Called as: hercules dac96lvs1.ev - Parsing runset "dac96lvs1.ev" ... DONE - Checking input conditions ... DONE The EV_ENGINE EXECUTABLE is run during the Device Extraction phase of LVS - Performing DRC checks and/or device extraction ... DONE No layout errors The EV_NETLIST executable is run during the netlist file generation - Outputting Hercules netlist ... DONE The LSH executable is run during the comparison phase of LVS - Performing layout vs schematic comparison ... DONE No LVS errors Hercules Run: Time= Hercules is done. 0:02:24 User=93.71 System=13.18

Each step in the Hercules LVS run represents a separate executable, which was called by the Hercules executable. For DRC or device extraction, Hercules calls the ev_engine executable. For netlisting, Hercules calls ev_netlist. For comparing the netlists, Hercules calls lsh. During the Hercules LVS job it is important to be aware of these stages, so that if there is an error or problem with your job you know which error file to look in for the details of the error. Also, each of these stages can be run independently. We go through examples of running the individual stages later in this chapter and in Chapter 8, HLVS Advanced Concepts.. In the next two sections of our Tutorial we discuss output files associated with the Hercules LVS Device Extraction phase of the job, including netlisting, and then the Hercules LVS comparison phase of the job. Keep in mind that we

192

Introduction to Hercules HLVS Overview of Hercules LVS

review all of these files to make you aware of the information available to you as a user. In the next chapter we show you user interfaces that take you through these files automatically, so you do not have to memorize all of this information.

LVS Device Extraction Output Files

The first group of output files we review are those associated with the device extraction from the layout and generating the layout netlist. The executable running during this phase is ev_engine, the same executable used for Hercules DRC. Because of this, most of the output files are the same as those we explained in Chapter 2. Review that chapter if you have not already done so. We only briefly describe the files that are the same as those in Chapter 2, An Error-Free Design for DRC. We go into detail for the files that are unique to LVS Device Extraction or have unique entries for LVS Device Extraction.

DAC96.LAYOUT_ERRORS
The design block that was run generates this error file during the LVS Extraction stage. In this example, we specified DAC96 in the HEADER section of the dac96lvs1 runset file. We have no errors, so the DAC96.LAYOUT_ERRORS file contents are minimal, containing only some repeated runset information (shown in Example 32). This file contains all texting errors, including shorts, opens, and unused text. This file also contains any device extraction error messages. For example, if, during the extraction, Hercules could find only the gate layer of a PMOS device, this file would show an error of missing terminals for that device. We review these types of errors in the Chapter 9, Hercules HLVS Debugging, example. Example 32 DAC96.LAYOUT_ERRORS File (No Errors)
LAYOUT ERRORS RESULTS: CLEAN # # # #### # # # # #### ##### ##### ## # # # # # ## # #### ###### # # # # # # # ## ##### # # # #

=============================================================== Library name: dac96 Structure name: DAC96

193

Introduction to Hercules HLVS Overview of Hercules LVS

ERROR SUMMARY ERROR DETAILS

DAC96.acct
The design block that was run generates this accounting file, listing all devices successfully extracted during the Hercules job. The block.acct file is located in the run_details directory. Notice, in Example 33, that the devices are listed hierarchically or under each sub-block where they were found. At the end of the file is a summary of all of the devices found in the design. Each total listed under the sub-blocks has a cell level count, the devices extracted from that block, a flat count, the devices extracted from the block, plus all of the devices extracted in each sub-block placed under the hierarchy of the block. For example, AND3 might have a placement of NAND3 and INVA, each containing designed devices. The count reported in the AND3 cell level is 0, because there are no devices in AND3. The count reported for the flat count is the combined total of devices in NAND3 and INVA. The final information in this file is the number of filtered devices. By default, Hercules tries to filter devices during the device extraction phase based on the options in the EQUATE commands. This option is called MOS_FILTER and is set in the PMOS or NMOS commands. The default for this option is TRUE if filtering is specified in the EQUATE and COMPARE sections of the runset. The accounting file lists how many devices were filtered from each block. One of our filtering options was to filter all devices that contain a floating pin. During this device extraction phase, Hercules was able to filter 148 NMOS devices and 4 PMOS devices from the layout before it generated a layout netlist. The main advantage to this step is seen in gate array or ROM style devices. In many cases, thousands of floating devices are extracted from unprogrammed regions. By filtering at this stage of the job, Hercules saves time and disk space by not netlisting them, and also saves time during the comparison stage because it does not have to read in all of these devices and operate on them. For more information on the MOS_FILTER option, see the Hercules Reference Manual. Example 33 DAC96.acct File
cellpwr Cell Level Device Counts DIODE[ndio] = 0 RES[rp] = 0 NMOS[n] = 0 PMOS[p] = 0

194

Introduction to Hercules HLVS Overview of Hercules LVS

Flat Device Counts DIODE[ndio] = 0 RES[rp] = 0 NMOS[n] = 0 PMOS[p] = 0 cellpwr2 Cell Level Device Counts DIODE[ndio] = 0 RES[rp] = 0 NMOS[n] = 0 PMOS[p] = 0 Flat Device Counts DIODE[ndio] = 0 RES[rp] = 0 NMOS[n] = 0 PMOS[p] = 0 PADVIA Cell Level Device Counts DIODE[ndio] = 0 RES[rp] = 0 NMOS[n] = 0 PMOS[p] = 0 Flat Device Counts DIODE[ndio] = 0 RES[rp] = 0 NMOS[n] = 0 PMOS[p] = 0 ........................ DATA OMITTED ......................... ram64k Cell Level Device Counts DIODE[ndio] = 0 RES[rp] = 0 NMOS[n] = 0 PMOS[p] = 0 Flat Device Counts DIODE[ndio] = 0 RES[rp] = 0 NMOS[n] = 264881 PMOS[p] = 133601 ram128k Cell Level Device Counts DIODE[ndio] = 0 RES[rp] = 0 NMOS[n] = 0 PMOS[p] = 0 Flat Device Counts DIODE[ndio] = 0

195

Introduction to Hercules HLVS Overview of Hercules LVS

RES[rp] = 0 NMOS[n] = 530282 PMOS[p] = 267722 corelow Cell Level Device Counts DIODE[ndio] = 0 RES[rp] = 0 NMOS[n] = 5Filtered: NMOS-8 = 4 PMOS[p] = 2Filtered: PMOS-8 = 4 Flat Device Counts DIODE[ndio] = 0 RES[rp] = 0 NMOS[n] = 533255Filtered: NMOS-8 = 4 PMOS[p] = 270644Filtered: PMOS-8 = 4 corehi Cell Level Device Counts DIODE[ndio] = 0 RES[rp] = 0 NMOS[n] = 0 PMOS[p] = 0 Flat Device Counts DIODE[ndio] = 0 RES[rp] = 0 NMOS[n] = 532648 PMOS[p] = 270088 DAC96 Cell Level Device Counts DIODE[ndio] = 0 RES[rp] = 0 NMOS[n] = 0 PMOS[p] = 0 ******** DEVICE EXTRACTION STATS TOPBLOCK = DAC96 DIODE[ndio] = 144 RES[rp] = 144 NMOS[n] = 1068927Filtered: NMOS-8 = 148 PMOS[p] = 546060Filtered: PMOS-8 = 4 *******

DAC96.sum
The summary file located in the run_details directory also gets its name from the block we specified (DAC96). The summary file contains information about the steps Hercules executed during the device extraction and netlisting phase of the LVS job. It also shows the resources used in each step. The summary file repeats much of the information that appeared in the runset file, plus a full list of options in the various runset sections, complete with user and default settings.

196

Introduction to Hercules HLVS Overview of Hercules LVS

Example 34 shows the summary file DAC96.sum, which you should have in your directory after your Hercules run is completed. Various sections of the summary file are explained using emphasis. Many of the sections are the same as the ones reviewed in Chapter 2, An Error-Free Design for DRC, of this manual. Only the sections unique to a Hercules LVS job are explained in detail. For more detail on the other sections, refer to Chapter 2. Example 34 DAC96.sum File (No Errors)
Hercules (R) Hierarchical Design Verification, Release DATA OMITTED Synopsys. All rights reserved. The information here shows the source of Hercules, followed by the command you typed to process the runset, "hercules dac96lvs1.ev." Called as: hercules dac96lvs1.ev DATE OMITTED The following line shows the version of EV_Engine used to run the Device Extraction. This is the same executable used for DRC. All polygon processing is done with EV_Engine. The naming convention for each release of this executable is as follows: year.quarter.compile#. If there is a patch release, the naming convention changes to: year.quarter.patch#.compile# EV_Engine (R) Hierarchical Design Rule Checker, Release DATA OMITTED Synopsys, Inc. All rights reserved. Running Multi-Threaded code with 2 thread(s) Notice that the following information shows the names of the input and output files as well as the sources and destinations of each. Runset file ...................... dac96lvs1.ev Current Directory ................ /remote/wwas1/hercules/venu/ HERCULES_DOC/tutor/TUTORIAL_LAB/Getting_Started_Hercules_LVS/ dac96lvs1 Hostname ......................... sunserv1 Platform type .................... SUN64_58 MILKYWAY input library path ...... /remote/wwas1/hercules/venu/ HERCULES_DOC/tutor/TUTORIAL_LAB/Getting_Started_Hercules_LVS/ dac96lvs1/ MILKYWAY input file name ......... dac96 MILKYWAY block name .............. DAC96

197

Introduction to Hercules HLVS Overview of Hercules LVS

MILKYWAY output library path ..... /remote/wwas1/hercules/venu/ HERCULES_DOC/tutor/TUTORIAL_LAB/Getting_Started_Hercules_LVS/ dac96lvs1/ MILKYWAY output file name ........ dac96_out MILKYWAY output_block name ....... EV_OUTPUT Run details ...................... /remote/wwas1/hercules/venu/ HERCULES_DOC/tutor/TUTORIAL_LAB/Getting_Started_Hercules_LVS/ dac96lvs1/run_details Group file directory ............. /remote/wwas1/hercules/venu/ HERCULES_DOC/tutor/TUTORIAL_LAB/Getting_Started_Hercules_LVS/ dac96lvs1/group Retain group files ............... smart Check reference structures ....... yes The OPTIONS section lists the settings you used to analyze and display data, including the default setting your runset did not alter. Notice that the EDTEXT file path is listed here. OPTIONS { ALL_TEXT_GLOBAL=FALSE ASCII_ONLY=FALSE ATTACH_TEXT=ALL BOX_CORNER=FALSE CHECK_REF_LIB=TRUE COUNT_TRAPS=FALSE EDTEXT=/remote/wwas1/hercules/venu/HERCULES_DOC/tutor/ TUTORIAL_LAB/Getting_Started_Hercules_LVS/dac96lvs1/dac96.text ERR_LIMIT_PER_CHECK = UNLIMITED ERR_PREFIX = ERR EXPLODE_AREFS=FALSE EXPLODE_HOLDING_CELL_LIMIT=0 EXPLODE_LIMIT=0 FLAG_ALL_AREF_ERRORS=FALSE FLAT_COUNT=FALSE FLAT_ERROR=FALSE GENERATE_INSTANCE_NAME=TRUE HIERARCHICAL_DELIMITER = \ IGNORE_CASE=FALSE INCREMENTAL_CELLS=FALSE INCREMENTAL_CELLS_FILE = INSTANCE_PREFIX = LAYOUT_GROUND = { GND VSSIO } LAYOUT_POWER = { VDD VDDIO } NET_PREFIX = XX_ SELECT_CELL_TO_NO_EXPLODE=TRUE EQUIV_TO_NO_EXPLODE=TRUE SCHEMATIC_TO_NO_EXPLODE=TRUE BLACK_BOX_TO_NO_EXPLODE=TRUE PROTOTYPE_PLACEMENTS=FALSE

198

Introduction to Hercules HLVS Overview of Hercules LVS

NO_MERGE=FALSE GENERATE_INSTANCE_NAME=TRUE PRINT_ERRSUM_FILE=TRUE MAXIMUM_CELLNAME_LENGTH=32 SCHEMATIC_GLOBAL = { VDD GND VDDIO VSSIO } SCHEMATIC_GROUND = { GND VSSIO } SCHEMATIC_POWER = { VDD VDDIO } SIZE_ENDPOINTS=FALSE SNAP_RES=TRUE SQUARE_CORNER=FALSE STOP_ON_GROUP_ERROR=TRUE TEXT_RECT=0.000 USE_EXPLODED_TEXT=FALSE EXPLORER_DATA=TRUE WIDTH=0.000 MAGNIFICATION_FACTOR=1.000 OUTPUT_MAGNIFICATION_FACTOR=1.000 POLYGON_COUNT_IN_ASSIGN = FALSE FLAT_POLYGON_COUNT = FALSE } The PREPROCESS OPTIONS allow you to specify printing information on Hercules efficiency at processing the design hierarchy, as well as to set options for path grid checking. This section lists all available options. PREPROCESS_OPTIONS { CELL_PROFILE = FALSE CELL_PROFILE_CNT=20 CHECK_PATH_ENDPOINTS = TRUE CHECK_PATH_45 = TRUE CHECK_PATH_90 = FALSE DESIGN_STATS = TRUE TREE = TRUE CELL_STATS = TRUE PRINT_PREPROCESS_FILES = TRUE } The TECHNOLOGY OPTIONS are the default hierarchy optimization options for a Hercules LVS job. We did not change any of these options in our runset. TECHNOLOGY_OPTIONS { VIA_AUTO_EXPLODE = TRUE SUBLEAF_AUTO_EXPLODE = 6 ALLOW_EXPLODE_WITH_TEXT = TRUE POST_VCELL_EXPLODE_CELL_SIZE <= 10 EXPLODE_CELL_SIZE_PERCENT = 70 CELL_SIZE_AUTO_EXPLODE <= 10

199

Introduction to Hercules HLVS Overview of Hercules LVS

EXPLODE_AREFS = FALSE EXPLODE_1XN_AREFS = FALSE EXPLODE_DATA_CELL_LIMIT = 4 POST_VCELL_EXPLODE_DATA_CELL_LIMIT = 12 EXPLODE_CELL_SIZE_PERCENT_OF_TOP = 70 EXPLODE_BIG_SPARSE_CELL = TRUE EXPLODE_HOLDING_CELL_LIMIT = 1 EXPLODE_PLACEMENT_LIMIT = 1 } EVACCESS OPTIONS are used for error viewing with EXPLORER. EVACCESS_OPTIONS { PATH = /remote/wwas1/hercules/venu/HERCULES_DOC/tutor/ TUTORIAL_LAB/Getting_Started_Hercules_LVS/dac96lvs1/ run_details/evaccess LIBRARY = DAC96 CREATE_MSG_VIEW = TRUE CREATE_NETLIST_VIEW = TRUE CREATE_XREF_VIEW = TRUE CREATE_GRAF_VIEW = TRUE } ASSIGN { NDIFF(1) PDIFF(2) NWELL(3) POLY (5) text(25) CONT (6) M1 (8) text(28) V1 (9) M2 (10) text(30) PAD (15) text(35) DIFF (1-2) RESP (50)} TEXT_OPTIONS { ATTACH_TEXT = ALL } DATATYPE_OFFSET=FALSE. There will be no datatype difference between FRAM and CEL views. Using existing technology table! Input Library Format: 127 char cellnames Output Library Format: No output library Preprocessing group files... Warning #190: Adding default TECHNOLOGY_OPTIONS. You can look in the DAC96.tech file to see what options were used. NOTE: If no options are specified, Hercules uses the default values for the TECHNOLOGY options, as explained previously.

200

Introduction to Hercules HLVS Overview of Hercules LVS

During a Hercules LVS run, if you supply an equivalence file, the TECHNOLOGY_OPTIONS section automatically places all layout cells listed as equivalence points in a NO_EXPLODE list. This guarantees that all of the layout cells you want to have as equivalence points are not exploded or flattened due to cell size and that they will appear in your layout netlist. Preprocess Step 1 : Exploding EQUIV_TO_NO_EXPLODE changed 84 cells to NO_EXPLODE Preprocessing time = 0:00:05 User=2.45 Sys=0.24 Mem=22.044 TECHNOLOGY_OPTIONS { VCELL_PASS { STYLE = PAIRS ITERATE_MAX = 15 ARRAY_ID = TRUE EXPLODE_INTO_VCELL = FALSE MIN_COUNT = 20 TOP_PERCENT_OF_VALUE = 40 } } Preprocess Step 2 : Vcell_pass Arrays and Pairs Iteration 1 Pairs time = 0:00:00 User=0.00 Sys=0.00 Mem=10.998 VCELL_PASS 1, no changes. Combined VCELL time = 0:00:01 User=0.11 Sys=0.05 Mem=11.138

Preprocess Step 3 : Post-VCell Explodes Post VCell time = 0:00:00 User=0.00 Sys=0.00 Mem=9.967 Performing grid check for path end points... 0 grid violations found. 0 non-45 violations found. Grid Check time = 0:00:00 User=0.02 Sys=0.01 Mem=9.967 The following section creates layer-specific information to be used by Hercules when processing commands stored in the group directory. Creating group files... Create time = 0:00:01 User=0.35 Sys=0.14 Mem=18.637

Sorting group files... Sort time = 0:00:00 User=0.29 Sys=0.05 Mem=21.621 Checking database:

201

Introduction to Hercules HLVS Overview of Hercules LVS

The following are the commands that generate the layers used for the designed device extraction and connectivity. A processing wall time, CPU time, system time (I/O or other non-CPU events), and memory usage is given for each command. Also, the "unique polygons written" number gives you a hierarchical, not a flat, count. If you encounter a command that takes a long time to run relative to the rest of the commands in your runset and has a relatively high unique polygon count, these two things combined could indicate a poor hierarchical design or poor hierarchy processing for your design. BOOLEAN PDIFF AND NWELL { } TEMP=pdev 38 unique polygons written. Check time = 0:00:00 User=0.03 Sys=0.02 Mem=18.754 BOOLEAN NDIFF NOT NWELL { } TEMP=ndev 44 unique polygons written. Check time = 0:00:00 User=0.03 Sys=0.01 Mem=18.910 BOOLEAN PDIFF NOT NWELL { } TEMP=subtie 32 unique polygons written. Check time = 0:00:00 User=0.02 Sys=0.02 Mem=18.972 BOOLEAN NDIFF AND NWELL { } TEMP=welltie 47 unique polygons written. Check time = 0:00:00 User=0.03 Sys=0.01 Mem=18.894 BOOLEAN POLY AND ndev { } TEMP=ngate 156 unique polygons written. Check time = 0:00:00 User=0.04 Sys=0.02 Mem=19.941 BOOLEAN POLY AND pdev { } TEMP=pgate 143 unique polygons written. Check time = 0:00:00 User=0.03 Sys=0.01 Mem=19.988 BOOLEAN ndev NOT ngate { } TEMP=nsd 210 unique polygons written. Check time = 0:00:00 User=0.03 Sys=0.00 Mem=21.144 smart delete of "ndev" BOOLEAN pdev NOT pgate { } TEMP=psd 186 unique polygons written. Check time = 0:00:00 User=0.03 Sys=0.00 Mem=21.159 smart delete of "pdev" BOOLEAN POLY NOT ngate { } TEMP=temp_field 335 unique polygons written.

202

Introduction to Hercules HLVS Overview of Hercules LVS

Check time = 0:00:00

User=0.05 Sys=0.01 Mem=21.159

BOOLEAN temp_field NOT pgate { } TEMP=tmp_field_poly 426 unique polygons written. Check time = 0:00:00 User=0.05 Sys=0.01 Mem=20.191 smart delete of "temp_field" BOOLEAN tmp_field_poly AND RESP { } TEMP=rpoly 1 unique polygon written. Check time = 0:00:00 User=0.01 Sys=0.03 Mem=19.050 BOOLEAN tmp_field_poly NOT rpoly { } TEMP=field_poly 427 unique polygons written. Check time = 0:00:00 User=0.02 Sys=0.01 Mem=19.159 smart delete of "tmp_field_poly" SELECT field_poly TOUCHING rpoly {}TEMP=res_term 2 unique polygons written. Check time = 0:00:00 User=0.09 Sys=0.03 Mem=22.362 SELECT NDIFF INTERACT POLY {}TEMP=nodiode 45 unique polygons written. Check time = 0:00:00 User=0.07 Sys=0.03 Mem=23.456 BOOLEAN NDIFF NOT nodiode { } TEMP=pos_ndiffdio 35 unique polygons written. Check time = 0:00:00 User=0.03 Sys=0.01 Mem=20.315 smart delete of "nodiode" BOOLEAN pos_ndiffdio NOT NWELL { } TEMP=ndiffdio 1 unique polygon written. Check time = 0:00:00 User=0.04 Sys=0.00 Mem=20.347 The following is the DIODE extraction command. The number of "unique" devices extracted is a hierarchical count. For a flat count, you will need to look in the DAC96.acct file. If there were any extraction errors, you would get a message below the DIODE command in this summary file. The rest of the device extraction commands follow. smart delete of "pos_ndiffdio" DIODE ndio ndiffdio ndiffdio SUBSTRATE { DIODE_TYPE=NP;} TEMP=ndiode Extracted 1 unique device with model name ndio. Extracted 1 unique 2-terminal device.

203

Introduction to Hercules HLVS Overview of Hercules LVS

Check time = 0:00:01

User=0.26 Sys=0.14 Mem=24.487

RES rp rpoly res_term res_term { EV_RESVAL = 1; } TEMP=pdevice Extracted 1 unique device with model name rp. Extracted 1 unique 2-terminal device. Check time = 0:00:01 User=0.24 Sys=0.14 Mem=21.518 Notice that even though this design has over 1.5 million devices, Hercules has to extract only 148 NMOS and 109 PMOS devices. This shows that the design has very good hierarchy. NMOS n ngate nsd nsd SUBSTRATE { /* EQUATE_FILTER_OPTIONS = { NMOS-3, NMOS-8 }; */ MOS_CALC_NRS_NRD=TRUE;} TEMP=ndevice Extracted 148 unique devices with model name n. Extracted 148 unique 4-terminal devices. Check time = 0:00:01 User=0.54 Sys=0.21 Mem=29.814 PMOS p pgate psd psd NWELL { /* EQUATE_FILTER_OPTIONS = { PMOS-3, PMOS-8 }; */ MOS_CALC_NRS_NRD=TRUE;} TEMP=pdevice Extracted 109 unique devices with model name p. Extracted 109 unique 4-terminal devices. Check time = 0:00:01 User=0.48 Sys=0.24 Mem=31.923 The next two sections show the CONNECT and TEXT commands that were executed, with runtime and memory usage. CONNECT { ngate pgate BY [ OVERLAP TOUCH ] field_poly M2 BY [ OVERLAP TOUCH ] PAD M1 M2 BY [ OVERLAP TOUCH ] V1 M1 ndiffdio res_term field_poly nsd psd welltie subtie BY [ OVERLAP TOUCH ] CONT NWELL BY [ OVERLAP TOUCH ] welltie SUBSTRATE BY [ OVERLAP TOUCH ] subtie } Check time = 0:00:02 User=1.85 Sys=0.07 Mem=40.219 TEXT { M1 BY M1.TEXT M2 BY M2.TEXT field_poly BY POLY.TEXT PAD BY PAD.TEXT NWELL BY "VDD" SUBSTRATE BY "GND" }

204

Introduction to Hercules HLVS Overview of Hercules LVS

Check time = 0:00:00 Check time = 0:00:00 Check time = 0:00:00 Check time = 0:00:00 Check time = 0:00:00 Check time = 0:00:00

User=0.03 Sys=0.04 Mem=28.799 User=0.03 Sys=0.02 Mem=28.799 User=0.01 Sys=0.02 Mem=25.767 User=0.01 Sys=0.01 Mem=24.767 User=0.01 Sys=0.00 Mem=23.799 User=0.00 Sys=0.00 Mem=23.799 User=0.18 Sys=0.17 Mem=33.783

Total Text time = 0:00:00

PROCESS_TEXT_OPENS is a command that is run by default when the NETLIST or GRAPHICS command appears in the runset. It is run prior to these commands and checks for text opens and shorts. It also merges nets with identical text. PROCESS_TEXT_OPENS {} Completed opens check. Now merging/renaming nets based on text. Check time = 0:00:01 User=0.31 Sys=0.01 Mem=23.440 Connecting devices ... Device Connect time = 0:00:04 User=0.82 Sys=1.18 Mem=28.064

The GRAPHICS_NETLIST command writes the device layer and connectivity layer data to an output database with property information. This is used by EXPLORER for debug, or it can be read into any layout editor for manual debug. We specified EXPLORER_LAYERS (100). Hercules automatically determines all of the device and connectivity layers necessary to create a complete database, starts numbering the layers with 100, and outputs them. The summary is where you need to look to see which layers are associated with each output layer number. EXPLORER does this layer-to-number association automatically for you; if you are doing it manually in a layout editor, you will need to refer to this summary file. GRAPHICS_NETLIST { EXPLORER_LAYERS (100) SUBSTRATE (100) subtie (101) welltie (102) field_poly (103) psd (104) pgate (105) ndevice (106)

205

Introduction to Hercules HLVS Overview of Hercules LVS

nsd (107) ngate (108) pdevice (109) res_term (110) rpoly (111) ndiode (112) ndiffdio (113) NDIFF (1) PDIFF (2) NWELL (3) POLY (5) PAD (15) RESP (50) M1 (8) M2 (10) CONT (6) V1 (9)} GRAPHICS_PROPERTY { NET_NAME (1) INSTANCE_NAME (4) } Writing Graphics Netlist The following is a summary of the time and memory it took to write the graphics netlist. You should write it to a local disk if this database is large. Check time = 0:00:22 User=5.13 Sys=6.77 Mem=38.044

The Hercules ev_netlist executable must read the connectivity database that is created below. If this database is created successfully, but for some reason your NETLIST command does not complete, you can rerun the following Hercules command to generate your block.net file: >hercules -N dac96lvs1.ev Creating netlisting connect database ... Check time = 0:00:02 User=0.84 Sys=0.60 Mem=45.032 Generating BLOCK.acct file ... Check time = 0:00:00 User=0.01 Sys=0.02 Mem=35.798 Checks complete. Total check time = 0:00:37 User=11.93 Sys=9.87 Mem=45.032

Here is the total time and the maximum memory used for the Device Extraction phase of the run, including checks, preprocessing, and outputting data. This time is only for the EV_Engine executable. Overall ev_engine time = 0:01:12 User=39.47 Sys=10.94 Mem=45.032

206

Introduction to Hercules HLVS Overview of Hercules LVS

The next section of the summary file gives information on the EV_NETLIST executable that Hercules calls. This step generates the DAC96.net layout netlist file. EV_NETLIST (R) Stand-alone netlist generator, Release V2003.12.0062 2003/10/30 (C) Copyright 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003. Synopsys, Inc. All rights reserved. Generating NETLIST file "DAC96.net". Once the netlist is written to an output file, you get a summary of the total runtime and memory usage for this executable. Netlisting time = 0:00:14 User=12.07 Sys=0.45 Mem=0.000

DAC96.net
At the end of the Device Extraction phase and netlisting, Hercules generates an ASCII text file of the layout netlist. This is always the top block name followed by a .net extension. In our design it is DAC96.net. This netlist is a Herculesformatted netlist representing the graphical input data based on the device definition and connectivity specified in the Hercules runset.

Tree Files and Technology Option Files

The remainder of the files generated during the Device Extraction phase of the Hercules LVS job are DAC96.tree0, DAC96.tree1, DAC96.tree3, DAC96.tech, and DAC96.vcell. These are all similar to the files detailed in Chapter 2. Refer to that explanation of these files if you have not already done so.

LVS Comparison Output Files

The second group of output files we review are those associated with the comparison of the DAC96.net layout netlist file and the DAC96.hrc schematic netlist file. The executable running during this phase is lsh. Because this is the first time we have presented them in the tutorial, we go into detail on these files.

207

Introduction to Hercules HLVS Overview of Hercules LVS

DAC96.LVS_ERRORS
The DAC96.LVS_ERRORS file, shown in Example 35, is a summary of major problems found in the Hercules LVS job. This file is linked to the HTML debug interface to direct you through the various comparison debug files. In our example, because we had no comparison errors, the file is just a statement to that effect. Example 35 DAC96.LVS_ERRORS File
TOP BLOCK COMPARE RESULTS: PASS ##### ## ##### # # # # # ##### ###### ##### # # # # # # # ##### ##### # ##### # #####

[DAC95 == DAC96] =============================================================== Comparison completed with 84 successful equivalencies. Comparison completed with 0 equivalence error. =============================================================== (DBG-0) Schematic and layout agree at all equivalent points. No further debugging necessary.

DAC96.cmpsum
The DAC96.cmpsum file located in the run_details directory is a summary file of the commands executed by the lsh executable. It is similar to the DAC96.sum file generated by the ev_engine executable. In the COMPARE summary files shown in Example 36, we have emphasized the major operations performed by Hercules during the time lsh is running. This file summarizes the second phase of the Hercules LVS job, the LVS comparison of the two netlists. Example 36 DAC96.cmpsum - Comparison Summary File
HLVS (R) Hierarchical Layout Versus Schematic, Release DATA OMITTED Synopsys. All rights reserved. Call as: lsh -s /remote/wwas1/hercules/venu/HERCULES_DOC/tutor/ TUTORIAL_LAB/Getting_Started_Hercules_LVS/dac96lvs1/dac96.hrc -Q -E DAC96.cmperr -S DAC96.cmpsum -b DAC96 dac96lvs1.ev

208

Introduction to Hercules HLVS Overview of Hercules LVS

The following information shows the names of the input files and their sources. It also shows all of the default COMPARE option settings, as well as the settings from your runset. ** Environment Status ** Hostname = sunserv1 Platform type = SUN64_58 runset = dac96lvs1.ev root = DAC96 layout_file = DAC96.net schematic_file = /remote/wwas1/hercules/venu/HERCULES_DOC/tutor/ TUTORIAL_LAB/Getting_Started_Hercules_LVS/dac96lvs1/dac96.hrc equivalence_file = /remote/wwas1/hercules/venu/HERCULES_DOC/tutor/ TUTORIAL_LAB/Getting_Started_Hercules_LVS/dac96lvs1/dac96.eqv compare_dir = compare evaccess library = DAC96 evaccess path = run_details/evaccess advance_symmetry_resolution auto_exclude_equiv combine_output_files detect_permutable_ports equate_by_net_name explode_on_error find_additional_equivs gate_recognition matched_ports_continue merge_parallel merge_series one_connection_warning parallel_merge_ratio property_errors_continue push_down_devices remove_dangling_nets restrict_merge_by_width restrict_parallel_merging require_texted_nets_match require_texted_ports_match retain_new_data schematic_vs_schematic stop_on_error static_equated_nets use_total_width = = = = = = = = = = = = = = = = = = = = = = = = = TRUE TRUE FALSE TRUE TRUE TRUE FALSE FALSE FALSE TRUE FALSE FALSE FALSE FALSE TRUE TRUE FALSE FALSE FALSE FALSE TRUE FALSE FALSE TRUE FALSE all_ports_texted = calculate_class = compare_properties = equate_by_device_name = equiv_by_name = FALSE filter = find_duplicate_equivs = match_by_property = memory_array_comparison = merge_paths = merge_series_gates = optional_pins = port_swap_on_top_block = property_warning = push_down_pins = restrict_merge_by_length= restrict_merge_series = restrict_series_merging = FALSE FALSE TRUE FALSE TRUE FALSE FALSE TRUE FALSE FALSE TRUE FALSE FALSE TRUE FALSE FALSE FALSE

retain_previous_data = FALSE short_equivalent_nodes = FALSE stop_on_no_explode_error = FALSE text_resolves_port_swap = TRUE write_netlists = TRUE

209

Introduction to Hercules HLVS Overview of Hercules LVS

zero_connection_warning evaccess_create_msg evaccess_create_xref ignore_case net_print_limit merge_net_warning merge_paths_device_limit tolerance_device_count

= = = = = = = =

FALSE TRUE TRUE FALSE 10 100 [none] [none]

evaccess_create_netlist explorer_data property_tolerance merge_net_error tolerance_net_count

= TRUE = TRUE = 0.10 = 1000 = [none]

The following functions are preprocessing and formatting performed by the Hercules lsh executable, before the comparison of the individual cells. Purging Compare Directory ... OK Reading schematic netlist ... generating EVaccess netlist data ... OK Reading layout netlist ... OK Processing schematic netlist ... OK Propagating schematic globals ... OK Processing layout netlist ... OK Removing dangling nets and pushing down connected pins ... OK Pushing down devices ... Warning: Shared devices found Please refer to DAC96.lvsdebug and *.cmperr file...OK Removing empty schematic cells ... OK Removing empty layout cells ... OK Removing empty schematic cells ... OK Removing empty layout cells ... OK Preprocessing schematic data ... OK Preprocessing layout data ... OK Total Preprocess Time = 0:00:03 User=1.00 Sys=0.35 Mem=12.088 Once all of the layout and schematic is read and preprocessed, Hercules starts at the lowest level cell and begins to compare blocks. Each time Hercules advances up a level in the hierarchy a new LEVEL title will appear. **** LEVEL 10 **** A summary of each layout and schematic block is written to this file, including the elapsed compare time, CPU (user) time and total memory used to compare the blocks. Later in this chapter we will review what the partitioned schematic and partitioned layout look like. Notice that after "Comparing" you have the message "OK." If there were problems with the block you might receive a "WARNING" or an "ERROR" message. Schematic = SENSEAMP, Layout = senseamp, Level = 10

210

Introduction to Hercules HLVS Overview of Hercules LVS

Partitioning schematic ... OK Partitioning layout ... OK Checking for swappable ports ... none found. Comparing ... OK Summary File: compare/senseamp/sum.SENSEAMP.senseamp Elapsed time = 0:00:00 User=0.03 Sys=0.00 Mem=11.256 Schematic = NOR3B, Layout = nor3c, Level = 10 Partitioning schematic ... OK Partitioning layout ... OK Checking for swappable ports ... none found. Comparing ... OK Summary File: compare/nor3c/sum.NOR3B.nor3c Elapsed time = 0:00:00 User=0.01 Sys=0.00 Mem=11.709 Schematic = NOR3B, Layout = nor3_gacell, Level = 10 Partitioning schematic ... OK Partitioning layout ... OK Comparing ... OK Summary File: compare/nor3_gacell/sum.NOR3B.nor3_gacell Elapsed time = 0:00:00 User=0.01 Sys=0.00 Mem=11.740 Schematic = NOR2B, Layout = nor2c, Level = 10 Partitioning schematic ... OK Partitioning layout ... OK Checking for swappable ports ... none found. Comparing ... OK Summary File: compare/nor2c/sum.NOR2B.nor2c Elapsed time = 0:00:00 User=0.01 Sys=0.01 Mem=11.740 Schematic = NOR2B, Layout = nor2_gacell, Level = 10 Partitioning schematic ... OK Partitioning layout ... OK Comparing ... OK Summary File: compare/nor2_gacell/sum.NOR2B.nor2_gacell Elapsed time = 0:00:00 User=0.00 Sys=0.00 Mem=11.771 ............................ DATA OMITTED .......................... Schematic = BSEL, Layout = bsel, Level = 10 Partitioning schematic ... OK Partitioning layout ... OK Comparing ... OK Summary File: compare/bsel/sum.BSEL.bsel Elapsed time = 0:00:00 User=0.00 Sys=0.00 Mem=11.958

211

Introduction to Hercules HLVS Overview of Hercules LVS

Schematic = BSEL, Layout = bsel_a1, Level = 10 Partitioning schematic ... OK Partitioning layout ... OK Comparing ... OK Summary File: compare/bsel_a1/sum.BSEL.bsel_a1 Elapsed time = 0:00:00 User=0.01 Sys=0.00 Mem=11.958 After Hercules has completed all of the blocks at a given "Level," a summary of the equivalent and nonequivalent blocks is given. In our example all blocks compare. The equal signs (==) always indicate a successful comparison, as defined by your COMPARE option settings. Equivalent blocks: level 10 SENSEAMP == senseamp NOR3B == nor3c NOR3B == nor3_gacell NOR2B == nor2c NOR2B == nor2_gacell XFER == xfer NAND3B == nand3c NAND3B == nand3_gacell INVA == invb INVA == inva NOR2 == nor2b NOR2 == nor2 INVB == invc INVB == inv_gacell NOR3 == nor3b NAND2B == nand2c NAND2B == nand2_gacell PRECHRG == prechrg NAND2 == nand2b NAND2 == nand2 NAND3 == nand3b NAND3 == nand3 BSEL == bsel_a2 BSEL == bsel BSEL == bsel_a1 Level 10 time = 0:00:02 User=0.23 Sys=0.16 Mem=11.958 **** LEVEL 9 **** Schematic = IOBUF, Layout = IOBUF, Level = 9 Partitioning schematic ... OK Partitioning layout ... OK

212

Introduction to Hercules HLVS Overview of Hercules LVS

Checking for swappable ports ... none found. For the IOBUF block, a WARNING is reported. This block will still remain as a compared block and will not be exploded into its parent. Only blocks with ERRORS are exploded. You can control whether certain comparison violations are WARNINGS or upgrade them to ERRORS, causing the block to miscompare and be exploded into the parent. This skill is covered later in the tutorial. Comparing ... WARNINGS WARNING: Device type with no Check_Properties Summary File: compare/IOBUF/sum.IOBUF.IOBUF Elapsed time = 0:00:00 User=0.02 Sys=0.00 Mem=11.974 ............................ DATA OMITTED .......................... **** LEVEL 4 **** Schematic = DOUT8, Layout = dout8, Level = 4 Partitioning schematic ... OK Partitioning layout ... OK Comparing ... WARNINGS Summary File: compare/dout8/sum.DOUT8.dout8 Elapsed time = 0:00:00 User=0.07 Sys=0.00 Mem=18.654 Equivalent blocks: level 4 DOUT8 == dout8 Level 4 time = 0:00:00 User=0.08 Sys=0.00 Mem=18.841 **** LEVEL 3 **** Schematic = RAM64K, Layout = ram64k, Level = 3 Partitioning schematic ... OK Partitioning layout ... OK Comparing ... WARNINGS WARNING: Matches were assumed Summary File: compare/ram64k/sum.RAM64K.ram64k Elapsed time = 0:00:03 User=2.53 Sys=0.10 Mem=23.819 Equivalent blocks: level 3 RAM64K == ram64k Level 3 time = 0:00:04 User=2.54 Sys=0.10 Mem=23.819 **** LEVEL 2 **** Schematic = RAM128K, Layout = ram128k, Level = 2

213

Introduction to Hercules HLVS Overview of Hercules LVS

Partitioning schematic ... OK Partitioning layout ... OK Checking for swappable ports ... none found. Comparing ... OK Summary File: compare/ram128k/sum.RAM128K.ram128k Elapsed time = 0:00:00 User=0.03 Sys=0.00 Mem=20.590 Equivalent blocks: level 2 RAM128K == ram128k Level 2 time = 0:00:00 User=0.03 Sys=0.00 Mem=20.590 **** LEVEL 1 **** Schematic = CORELOW, Layout = corelow, Level = 1 Partitioning schematic ... OK Partitioning layout ... OK Checking for swappable ports ... none found. Comparing ... OK Summary File: compare/corelow/sum.CORELOW.corelow Elapsed time = 0:00:00 User=0.14 Sys=0.00 Mem=20.761 Schematic = COREHI, Layout = corehi, Level = 1 Partitioning schematic ... OK Partitioning layout ... OK Checking for swappable ports ... none found. Comparing ... WARNINGS WARNING: Matches were assumed WARNING: Net match warning Summary File: compare/corehi/sum.COREHI.corehi Elapsed time = 0:00:00 User=0.15 Sys=0.00 Mem=20.995 Equivalent blocks: level 1 CORELOW == corelow COREHI == corehi Level 1 time = 0:00:00 User=0.30 Sys=0.01 Mem=20.995 When you reach "LEVEL 0," you are at the top block. In our example, the top block, DAC96 (layout) and DAC95(schematic), compares with WARNINGS. **** LEVEL 0 **** Schematic = DAC95, Layout = DAC96, Level = 0 Partitioning schematic ... OK Partitioning layout ... OK Comparing ... WARNINGS WARNING: Net match warning WARNING: Device type with no Check_Properties

214

Introduction to Hercules HLVS Overview of Hercules LVS

Summary File: compare/DAC96/sum.DAC95.DAC96 Elapsed time = 0:00:00 User=0.09 Sys=0.00 Mem=20.762 Equivalent blocks: DAC95 == DAC96 level 0

The last section of the summary file is a summary of blocks that compared with WARNINGS and without WARNINGS, and blocks that did not compare. **** SUMMARY COMPARE RESULTS **** Compare messages printed: WARNING: Matches were assumed [DATBIDIR, datbidir] [BUF4X, buf4x] [RAM64K, ram64k] [COREHI, corehi] WARNING: Net match warning [COREHI, corehi] [DAC95, DAC96] WARNING: Device type with no Check_Properties [IOBUF, IOBUF] [OBUF, OPAD] [IBUF, IPAD] [DAC95, DAC96] Equivalent blocks: SENSEAMP == senseamp (level 10) NOR3B == nor3c (level 10) NOR3B == nor3_gacell (level 10) NOR2B == nor2c (level 10) NOR2B == nor2_gacell (level 10) XFER == xfer (level 10) NAND3B == nand3c (level 10) NAND3B == nand3_gacell (level 10) INVA == invb (level 10) INVA == inva (level 10) NOR2 == nor2b (level 10) NOR2 == nor2 (level 10) INVB == invc (level 10) INVB == inv_gacell (level 10) NOR3 == nor3b (level 10) NAND2B == nand2c (level 10) NAND2B == nand2_gacell (level 10) PRECHRG == prechrg (level 10)

215

Introduction to Hercules HLVS Overview of Hercules LVS

NAND2 == nand2b (level 10) NAND2 == nand2 (level 10) NAND3 == nand3b (level 10) NAND3 == nand3 (level 10) BSEL == bsel_a2 (level 10) BSEL == bsel (level 10) BSEL == bsel_a1 (level 10) IOBUF == IOBUF (level 9) MEMBIDIR == membidir (level 9) PC_8 == pc_8_l_endcell (level 9) PC_8 == pc_8 (level 9) PC_8 == pc_8_r_endcell (level 9) DATBIDIR == datbidir (level 9) AND3B == and3_ga (level 9) AND2B == and2_ga (level 9) AND2B == and2c (level 9) OR2B == or2c (level 9) AND3B == and3c (level 9) OR3B == or3_ga (level 9) OR3B == or3c (level 9) OR2B == or2_ga (level 9) MUX == mux (level 9) LATR == latr (level 9) BUF4X == buf4x (level 9) AND2 == and2b (level 9) AND3 == and3b (level 9) AND3 == and3 (level 9) OR2 == or2b (level 9) OR2 == or2 (level 9) OR3 == or3b (level 9) BSEL_8 == bsel8 (level 9) CS_ADDB == cs_add_ovlp (level 8) CS_ADDB == cs_add_ga (level 8) SAMP1 == samp1_a1 (level 8) SAMP1 == samp1 (level 8) DFFR == dffr (level 8) ADR2DEC4 == adr2dec4 (level 8) MUX_4 == mux4 (level 8) CS_ADD1 == cs_add (level 8) OBUF == OPAD (level 8) IBUF == IPAD (level 8) PC_64 == pc_64_l_endcell (level 8) PC_64 == pc_64 (level 8) PC_64 == pc_64_r_endcell (level 8) BUF4X4 == buf4x4 (level 8)

216

Introduction to Hercules HLVS Overview of Hercules LVS

LOWDEC_8 == lowdec8 (level 8) ADD4B == add4_ovlp (level 7) ADD4B == add4_ga (level 7) ADR3DEC8 == adr3dec8 (level 7) DFFR4 == dffr4 (level 7) SAMP4 == samp4 (level 7) MUX_16 == mux16 (level 7) ADD4 == add4 (level 7) PC_256 == pc_256 (level 7) BUF4X8 == buf4x8 (level 7) MEDDEC_8 == meddec8 (level 7) DOUT1 == dout1 (level 6) DFFR16 == dffr16 (level 6) WDEC_256 == wdec256 (level 6) DOUT4 == dout4 (level 5) DOUT8 == dout8 (level 4) RAM64K == ram64k (level 3) RAM128K == ram128k (level 2) CORELOW == corelow (level 1) COREHI == corehi (level 1) DAC95 == DAC96 (level 0) Next is a list of the number of successful equivalences and equivalence errors. Because all of our blocks compared, we have 0 equivalence errors. It is possible to have a successful comparison with some equivalence errors. A sub-block might not compare, but if the parent of that block compares when the sub-block is exploded, your top block might still compare. This information should be used simply to judge how much hierarchy you were able to maintain during your comparison. Comparison completed with 84 successful equivalencies. Comparison completed with 0 equivalence errors. The total compare time (wall time), CPU time (user), and total memory are summarized here. Total Compare Time = 0:00:37 User=23.60 Sys=1.40 Mem=23.819

The bottom of the comparison summary file shows the status of the LVS Extraction error file. In many cases, when the comparison phase of your Hercules LVS job fails, you immediately want to debug the run using the output files of the netlist comparison. You should always make sure the device extraction phase of your Hercules LVS job completes without errors before you spend too much time debugging the second phase. The statement here is to remind you whether you had any errors in the device extraction phase, which are reported in the DAC96.LAYOUT_ERRORS file.

217

Introduction to Hercules HLVS Overview of Hercules LVS

No errors listed in "DAC96.LAYOUT_ERRORS"

DAC96.cmperr
The DAC96.cmperr file, located in the run_details directory, contains a more detailed summary of the processes performed by the LVS COMPARE operation and more detail on the runtime of each process. Be aware that this file is not equivalent to the block.LAYOUT_ERRORS file in the extraction process. It is not the file that holds all of the error information. The error information for individual equivalence points is found under the compare/ directory, which we discuss in greater detail later in the tutorial. In the Compare Summary Error file in Example 37, additional information found in this file that is not found in the DAC96.cmpsum file is emphasized. Example 37 DAC96.cmperr - COMPARE Summary Error File
HLVS (R) Hierarchical Layout Versus Schematic, Release DATA OMITTED Synopsys, Inc. All rights reserved. The entire netlist processing phase of the COMPARE run is given in more detail here. Runtimes and memory use for all the individual processes are listed, as well as information about what has occurred. Reading schematic netlist ... generating EVaccess netlist data ... OK Reading Schematic Time = 0:00:01 User=0.13 Sys=0.14 Mem=6.339 Reading layout netlist ... OK Reading Layout Time = 0:00:01 User=0.22 Sys=0.01 Mem=8.718 Processing schematic netlist ... OK Propagating schematic globals ... Propagate Schematic Globals Time = 0:00:00 User=0.01 Sys=0.00 Mem=8.960 Processing layout netlist ... OK Netlist root: DAC95 Cell count: 74 Netlist root: DAC96 Cell count: 115 Removing dangling nets and pushing down connected pins ... OK Dangling/PushDown Time = 0:00:00 User=0.19 Sys=0.00 Mem=11.018 Pushing down devices ... Warning: Shared devices found Please refer to DAC96.lvsdebug and *.cmperr file... Layout: Shared Device : cs_add_ovlp/M12 Cell : nor2c BULK : VDD DRN : XX_20

218

Introduction to Hercules HLVS Overview of Hercules LVS

SRC GATE Cell : and2c BULK DRN SRC GATE Layout: Shared Device : Cell : nor2c BULK DRN SRC GATE Cell : and2c BULK DRN SRC GATE

: : : : : :

XX_17 VDD VDD OUT XX_7 VDD

cs_add_ovlp/M3 : : : : : : : : GND XX_23 XX_21 GND GND XX_13 OUT GND

............................ DATA OMITTED .......................... Cell : and2c BULK : GND DRN : XX_13 SRC : OUT GATE : GND OK PushDown Device Time = 0:00:00 User=0.07 Sys=0.00 Mem=12.088 Removing empty schematic cells ... Removing Empty Schematic Cells Time = 0:00:01 User=0.00 Sys=0.00 Mem=11.075 Here is an example of the fact that more detail is listed in the .cmperr file. As the compare process reads in the netlists and processes the hierarchy, all empty cells are removed from the hierarchy, with their connections placed in their parent. The compare engine compares devices and their connection. If a cell has no devices, it is considered empty and "exploded" into its parent. This occurs in the layout and schematic netlist and is a multipass process. Removing empty layout cells ... WARNING: Deleting empty cell 'VSSIOPAD' WARNING: Deleting empty cell 'VDDCRPAD'

219

Introduction to Hercules HLVS Overview of Hercules LVS

WARNING: Deleting empty cell 'cellpwr2' WARNING: Deleting empty cell 'VDDIOPAD' WARNING: Deleting empty cell 'cellpwr' WARNING: Deleting empty cell 'temp_pwr_route' WARNING: Deleting empty cell 'VSSCRPADv WARNING: Deleting empty cell 'PADVIA' WARNING: Deleting empty cell 'ldec8con' WARNING: Deleting empty cell 'IOVIA' Removing Empty Layout Cells Time = 0:00:00 User=0.11 Sys=0.00 Mem=11.215 Removing empty schematic cells ... WARNING: Deleting empty cell 'CE8X8' WARNING: Deleting empty cell 'CE32X32' WARNING: Deleting empty cell 'MEMORY' WARNING: Deleting empty cell 'CE64K' WARNING: Deleting empty cell 'CE16K' WARNING: Deleting empty cell 'CE2X2' WARNING: Deleting empty cell 'CE4X4' WARNING: Deleting empty cell 'CE64X64' WARNING: Deleting empty cell 'CE16X16' Removing Empty Schematic Cells Time = 0:00:00 User=0.00 Sys=0.01 Mem=10.778 Removing empty layout cells ... WARNING: Deleting empty cell 'ce16k_3' WARNING: Deleting empty cell 'PADVIA' WARNING: Deleting empty cell 'cell_hlding' WARNING: Deleting empty cell 'ce16x16_2' WARNING: Deleting empty cell 'ce64x64_2' WARNING: Deleting empty cell 'ce16x16_3' WARNING: Deleting empty cell 'ce64x64_3' WARNING: Deleting empty cell 'VSSIOPAD' WARNING: Deleting empty cell 'ce4x4_2' WARNING: Deleting empty cell 'ce4x4_3' WARNING: Deleting empty cell 'VSSCRPAD' WARNING: Deleting empty cell 'cellpwr2' WARNING: Deleting empty cell 'ce8x8_2' WARNING: Deleting empty cell 'ce8x8_3' WARNING: Deleting empty cell 'ldec8con' WARNING: Deleting empty cell 'temp_pwr_route' WARNING: Deleting empty cell 'IOVIA' WARNING: Deleting empty cell 'ce64kd' WARNING: Deleting empty cell 'VDDIOPAD' WARNING: Deleting empty cell 'ce2x2_2' WARNING: Deleting empty cell 'ce2x2_3' WARNING: Deleting empty cell 'ce32x32_2' WARNING: Deleting empty cell 'ce32x32_3'

220

Introduction to Hercules HLVS Overview of Hercules LVS

WARNING: Deleting empty cell 'cell_no_ovlp' WARNING: Deleting empty cell 'VDDCRPAD' WARNING: Deleting empty cell 'cellpwr' Removing Empty Layout Cells Time = 0:00:00 User=0.00 Sys=0.00 Mem=10.778 Preprocessing schematic data ... OK Preprocessing layout data ... OK Total Preprocess Time = 0:00:03 User=1.00 Sys=0.35 Mem=12.088 **** LEVEL 10 **** Schematic = SENSEAMP, Layout = senseamp, Level = 10 Partitioning schematic = SENSEAMP Partitioning Time = 0:00:00 User=0.00 Sys=0.00 Mem=10.639 Partitioning layout = senseamp Partitioning Time = 0:00:00 User=0.01 Sys=0.00 Mem=10.654 Comparing ... OK Summary File: compare/senseamp/sum.SENSEAMP.senseamp Elapsed time = 0:00:00 User=0.03 Sys=0.00 Mem=11.256 Schematic = NOR3B, Layout = nor3c, Level = 10 Partitioning schematic = NOR3B Partitioning Time = 0:00:00 User=0.00 Sys=0.00 Mem=11.709 Partitioning layout = nor3c Partitioning Time = 0:00:00

User=0.00 Sys=0.00 Mem=11.232

Comparing ... OK Summary File: compare/nor3c/sum.NOR3B.nor3c Elapsed time = 0:00:00 User=0.01 Sys=0.00 Mem=11.709 ............................ DATA OMITTED .......................... Schematic = BSEL, Layout = bsel_a2, Level = 10 Partitioning schematic = BSEL Partitioning Time = 0:00:00 User=0.00 Sys=0.00 Mem=11.927 Partitioning layout = bsel_a2 Partitioning Time = 0:00:00 User=0.01 Sys=0.00 Mem=11.435 Comparing ... OK Summary File: compare/bsel_a2/sum.BSEL.bsel_a2 Elapsed time = 0:00:00 User=0.01 Sys=0.00 Mem=11.927

221

Introduction to Hercules HLVS Overview of Hercules LVS

Schematic = BSEL, Layout = bsel, Level = 10 Partitioning schematic = BSEL Partitioning Time = 0:00:00 User=0.00 Sys=0.00 Mem=11.958 Partitioning layout = bsel Partitioning Time = 0:00:00

User=0.00 Sys=0.00 Mem=11.466

Comparing ... OK Summary File: compare/bsel/sum.BSEL.bsel Elapsed time = 0:00:00 User=0.00 Sys=0.00 Mem=11.958 Schematic = BSEL, Layout = bsel_a1, Level = 10 Partitioning schematic = BSEL Partitioning Time = 0:00:00 User=0.00 Sys=0.00 Mem=11.958 Partitioning layout = bsel_a1 Partitioning Time = 0:00:00 User=0.01 Sys=0.00 Mem=11.466 Comparing ... OK Summary File: compare/bsel_a1/sum.BSEL.bsel_a1 Elapsed time = 0:00:00 User=0.01 Sys=0.00 Mem=11.958 Equivalent blocks: level 10 SENSEAMP == senseamp NOR3B == nor3c NOR3B == nor3_gacell NOR2B == nor2c NOR2B == nor2_gacell XFER == xfer NAND3B == nand3c NAND3B == nand3_gacell INVA == invb INVA == inva NOR2 == nor2b NOR2 == nor2 INVB == invc INVB == inv_gacell NOR3 == nor3b NAND2B == nand2c NAND2B == nand2_gacell PRECHRG == prechrg NAND2 == nand2b NAND2 == nand2 NAND3 == nand3b NAND3 == nand3

222

Introduction to Hercules HLVS Overview of Hercules LVS

BSEL == bsel_a2 BSEL == bsel BSEL == bsel_a1 **** LEVEL 9 **** Schematic = IOBUF, Layout = IOBUF, Level = 9 Partitioning schematic = IOBUF Partitioning Time = 0:00:00 User=0.01 Sys=0.00 Mem=11.974 Partitioning layout = IOBUF Exploding instances of cell "p60" Partitioning Time = 0:00:00 User=0.00 Sys=0.00 Mem=11.482 Comparing ... WARNINGS WARNING: Device type with no Check_Properties Summary File: compare/IOBUF/sum.IOBUF.IOBUF Elapsed time = 0:00:00 User=0.02 Sys=0.00 Mem=11.974 ............................ DATA OMITTED .......................... **** LEVEL 3 **** Schematic = RAM64K, Layout = ram64k, Level = 3 Partitioning schematic = RAM64K Partitioning Time = 0:00:01 User=0.91 Sys=0.01 Mem=23.569 Partitioning layout = ram64k Partitioning Time = 0:00:01 User=1.00 Sys=0.01 Mem=23.819 Comparing ... WARNINGS WARNING: Matches were assumed Summary File: compare/ram64k/sum.RAM64K.ram64k Elapsed time = 0:00:03 User=2.53 Sys=0.10 Mem=23.819 Equivalent blocks: level 3 RAM64K == ram64k **** LEVEL 2 **** Schematic = RAM128K, Layout = ram128k, Level = 2 Partitioning schematic = RAM128K Partitioning Time = 0:00:00 User=0.01 Sys=0.00 Mem=20.590 Partitioning layout = ram128k

223

Introduction to Hercules HLVS Overview of Hercules LVS

Partitioning Time = 0:00:00

User=0.00 Sys=0.00 Mem=20.145

Comparing ... OK Summary File: compare/ram128k/sum.RAM128K.ram128k Elapsed time = 0:00:00 User=0.03 Sys=0.00 Mem=20.590 Equivalent blocks: level 2 RAM128K == ram128k **** LEVEL 1 **** Schematic = CORELOW, Layout = corelow, Level = 1 Partitioning schematic = CORELOW Exploding instances of cell "ADDERB" Exploding instances of cell "DFFR16_EXP" Partitioning Time = 0:00:00 User=0.01 Sys=0.00 Mem=20.637 Partitioning layout = corelow Partitioning Time = 0:00:00 User=0.01 Sys=0.00 Mem=20.207 Comparing ... OK Summary File: compare/corelow/sum.CORELOW.corelow Elapsed time = 0:00:00 User=0.14 Sys=0.00 Mem=20.761 Schematic = COREHI, Layout = corehi, Level = 1 The following equivalence points have been automatically excluded because there are a different number of instances between the schematic and layout, or because they are in the 'exclude_equiv' list for the current equiv point: EQUIV LOWDEC_8 = lowdec8 Partitioning schematic = COREHI Exploding instances of cell "ADDER" Exploding instances of cell "CONTROL" Exploding instances of cell "LOWDEC_8" Partitioning Time = 0:00:00 User=0.01 Sys=0.00 Mem=20.715 Partitioning layout = corehi Partitioning Time = 0:00:00 User=0.01 Sys=0.00 Mem=20.301 Comparing ... WARNINGS WARNING: Matches were assumed WARNING: Net match warning Summary File: compare/corehi/sum.COREHI.corehi Elapsed time = 0:00:00 User=0.15 Sys=0.00 Mem=20.995

224

Introduction to Hercules HLVS Overview of Hercules LVS

Equivalent blocks: level 1 CORELOW == corelow COREHI == corehi **** LEVEL 0 **** Schematic = DAC95, Layout = DAC96, Level = 0 The partitioning phase involves flattening the hierarchy that exists below the current equivalence point; in this case, DAC95 in the schematic. The process flattens all cells that are not previously matched equivalence points. If any cells are flattened, they are listed. This occurs for the schematic and layout. Here you can see that DAC_CORE was flattened in the schematic. IPAD8, OPAD8, OGRP1, and IGRP1 were flattened in the layout. Following the list of removed hierarchy are the runtime and memory for this process. It is important to notice that this removal of hierarchy (flattening) is not permanent (as it is if you explode or flatten a cell in the extraction phase), but only temporary. It applies only to the current equivalence point the Hercules comparison engine is processing. Partitioning schematic = DAC95 Exploding instances of cell "DAC_CORE" Partitioning Time = 0:00:00 User=0.01 Sys=0.00 Mem=20.762 Partitioning Exploding Exploding Exploding Exploding Partitioning layout = DAC96 instances of cell "IPAD8" instances of cell "OPAD8" instances of cell "OGRP1" instances of cell "IGRP1" Time = 0:00:00 User=0.03 Sys=0.00 Mem=19.256

Comparing ... WARNINGS WARNING: Net match warning WARNING: Device type with no Check_Properties Summary File: compare/DAC96/sum.DAC95.DAC96 Elapsed time = 0:00:00 User=0.09 Sys=0.00 Mem=20.762 Equivalent blocks: DAC95 == DAC96 level 0

**** SUMMARY COMPARE RESULTS ****

225

Introduction to Hercules HLVS Overview of Hercules LVS

Compare messages printed: WARNING: Matches were assumed [DATBIDIR, datbidir] [BUF4X, buf4x] [RAM64K, ram64k] [COREHI, corehi] WARNING: Net match warning [COREHI, corehi] [DAC95, DAC96] WARNING: Device type with no Check_Properties [IOBUF, IOBUF] [OBUF, OPAD] [IBUF, IPAD] [DAC95, DAC96] Equivalent blocks: SENSEAMP == senseamp (level 10) NOR3B == nor3c (level 10) NOR3B == nor3_gacell (level 10) NOR2B == nor2c (level 10) NOR2B == nor2_gacell (level 10) XFER == xfer (level 10) NAND3B == nand3c (level 10) NAND3B == nand3_gacell (level 10) INVA == invb (level 10) INVA == inva (level 10) NOR2 == nor2b (level 10) NOR2 == nor2 (level 10) INVB == invc (level 10) INVB == inv_gacell (level 10) NOR3 == nor3b (level 10) NAND2B == nand2c (level 10) NAND2B == nand2_gacell (level 10) PRECHRG == prechrg (level 10) NAND2 == nand2b (level 10) NAND2 == nand2 (level 10) NAND3 == nand3b (level 10) NAND3 == nand3 (level 10) BSEL == bsel_a2 (level 10) BSEL == bsel (level 10) BSEL == bsel_a1 (level 10) IOBUF == IOBUF (level 9) MEMBIDIR == membidir (level 9) PC_8 == pc_8_l_endcell (level 9) PC_8 == pc_8 (level 9)

226

Introduction to Hercules HLVS Overview of Hercules LVS

PC_8 == pc_8_r_endcell (level 9) DATBIDIR == datbidir (level 9) AND3B == and3_ga (level 9) AND2B == and2_ga (level 9) AND2B == and2c (level 9) OR2B == or2c (level 9) AND3B == and3c (level 9) OR3B == or3_ga (level 9) OR3B == or3c (level 9) OR2B == or2_ga (level 9) MUX == mux (level 9) LATR == latr (level 9) BUF4X == buf4x (level 9) AND2 == and2b (level 9) AND3 == and3b (level 9) AND3 == and3 (level 9) OR2 == or2b (level 9) OR2 == or2 (level 9) OR3 == or3b (level 9) BSEL_8 == bsel8 (level 9) CS_ADDB == cs_add_ovlp (level 8) CS_ADDB == cs_add_ga (level 8) SAMP1 == samp1_a1 (level 8) SAMP1 == samp1 (level 8) DFFR == dffr (level 8) ADR2DEC4 == adr2dec4 (level 8) MUX_4 == mux4 (level 8) CS_ADD1 == cs_add (level 8) OBUF == OPAD (level 8) IBUF == IPAD (level 8) PC_64 == pc_64_l_endcell (level 8) PC_64 == pc_64 (level 8) PC_64 == pc_64_r_endcell (level 8) BUF4X4 == buf4x4 (level 8) LOWDEC_8 == lowdec8 (level 8) ADD4B == add4_ovlp (level 7) ADD4B == add4_ga (level 7) ADR3DEC8 == adr3dec8 (level 7) DFFR4 == dffr4 (level 7) SAMP4 == samp4 (level 7) MUX_16 == mux16 (level 7) ADD4 == add4 (level 7) PC_256 == pc_256 (level 7) BUF4X8 == buf4x8 (level 7) MEDDEC_8 == meddec8 (level 7)

227

Introduction to Hercules HLVS Overview of Hercules LVS

DOUT1 == dout1 (level 6) DFFR16 == dffr16 (level 6) WDEC_256 == wdec256 (level 6) DOUT4 == dout4 (level 5) DOUT8 == dout8 (level 4) RAM64K == ram64k (level 3) RAM128K == ram128k (level 2) CORELOW == corelow (level 1) COREHI == corehi (level 1) DAC95 == DAC96 (level 0) Comparison completed with 84 successful equivalencies. Comparison completed with 0 equivalence errors. Total Compare Time = 0:00:37 User=23.60 Sys=1.40 Mem=23.819

Compare Directory Structure

As described earlier in the chapter, Hercules works from the lowest level equivalence points up through the hierarchy, comparing blocks. In our example, a block is either compared successfully and the port connections are saved to be used in the parent block comparison, or the block is compared unsuccessfully and the block is exploded in the context of the schematic and layout netlists, with all devices in the block moved up into the parent for comparison. The compare directory structure contains a subdirectory for each block listed in the equivalence file. In that subdirectory is a summary file for the block as well as the layout and schematic netlist that Hercules compared at that point in the hierarchy. Remember, one of the advantages of a hierarchical verification tool is easy debugging at the cell level, where your error is located, eliminating the need to debug the entire design. As an example, we look at one of the subblocks in the middle of the hierarchy. We are reviewing these files to make you aware of the information they contain. Obviously, if you have many errors, it is cumbersome to work your way through all of these files with no direction. You can easily walk through these files using direction from the HTML interface and Hercules-Explorer. We go through those exercises after we have completely gone through the basics of a Hercules hierarchical comparison. ./compare/membidir/lay.membidir. This file is the cell-level layout netlist for the equivalence point MEMBIDIR and is the Hercules-formatted netlist generated by the Hercules tool during the LVS job. Notice in Example 38 that it

228

Introduction to Hercules HLVS Overview of Hercules LVS

is a flat netlist, where all blocks that successfully compared at a lower level are now only black-box instances. Example 38 lay.membidir: A Cell-Level Layout Netlist
{NETLIST membidir {VERSION 1 0 0} {CELL membidir {PORT GND VDD BL BLB DIO RD DO } {INST M3=n {PROP n="n" x=130.5 y=32 l=1 w=10 } {PIN XX_13=GATE XX_5=SRC BL=DRN GND=BULK }} {INST M1=n {PROP n="n" x=66 y=9.5 l=1 w=13 } {PIN A=GATE DIO=SRC GND=DRN GND=BULK }} {INST nand2_42=nand2 {PROP n="nand2" x=0.5 y=-1 } {PIN VDD=VDD GND=GND XX_14=QN XX_25=A XX_23=B }} {INST inva_47=inva {PROP n="inva" x=85 y=-1 } {PIN VDD=VDD XX_5=Z GND=GND XX_30=A }} {INST inva_45=inva {PROP n="inva" x=109 y=-1 } {PIN VDD=VDD XX_9=Z GND=GND XX_29=A }} {INST inva_43=inva {PROP n="inva" x=-11.5 y=-1 } {PIN VDD=VDD XX_25=Z GND=GND XX_24=A }} {INST inva_41=inva {PROP n="inva" x=30.5 y=-1 } {PIN VDD=VDD XX_23=Z GND=GND XX_13=A }} {INST M4=p {PROP n="p" x=66 y=34.75 l=1 w=20.5 } {PIN XX_14=GATE DIO=SRC VDD=DRN VDD=BULK }} {INST M2=n {PROP n="n" x=130.5 y=15 l=1 w=10 } {PIN XX_13=GATE BLB=SRC XX_9=DRN GND=BULK }} {INST nor2_52=nor2 {PROP n="nor2" x=42.5 y=-1 } {PIN VDD=VDD A=QN XX_25=B XX_13=A GND=GND }} {INST inva_48=inva {PROP n="inva" x=73 y=-1 } {PIN VDD=VDD XX_30=Z GND=GND DIO=A }} {INST inva_46=inva {PROP n="inva" x=97 y=-1 } {PIN VDD=VDD XX_29=Z GND=GND XX_30=A }} {INST inva_44=inva {PROP n="inva" x=-23.5 y=-1 } {PIN VDD=VDD XX_24=Z GND=GND DO=A }} {INST inva_40=inva {PROP n="inva" x=30.5 y=-1 } {PIN VDD=VDD XX_13=Z GND=GND RD=A }} } }

./compare/membidir/sch.MEMBIDIR. This file is the cell-level schematic netlist for the equivalence point MEMBIDIR and is a Hercules-formatted netlist generated by the Hercules tool during the LVS job. Notice in Example 39 that it is a flat netlist, where all blocks that successfully compared at a lower level are now only black-box instances.

229

Introduction to Hercules HLVS Overview of Hercules LVS

Example 39 sch.MEMBIDIR: A Cell-Level Schematic Netlist

{NETLIST MEMBIDIR {VERSION 1 0 0} {CELL MEMBIDIR {PORT BL BLB DIO DO RD GND VDD } {INST $1I4=P {PROP n="P" l=1 w=20.5 } {PIN $1N19=G DIO=S VDD=D VDD=VBB }} {INST $1I2=N {PROP n="N" l=1 w=10 } {PIN $1N43=G $1N47=S BLB=D GND=VBB }} {INST $1I55=NOR2 {PROP n="NOR2" } {PIN VDD=VDD $1N23=QN $1N17=B $1N43=A GND=GND }} {INST $1I53=INVA {PROP n="INVA" } {PIN VDD=VDD $1N45=OUT GND=GND $1N34=IN }} {INST $1I51=INVA {PROP n="INVA" } {PIN VDD=VDD $1N54=OUT GND=GND $1N34=IN }} {INST $1I11=INVA {PROP n="INVA" } {PIN VDD=VDD $1N34=OUT GND=GND DIO=IN }} {INST $1I3=N {PROP n="N" l=1 w=13 } {PIN $1N23=G GND=S DIO=D GND=VBB }} {INST $1I1=N {PROP n="N" l=1 w=10 } {PIN $1N43=G $1N45=S BL=D GND=VBB }} {INST $1I61=INVA {PROP n="INVA" } {PIN VDD=VDD $1N43=OUT GND=GND RD=IN }} {INST $1I52=INVA {PROP n="INVA" } {PIN VDD=VDD $1N47=OUT GND=GND $1N54=IN }} {INST $1I50=INVA {PROP n="INVA" } {PIN VDD=VDD $1N66=OUT GND=GND $1N43=IN }} {INST $1I5=NAND2 {PROP n="NAND2" } {PIN VDD=VDD GND=GND $1N19=QN $1N17=A $1N66=B }} {INST $1I49=INVA {PROP n="INVA" } {PIN VDD=VDD $1N17=OUT GND=GND $1N15=IN }} {INST $1I10=INVA {PROP n="INVA" } {PIN VDD=VDD $1N15=OUT GND=GND DO=IN }} } }

.compare/membidir/sum.MEMBIDIR.membidir. Similar to the summary files we have already discussed, this summary file contains detailed information on the processes performed during the comparison between the layout netlist for MEMBIDIR and the schematic netlist for MEMBIDIR. These files, referred to as sum.block.block files, are the main source of debug information for determining problems in the comparison phase of your LVS job. In the summary files that follow emphasized comments explain the information found in this file.

230

Introduction to Hercules HLVS Overview of Hercules LVS

Example 40 sum.MEMBIDIR.membidir
COMPARE (R) Hierarchical Layout Vs. Schematic Version DATA OMITTED Copyright (C) Synopsys, Inc. All rights reserved. The following information shows the default settings of the COMPARE options, as well as the settings from your runset and equivalence files. If you set an option in the equivalence file that was specific to a particular block, that option setting is shown in the summary file corresponding to that block. all_ports_texted calculate_class compare_properties equate_by_device_name filter match_by_property merge_parallel merge_series one_connection_warning parallel_merge_ratio property_errors_continue push_down_devices remove_dangling_nets require_texted_ports_match restrict_merge_by_width short_equivalent_nodes text_resolves_port_swap zero_connection_warning merge_paths_device_limit tolerance_net_count = = = = = = = = = = = = = = = = = = = = FALSE FALSE TRUE FALSE TRUE FALSE TRUE FALSE FALSE FALSE FALSE TRUE TRUE FALSE FALSE FALSE TRUE FALSE [none] [none] auto_exclude_equiv = combine_output_files = detect_permutable_ports = equate_by_net_name = ignore_case = memory_array_comparison = merge_paths = merge_series_gates = optional_pins = port_swap_on_top_block = property_warning = push_down_pins = require_texted_nets_match= restrict_merge_by_length = restrict_merge_series = static_equated_nets = use_total_width = tolerance_device_count TRUE FALSE TRUE TRUE FALSE TRUE FALSE FALSE TRUE FALSE FALSE TRUE FALSE FALSE FALSE TRUE FALSE

= [none]

The next set of steps outlines the schematic netlist processing that takes place on the specific block that is running. All merging of devices and filtering of unused devices is done, and then a table of the results is shown. The table also shows whether any of the devices in this block were put there when the PUSH_DOWN_DEVICES preprocessing was done on the schematic netlist. In this example, we have 14 total schematic devices and 17 schematic nets before and after merging. Notice that previously compared blocks, such as INVA, are considered devices. Once a sub-block is compared successfully, the comparison algorithm treats it in the same way as a transistor or other designed device; it is simply a device with pins. Filtering Schematic unused devices ...

231

Introduction to Hercules HLVS Overview of Hercules LVS

Removed 0 unused devices. Merging Schematic parallel devices ... Created 0 composite parallel devices. Filtering Schematic unused devices ... Removed 0 unused devices. Checking Schematic port net connections ... Schematic Netlist Statistics for "MEMBIDIR": Initial ------8 3 1 1 1 ------14 Initial ------17 PushDown -------0 0 0 0 0 -------0 PushDown -------0 Filter -----0 0 0 0 0 -----0 Dangle -----0 Parallel -------0 0 0 0 0 -------0 Path/Ser -------0 0 0 0 0 -------0 Final ----8 3 1 1 1 ----14 Final ----17

INVA N NAND2 NOR2 P Total Devices

0 Connect Path/Ser -------- -------0 0

Total Nets

The following is the total time and memory it took for this stage of the COMPARE on the MEMBIDIR block. Merge/Filter Time = 0:00:00 User=0.01 Sys=0.00 Mem=11.497

The next set of steps outlines the layout netlist processing that takes place on the specific block that is running. All merging of devices and filtering of unused devices is done, and then a table of the results is shown. The table also shows whether any of the devices in this block were put there when the PUSH_DOWN_DEVICES preprocessing was done on the layout netlist. In this example, we have 14 total layout devices and 17 layout nets before and after merging. Notice that previously compared blocks, such as INVA, are considered devices. Once a sub-block is compared successfully, the comparison algorithm treats it in the same way as a transistor or other designed device; it is simply a device with pins. Filtering Layout unused devices ... Removed 0 unused devices.

232

Introduction to Hercules HLVS Overview of Hercules LVS

Merging Layout parallel devices ... Created 0 composite parallel devices. Filtering Layout unused devices ... Removed 0 unused devices. Checking Layout port net connections ... Layout Netlist Statistics for "membidir": Initial PushDown Filter Parallel Path/Ser Final ------- -------- ------ -------- -------- ----8 0 0 0 0 8 3 0 0 0 0 3 1 0 0 0 0 1 1 0 0 0 0 1 1 0 0 0 0 1 ------- -------- ------ -------- -------- ----14 0 0 0 0 14 Initial ------17 PushDown -------0 Dangle -----0 0 Connect Path/Ser -------- -------0 0 Final ----17

inva n nand2 nor2 p Total Devices

Total Nets

The following is the total time and memory it took for this stage of the COMPARE on the MEMBIDIR block. Merge/Filter Time = 0:00:00 User=0.00 Sys=0.00 Mem=11.497

The next two sections contain information about swappability of ports Swappable Port Groups: NONE The Post-Merge table gives you a side-by-side listing of the schematic and layout device counts and net counts for the cell. In this example, because there were no errors, the device and net count are identical. Post-Merge Netlist Statistics: Schematic --------8 3 Layout -----8 3

[INVA, (inva, invb)] [N, n]

233

Introduction to Hercules HLVS Overview of Hercules LVS

1 1 1 --------14 17

1 1 1 -----14 17

[NAND2, (nand2, nand2b)] [NOR2, (nor2, nor2b)] [P, p] Total Devices Total Nets

The following is a summary of equated nets that were equated based on the equate_by_net_name option. If this section is empty and you expect to have nets equated by name, you might want to check to make sure your text was properly applied in the Device Extraction phase of the Hercules LVS job. Summary of Equated Nets: BL==BL BLB==BLB DIO==DIO DO==DO GND==GND RD==RD VDD==VDD Initialization Time = 0:00:00 Matching Time = 0:00:00 User=0.00 Sys=0.00 Mem=11.529

User=0.00 Sys=0.00 Mem=11.529

Post-Compare Netlist Statistics summarize the number of matching devices and nets in a cell and indicate which types matched. Post-Compare Netlist Statistics: Matched --------8 3 1 1 1 --------14 17 Schematic Unmatched --------0 0 0 0 0 --------0 0 Layout Unmatched --------0 0 0 0 0 --------0 0

[INVA, (inva, invb)] [N, n] [NAND2, (nand2, nand2b)] [NOR2, (nor2, nor2b)] [P, p] Total Devices Total Nets

234

Introduction to Hercules HLVS Overview of Hercules LVS

If you are comparing properties, the next section is a summary of the property compare time and errors or warnings. Comparing device properties ... Property Compare Time = 0:00:00 User=0.00 Sys=0.00 Mem=11.529

Writing cross-reference entries for port nets ... The last major section of the sum.block.block file is the Port CrossReference Table. This table shows all equated ports in the schematic and layout, as well as their pin class. The Port Cross-Reference Table gives you information on how this sub-block will be viewed when its parent is compared. For example, in the case of MEMBIDIR, a device is created with 7 ports that are all unique in class; therefore, none are swappable. Port Cross-Reference Table: Generated Sch Port --------Generated Lay Port --------Port Class ----4 5 6 1 7 2 3 Sch Net / Lay Net --------BL / BL BLB / BLB DIO / DIO DO / DO GND / GND RD / RD VDD / VDD

The final information in this file is a summary of the runtime and memory for the comparison of the netlists (lay.membidir and sch.membidir), and a total elapsed time and memory for the entire COMPARE process run on MEMBIDIR. Compare only time = 0:00:00 User=0.00 Sys=0.00 Mem=11.591 Elapsed time = 0:00:00 User=0.01 Sys=0.00 Mem=11.990

Notice that the sections containing reports on unmatched devices and nets and matched devices connected to unmatched nets are not included in this sum.block.block file because there are no errors.

235

Introduction to Hercules HLVS Overview of Hercules LVS

./lvsflow Directory Structure

When the comparison phase of a Hercules LVS job must generate certain files not supplied by the user, the lvsflow is used as a working directory for those files. The lvsflow directory is located in the run_details directory. In the example we are now reviewing, all necessary files and options are specified. The optional files and options include a Hercules-formatted netlist (you could input one of the translatable formats), an equivalence file, the EQUATE commands, the SCHEMATIC_GLOBALS, and the COMPARE section of the runset. There are more details about this in Chapter 5 of the Hercules LVS User Guide. If all of the optional information is supplied, the lvsflow directory contains a tree structure of the layout netlist in the lay.tree file, and a tree structure of the schematic netlist in the sch.tree file. These files also include a flat count of all of the cells in the netlist. Sections of these two files are shown in Example 41 and Example 42. Example 41 ./lvsflow/lay.tree - Tree Structure For Layout Netlist
DAC96 Level=0 Count=1 VSSCRPAD Level=1 Count=2 PADVIA Level=2 Count=1 corelow Level=1 Count=1 ram128k Level=2 Count=1 ram64k Level=3 Count=2 wdec256 Level=4 Count=1 meddec8 Level=5 Count=4 lowdec8 Level=6 Count=8 and3 Level=7 Count=8 nand3 Level=8 Count=1 inva Level=8 Count=1 dout8 Level=4 Count=1 dout4 Level=5 Count=2 dout1 Level=6 Count=4 datbidir Level=7 Count=1 inva Level=8 Count=7 nand2 Level=8 Count=1 nor2 Level=8 Count=1 .......................... DATA OMITTED ........................ OPAD8 Level=1 Count=1 OPAD Level=2 Count=8 IOBUF Level=3 Count=1 inva Level=4 Count=5 p60 Level=4 Count=8 PADVIA Level=4 Count=1 IOVIA Level=4 Count=1 IOVIA Level=3 Count=2

236

Introduction to Hercules HLVS Overview of Hercules LVS

CELL STATISTICS TOP CELL = DAC96 Ports CELL = PADVIA Flat Placements CELL = datbidir Flat Placements CELL = samp1_a1 Flat Placements CELL = adr3dec8 Flat Placements = = = = = 0 180 32 32 12

.......................... DATA OMITTED ........................ CELL = nand2b Flat Placements CELL = nand2c Flat Placements CELL = pc_64_l_endcell Flat Placements = = = 48 24 4

Example 42 ./lvsflow/sch.tree - Tree Structure For Schematic Netlist

DAC95 Level=0 Count=1 IBUF Level=1 Count=88 IOBUF Level=2 Count=1 INVA Level=3 Count=5 OBUF Level=1 Count=56 IOBUF Level=2 Count=1 INVA Level=3 Count=5 DAC_CORE Level=1 Count=1 CORELOW Level=2 Count=1 DFFR16 Level=3 Count=6 DFFR4 Level=4 Count=4 INVA Level=5 Count=1 .......................... DATA OMITTED ........................ NOR2 Level=7 Count=1 OR3 Level=6 Count=1 INVA Level=7 Count=1 NOR3 Level=7 Count=1 NOR2 Level=6 Count=2

237

Introduction to Hercules HLVS Progress Review of Hercules LVS

MUX_16 Level=3 Count=3 MUX_4 Level=4 Count=4 MUX Level=5 Count=4 INVA Level=6 Count=3 XFER Level=6 Count=2 INVA Level=5 Count=2 CELL STATISTICS TOP CELL = DAC95 Ports CELL = DFFR4 Flat Placements CELL = XFER Flat Placements = = = 4 68 1312

.......................... DATA OMITTED ........................ CELL = NOR2 Flat Placements CELL = NOR3 Flat Placements CELL = PC_256 Flat Placements = = = 128 16 4

Progress Review of Hercules LVS

Thus far we have reviewed the basics of hierarchical LVS in Hercules, including the input and output files. Many concepts and files were presented in this chapter, because it is important to comprehend the hierarchical concepts and know the resources available for deciphering a Hercules LVS job. It is not necessary, however, to memorize all the available options and debug information in all of the files. Most of what was reviewed in this chapter can be automated, including the debug. We describe how to automate Hercules later in the tutorial, but we want you to be aware of the power of the tool, should you want to customize it to take advantage of its many features.

238

Introduction to Hercules HLVS Whats Next?

Whats Next?
Now that you have reviewed the options and flow of the Hercules LVS tool, you are ready to continue on to Chapter 8, HLVS Advanced Concepts. You learn how to complete a strict Hercules comparison, including downgrading default error messages and upgrading default warning messages. In Chapter 8 you are also introduced to the Hercules HTML interface for debugging your LVS errors.

239

Introduction to Hercules HLVS Whats Next?

240

8
HLVS Advanced Concepts8
In this chapter we discuss, in detail, the concepts used in a strict Hercules LVS comparison, as well as the Hercules LVS advanced options and commands required to make the flow work. We run two examples with a few errors in order to better illustrate the advanced features of Hercules that are used in this flow.

Learning Objectives for This Chapter

To learn a strict LVS flow, where all inputs are defined, port text matching is required, and all equivalence points must match To run an example of a strict LVS flow with errors To learn the Hercules LVS HTML interface for debugging the LVS results To become acquainted with the standard flow for debugging an LVS job

259

HLVS Advanced Concepts Before You Start

Before You Start

Before you start this tutorial, make sure that you have completely gone through the installation and setup procedures described in Chapter 1, Installation and Setup.

General Requirements of a Strict LVS Flow Comparison

Strict LVS flow comparison requires that all equivalence points match, so building the equivalence file takes extra care. Remember that only a very small percentage of Hercules users require an LVS flow as strict as the one described here. The example in this chapter is meant to teach you some of the more complex options available with the Hercules LVS tool. The next chapter is a better example of a typical mainstream LVS flow. Below is a list of the general requirements that must be followed to generate a successful comparison in our strict LVS flow example. Compare the top-block layout ports with the top-block schematic ports Require that all ports be texted and that the layout and schematic port text matches in all blocks Resolve all symmetrical ports with text, so Hercules does not need to resolve the symmetries Match all equivalence points Extract and netlist all devices in the cell that contains the device layer, for example the GATE layer of a MOSFET

Before we execute our Hercules job, we explain how to achieve the requirements listed above, using excerpts from a Hercules runset as our examples. That Hercules runset, dac96lvs2.ev, is also be used for our first example in this chapter.

Comparing Top-Block Ports

By default, no ports are netlisted in the top block of a Hercules layout netlist. You must identify for Hercules the polygons that represent the pins, or top-block ports. Hercules has a command, CREATE_PORTS, that is used to designate these ports, especially for the top block, so that the ports are netlisted. The COMPARE process can then check that ports in the layout netlist match the schematic netlist ports.

260

HLVS Advanced Concepts General Requirements of a Strict LVS Flow Comparison

To designate these ports, define a marker layer in your design. In our design this layer is PAD. The marker layer, or PAD layer, is processed against a connected layer, and the interaction between the marker polygon and the connect layer polygon creates a new port. We use the PAD, layer 15, as the marker layer and the connected layer. In the following example, you notice that PAD is listed in our CONNECT command, so it qualifies as a connected layer. Finally, in order to allow matching of layout port names with the schematic port names, we also make sure that all of the PAD polygons are texted to match the schematic port text. Example 43 shows the command from the dac96lvs2.ev runset we use to generate our ports for comparison. Note: The PAD layer is not located in the top block, DAC96, so we must add the FLATTEN command to flatten all of the PAD polygons to the top block. Example 43 CREATE_PORTS Syntax from Hercules Runset Example dac96lvs2.ev
FLATTEN PAD {cell_list = {*}} temp = PADTOP /* -------------------------------- Define Connectivity Rules */ CONNECT { ngate pgate BY field_poly M2 BY PADTOP M1 M2 BY V1 M1 ndiffdio res_term field_poly nsd psd welltie subtie BY CONT NWELL by welltie SUBSTRATE by subtie } /* --------------------------------- Define Layout Netlist Ports */ CREATE_PORTS { top_cell_only = TRUE PADTOP BY PADTOP } /* -------------------------------- Define Text Attachment Rules */ TEXT { M1 BY M1

261

HLVS Advanced Concepts General Requirements of a Strict LVS Flow Comparison

M2 BY M2 field_poly BY POLY PADTOP BY PAD NWELL BY "VDD" SUBSTRATE BY "GND" }

Requiring Ports to Match by Name

Once you have generated layout and schematic ports in the top block, you must tell Hercules that these ports need to match by name. The Hercules comparison algorithm has an option, REQUIRE_TEXTED_PORTS_MATCH, which you can set to TRUE. This option is valid in the COMPARE section of the Hercules runset, and you can also set it for a specific block (cell) in the equivalence file. In the strictest methodologies this option is set in the COMPARE section and applies to all texted ports in the design. In our example we first set this option for only the top block by placing it in the equivalence file. This also serves as an example of setting an option for a specific block instead of globally. We then do a second Hercules run where we set the option globally in the COMPARE section of the runset. The syntax of an equivalence file is: EQUIV [cell]=[cell]{[option 1 [option 2 ... }

Requiring All Ports to be Texted

The final step to matching all schematic and layout ports is to tell Hercules that all ports are required to be texted. The Hercules comparison algorithm has an option, ALL_PORTS_TEXTED, which you can set to TRUE to generate a warning or error if all ports are not texted. Similar to the REQUIRE_TEXTED_PORTS_MATCH command, in the strictest methodologies this option is set in the COMPARE section and applies to all texted ports in the design. In our example we first set this option for only the top block by placing it in the equivalence file. We then do a second Hercules run where we set the option globally in the COMPARE section of the runset. Example 44 shows a sample of the equivalence file used in our first example of the chapter, dac96.eqv2. It contains the options requiring that all ports be texted in the top block, and that all of the texted ports match by name. Example 44 Equivalence File for dac96.eqv2
EQUIV DAC95=DAC96 {

262

HLVS Advanced Concepts General Requirements of a Strict LVS Flow Comparison

require_texted_ports_match = true all_ports_texted = true} EQUIV COREHI=corehi {} EQUIV CORELOW=corelow {} EQUIV CS_ADD1=cs_add {} EQUIV IBUF=IPAD {} EQUIV ADD4=add4 {} EQUIV OBUF=OPAD {} .......................... DATA OMITTED ........................ EQUIV EQUIV EQUIV EQUIV EQUIV EQUIV EQUIV EQUIV EQUIV EQUIV EQUIV EQUIV EQUIV EQUIV EQUIV EQUIV EQUIV BUF4X4=buf4x4 {} ADR3DEC8=adr3dec8 {} DFFR4=dffr4 {} SAMP4=samp4 {} ADD4B=add4_ovlp {} ADD4B=add4_ga {} MUX_16=mux16 {} PC_256=pc_256 {} BUF4X8=buf4x8 {} MEDDEC_8=meddec8 {} DOUT1=dout1 {} DFFR16=dffr16 {} WDEC_256=wdec256 {} DOUT4=dout4 {} DOUT8=dout8 {} RAM64K=ram64k {} RAM128K=ram128k {}

Symmetry: Independent and Dependent Swappability

In Chapter 7, Introduction to Hercules HLVS, we briefly discussed symmetrical nets. In a strict LVS flow, the designer requires that no ports can be swapped. As a result, the DETECT_PERMUTABLE_PORTS option in the COMPARE section is set to FALSE. This guarantees that even the strictest timing constraints are upheld. For example, in a large DRAM block many of the control pins are swappable. Timing of these control signals is often critical; they might be hooked up in the schematic to reflect the tightest timing constraints. Prohibiting port-swapping guarantees not only the logic, but the critical timing connections on these swappable ports as well. Prohibition of port-swapping occurs only in the strictest custom design environments.

263

HLVS Advanced Concepts General Requirements of a Strict LVS Flow Comparison

Guaranteeing Equivalence Point Matching

As described in Chapter 7, Introduction to Hercules HLVS, the equivalence file is an optional input file. In many flows you do not specify this file, but instead allow Hercules to generate it automatically. In these automatic flows, the equivalence file is used to generate as much hierarchy as possible for easy debug. In stricter LVS flows, however, the designers require that certain blocks of a design match, and guarantee they match in the final design when they are used as equivalence points. EXPLODE_ON_ERROR is set to FALSE to make sure that if the blocks do not match, the comparison fails. Various reasons exist for the requirement that certain blocks match in a final LVS run. We discuss two of them.

Reuse of IP Blocks and Macros

Many design methodologies require that you be able to reuse IP blocks, or smaller macros, and suggest that you guarantee that these be maintained as equivalence points. This is so that both the schematic and layout blocks can be reused without generating new timing models or other post-layout data. In designs with very tight timing or a lot of custom design areas, it is often easier for a designer to add an engineering change order by grabbing whatever gates are closest to the edit location and not actually including them inside the macro that was changed in the schematic. This results in a macro in the schematic that matches to a macro plus some extra logic in the layout, making it difficult to reuse the layout of the macro in another design. It also makes it impossible to build a reusable timing model for the macro, because there is no equivalence point between the layout and schematic, and therefore no common cell that could be replaced with a timing model.

Debugging Large Designs

A very common and important reason for requiring that all equivalence points match is to guarantee the fastest debugging, or turn-around time, for design changes. The runtime of Hercules can be greatly improved by using a good equivalence file. Below is a list of guidelines to follow when creating the methodology for generating your equivalence file. If the schematic and layout designers follow this methodology, then, as changes are made to a design at the end of the design cycle, the Hercules LVS job runs very quickly and it is easy to debug any problems that occur because of the changes.

264

HLVS Advanced Concepts General Requirements of a Strict LVS Flow Comparison

Guidelines for a Good Equivalence File

All library cells should be equivalence points. All IP blocks or macros should be equivalence points. In most cases, function blocks should not be equivalence points. For example, if you have the hierarchy ALU (macro), ADDER32 (function), ADDER4 (library), you should include ALU and ADDER4 as equivalence points, but exclude ADDER32. In a memory (such as RAM, ROM, DRAM, FLASH) include either a bit cell or 8/9 bit cell, an intermediate block (preferably one that is texted correctly), and the top block. For example, RAM512K, RAM32K, and RAM8bit. Hercules LVS optimally processes these types of cells and hierarchy Such an equivalence file has a good set of debug points, not too many devices in each block, and not too many actual blocks to debug. Too many equivalence pointsIn this scenario Hercules spends extra time processing each equivalence point and the hierarchical interactions between them. Also, you are overwhelmed with all of the debug points. Not enough equivalence pointsIn this scenario Hercules spends too much time processing large blocks of transistors, instead of processing smaller blocks and then simply looking at their hierarchical interactions. Also, you end up debugging blocks with tens of thousands of transistors.

As stated above, following these guidelines serves two purposes:

The two extremes of less-than-optimal performance are:

Of course, in some cases you might want to add more equivalence points than is optimal, so as to help reduce your debugging time. Adding a few minutes to an LVS run is minor compared to saving hours of debug time, because you have reduced the size and scope of the debug problem.

Guaranteeing Devices Are Netlisted in the Cell Where They Are Designed
The concept of requiring equivalence points to match is considered a more advanced feature of Hercules, and for this reason we present it in this chapter of the guide. This requirement is almost always part of a strict Hercules comparison, but it is also used in any Hercules LVS when the output is going into STAR-RCXT, and this includes many less strict LVS flows.

265

HLVS Advanced Concepts General Requirements of a Strict LVS Flow Comparison

The primary reason users require that all devices be netlisted in the cell where they are designed is that they are using the results of a Hercules LVS job as input for a STAR-RCXT extraction job and they need all of their equivalence points to match. STAR-RCXT allows you to input a library of timing models for each of the library cells, or macro blocks, in the equivalence file. If, for some reason, an equivalence point fails although the entire design compares at the top, you no longer have this block, or equivalence point, as a reference for inputting the timing model. When requiring blocks to compare for a Hercules-to-STAR-RCXT flow, you generally do not care why the equivalence point failed. You might, for example, not have restrictions on devices being designed across the hierarchy, nor have restrictions on port text matching, such as might exist in a strict Hercules comparison. In such a case you simply need to make sure that the hierarchy of equivalence points matches the library and macro cells that have generated timing models. In most cases, these equivalence points are lost due to hierarchical interaction with devices that cause them to be generated one level above the cell in which they were originally designed. To help guarantee that devices are placed in the original cells in which they were designed, even in designs where there is a lot of hierarchical interaction between devices, Hercules has two command options, MOS_REFERENCE_LAYER for the extraction phase of LVS, and PUSH_DOWN_DEVICES for the comparison stage.

MOS_REFERENCE_LAYER
In the extraction stage MOS_REFERENCE_LAYER is the option for the PMOS and NMOS extraction commands. A similar option exists for each designed device type. (For example, there is also a RES_REFERENCE_LAYER command.) Even though there might be hierarchical interaction for some of the device layers, such as source drain overlap, the MOS_REFERENCE_LAYER option tells the Hercules extraction code to place the MOSFET in the cell that has this reference layer. The problem of having the hierarchical interactions move the device into a parent cell is thus avoided, as is the problem of the Hercules code being too aggressive and pushing the device into a child cell. Note: Having the device in the parent of the intended cell, or a child of the intended cell, happens only if this is a logically and physically equivalent scenario. Hercules does not change the actual design, just the format of the layout netlist hierarchy.

266

HLVS Advanced Concepts General Requirements of a Strict LVS Flow Comparison

Figure 63 and Figure 64 illustrate a situation in which Hercules puts the device into a child cell (Cell B). Adding the MOS_REFERENCE_LAYER option to the PMOS and NMOS commands corrects the problem. Figure 63 Effect of Placing Device in Child Cell: Schematic Cell A Cell B

Figure 64 Effect of Placing Device in Child Cell: Layout Viewed with Enterprise

The child (Cell B) compares alone. When the parent (Cell A) is run, the INVERTER from the parent gets pushed down into the child, so the child does not compare. Unlike the schematic netlist, the layout netlist shows INV as flat

267

HLVS Advanced Concepts General Requirements of a Strict LVS Flow Comparison

(that is, not an instance). Example 45 shows the schematic netlist, Cell_A.sch, for Cell A. Notice that CELL_B, in the schematic, has two instances of INV, and CELL_A has a flat inverter, made from an instance of a p device and an instance of an n device. Example 45 Schematic Netlist for Cell A
{NETLIST CELL_A {VERSION 1 0 0} /* Level 2 */ {CELL INV {PORT 1 2 3 9} {INST M1=p {PROP x=12.5 y=32.5 l=2.000 w=12.000} {PIN 2=GATE 3=SRC 1=DRN 1=BULK }} {INST M2=n {PROP x=12.5 y=10.5 l=2.000 w=6.000} {PIN 2=GATE 3=SRC 9=DRN 9=BULK }} } /* Level 1 */ {CELL CELL_B {PORT 1 4 5 6 7} {INST 11=INV {PROP x=-27.5 y=0.5 angle=0 reflection=0} {PIN 1=1 8=2 7=3 4=9}} {INST 12=INV {PROP x=28.5 y=0.5 angle=0 reflection=0} {PIN 1=1 9=2 6=3 5=9}} } /* Level 0 */ {CELL CELL_A {INST M1=p {PROP x=22 y=33 l=2.000 w=12.000} {PIN 2=GATE 3=SRC 1=DRN 1=BULK }} {INST M2=n {PROP x=22 y=11 l=2.000 w=6.000} {PIN 2=GATE 3=SRC 7=DRN 7=BULK }} {INST 0=INV {PROP x=-45.5 y=0 angle=0 reflection=0} {PIN 1=1 13=2 2=3 7=9}} {INST 1=INV {PROP x=69 y=0.5 angle=0 reflection=0} {PIN 1=1 3=2 6=3 7=9}} {INST 2=CELL_B {PROP x=9.5 y=-0.5 angle=0 reflection=0} {PIN 1=1 7=4 7=5 3=6 2=7}} } }

The CELL_A.net layout netlist (shown in Example 46) reflects the problem of extracting and netlisting the MOSFETs that make up the INVERTER. We ran Hercules using the mos_ref_err.ev runset to generate the CELL_A.net layout netlist below. Notice that there are two instances of INV in CELL_B, just like in the schematic, but that there is also a flat inverter, made from one instance of a

268

HLVS Advanced Concepts General Requirements of a Strict LVS Flow Comparison

p device and one instance of an n device. Also notice that CELL_A is missing the flat inverter that was in CELL_A in the schematic. Example 46 Cell_A.net Layout Netlist
{NETLIST CELL_A {VERSION 1 0 0} /* Level 2 */ {CELL INV {PORT 1 2 3 9} {INST M1=p {PROP {PIN 2=GATE {INST M2=n {PROP {PIN 2=GATE } /* Level 1 */ {CELL CELL_B {PORT 1 2 3 6 7 8 9 10 11 12 13 14} {INST M1=p {PROP x=12.5 y=33.5 l=2.000 w=12.000} {PIN 2=GATE 12=SRC 13=DRN 1=BULK }} {INST M2=n {PROP x=12.5 y=11.5 l=2.000 w=6.000} {PIN 3=GATE 10=SRC 11=DRN 14=BULK }} {INST 11=INV {PROP x=-27.5 y=0.5 angle=0 reflection=0} {PIN 1=1 15=2 9=3 6=9}} {INST 12=INV {PROP x=28.5 y=0.5 angle=0 reflection=0} {PIN 1=1 16=2 8=3 7=9}} } /* Level 0 */ {CELL CELL_A {PORT} {INST 0=INV {PROP x=-45.5 y=0 angle=0 reflection=0} {PIN 1=1 13=2 2=3 7=9}} {INST 1=INV {PROP x=69 y=0.5 angle=0 reflection=0} {PIN 1=1 3=2 6=3 7=9}} {INST 2=CELL_B {PROP x=9.5 y=-0.5 angle=0 reflection=0} {PIN 1=1 2=2 2=3 7=6 7=7 3=8 2=9 3=10 7=11 3=12 1=13 7=14}} } }

x=12.5 y=32.5 l=2.000 w=12.000} 3=SRC 1=DRN 1=BULK }} x=12.5 y=10.5 l=2.000 w=6.000} 3=SRC 9=DRN 9=BULK }}

269

HLVS Advanced Concepts Setting up Error and Warning Messages

Include MOS_REFERENCE_LAYER variables in the NMOS and PMOS commands in the runset, as in the following:
PMOS p pgate psd psd {mos_reference_layer NMOS n ngate nsd nsd {mos_reference_layer substrate = "poly";} TEMP=pgates well = "poly";} TEMP=ngates

As an exercise to see varying results, run Hercules on mos_ref_err.ev to generate the miscompare of Cell B. Cell A, however, does match. The mos_ref_fixed.ev runset generates the correct compare of Cell B, with Cell A still matching. You find these runsets under the Getting_Started_Hercules_LVS directory.

PUSH_DOWN_DEVICES
In the comparison stage, PUSH_DOWN_DEVICES is the option used to guarantee equivalence points. It is added to the COMPARE section of your runset and set to TRUE. PUSH_DOWN_DEVICES is the initial recommended solution to the problem of hierarchical interactions causing equivalence points to miscompare. PUSH_DOWN_DEVICES identifies all devices that meet the following two criteria: 1. All of the device terminals are directly connected to ports of one cell. 2. The connectivity of these ports is consistent across all instances of that cell. If these two criteria are met, the Hercules comparison removes those devices from the higher level and places them in the cell to which the ports are connected. There is a detailed description entitled PUSH_DOWN_DEVICES in Chapter 7, Introduction to Hercules HLVS.

Setting up Error and Warning Messages

Warning and error messages are generated during both the extraction and comparison phases of a Hercules LVS job. All LVS extraction ERRORs appear in the block.LAYOUT_ERRORS file. The most common of these errors include text opens, text shorts, and device extraction errors. The comparison phase of LVS runs even if there are errors in the block.LAYOUT_ERRORS file, so you must make sure this file is okay before you begin to debug the comparison phase of your LVS run. All comparison error and warning messages appear in the sum.block.block files and the block.cmperr file. Remember, the primary files for reviewing these

270

HLVS Advanced Concepts Hercules Examples

errors and warnings are in the sum.block.block files of each block. Hercules has default settings for what it reports as errors and warnings. A table of these defaults is located in the Hercules Reference Manual. Hercules also allows you to change what is reported as an error or a warning. in certain cases you might wish to reduce the size of output files by switching off particular types of messages. Normally, these messages are warnings that are understood by the user, or data that is not generally referenced. In other instances, you might want to turn on other messages to produce more verbose output. Note: A message might be more than one line long, particularly for tables that list data unique to a particular block. The MESSAGE_SUPPRESS command in the OPTIONS section can be used to disable the printing of certain message types in COMPARE. The MESSAGE_ENABLE command in the OPTIONS section is used to enable the printing of certain other messages. The MESSAGE_IDENTIFIERS option is set to display the message identifiers in the listing file. The MESSAGE_ERROR option is set to upgrade a message to a severity level of ERROR. Example 47
OPTIONS { message_suppress = { CMP-39 CMP-45 } /* Do not print these messages. */ message_enable = { CMP-60, CMP-61 } /* Do print these messages */ message_identifiers = on /* Prints message IDs in output files. */ message_error = { CMP-52 } /* Upgrade message(s) level to error. */ }

In our first tutorial example you see a sample sum.block.block file, which includes the MESSAGE_IDENTIFIERS option. These are CMP-XX numbers beside each information output in the file and are controllable with the options listed above.

Hercules Examples
Now that we have explained the different options we set in our examples, here is a brief summary of each example in this chapter and the learning objectives for each example. Example 1: Run Hercules on a strict comparison runset, where CREATE_PORTS is used in the device extraction and layout netlisting. All top

271

HLVS Advanced Concepts Hercules Examples

ports are required to be texted and the text must match between the layout and schematic. We run this example twice, once with the standard warning message, and the second time with the CMP-XX error numbers displayed and the warning message upgraded to an error. Learning Objectives: To become familiar with setting options in the equivalence file, as opposed to the COMPARE section To practice using the HTML interface to search through sum.block.block files, and the block.LVS_ERRORS file To see an example of strict port comparison

Example 2: Run Hercules on a strict comparison runset similar to the first example, but set the options in the runset during the COMPARE section. Also, a new warning is generated because a layout port net is equated to a net that is not a port in the schematic. Learning Objective: To review some of the CMP-XX error numbers relating to port matching

Running Hercules LVS for Example 1

Go to the directory where your dac96lvs2.ev file is located, your_path/tutorial/ Getting_Started_Hercules_LVS/dac96lvs2/. Enter the command: hercules -html dac96lvs2.ev Your active window displays the execution process. While the screen contents might scroll quickly (freeze the screen with Control-s and restart with Controlq), you should be able to notice any specific actions or warnings that appear. All of this information appears in a file for your examination. The sample runset file should only take a few minutes to run.

Runfile Results for Example 1

Notice that this runset is the same as the one in Chapter 7, except for the addition of the options described above. If you already have a browser open, go to the browser and see if the Hercules results are in the browser window. If not, open a browser displaying the file: your_path/tutorial/Getting_Started_Hercules_LVS/dac96lvs2/ Compare_Results.html.

272

HLVS Advanced Concepts Hercules Examples

A successful compare shows what is seen in Figure 65. Figure 65 Successful Compare

Verify that the LVS Extraction phase of the job ran without errors. Click the LAYOUT ERRORS button (see left-hand arrow in Figure 65) to get a view of the DAC96.LAYOUT_ERRORS file, as seen in Figure 66.

273

HLVS Advanced Concepts Hercules Examples

Figure 66 LAYOUT ERRORS Window Showing Contents of DAC96.LAYOUT_ERRORS

Click the LVS SUMMARY button (see right-hand arrow in Figure 65) to get a view of the DAC96.cmpsum file, as seen in Figure 67.

274

HLVS Advanced Concepts Hercules Examples

Figure 67 Top Part of DAC96.cmpsum File

All equivalence points (with and without errors) Note:

Use scroll bar to look further down in this file

Remember, you can resize any of the frames by dragging the frame edge with the mouse. Notice that on the left there is a directory of all of your blocks, which are hyperlinked to the sum.block.block files.

275

HLVS Advanced Concepts Hercules Examples

Scroll through the file (see the right arrow in Figure 67) until you get near the bottom, where you see the following: Figure 68 Bottom Part of DAC96.cmpsum File

The CMP-XX messages are numbered, so you have the option of customizing the looks of this file by suppressing the printing information for each. Notice the WARNINGs and the links to each of the blocks in the file.

276

HLVS Advanced Concepts Hercules Examples

Note: There are categories of warnings listed here for COREHI. We look at the COREHI sum.block.block file after reviewing DAC96. Now either select the DAC96 file from the list on the far left of the browser, or click the link to it in the cmpsum file to get the sum.block.block file for the top block, DAC96. You should get a view similar to that shown in Figure 69. Figure 69 Sum.block.block File for Top Block of DAC96

You are now in the sum.block.block file for the top block, DAC96. This is the block where we set the ALL_PORTS_TEXTED and REQUIRE_TEXTED_PORTS_MATCH options. As a result of those settings we

277

HLVS Advanced Concepts Hercules Examples

expect to see WARNINGs, because that is the default type of output message if there are problems introduced with these option requirements. Notice that the file is divided into sections. We go into more detail on these sections in the next chapter, when we have more errors in our design. Click on the Port Cross-Reference table (indicated by arrow in Figure 69) to take you to the texted ports list for this block, as shown in Figure 70. Figure 70 Top of Port Cross-Reference File - Resized Frames

278

HLVS Advanced Concepts Hercules Examples

Figure 71 Bottom of Port Cross-Reference File Showing ERRORS and WARNINGS - Resized Frames

CMP-119 is the WARNING message, so we can now upgrade that to an ERROR. We are now going to learn to suppress warning messages before we rerun Hercules. Click LVS SUMMARY at the top to go back to the summary file and get a list of all equivalence points. Now select COREHI, the block having warning messages we pointed out in the note following the discussion of the LVS SUMMARY (see Figure 68).

279

HLVS Advanced Concepts Hercules Examples

The warning for net matching is part of the post-compare information, so click that link (POST-COMPARE) in the list on the left side of the browser window. In the window with the post-compare netlist statistics, scroll down to the warning messages near the end. Figure 72 COREHI Netlist Statistics with Two Warnings

280

HLVS Advanced Concepts Hercules Examples

Look at CMP-8 and CMP-27. These warnings are generally okay, therefore we are going to suppress them in our example. However, most people want to pay attention to the CMP-42 WARNING, so we leave that warning as is. (If you need to, enlarge the windows to see information better by dragging the margins with the mouse.) Now edit the dac96lvs2.ev file to include the message_suppress = {CMP-8 CMP-27} and the message_error = {CMP-119}; or, you can use the dac96lvs2a.ev runset that already has the changes. Execute Hercules from your UNIX shell again. This time, we rerun only the COMPARE, because our extraction phase had no errors. Enter: hercules -C -html dac96lvs2a.ev Or, if you have updated the file, enter: hercules -C -html dac96lvs2.ev Notice that, if you keep your browser window open, the files are automatically updated when the Hercules job is complete. Now look at the block.LVS_ERRORS file in the HTML window showing the error and an unsuccessful compare.

281

HLVS Advanced Concepts Hercules Examples

Figure 73 Unsuccessful Compare Error

Notice that the block with an error is listed to the left. Select the block in error, DAC96, to get the view shown in the sum.block.block file. Be aware that the general advice in the main window is only a guide. You should first examine the block error.

282

HLVS Advanced Concepts Hercules Examples

Figure 74 DAC96 Error

To see the error, go to the Port Cross-Reference table by choosing the link indicated by the arrow in Figure 74. Then scroll down until you see the error message.

283

HLVS Advanced Concepts Hercules Examples

Figure 75 Port Cross-Reference Error

Because we upgraded the warning to an error, the COMPARE is no longer clean, but has an error and fails. We also go back and look at the warnings we suppressed. Click on LVS SUMMARY to get a list of all blocks in the design. Scroll to the same place we did earlier, with COREHI and DAC96, to get the view shown in Figure 76.

284

HLVS Advanced Concepts Hercules Examples

Figure 76 COREHI with Only One Warning

For COREHI, there is only one type of warning now instead of two. As a practice exercise, go into the sum.block.block file and verify that the warning is no longer there, either. You might also want to look through the files to review the different sections and the CMP-XX messages. You can suppress many of these in order to change the format and reduce the size of the file. You can also

285

HLVS Advanced Concepts Hercules Examples

add more informational messages, which are suppressed by default. For a complete list of messages based on the files in which they are printed (cmpsum, sum.block.block, or cmperr) or suppressed, see the Hercules Reference Manual.

Running Hercules LVS for Example 2

Go to the directory where your dac96lvs3.ev file is located, your_path/tutorial/ Getting_Started_Hercules_LVS/dac96lvs3/. Enter the command: hercules -html dac96lvs3.ev First, remember to convert the dac96.gds files using gdsin, as described in Chapter 1, Installation and Setup. The sample runset file should only take a few minutes to run. Your active window displays the execution process. While the screen contents might scroll quickly (freeze the screen with Control-s and restart with Control-q), you should be able to notice any specific actions or warnings that appear. All of this information appears in a file for your examination.

Runfile Results for Example 2

First, examine the runset in Example 48 to see that we have upgraded WARNINGs to MESSAGE_ ERRORs for CMP-42 and CMP-43. We have also moved the ALL_PORTS_TEXTED = TRUE and REQUIRE_TEXTED_PORTS_MATCH commands out of the equivalence file and put them in the COMPARE section of the runset, so that they apply to all equivalence points, not just the top block, DAC96. Example 48 Portion of dac96lvs3.ev Runset
/* ------------------------- Runset options */ OPTIONS { MESSAGE_ERROR = {CMP-42 CMP-43} MESSAGE_IDENTIFIERS = ON EXPLORER_DATA = TRUE IGNORE_CASE = FALSE SCHEMATIC_GLOBAL = {VDD GND VDDIO VSSIO} SCHEMATIC_GROUND = {GND VSSIO} SCHEMATIC_POWER = {VDD VDDIO} LAYOUT_POWER = {VDD VDDIO} LAYOUT_GROUND = {GND VSSIO} EDTEXT=dac96.text

286

HLVS Advanced Concepts Hercules Examples

NET_PREFIX = XX_ .......................... DATA OMITTED ........................ COMPARE { COMPARE_PROPERTIES = TRUE PROPERTY_WARNING = FALSE EXPLODE_ON_ERROR = FALSE RETAIN_NEW_DATA = TRUE STOP_ON_ERROR = FALSE FILTER = TRUE MERGE_SERIES = FALSE MERGE_PARALLEL = TRUE MERGE_PATHS = FALSE EQUATE_BY_NET_NAME = TRUE AUTO_EXCLUDE_EQUIV = TRUE REMOVE_DANGLING_NETS = TRUE PUSH_DOWN_PINS = TRUE PUSH_DOWN_DEVICES = TRUE DETECT_PERMUTABLE_PORTS = FALSE ALL_PORTS_TEXTED = TRUE REQUIRE_TEXTED_PORTS_MATCH = TRUE

You should already have your browser open from the previous example, so now go to the browser window and look at the results from your completed run. We still have EXPLODE_ON_ERROR = FALSE, but also STOP_ON_ERROR = FALSE. As a result, if an equivalence point has an error, it is not exploded, and no cells containing that equivalence point are compared due to their dependency on the uncompared block. Because STOP_ON_ERROR = FALSE, however, the job continues to compare all blocks that do not contain the uncompared blocks in their sub-tree. Now look at the comparison file with the browser. You should see the following:

287

HLVS Advanced Concepts Hercules Examples

Figure 77 Top-Level Unsuccessful Compare

Verify that the LVS Extraction phase of the job ran without errors. Click the LAYOUT ERRORS button as you did in Example 1. Figure 78 shows the results you should see in the LAYOUT ERRORS window.

288

HLVS Advanced Concepts Hercules Examples

Figure 78 LAYOUT ERRORS Window Showing Contents of DAC96.LAYOUT_ERRORS

Click the BACK button in your browser to return to the LVS SUMMARY window shown in Figure 77. Notice that there is a message reminding you that EXPLODE_ON_ERROR is FALSE. You have two blocks with errors, corehi and IOBUF. Let's first open IOBUF. Choose IOBUF in the left window to get EQUIV = [IOBUF, IOBUF].

289

HLVS Advanced Concepts Hercules Examples

Figure 79 EQUIV = [IOBUF, IOBUF]

Scroll through the top window to find the error, a property mismatch, as seen in Figure 80.

290

HLVS Advanced Concepts Hercules Examples

Figure 80 Property Mismatch Error

In many cases, the properties in the schematic do not match the properties in the layout netlist. Also, in most cases, if you are the person debugging the design to try to get it to compare, you are not at liberty to fix these property errors. Hercules has an option in the COMPARE section, PROPERTY_WARNING, which causes the TRUE setting to report property errors as warnings. You should generate warnings for the property mismatches until you complete all of the other debugging of the design.

291

HLVS Advanced Concepts Hercules Examples

Click on LVS ERRORS at the top of the browser to get back to your blocks with errors. Now let's look at corehi. Choose corehi in the left-hand column of the browser. Scroll in the top main window until you see the RED error message, CMP-42, shown in Figure 81. Figure 81 Red Error Message for CMP-42

If you scroll down in the Port Cross-Reference table, you notice that CARRY = COUT; this is the reason for the error. Normally, this would be only a warning, but we upgraded it. Scroll even further down in the window, and notice another

292

HLVS Advanced Concepts Hercules Examples

WARNING message that can be upgraded to an ERROR in this strict comparison, CMP-124 (shown in Figure 82). Figure 82 WARNING in Strict Comparison - CMP-124

Remember, we required that all ports be texted in the COMPARE section. You should upgrade this message to an error for the strict comparison flow. Click on LVS SUMMARY and scroll to the bottom of the window for the DAC96 summary. Notice (in Figure 83) that this block was not run, due to dependency

293

HLVS Advanced Concepts Hercules Examples

errors. Because corehi and IOBUF did not compare, and they are sub-blocks of DAC96, DAC96 was not compared. Figure 83 DAC96 Summary

We now rerun this example using the dac96lvs3a.ev runset, which contains an upgrade for the CMP-124 WARNING to ERROR, and PROPERTY_WARNING = TRUE. Again, we have to rerun only the comparison phase. In your UNIX shell enter: hercules -html -C dac96lvs3a.ev

294

HLVS Advanced Concepts Hercules Examples

Notice that IOBUF is no longer listed as a cell with an error. However, there are quite a few blocks that were added to the list of blocks with errors, due to the upgrade of CMP-124, shown in Figure 84. Figure 84 Errors Added to CMP124

Take a few minutes to browse through some of these blocks and the different sections of the files available with the HTML interface. We go into more detail on this interface in Chapter 9, Hercules HLVS Debugging, showing examples of the Schematic Unmatched, Layout Unmatched, and Matched Devs Connected to Unmatched Nets sections of the files and how the interface helps debug these types of problems.

295

HLVS Advanced Concepts EQUATE, EQUIV, and COMPAREWhich Setting Takes Priority?

EQUATE, EQUIV, and COMPAREWhich Setting Takes Priority?

As you have seen in our two examples, you can set options in the COMPARE section of the runset, in the equivalence file, or in both. Many of these options can also be set in the EQUATE commands. FILTER, for example, is an option that could go in all three places. The following rules govern option settings: Rule 1: Options set in EQUATE specify which devices are eligible for consideration if a given function is performed. In the following example, filter_options means that device n should be considered if the filtering functionality is performed. It says nothing about whether that operation will actually be performed.
EQUATE NMOS N = n G S D VBB { filter_options = {nmos-3 nmos-8}

Rule 2: Options set in COMPARE globally control functionality. In the following example, filter = true tells Hercules to perform the filtering operation. The COMPARE filtering operates only on devices where the filter_options are set in the EQUATE command for that device.
COMPARE { filter = true }

Rule 3: Options set in the equivalence file override the global setting and allow for local control. In the following example, the filtering operation is not performed for the inv block.
equiv inv = inv { filter = false }

Whats Next?
Now that you are familiar with running a Hercules LVS job and the basics of the HTML interface, you should continue on to Chapter 9, Hercules HLVS Debugging, which gives a detailed example of debugging a Hercules LVS job. You learn more benefits of the HTML interface and how to use HerculesExplorer to debug specific device and net mismatch errors.

296

9
Hercules HLVS Debugging9
In this chapter you go through a complete Hercules LVS debugging example. You learn how to use the HTML interface and Hercules-Explorer, a GUI-based debugging tool.

Learning Objectives for This Chapter

To have a quick checklist of things to look for when your LVS job fails To run an example of a standard LVS comparison with errors To learn the Hercules LVS HTML interface to debug the LVS results To learn the Hercules-Explorer debugging tool, and how to use it with the HTML interface

Before You Start

Before you start this tutorial, make sure you have completely gone through the installation and setup procedure described in Chapter 1, Installation and Setup. See the section, Creating Directories and Getting the Files in Chapter 1 for directory structure and necessary files. You should also, at the very least, have completed the tutorials in Chapter 2, 3, 7, and 8.

297

Hercules HLVS Debugging Quick Checklist for LVS Debug

Quick Checklist for LVS Debug

Now that you have reviewed the output files available to you for LVS debug, here is a checklist for quickly debugging your LVS results without having to look through all the output files manually. You should refer to this generic list whenever debugging an LVS job. STEP 1: Check for texting or device extraction errors. STEP 2: If you have major texting errors, review your TEXT_OPTIONS, ASSIGN, and TEXT sections to make sure you have the correct text layers attached to the correct polygon layers. STEP 3: Debug all device extraction errors. STEP 4: Rerun your Hercules LVS job. STEP 5: Open the Compare_Results.html file in your browser and review the equivalence points listed in the main LVSDEBUG window. STEP 6: Fix COMPARE errors and rerun Hercules.

A specific example of LVS debug follows the checklist details below, but it does not have examples of all of the potential problems listed below, and therefore is not as generic.

LVS Extraction Debug

Steps 1 through 4 of the quick checklist debug the extraction phase of your LVS job.

STEP 1: Check for Texting or Device Extraction Errors.

You should check the block.LAYOUT_ERRORS file (using vi or more editors) to make sure you do not have any texting or device extraction errors. Below are some of the more common problems you might encounter during this step and an example of each situation.

Missing Terminals - Device Extraction Errors

In this example we have built an NMOS device that has only one terminal. The NMOS command option, MOS_SINGLE_SD, is set to NORMAL. This tells Hercules to generate an extraction error if any NMOS device does not have two

298

Hercules HLVS Debugging LVS Extraction Debug

terminals. Figure 85 shows the layout of the extracted NMOS with the error and Example 49 shows the actual error in the block.LAYOUT_ERRORS file. Figure 85 Layout of NMOS Defined with Missing Terminals

src/dm

src/dm

gate

gate

Example 49 NMOS Defined with Missing Terminals in block.LAYOUT_ERRORS File

Library name: dac96 Structure name: inva #####--- ERR_DEVICE ----------------------------------NMOS n ngate nsd nsd SUBSTRATE { MOS_PRINT_XY_POSITION=FALSE; MOS_PRINT_STATS=FALSE; MOS_SAVE_ALL_PROPS=FALSE; MOS_REFERENCE_LAYER="POLY"; MOS_HIERARCHICAL=TRUE; MOS_CALC_NRS_NRD=TRUE; MOS_MULTITERM_EXTRACT=FALSE; MOS_NODE_BASE_EXTRACT=TRUE; MOS_LEVEL_SD=FALSE; MOS_COMBINE_SOURCE=TRUE; MOS_SINGLE_SD=NORMAL;} TEMP=ndevice - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Structure Error Type Layer Value ( position x, y ) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - inva MISSING_TERMINALS nsd 1 (11.000, 10.500)

299

Hercules HLVS Debugging LVS Extraction Debug

Too Many Terminals - Device Extraction Errors

For our example we built a diode, but, instead of using the diffusion layer as both of the terminals, we used the diffusion-derived layer as one and the diocont layer as the other. Figure 86 shows a picture of the device and Example 50 shows the ERROR in the block.LAYOUT_ERRORS file. Notice that the value in the block.LAYOUT_ERRORS file is 2. This value is always one greater than the number of terminals you are allowed to have for a specific layer. In the case of this example, you should have 1 polygon for the ndiffdio layer, and 1 polygon for the diocont layer. Figure 86 Layout of Diode Defined with Too Many Terminals

Example 50 Example of Diode Defined with Too Many Terminals in block.LAYOUT_ERRORS File
Library name: dac96.db Structure name: IOBUF #####--- ERR_DEVICE ----------------------------------DIODE ndio ndiffdio diocont substrate { DIODE_PRINT_XY_POSITION=FALSE; DIODE_PRINT_STATS=FALSE; DDIODE_SAVE_ALL_PROPS=FALSE; DIODE_TYPE=NP; DIODE_HIERARCHICAL=TRUE; DIODE_RECOGNITION_LAYER_USED=TRUE;} TEMP=ndiode - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

300

Hercules HLVS Debugging LVS Extraction Debug

Structure Error Type Layer Value ( position x, y ) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - IOBUF TOO_MANY_TERMINALS diffcont 2 (-88.000, 112.500)

To fix this error, use the ndiffdio layer for both terminals. The DIODE is formed from the N material in the terminals and the P material in the substrate.

Unused Text
If you define a text layer in the ASSIGN section and use it in the TEXT section, Hercules generates an unused text error for each piece of that text that is not attached to a polygon. Attached is defined by the value of the ATTACH_TEXT variable in the TEXT_OPTIONS section, and by whether or not the text string overlaps the layer with which it was associated in the TEXT section. Below is an example of an unused text error. In Figure 87 you see that the text strings are overlapping M2, not M1. The TEXT on layer 30 should be attached to M2 instead of M1 to avoid these errors. Figure 87 M1 and M2 Text in IOBUF

VDD-M1

GND-M1

Example 51 Unused Text ERROR in block.LAYOUT_ERRORS File

Library name: dac96.db Structure name: IOBUF #####--- ERR_TEXT_UNUSED -----------------------------------

301

Hercules HLVS Debugging LVS Extraction Debug

Reports unused text of M1.txt file after all text assignments. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Structure Unused Text l;dt ( position x, y ) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - IOBUF GND 30;0 (-89.500, -303.500) IOBUF VDD 30;0 (-89.500, -253.300)

Text Opens
Whenever you have two unconnected nets in a cell with the same text string, Hercules generates a text open error in the block.LAYOUT_ERRORS file. Example 52 shows an example of a text open error message in the block.LAYOUT_ERRORS file. There are special TEXT_OPTIONS such as USE_COLON_TEXT and USE_SEMI_COLON_TEXT to suppress certain text open errors in library (or standard) cells. See the Hercules Reference Manual for details on these options. Example 52 Text Open ERROR in block.LAYOUT_ERRORS File
Library name: dac96 Structure name: buf4x #####--- ERR_TEXT_OPEN ----------------------------------Nets in named structures are connected by text. Connect and Text commands used for opens processing: CONNECT { ngate pgate BY [ TOUCH OVERLAP ] field_poly M2 BY [ TOUCH OVERLAP ] PADTOP M1 M2 BY [ TOUCH OVERLAP ] V1 M1 ndiffdio res_term field_poly nsd psd welltie subtie BY [ TOUCH OVERLAP ] CONT NWELL BY [ TOUCH OVERLAP ] welltie SUBSTRATE BY [ TOUCH OVERLAP ] subtie } TEXT { M1 BY M1.text M2 BY M2.text field_poly BY POLY.text PADTOP BY PAD.text

302

Hercules HLVS Debugging LVS Extraction Debug

NWELL BY "VDD" SUBSTRATE BY "GND" } - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Parent Struct Base l;dt Parent Inst origin Base Text From Path Text Text (x, y) (x, y) Net ID or Info - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - buf4x IN 30;0 (3.000, 56.000) XX_5 LAYER Signal 30;0 (57.000, 54.500) LAYER Signal

Text Shorts
Whenever you have two different text strings attached to the same electrically connected net, Hercules generates a text short error in the block.LAYOUT_ERRORS file. Example 53 shows how that error appears in the file. Later we show you how to use the TEXT_OPTION FIND_SHORTEST_PATH_BETWEEN_TEXT_SHORTS and the short-finding utility in Hercules-Explorer to trace these text shorts. Example 53 Text Short ERROR in block.LAYOUT_ERRORS File
Library name: dac96.db Structure name: IOBUF

#####--- ERR_TEXT_SHORT ----------------------------------Text for net in named structures are shorted. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Structure Net ID Used Text l;dt (position x, y) Text From - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - inva XX_1 * A 30;0 (3.000, 2.000) LAYER Z 30;0 (9.000, 2.000) LAYER

STEP 2: Review Your TEXT_OPTIONS, ASSIGN, and TEXT Sections,

If you have major texting errors, review your TEXT_OPTIONS, ASSIGN, and TEXT sections in the runset to make sure you have the correct text layers attached to the correct polygon layers. You might also want to open your input database in a layout editor and look at the relationship of the text to the polygon data.

303

Hercules HLVS Debugging LVS Comparison Debug

STEP 3: Debug All Device Extraction Errors.

Debug all device extraction errors using the Hercules-Explorer graphical debug tool, or open your input layout database in a layout editor of your choice, and view the errors using the coordinates given in the block.LAYOUT_ERRORS file.

STEP 4: Rerun Your Hercules LVS Job.

Once you have fixed all the device extraction and texting errors, rerun your Hercules LVS job.

LVS Comparison Debug

Steps 5 and 6 of the quick checklist debug the comparison phase of your LVS job.

STEP 5: Review the Equivalence Points.

Open the Compare_Results.html file in your browser and review the equivalence points listed in the main LVSDEBUG window. When you click on each of these links, you jump directly to the error in the sum.block.block file. The following sections discuss common errors found on the first run of LVS COMPARE on a design.

Filtering Options Missing

If COMPARE determines that you have extra devices in the layout or schematic that match one of the available Hercules filter options, it generates a message. This message informs you of the filtering option that applies to the extra devices and recommends that you set that option to help your design compare.

Merging Options Missing

If COMPARE determines that you have extra devices in the layout or schematic that can be merged in series or parallel to help your design match, it generates a message. This message informs you of the merging option that applies to the extra devices and recommends that you set that option to TRUE to help your design compare.

304

Hercules HLVS Debugging LVS Comparison Debug

POWER/GROUND Shorts
In many cases a text short error seen in the block.LAYOUT_ERRORS file also results in POWER/GROUND shorts seen in the sum.block.block files. Whenever a short is found, a table is generated in the sum.block.block file showing the possible shorted nets in the layout (or schematic) and how they correspond to nets in the schematic (or layout). Example 54 shows one of these tables. Example 54 Diagnostic OPEN/SHORT Table in sum.block.block File
Diagnostic analysis recognizes the following correspondence between unmatched nets in the schematic and layout. These might indicate the source of shorts or opens: Schematic Layout Net Name Connections Connections -------------------------------------------9 GND 4 GND 5 $1N7

LAYOUT POWER or LAYOUT GROUND Definitions Missing

When the LAYOUT_POWER or LAYOUT_GROUND definitions are missing, Hercules generates a warning telling you that these nets are not defined, but Hercules tries to generate these net names automatically based on string matching. Chapter 7, Introduction to Hercules HLVS, provides further detail on string matching. If the list of LAYOUT_POWER or LAYOUT_GROUND nets is incorrect, filtering and merging might not occur correctly. Example 55 illustrates this warning. Example 55 Warning: LAYOUT_POWER or LAYOUT_GROUND Definitions Missing
HLVS (R) Hierarchical Layout Versus Schematic, Release DATA OMITTED Copyright. Synopsys. All rights reserved.

** Environment Status ** runset root = test.ev = DAC96

............................ DATA OMITTED ......................... stop_on_no_explode_error = FALSE static_equated_nets = TRUE

305

Hercules HLVS Debugging Running Hercules LVS with Errors

text_resolves_port_swap write_netlists

= TRUE = TRUE

use_total_width zero_connection_warning

= FALSE = FALSE

Purging Compare Directory ... OK Reading schematic netlist ... OK Reading layout netlist ... OK WARNING: No layout power/ground nets were found. Generating them automatically: VDDIO VDD GND VSSIO ... Processing schematic netlist ... OK Propagating schematic globals ... OK Processing layout netlist ... OK ............................ DATA OMITTED ..........................

Schematic Globals Missing

Hercules automatically tries to generate schematic globals when they are not defined in your runset. As described in Chapter 7, Introduction to Hercules HLVS, a search of the schematic netlist generates this list, but Hercules might miss less commonly defined schematic globals. If this section is missing from your runset, double check that Hercules found all the necessary schematic globals, or false opens might exist in the comparison output.

STEP 6: Fix COMPARE Errors and Rerun Hercules.

Once you have reviewed and fixed all of these major problems, rerun Hercules LVS on your design and refer to the following detailed instructions for debugging Hercules LVS error output.

Running Hercules LVS with Errors

The next group of commands explains how to run a Hercules LVS job with errors. The first section takes you through the checklist steps listed above, showing how to fix some of the global errors. The second section has you rerun Hercules LVS and goes into detail on debugging unmatched nets and devices. Be sure that you are in the directory where your dac96lvs4.ev file is located, your_path/tutorial/Getting_Started_Hercules_LVS/dac96lvs4/. Enter: hercules -html dac96lvs4.ev

306

Hercules HLVS Debugging Running Hercules LVS with Errors

The sample runset file should take only a few minutes to run. Your active window displays the execution process. While the screen contents might scroll quickly (freeze the screen with Control-s and restart with Control-q), you should be able to notice any specific actions or warnings that appear. All of this information appears in a file for your examination. During the run, the HTML DRC Extraction frame (shown in Figure 88) appears in your HTML window, indicating the contents of the DAC96.LAYOUT_ERRORS file. Figure 88 DRC Extraction Frame

307

Hercules HLVS Debugging Running Hercules LVS with Errors

At the end of the run, the LVS Debug Compare Results are loaded in your HTML window. Choose LVS ERRORS to see COMPARE results (shown in Figure 89). Figure 89 LVS ERRORS Compare Results Frame

308

Hercules HLVS Debugging Debugging Your Hercules LVS Run

Debugging Your Hercules LVS Run

When your Hercules LVS job is complete, follow the steps above in the Quick Checklist for LVS Debug. As you go through the checklist for this example, you are introduced to major topics of interest. The STEP headings continue sequentially through this part of the tutorial.

STEP 1: Check for Texting or Device Extraction Errors.

Review the HTML LAYOUT ERRORS frame in Figure 89. Based on the DRC Extraction results shown, your first step should be to locate the GND/VDD shorts, and the DINT15/ICDOUT15 short. We now go through the steps for finding these shorts. For now, you can minimize this screen.

Short Finding in Hercules

The cause for a text short might not always be obvious. Hercules has two methods for locating shorts in your layout. The first method is to use a feature within Hercules-Explorer. It is an interactive short finder, run from the HerculesExplorer interface. The Shortest Path feature in Hercules-Explorer generates graphical output to identify a path between the selected start and stop coordinates. Use the interactive short finder in Hercules-Explorer for small chips, macro blocks, or untexted net shorts. The second way to locate shorts in your layout is to use the FIND_SHORTEST_PATH_BETWEEN_TEXT_SHORTS (known as FSPBTS) option in the TEXT_OPTIONS section of the Hercules runset. This option is part of the standard ERC license, which usually comes with a complete Hercules package. Use the FSPBTS option for chip-level power/ground or large texted net shorts. FSPBTS locates the path with the minimum distance between two shorted text points. When using FSPBTS, the REMOVE_TEXT_FROM_SHORT option must be set to FALSE. (For more details on short finding with Hercules, see TEXT Short Finding in the Hercules DRC and ERC User Guide, Chapter 5.) Below we go through the exercise of finding these shorts using both methods. We use the interactive short finder of Hercules-Explorer for the DINT15/ ICDOUT15 signal net short. We use the FSPBTS option to find the VDD/GND short in corehi. The VDD/GND short in corehi is the same as the one in DAC96; thus, once we fix the short in corehi our block.LAYOUT_ERRORS file will be clean. If you do not have the FSPBTS option, you can use the Hercules-

309

Hercules HLVS Debugging Debugging Your Hercules LVS Run

Explorer Shortest Path feature for the VDD/GND short in the corehi block. We have also included instructions to do this.

Short Finding in Hercules-Explorer

Make sure you are still in the directory where your dac96lvs4.ev file is located, your_path/tutorial/dac96lvs4/. From this directory start Enterprise. Enter: Enterprise & Now start Hercules-Explorer LVS. Choose Verification > Explorer LVS. You should now have the Hercules-Explorer window on your screen (see Figure 91). Hercules-Explorer automatically loads the available data. If it does not, you need to load the data manually using the following steps: Choose File > Load in the left-hand corner of the Hercules-Explorer window. Figure 90 shows what you should see displayed. Figure 90 Hercules-Explorer hxlvs: File > Load

Fill in the Block field with DAC96 and the Run Directory field with the path to your run directory. Click Load. Figure 91 shows what you should see displayed.

310

Hercules HLVS Debugging Debugging Your Hercules LVS Run

Figure 91 Hercules-Explorer HXLVS Loaded

Be sure that your Hercules-Explorer window is connected to your Enterprise session. In the upper right-hand corner of your Hercules-Explorer window make sure there is a check mark in the window next to Enterprise. At the top of the list of blocks loaded you should see Layout Extract Errors. Select this line to open Hercules-Explorer hxdrc and view all the layout extraction errors in the DAC96 design. Figure 92 shows the Hercules-Explorer hxdrc window that is displayed. For the rest of the short-finding example, when we refer to the Hercules-Explorer window, this is the window you should use. You might want to minimize your hxlvs window to avoid confusion.

311

Hercules HLVS Debugging Debugging Your Hercules LVS Run

Figure 92 Hercules-Explorer hxdrc Extract Errors

Loading Extract Errors in Hercules-Explorer

Next, in the Hercules-Explorer window with the extraction errors, select corehi under the Layout Block section. Choose Options > Shortest Path. In Figure 93, you see the Hercules-Explorer window (with corehi selected) and the Shortest Path window.

312

Hercules HLVS Debugging Debugging Your Hercules LVS Run

Figure 93 Hercules-Explorer hxdrc: Starting Shortest Path

Now you use the text coordinate errors to locate the shortest path between our DINT15 and ICDOUT15 short. Before you start this process, double check that your Hercules-Explorer window is connected to your Enterprise session.

Loading Text Short Coordinates Into Shortest Path Tool

You are now ready to load the text short errors to help you find the short between DINT15 and ICDOUT15. To make it easier to follow the next set of instructions, arrange your Enterprise and Hercules-Explorer windows as shown in Figure 94. In the Hercules-Explorer window, select corehi under Layout Block. Next select 33: Text (Text Short) under Error Check to open the corehi block and see the first of 33 text short errors displayed. Figure 94 shows what you should see in the Enterprise, Hercules-Explorer hxdrc, and Shortest Path windows. Notice that the block, netname, and coordinates of the text short were all loaded in the Shortest Path window.

313

Hercules HLVS Debugging Debugging Your Hercules LVS Run

Figure 94 Hercules-Explorer and Enterprise Connected for Short Finding

Setting Error Highlight Options

It is difficult to see the actual text short error with all of the layers displayed. The next set of steps show you how to set up your own error highlight colors, as well as give you some hints for viewing the errors in Enterprise. Choose Options > Color/Fill under the Hercules-Explorer hxdrc window. The button is at the top of the window. Figure 95 shows the pop-up you should see. Set your colors to ones you are comfortable with for error viewing. The Net setting is used for Shortest Path, the Primary and Secondary settings are used for the text short error. We have chosen to set Net and Primary to yellow/semi-

314

Hercules HLVS Debugging Debugging Your Hercules LVS Run

transparent, and Secondary to green/semi-transparent. Once you have set your colors, you can dismiss the menu. Figure 95 Hercules-Explorer: Highlight Color/Fill Pop-up

You are now ready to generate your shortest path. Choose Generate at the top of the Shortest Path window.

Viewing Text Short Errors in Enterprise

Now that the short tracing is complete, you execute a few Enterprise commands to make it easier to view the text error information in the Enterprise window. In top right-hand corner (see arrow in Figure 96) of the Enterprise command window, select Vls > All Off to turn off the view of all the input layers. Click the redraw button (see arrow in Figure 96) the Enterprise window, or press the r key while the cursor is in the window, to automatically redraw. You should now see what is displayed in Figure 96.

315

Hercules HLVS Debugging Debugging Your Hercules LVS Run

Figure 96 Shortest Path Highlights in Enterprise

Redraw

To zoom in on the starting point in Enterprise, execute the following in the command window: gxwSetView 1 "g" '() gxwAddPoint 1 '(3504 14115) gxwAddPoint 1 '(3908 13746) Redraw the Enterprise window. Notice the connection between the two nets that appears (see the top right-hand corner of the graphic in Figure 97).

316

Hercules HLVS Debugging Debugging Your Hercules LVS Run

Figure 97 Shortest Path Highlights in Enterprise

To zoom in on the starting point in Enterprise, again execute the following in the command window: gxwSetView 1 "g" '() gxwAddPoint 1 '(3504 14115) gxwAddPoint 1 '(3908 13746) In the Enterprise command window, select the V button in the layer attribute panel (on the right side) to view layers metal1 (M1), metal2 (M2) and via (V1). Redraw the Enterprise window. You can see the short between the two nets in Figure 98. Select the Clear Hilites button, either in the User Commands pop-up or the middle of the Hercules-Explorer window, to see only the input layer.

317

Hercules HLVS Debugging Debugging Your Hercules LVS Run

Figure 98 View of DINT15/ICDOUT15 Short

Fixing the Short Between DINT15 and ICDOUT15

If you are using a fully-licensed Enterprise session, you can fix the short at this time. If you do not have a fully-licensed Enterprise session, you can fix the short in your own layout editor. We have provided you with an updated layout database for the later steps in this tutorial, so it is not necessary that you fix the error to continue the tutorial. To fix the error, execute the following command in the Enterprise window: s Using your left mouse button, select the lower part of the metal 2 line (layer 10) that crosses the top via. Next, select the top edge of that polygon and slide it down so it is even with the horizontal metal 1 (layer 8) polygon. See Figure 99 for the corrected net.

318

Hercules HLVS Debugging Debugging Your Hercules LVS Run

Figure 99 Corrected DINT15/ICDOUT15 Short

Using Hercules-Explorer Shortest Path for VDD/GND Short

If you have a Hercules ERC license, you might want to skip this section and go to the section Short Finding with FSPBTS. If you do not have an ERC license, we now quickly run through locating the VDD/GND short in our design. If you have any problems, refer back to the more detailed example above. Click the Reset button in the middle of the Shortest Path window on the left side. This clears out the coordinates and netname so that we can start on the VDD/GND short. Click the down arrow on the right side of the Hercules-Explorer hxdrc window (to the left of the User button) once to display the next text short error. Continue clicking the down arrow key until you reach Error #7. Figure 100 shows what you should see in your Enterprise, Hercules-Explorer, and Shortest Path windows. Notice in the Shortest Path window that your starting point and netname are GND, and your stop point is the VDD text.

319

Hercules HLVS Debugging Debugging Your Hercules LVS Run

Figure 100 Hercules-Explorer Shortest Path and Enterprise Display for VDD/ GND Text Short Error

320

Hercules HLVS Debugging Debugging Your Hercules LVS Run

Because there are multiple text short errors for the GND/VDD net, we continue to load more coordinates and they are automatically loaded as stop points. We could not do this for the DINT15/ICDOUT15 short because there was only one text short error for that net. Click the Text button in the Shortest Path window. Then click the Select Cluster button. Click the down arrow in the Hercules-Explorer window six more times to load six more stop points. In Figure 101 you should see all the stop points added in the Shortest Path window. Multiple stop points allow HerculesExplorer to generate the path faster and create an easy path to trace your short.

321

Hercules HLVS Debugging Debugging Your Hercules LVS Run

Figure 101 Shortest Path Pop-up After Stop Points Are Loaded

Click Generate in the Shortest Path window. Tracing a power/ground short could take a few minutes, depending on the size of the design. While Hercules-Explorer is tracing the path, it displays a working message. Once the short tracing is complete, you should see the error message Wrn: Shortest path is through substrate. This message warns that your shortest path was through the substrate. In such a situation you see a fly line from one well tap to another showing the path through the substrate. You should be able to find your short very close to one end or the other of this fly line.

322

Hercules HLVS Debugging Debugging Your Hercules LVS Run

Turn off all visible layers by choosing Vls > All Off. Redraw the Enterprise window. Your layout window should look similar to the one in Figure 102. Figure 102 Shortest Path Highlights in Enterprise between VDD and GND

Zoom in to the right end of the path highlighting line and turn on layers metal1 (M1), metal2 (M2) and via (V1) using the layer attribute panel. You can see side-by-side power/ground rails. If we follow along these rails, we can see that the highlighting shows a grouping of vias(V1) that join the two rails incorrectly. Zoom to the following coordinates to see the short better: gxwSetView 1 "g" '() gxwAddPoint 1 '(3757.15 14021.3) gxwAddPoint 1 '(3843.25 13931) Figure 103 shows the area to which you should have zoomed. Someone not familiar with the design might have to trace along the highlighted layers to discover this short. You can see that the 2x2 set of vias on the VDD net are causing your short between VDD and GND.

323

Hercules HLVS Debugging Debugging Your Hercules LVS Run

Figure 103 Close-up of Shortest Path between VDD and GND

Selecting Start and Stop Points Manually

If you would like to verify that you have the correct path and also go through the exercise of selecting start and stop points manually, the next exercise regenerates the shortest path between VDD and GND, using the two bus polygons shown in Figure 103. Click the Reset button in the Shortest Path window. Choose Select Start Points in the Shortest Path window. Fill in the Block Name with corehi and the Net Name with GND. Choose User Commands > Select Layout Point, and then click the right bus or the GND net for your start point (see Figure 103). Next, choose Select Stop Points in the Shortest Path window (see Figure 104). Choose User Commands > Select Layout Point, and then click the left bus or the VDD net for your stop point (see Figure 103).

324

Hercules HLVS Debugging Debugging Your Hercules LVS Run

Finally, choose Generate to generate the shortest path between the VDD and GND polygons you selected. Figure 104 Shortest Path Pop-up with Manually Selected Coordinates

In Figure 105 the shortest path is now generated on all metal layers instead of through substrate, making it easier to see the problem.

325

Hercules HLVS Debugging Debugging Your Hercules LVS Run

Figure 105 Shortest Path Highlights in Enterprise

Correcting the VDD/GND Short

At this time, if you do not have the FIND_SHORTEST_PATH_BETWEEN_TEXT_SHORTS (FSPBTS) feature, you can correct your layout by removing the vias that are causing the short. (For users who do not have an Enterprise editing license, we have provided an updated database for the later steps in this tutorial.) The following is the suggested sequence for deleting the vias. While in the Enterprise layout window, choose Edit > Delete. Use the left mouse button to select one of the vias to delete. Repeat these steps for the other three vias.

Short Finding with FSPBTS

Make sure you are still in the directory where your dac96lvs4a.ev file is located, your_path/tutorial/dac96lvs4/.

326

Hercules HLVS Debugging Debugging Your Hercules LVS Run

Example 56 shows a modified version of the dac96lvs4.ev runset we used for our LVS extraction and comparison. The FSPBTS command has been added to the TEXT_OPTIONS section and is emphasized. The SHORTEST_PATH_NETS option was also added to the runset below. This option, set to VDD and GND, specifies which nets FSPBTS should consider when generating output. In our example we are looking for shorts on only VDD or GND nets. Note: We commented out the comparison sections of the runset because we are interested in the FSPBTS option only in the extraction phase of the LVS job. FSPBTS locates the path with the minimum distance between two shorted points. The path is output to a user-specified output layer, and an error is written to the block.LAYOUT_ERRORS file. If there are multiple shorts, the path for each short is written to a different data type on the given output layer. Wherever a path piece is rectangular, the path output is a line drawn along the center of the polygon. Small boxes are placed at junctions of path pieces. Later in our example you see the output from the FSPBTS option. Example 56 FSPBTS Runset dac96lvs4a.ev
/* HLVS SAMPLE RUNSET */ /* -------------------------- Runset Header information */ HEADER{ LAYOUT_PATH= ./ INLIB = dac96_dirty BLOCK = DAC96 OUTLIB = dac96_out FORMAT = MILKYWAY GROUP_DIR = ./run_details/group COMPARE_DIR = ./run_details/compare EQUIVALENCE = dac96.eqv /* COMMENTED OUT COMPARISON INPUT DATA */ SCHEMATIC = dac96.hrc SCHEMATIC_FORMAT = HERCULES /* COMMENTED OUT COMPARISON INPUT DATA */ } /* ------------------------- Runset options */ OPTIONS {

327

Hercules HLVS Debugging Debugging Your Hercules LVS Run

DELETE = {IPO VCLOGO} EXPLORER_DATA = TRUE IGNORE_CASE = FALSE SCHEMATIC_GLOBAL = {VDD GND VDDIO VSSIO} SCHEMATIC_GROUND = {GND VSSIO} SCHEMATIC_POWER = {VDD VDDIO} LAYOUT_POWER = {VDD VDDIO} LAYOUT_GROUND = {GND VSSIO} EDTEXT=dac96.text NET_PREFIX = XX_ } /* --------------------------- Data Preprocessing options */ PREPROCESS_OPTIONS { CHECK_PATH_90 = false } /* --------------------------- Text Processing options */ TEXT_OPTIONS { ATTACH_TEXT = ALL FIND_SHORTEST_PATH_BETWEEN_TEXT_SHORTS = 200 SHORTEST_PATH_NETS = {VDD GND} } /* --------------------------- Layer assignments */ ASSIGN { NDIFF (1) PDIFF (2) NWELL (3) POLY (5) TEXT (25) CONT (6) M1 (8) TEXT (28) V1 (9) M2 (10) TEXT (30) PAD (15) TEXT (35) DIFF (1-2) RESP (50) } ............................ DATA OMITTED .......................... /* ----------------------- Layout Netlist Generation */ NETLIST /* -------------------------- Output Layer assignment */

328

Hercules HLVS Debugging Debugging Your Hercules LVS Run

GRAPHICS{ explorer_layers(100) NDIFF (1) PDIFF (2) NWELL (3) POLY (5) PAD (15) RESP (50) M1 (8) M2 (10) CONT (6) V1 (9) } /* COMMENTED OUT COMPARISON SECTION OF RUNSET */ /*=====================================================*/ /* LVS COMPARISON SECTION OF RUNSET */ /*=====================================================*/ ............................ DATA OMITTED .......................... /* COMMENTED OUT COMPARISON SECTION OF RUNSET */

Running Hercules with FSPBTS

The following commands show you how to run Hercules using the FSPBTS option, and then how to use Hercules-Explorer to debug your results. This example was executed on the dac96_dirty database after the DINT15/ ICDOUT15 text short was fixed, so if you have not fixed this short you might see more text short errors than we are showing in the Hercules-Explorer window. Because we specified output only for VDD and GND for the FSPBTS option, no FSPBTS data is output for DINT15 or ICDOUT15, even if you are using the original dirty database. To execute Hercules and find the shortest path between VDD and GND, enter: hercules dac96lvs4a.ev In the Hercules-Explorer hxdrc window from the previous example, choose File > Load. Make sure the block specified is DAC96 and then choose Load in the pop-up menu. Select corehi under the Layout Block list and 1: Text (Text Shortest...) under the Error Check list. (To reiterate, you might see more text short errors in

329

Hercules HLVS Debugging Debugging Your Hercules LVS Run

yours.) Your Hercules-Explorer hxdrc window should look similar to the one in Figure 106. Figure 106 FSPBTS Output in Hercules-Explorer

Viewing the Shortest Path Output

The following commands show you how to better view the shortest path by turning on only the metal and via layers, and also by zooming in on the path. Turn off all visible layers except for M1, V1, and M2 (layers 8, 9, and 10, respectively): Redraw the Enterprise window. Use the left mouse button to create a window in the Enterprise display window that you want to zoom in on. Zoom in on a location similar to the one shown in Figure 107.

330

Hercules HLVS Debugging Debugging Your Hercules LVS Run

Figure 107 FSPBTS Highlights in Enterprise

Trace the highlighted line to the right until you find the short. Figure 108 shows what the short should look like. You have been tracing a VDD net. When you reach the GND text under the 5x5 grid of vias, you make a connection to the GND net. As described in the section above, these four vias (over VDD net) must be deleted to remove the VDD/ GND short. Refer to the previous section, Correcting the VDD/GND Short, for a brief explanation of how to correct the short.

331

Hercules HLVS Debugging Running Hercules After All block.LAYOUT_ERRORS Errors Are Fixed

Figure 108 FSPBTS Highlights Showing VDD/GND Short

Quit Hercules-Explorer hxlvs by choosing File > Quit. At this time we have corrected all of the problems in the DAC96.LAYOUT_ERRORS file, and thus completed STEP 1.

Running Hercules After All block.LAYOUT_ERRORS Errors Are Fixed

We rerun Hercules on a database that has all of the text shorts fixed. Even if you have been correcting your design as we have explained, use the dac96lvs4b.ev runset for the next series of commands. The dac96lvs4b.ev runset points to a database where the shorts are fixed, guaranteeing that your output match the remainder of this tutorial. (Remember we are working according to the Quick Checklist for LVS Debug at the beginning of the chapter.)

332

Hercules HLVS Debugging Running Hercules After All block.LAYOUT_ERRORS Errors Are Fixed

Step 2: Review your TEXT_OPTIONS, ASSIGN, and TEXT Sections.

We reviewed the text errors during STEP 1 and there are no texting errors aside from the text shorts we just fixed.

Step 3: Debug All Device Extraction Errors.

We reviewed the DAC96.LAYOUT_ERRORS file and there are no device extraction errors in this design.

Step 4: Rerun Your Hercules LVS Job

Now that we have completed fixing all of the problems found in the DAC96.LAYOUT_ERRORS file, we rerun Hercules on our updated database. Make sure you are still in the directory where your dac96lvs4b.ev file is located, your_path/tutorial/dac96lvs4/. Enter: hercules -html dac96lvs4b.ev During your Hercules run, the DRC frame appears in your HTML window verifying that your DAC96.LAYOUT_ERRORS file is now empty.

Step 5: Review the Equivalence Points.

The next step is to review the block.LVS_ERRORS file in the HTML interface, so as to determine and correct any global LVS comparison errors. Before we do this, however, we go through the steps of loading the Hercules-Explorer data and linking our HTML output to Hercules-Explorer.

Linking Hercules-Explorer to HTML Interface

Start Hercules-Explorer hxlvs from the Enterprise window by choosing Verification > Explorer LVS. Hercules-Explorer loads the top block automatically. If it does not, in the Hercules-Explorer hxlvs window choose File > Load to make sure your block is still DAC96. Choose Load in the pop-up to load the new data.

333

Hercules HLVS Debugging Running Hercules After All block.LAYOUT_ERRORS Errors Are Fixed

Finally, choose Setup > HTML Cross-Reference to link the HTML output and the Hercules-Explorer data. Figure 109 shows what you should see in the Hercules-Explorer hxlvs window after you perform the steps listed above. Note: If you select a block in the Hercules-Explorer window, your HTML window automatically updates. The opposite of this is not true; in other words, if you select a block in the HTML window, the Hercules-Explorer and Enterprise windows does not update. Figure 109 Hercules-Explorer hxlvs Setup Menu

Figure 110 shows the HTML pop-up that results from these steps. Click the small selection square in the HTML pop-up to enable the crossreferencing to HTML.

334

Hercules HLVS Debugging Running Hercules After All block.LAYOUT_ERRORS Errors Are Fixed

Figure 110 Hercules-Explorer HTML Cross-Referencing Setup Menu

Reviewing the LVSDEBUG File

Bring your HTML window forward so you can see what is in the LVS ERRORS message area. Figure 111 shows what you should see in your window. Notice that some of the unmatched devices in your blocks are filterable. Figure 111 LVS ERRORS Output in HTML Interface

Select the red highlighted section of this message, NAND3B, nand3c,and it opens a block that demonstrates the error. Figure 112 shows the updated HTML screen after this operation.

335

Hercules HLVS Debugging Running Hercules After All block.LAYOUT_ERRORS Errors Are Fixed

Figure 112

HTML Window After Selecting NAND3B, nand3c

Choose Post-Processing for Unmatched Devices/Nets Analysis on the left side of the HTML screen to get to the Applicable Filterable Layout Devices. Note: While reviewing these global errors, it is easier to use the HTML driver instead of Hercules-Explorer. Later we show you where you should use Hercules-Explorer. You can decide for yourself how to combine the HTML and Hercules-Explorer interfaceshere we are just presenting some of the more efficient ways to use the interfaces together.

336

Hercules HLVS Debugging Running Hercules After All block.LAYOUT_ERRORS Errors Are Fixed

Figure 113 Applicable Filter Options

If you click Applicable Filter Options (shown in Figure 113), you notice that all the suggested options for PMOS devices are listed in a table in the bottom HTML window. If you look in the dac96lvs4b.ev runset (shown in Example 57), you see that there are filter options for NMOS (NMOS-3 and NMOS-8), but not PMOS. The table in your HTML window suggests that PMOS-3, PMOS-16, and PMOS-21 are required for the PMOS devices. Before adding or removing any filter options, you should always check with your design rules to make sure a particular filter option is allowed, or if the design needs to be modified to fix your compare problems. If look at dac96lvs4c.ev, you see that we have added the PMOS-3 and PMOS8 filter options to the EQUATE commands. PMOS-8 is not listed in the table as an Applicable Filter Option and might not be necessary, but we added it to be

337

Hercules HLVS Debugging Running Hercules After All block.LAYOUT_ERRORS Errors Are Fixed

consistent with the NMOS filter options. Now that we have corrected all of the global problems listed in the HTML LVS ERRORS file, we rerun Hercules. Note: You can also consider the blocks with shorts and opens listed in the LVS ERRORS window as a global type of error. In most cases, however, if you have a major filtering problem, you should rerun Hercules as soon as it is fixed. Example 57 EQUATE Commands in dac96lvs4b.ev Runset
/*=====================================================*/ /* LVS COMPARISON SECTION OF RUNSET */ /*=====================================================*/

/* ----------------------- Define Schematic Diode equal to layout diode */ EQUATE DIODE NDIO = ndio A B { check_properties = {area} rel_tolerance[area] = {5} } /* ----------------- Define Schematic Resistor equal to layout resistor */ EQUATE RES RP1 = rp A B { } /* ------------------ Define Schematic N Mosfet equal to layout N mosfet */ EQUATE NMOS N = n G S D VBB { check_properties={l,w} rel_tolerance[l]={5} rel_tolerance[w]={5} filter_options={nmos-3 nmos-8} } /* ------------------------- Define Schematic P Mosfet equal to layout P mosfet */ EQUATE PMOS P = p G S D VBB { check_properties={l,w} rel_tolerance[l]={5} rel_tolerance[w]={5} }

338

Hercules HLVS Debugging Using Hercules-Explorer hxlvs to Debug Specific COMPARE Errors

Using Hercules-Explorer hxlvs to Debug Specific COMPARE Errors

Now that we have completed debugging and correcting all the LVS extract errors, reviewed for any texting problems, and corrected all global LVS compare errors, we are ready to execute Hercules again and debug specific net and device mismatch errors from the comparison phase.

STEP 6: Fix COMPARE Errors and Rerun Hercules.

Make sure you are still in the directory where your dac96lvs4c.ev file is located, your_path/tutorial/dac96lvs4/. Enter the command: hercules -html dac96lvs4c.ev Figure 114 shows the results of your latest Hercules run in the LVS ERRORS HTML file.

339

Hercules HLVS Debugging Using Hercules-Explorer hxlvs to Debug Specific COMPARE Errors

Figure 114 LVS ERRORS in HTML Interface After Filtering Is Corrected

Next you need to load the new comparison results into Hercules-Explorer. Choose File > Load and verify that the block listed is DAC96. Click Load in the pop-up menu. Figure 115 shows the Hercules-Explorer window after the load is completed.

340

Hercules HLVS Debugging Using Hercules-Explorer hxlvs to Debug Specific COMPARE Errors

Figure 115 Hercules-Explorer hxlvs After Loading New Error Output

Where to Start Debugging LVS Errors

We now learn the process for LVS debug using a hierarchical tool. Because Hercules starts at the lowest level and compares the smallest blocks first, you should also start debugging your problems at that level. In general, the fewer devices there are in a block, the easier it is to debug. In some cases all of the lower-level blocks have the same problem and there is no need to debug all of these blocks. Generally, a situation like this is reported as a global problem in the LVS ERRORS HTML file, so you do not need to look through all of the mismatched blocks. This was the case with the filter options in

341

Hercules HLVS Debugging Using Hercules-Explorer hxlvs to Debug Specific COMPARE Errors

this example. If you look back, you see that fixing that problem significantly reduced the number of non-equivalent blocks. At this phase of the example, there are only a few mismatched blocks in the lower levels that are not dependent on each other, so we work our way through each of these. If you debug a lower-level block and you have a mismatched block at the next level that is dependent on that lower-level block, there is no need to debug the higher-level block. For example, buf4x does not compare and is listed at level 9. Level 8 has buf4x4 listed, and higher up is buf4x8. When we fix the problem in buf4x and it compares, then, most likely, buf4x4 and buf4x8 will also compare. We start debugging with buf4x.

Loading buf4x for Debug

Select BUF4X :: buf4x under the Schematic :: Layout list in the HerculesExplorer window. The Hercules-Explorer window and any files you have opened through Hercules-Explorer update automatically. There is a summary of the errors and warnings on the right side of the Hercules-Explorer window. If you click any of the summary information in the lists, more detailed information is shown. Figure 116 shows the Hercules-Explorer window after you selected BUF4X :: buf4x. Figure 117 shows the updated HTML file. At this time we are concentrating on the Hercules-Explorer interface. We use the LVSDEBUG HTML file only to help choose which blocks to debug next, by looking at their level and place in the hierarchy.

342

Hercules HLVS Debugging Using Hercules-Explorer hxlvs to Debug Specific COMPARE Errors

Figure 116 Hercules-Explorer hxlvs: Selecting BUF4X::buf4x Block

343

Hercules HLVS Debugging Using Hercules-Explorer hxlvs to Debug Specific COMPARE Errors

Figure 117

HTML Updated by Selecting buf4x in Hercules-Explorer

Files Available in Hercules-Explorer

In Chapter 7, Introduction to Hercules HLVS, we reviewed, in detail, the sum.block.block files, explaining that these were the files for each block that contain all of the detailed error information. We also reviewed the cell-level schematic netlist (sch.block) and explained that it is a flat netlist, where all blocks that were successfully compared at a lower level are now only black-box instances.

344

Hercules HLVS Debugging Using Hercules-Explorer hxlvs to Debug Specific COMPARE Errors

When debugging a comparison error, it is often helpful to have these two files open. You can open these files through Hercules-Explorer and use the information in the files for cross-probing and probing in the layout. The next few operations involve opening these files. Choose View > Equivalence Schematic Netlist to open the schematic netlist for buf4x. Figure 118 shows this operation and Figure 119 shows the Equivalence Schematic Netlist that is opened. Figure 118 Hercules-Explorer View Menu

345

Hercules HLVS Debugging Using Hercules-Explorer hxlvs to Debug Specific COMPARE Errors

Figure 119 Equivalence Schematic Netlist in Hercules-Explorer

In Figure 119, notice that Highlight in Netlist is not selected in your Equivalence Schematic Netlist window. Click the small box to the left of the option to select it (see arrow in Figure 119). This allows nets and devices that are highlighted in the layout window to be highlighted in the schematic netlist window as well. In the Hercules-Explorer window, choose View > Equivalence Summary File to open the sum.block.block file, the summary file for buf4x. Figure 120 shows the middle of this file.

346

Hercules HLVS Debugging Using Hercules-Explorer hxlvs to Debug Specific COMPARE Errors

Figure 120 Equivalence Summary File in Hercules-Explorer

Figure 121 shows the buf4x block that was automatically opened in your Enterprise window.

347

Hercules HLVS Debugging Using Hercules-Explorer hxlvs to Debug Specific COMPARE Errors

Figure 121 buf4x Opened by Hercules-Explorer in Enterprise Window

Reading the sum.block.block File

You want to arrange your schematic netlist, summary file, and Enterprise window so that you can see all of them. These are your main sources of information for debugging unmatched nets and devices. In the summary file window, scroll or search for the section Unmatched Schematic Nets. You should notice in the buf4x block that all devices match. We are concerned with only unmatched nets.

Table on Schematic and Layout Net Relationships

Figure 120 has an arrow pointing to a very useful table in the summary file. This table shows how the connections of unmatched layout nets and unmatched schematic nets relate. COMPARE uses information about the matched devices to which these nets connect to help determine whether nets are shorted, opened, or crossed.

348

Hercules HLVS Debugging Using Hercules-Explorer hxlvs to Debug Specific COMPARE Errors

Highlighting Nets and Devices in the Layout

Based on the table in our summary file, it appears that there is a short between the two nets in the layout that match the schematic nets $IN7 and OUT. The easiest way to find a short between two fairly short nets is to highlight the problem in the layout. The top of the Equivalence Summary File window has a command line where you can input a device or net name. You must use the button (indicated by the right-most arrow in Figure 122) to tell Hercules-Explorer if the name is a layout net, layout device, schematic net, or schematic device. Select Layout Net at the top of the window. In our example, we want first to highlight the layout net OUT. Use your mouse to highlight the net OUT in the table and it automatically appears on the command line. Or, type the netname on the command line. Figure 122 shows what your window should look like. Click the Send Selected button to the left of the command line.

349

Hercules HLVS Debugging Using Hercules-Explorer hxlvs to Debug Specific COMPARE Errors

Figure 122 Selecting a Device or Net to Highlight in the Layout

You should immediately see the net highlighted in your Enterprise window, as shown in Figure 123.

350

Hercules HLVS Debugging Using Hercules-Explorer hxlvs to Debug Specific COMPARE Errors

Figure 123 Highlight of OUT Net in Enterprise Window

Using Information About Matched Devices Connected to Unmatched Nets

Once you have identified the unmatched net in the layout, your next step is to locate matched devices that are connected to this net, in order to help determine where the short is located. If you scroll down a page in the Equivalence Summary File window, you see a list of Matched Devices Connected to Unmatched Nets. You probably want to select a device that is supposed to be connected to both. We use $1I2. In the middle of the Hercules-Explorer window click the Clear Hilites button. With your mouse, select $1I2 from Matched Devices Connected so that it appears on the command line in the Equivalence Summary File window. Select Schematic Device to tell Hercules-Explorer what the $1I2 name refers to. Click Send Selected.

351

Hercules HLVS Debugging Using Hercules-Explorer hxlvs to Debug Specific COMPARE Errors

Figure 124 shows the $1I2 instance of INVA highlighted in the Enterprise window and the schematic netlist window. Note: You might want to re-highlight the OUT net to see the relationship between the net and the instance better. Figure 124 $1I2 Instance of INVA Highlighted in Layout

Analyzing the Highlight Information

Now you know the location of the OUT net in the layout and you can see how it connects to the $1I2 instance of INVA. The summary file shows that the output, Z, should be connected to OUT, and that the input, A, should be connected to $1N7. By looking at the design of the INVA cell, you can see that the input, which is tied to the gate, is supposed to be connected to the bottom net, and that the output, which is tied to the source/drain, is supposed to be connected to the top net. There is an extra via on the output of $1I2 that is shorting $1I2 to the metal 1 line, $1N7. If you have a full Enterprise license, remove this via.

352

Hercules HLVS Debugging Using Hercules-Explorer hxlvs to Debug Specific COMPARE Errors

Loading cs_add for Debug

Now that you have found the error in the Level 9 block, bring up your HTML window and go back to the LVS ERRORS window to determine the next block to debug. LEVEL 8 has three blocks, buf4x4, cs_add, and adrdec4. The block buf4x4 is probably failing because it included the buf4x block with errors, so we skip this block. The next block we load is cs_add. Follow the same steps you used to load the buf4x block. The schematic netlist, summary file, and Enterprise windows should all automatically update with the new block information. Figure 125 shows the updated summary and HTML files. In the summary file, scroll to the section Unmatched Layout Nets and look for a table similar to the one we saw for buf4x. Find a similar table in the HTML file. The block cs_add appears to have two nets in the layout and one in the schematic that are unmatched. All devices match. After reviewing the table, you should be able to determine that you most likely have an open between XX_17 and XX_10.

353

Hercules HLVS Debugging Using Hercules-Explorer hxlvs to Debug Specific COMPARE Errors

Figure 125 Equivalence Summary File and HTML File for cs_add

354

Hercules HLVS Debugging Using Hercules-Explorer hxlvs to Debug Specific COMPARE Errors

Highlighting to Find an Open Between Two Nets

Use your mouse to select the XX_14 net in the summary file, set the type to Layout Net, and click Send Selected to highlight the first net in the layout. Figure 126 shows this operation in the Equivalence Summary File window. Figure 126 Highlighting XX_14 Net Using Equivalence Summary File

Use your mouse to select the XX_6 net in the summary file and click Send Selected to highlight the second net in the layout. In the Enterprise window, choose Fit View With Border (see arrow in Figure 127) or press the f key to fit the layout view. Figure 127 shows the XX_17 and XX_10 nets highlighted in the Enterprise window.

355

Hercules HLVS Debugging An Exercise for the Reader

Figure 127 Highlighted Open between XX_17 and XX_10

Notice the obvious open at coordinates x=60, y=30. By using the Enterprise command s, you can stretch the lower metal 2 line over the via. Use save cell to save your changes.

An Exercise for the Reader

We have left the last block in Level 8 as an exercise for you. Using the information you have learned in this chapter you should be able to load the adr2dec4 block and determine the error. In the dac96lvs4 directory, the file dac96lvs4.solution contains an explanation of the error if you are not able to complete the exercise successfully. HINT: The sum.block.block file has a section called Suspicious Connection. If you have mismatched nets that are not shorts or opens, this is the section that, in most cases, should be able to help you.

356

Hercules HLVS Debugging Whats Next?

When Do You Rerun Hercules?

As we mentioned earlier, you should debug most of the lower-level blocks that do not depend on other blocks that failed to compare. In our example, once you have completed debugging Level 9 and Level 8, you would be ready to rerun Hercules.

Whats Next?
Chapter 10 is for Dracula users who need to convert Dracula LVS runsets to Hercules LVS runsets and debug Hercules LVS in the Opus environment. You learn how translate a Dracula LVS runset to Hercules, run Hercules in the Opus environment, and debug your run using Hercules-Explorer interfaced to Virtuoso and Composer. If you have already completed Chapter 10, or are not a current Dracula user, continue on to Chapter 11, Runset Debugger, for an introduction to the Hercules Runset Debugger.

357

Hercules HLVS Debugging Whats Next?

358

10
HLVS Migration with Hercules-Explorer10
In this chapter you convert a simple HLVS Dracula rule set to a Hercules runset using the translation options you learned in Chapter 5, Hercules DRC Migration. Following that, you run Hercules on this runset and view the results using HerculesExplorer interfaced to Virtuoso and Composer, which are the Cadence layout and schematic tools.

Summary of Progress to This Point

If you are completing the exercises in the recommended order, you should now be familiar with Hercules and its associated input and output files, know how to execute Hercules from a UNIX command line, and be familiar with the Hercules to Dracula translator, Drac2He. Now that you have the basic information, you can move on to a more realistic example in your design environment.

Learning Objectives for This Chapter

In this part of the tutorial, we simulate a real design environment so that you have a better understanding of how to apply Hercules to your application. You will:

371

HLVS Migration with Hercules-Explorer Before You Start

Review the overall Dracula to Hercules migration flow Convert a Dracula LVS rule set to a Hercules runset using Drac2He Set up the Hercules and Hercules-Explorer menus in Opus Run Hercules on the output from Drac2He, automatically translating the CDL schematic, generating an equivalence file, and completing a hierarchical LVS Introduce and run Hercules-Explorer connected to Virtuoso and Composer to show how the error detection process can be made easier through crossprobing Explain in detail the LVS run from the Dracula input Rerun Hercules on a clean database using all of the automatically generated data from the first Hercules run

Before You Start

Before you start the tutorial, make sure that you have completely gone through the installation and setup procedure described in Chapter 1, Installation and Setup.

Overview of HLVS Migration Flow

In this chapter, you translate a Dracula rule file by setting the option on the command line to generate the necessary options for Hercules-Explorer with Virtuoso and Composer. You also run Hercules and then view the ERROR output with Hercules-Explorer in Virtuoso and Composer. Figure 128 shows the major steps that are reviewed in this chapter.

372

HLVS Migration with Hercules-Explorer Overview of HLVS Migration Flow

Figure 128

Dracula to Hercules HLVS Migration Flow

Opus DATA GENERATION (layout and schematic)

Drac2He (rule file and edtext translation)

CDL Schematic Netlist

GDSII Layout Database

runset.ev Runset

hedtext Runset

Hercules LVS RUN

PHYSICAL
Enterprise Error Database

FILES
SUMMARY ERROR HIERARCHY ./compare

Details of Flow Diagram

The following is a brief explanation of the flow shown in Figure 128. Generate CDL schematics and a GDSII layout database from your Opus environment. The files are provided, but you can also generate them from the AD4FUL library provided in the tutorial. Translate the Dracula rule file and hedtext or edtext file using the Synopsys Drac2He translator. This is the first step in this part of the tutorial.

373

HLVS Migration with Hercules-Explorer Generating a Runset with Drac2He

Run Hercules LVS using the CDL schematics, GDSII layout, translated rule file, and translated edtext file as input. First you bring up the HerculesExplorer/Virtuoso/Composer debug environment and then run Hercules LVS from this environment. Finally, review and, if necessary, debug the Hercules LVS results using Hercules-Explorer connected to Virtuoso and Composer. There is one error in the example, which is identified and left for you to correct.

Generating a Runset with Drac2He

The first step in the flow is to translate the Dracula rule file to a Hercules runset using Drac2He. Go to the directory that contains the LVS migration test, your_path/tutorial/ Getting_Started_Drac2he_LVS/migration_lvs This directory contains the necessary technology files for the Cadence Opus environment, as well as the following versions of the AD4FUL library: gdsii: ad4ful_error.gds Cadence 4.4.x library: ./lib4 gdsii: ad4ful_fix.gds

In all three cases the top block is AD4FUL. The Cadence AD4FUL library is the same as the ad4ful_error.gds library. Use the command: drac2he -explorer -E error.out migration_lvs.drac > ad4ful_lvs.ev The -explorer option generates the necessary option in the Hercules runset to use Hercules-Explorer for error debug. Note: At some point before or after the translation, you want to make sure the library and schematic netlist files are correctly named in your Dracula rule file or Hercules runset. If you choose to edit the Dracula rule file, make sure the INDISK and SCHEMATIC variables in the DESCRIPTION section are correct. If you choose to edit the Hercules runset, you want to check the INLIB and SCHEMATIC variables in the HEADER section. Your screen does not display data while the translator runs. When the translation is complete, ad4ful_lvs.ev contains the Hercules runset ready for execution. Before you run Hercules on this runset, you review its contents.

374

HLVS Migration with Hercules-Explorer Translation Results for Migration.lvs Example

Translation Results for Migration.lvs Example

This runset was output from the Drac2He translation you just completed. You run Hercules from the Hercules-Explorer/Virtuoso/Composer debug environment using this runset. Example 58 ad4ful_lvs.ev HEADER and OPTIONS Sections
HEADER { INLIB = ad4ful_error.gds OUTLIB = EV_OUT BLOCK = AD4FUL GROUP_DIR = group FORMAT = GDSII OUTPUT_FORMAT = LTL OUTPUT_LAYOUT_PATH = . SCHEMATIC = adder4.cdl SCHEMATIC_FORMAT = CDL } OPTIONS { IGNORE_CASE=TRUE DRACULA_DEFAULTS=TRUE EXPLORER_DATA=TRUE RESOLUTION=0.050 WIDTH=0.100 NET_PREFIX = N_ LAYOUT_POWER = { VDD VCC } LAYOUT_GROUND = { VSS ground } } EVACCESS_OPTIONS { PATH = evaccess CREATE_VIEWS = TRUE }

Translated Header and Option Sections

Example 58 shows the HEADER, OPTIONS, and EVACCESS_OPTIONS sections you should have in the ad4ful_lvs.ev file that Drac2He output. Notice that: INLIB is ad4ful_error.gds and FORMAT is GDSII. OUTPUT_FORMAT is Enterprise. The Enterprise format is for HerculesExplorer to read. SCHEMATIC_FORMAT is CDL. Hercules automatically translates this to the Hercules format.

375

HLVS Migration with Hercules-Explorer Translation Results for Migration.lvs Example

No EQUIVALENCE file is specified. It is generated automatically. No SCHEMATIC_GLOBALS are specified. They are generated automatically. In the OPTIONS sections, the EXPLORER_DATA option is TRUE. This tells Hercules to generate the extra data necessary for Hercules-Explorer to highlight ERRORS. The EVACCESS_OPTIONS section sets all CREATE_VIEWS to TRUE. This generates the extra data necessary for Hercules-Explorer to highlight errors.

Translated EDTEXT and HEDTEXT Files

The Drac2He translator converts all EDTEXT and HEDTEXT (hierarchical EDTEXT) files to the Hercules EDTEXT file format. Example 59 shows an example of the ad4ful_text.herc file generated by Drac2He. The translator takes the input file listed by the EDTEXT or HEDTEXT command in the Dracula rule file, converts it to the Hercules format, and then appends a .herc extension to the file name. Example 60 shows the ASSIGN and OPTIONS sections with the EDTEXT command, and the TEXT section in the Hercules runset with these new text layers listed. Example 59 Hercules EDTEXT File
structure INV IN 50 255 structure ADFULAH VSS 51 255 VDD 51 255 structure INV VSS 51 255 VDD 51 255 structure DGATE VSS 51 255 VDD 51 255 structure INVH VSS 51 255 VDD 51 255 structure TGATE VSS 51 255 VDD 51 255

12.500000 1.400000 1.700000 17.300000 15.800000 48.300000 47.700000 18.200000 17.750000 16.750000 16.450000

22.000000 2.900000 45.050000 2.100000 43.750000 3.750000 45.100000 2.350000 42.850000 -5.250000 36.150000

376

HLVS Migration with Hercules-Explorer Translation Results for Migration.lvs Example

Example 60 Hercules Runset ASSIGN, EDTEXT, and TEXT Sections

/* BEGIN INPUT LAYER BLOCK */ /* *INPUT-LAYER */ ASSIGN { PWELL(31) /* PWELL = 31 */ TOX (1) /* TOX = 1 */ POLY (5) /* POLY = 5 */ CONT (6) /* CONT = 6 ; */ MET1 (8) text(100)/* MET1 = 8 TEXT = 100 ATTACH MET1 */ MET2 (10) text(110)/* MET2 = 10 TEXT = 110 ATTACH MET2 */ PSEL (14) /* PSEL = 14 ; */ VIA (19) /* VIA = 19 ; */ MET1_GEN_TEXT_LAYER1(51;255)text(51;255)/* VIA = 19 ; */ POLY_GEN_TEXT_LAYER2(50;255)text(50;255)/* VIA = 19 ; */} /* HEDTEXT = ad4ful_text; ATTACH TEXT file OPTIONS { EXPLIST = edtextnoexplode EDTEXT = ad4ful_text.herc } TEXT { MET1 BY MET1.TEXT MET2 BY MET2.TEXT MET1 BY MET1_GEN_TEXT_LAYER1.TEXT POLY BY POLY_GEN_TEXT_LAYER2.TEXT } */

Notice that under the OPTIONS section Drac2He also creates an EXPLIST file. This file, edtextnoexplode, contains a list of the cells in the EDTEXT file, telling Hercules not to explode these cells for any reason. Exploding the cells would prevent the text in the EDTEXT file, ad4ful_text.herc, from being attached. For more details on EXPLIST files, see the Hercules Reference Manual. We go over the automatic steps in the Hercules LVS run later when we execute Hercules. First, we set up the Opus environment.

Netlisting Consistency Between Composer and HerculesExplorer

When you generate your CDL netlist from Composer, single-letter prefixes are automatically generated and attached to each instance name and device name (if they do not already exist in Composer) to make the netlist SPICEcompatible. For example, all MOSFETs are prefixed with an M and all instances are prefixed with an X. When Hercules-Explorer tries to cross-reference the device names in the schematic netlist generated by NetTran (from the CDL), it

377

HLVS Migration with Hercules-Explorer Setting up Hercules in the Opus Environment

is not able to match XI10 in the netlist file to I10 in the Composer schematics due to this prefix. To correct this cross-referencing problem when CDL is used and the Composer naming convention does not match SPICE, use the NetTran -cdl-chop option that must be set in the runset. You need to set this in the tutorial example. Edit the ad4ful_lvs.ev file using vi or the editor of your choice. Search for the OPTIONS section, and add the following syntax:
NETTRAN_OPTIONS = "-cdl-chop"

Example 61 shows how your new OPTIONS section should appear. Example 61 New OPTIONS Section
OPTIONS { NETTRAN_OPTIONS = "-cdl-chop" IGNORE_CASE=TRUE DRACULA_DEFAULTS=TRUE EXPLORER_DATA=TRUE RESOLUTION=0.050 WIDTH=0.100 NET_PREFIX = N_ LAYOUT_POWER = { VDD VCC } LAYOUT_GROUND = { VSS ground } }

Case Sensitivity
Hercules and Dracula have different rules for working with case sensitivity. When you are streaming out from Virtuoso, you must select the PRESERVE_CASE option to guarantee that Hercules-Explorer can crossprobe correctly. The Drac2He translator sets IGNORE_CASE to TRUE, which does not allow you to cross-probe to the Composer schematic if you use mixed case. In our example we used the PRESERVE_CASE option, so you do not need to change the setting of the IGNORE_CASE option.

Setting up Hercules in the Opus Environment

This section of the tutorial shows you how to set up Hercules HerculesExplorer, the Virtuoso interface, and the Composer interface in the Opus environment.

378

HLVS Migration with Hercules-Explorer Setting up Hercules in the Opus Environment

First, verify that your XPROBE environment variable is set. If not, set it using the command: setenv XPROBE /tmp/xprobe-$user When Hercules-Explorer is started, it creates a file at the XPROBE location. Be sure to set XPROBE to a location where you have read/write privileges. Also, you should choose a location on a local disk drive.

Starting Opus
Next, enter the command: icfb & The icfb command starts the Cadence Opus, version 4.2.2 or higher. See the Hercules Reference Manual for earlier versions.

Loading Synopsys SKILL Code

In your CIW window, enter the command: load "{$HERCULES_HOME_DIR}/bin/{$AVANTI_SYSTYPE} / skill_menu_4.4.il" A successful setup of the Opus environment with the Synopsys tools results in the following message in your icfb window:
/***********************************/ Explorer Msg: Loading skill_menu_4.4.il.. .... Explorer Msg: Defined <Key>g -- Probe Selected Object. Explorer Msg: Defined <Key>p -- Probe Layout Point. Explorer Msg: Defined <Key>r -- Remove Highlights. ... Synopsys SKILL environment setup is done t

Note: If your SKILL load fails, include an explicit path. For example: load "/l0/synopsys/bin/SUN32_58/skill_menu_4.4.il" At this time you start a layout window in Opus, begin your Virtuoso and Composer sessions, and then open the AD4FUL library.

379

HLVS Migration with Hercules-Explorer Setting up Hercules in the Opus Environment

Opening Your Layout

From the Tools menu in the CIW window, open the Library Manager. If the library is not in the search path, you have to execute the next three steps: 1. Under Library Manager, choose Edit > Library Path. 2. Under Library Path Editor, choose Edit > Add Library to add the library path. 3. Use the browser to locate the AD4FUL library and add it to the path. Now you should have the AD4FUL library in your path. Before continueing, save these changes so they appear in the Library Manager. Under Library, select AD4FUL. Under Cell, select AD4FUL. Under View, select layout by double-clicking. Under View, select schematic by double-clicking. Now you should have the AD4FUL layout open in Virtuoso and the schematic open in Composer. Finally, before you can run Hercules you need to bring up the Synopsys GUI-based tools.

Connecting Hercules-Explorer to Virtuoso and Composer

The next set of steps start Hercules-Explorer and connect it to both Virtuoso and Composer. For successful cross-probing of nets, it is very important that Hercules-Explorer be linked to both tools. From the Synopsys Tools menu (shown in Figure 129), choose Execute Explorer > Start Explorer LVS (with Composer). Figure 129 Execute Synopsys Tools Menu

380

HLVS Migration with Hercules-Explorer Setting up Hercules in the Opus Environment

Set the Hercules run directory to your_path/tutorial/ Getting_Started_Drac2he_LVS/migration_lvs and click OK in the HerculesExplorer window, shown in Figure 130. Figure 130 Set Hercules Run Directory and Hercules-Explorer Host Menu

When the HXLVS or Hercules-Explorer LVS window starts, make sure you get the following message in the Message window (also shown in Figure 131):
Msg: skill_filter_4.4.il: $Revision: 4.5 $ $Date:2000/06/19 17:58:42 $

Also, make sure that you have both the Composer and Virtuoso check marks in the HXLVS window, as shown in Figure 131.

381

HLVS Migration with Hercules-Explorer Executing Hercules LVS in the Opus Environment

Figure 131 Hercules-Explorer LVS with Filter Load Messages

Executing Hercules LVS in the Opus Environment

You have now set up your Hercules/Hercules-Explorer/Opus environment. The next step in the flow is to execute Hercules from this environment. Before you execute Hercules LVS, verify that all the necessary files are in your run directory. adder4.cdl: CDL schematic netlist, output from Composer (in our example we are using a SPICE netlist similar to CDL) ad4ful_error.gds: GDSII layout, output from Virtuoso ad4ful_text.herc: EDTEXT file, output from Drac2He ad4ful_lvs.ev: Hercules runset, output from Drac2He

382

HLVS Migration with Hercules-Explorer Executing Hercules LVS in the Opus Environment

After verifying that all these files exist in the your_path/tutorial/ Getting_Started_Drac2he_LVS/migration_lvs directory, choose File > Execute Hercules in Hercules-Explorer. The File button is in the top left of the HerculesExplorer window. Fill in the Runset File field, ad4ful_lvs.ev, and the Block Name field, AD4FUL, as shown in Figure 132. Also, verify that the Run Directory is your_path/tutorial/ Getting_Started_Drac2he_LVS/migration_lvs. Figure 132 Execute Hercules Menu

Choose Execute. When the job completes, the block automatically loads and HXLVS window should update, as shown in Figure 133.

383

HLVS Migration with Hercules-Explorer Executing Hercules LVS in the Opus Environment

Figure 133 HLVS Hercules-Explorer after LVS Error Data Loaded

Select the adfulah::ADFULAH block. Both the Virtuoso and Composer windows load and display the ADFULAH block as shown in Figure 134 and Figure 135.

384

HLVS Migration with Hercules-Explorer Executing Hercules LVS in the Opus Environment

Figure 134 Example of Layout Block ADFULAH

Figure 135 Example of Schematic Block ADFULAH

You have now set up your Hercules/Hercules-Explorer/Opus environment and executed Hercules on the ad4ful_lvs.ev runset. If you had any problems, or if want a more detailed description of the commands available in the SKILL files supplied by Synopsys, refer to the Hercules Reference Manual for a complete description of the Hercules-Explorer/Opus interface.

Highlighting in Virtuoso and Composer

Our example has one error in ADFULAH, which we use to show you how to highlight and cross-probe between your layout and schematic. You can select a net to highlight in the Composer window, and if that net has a matching net in the layout, Virtuoso zooms to the net in the layout and highlights the matching net. The same is true for matching devices.

385

HLVS Migration with Hercules-Explorer Debugging with Hercules-Explorer Connected to Virtuoso and Composer

You can also select a net to highlight in the Virtuoso window and, if that net has a matching net in the schematic, Composer automatically highlights that matching net. The same is true for matching devices. To see the highlighted net or device in Composer, however, you might need to use the arrow keys, or simply refresh the window to see the highlight. In this tutorial we explain in detail how to cross-probe using the files in Hercules-Explorer. You can also choose the menu Tools > Probe Selected to select nets and devices to cross-probe. Note: In some cases the redraw command in Virtuoso or Composer might erase the highlights. If this happens, simply use the arrow keys to pan and redraw your screen.

Debugging with Hercules-Explorer Connected to Virtuoso and Composer

The first step in debugging our design is to check for errors in our layout extraction. You can look at these errors using Hercules-Explorer or view the AD4FUL.LAYOUT_ERRORS file. In either case, the only error you should find is a non-90 path centerline on POLY in the DGATE. Next we debug the errors in our lowest level of hierarchy. In this case, there are errors only in AD4FUL, the top block, and in ADFULAH, the level 1 block. By fixing the errors in the ADFULAH block, we actually fix the errors in the AD4FUL block as well, because they were propagated up the hierarchy.

Opening the sum.block.block File in Hercules-Explorer

Select the ADFULAH block under the Schematic::Layout window on the left side of the Hercules-Explorer GUI. Choose View > Equivalence Summary File (sum.*.*) to open the sum.adfulah.ADFULAH file in Hercules-Explorer. Figure 136 shows this step.

386

HLVS Migration with Hercules-Explorer Debugging with Hercules-Explorer Connected to Virtuoso and Composer

Figure 136 Selecting the Equivalence Summary File

Scroll down in the sum.adfulah.ADFULAH file until you see the ERRORS. Your Hercules-Explorer session should look like the one in Figure 137.

387

HLVS Migration with Hercules-Explorer Debugging with Hercules-Explorer Connected to Virtuoso and Composer

Figure 137 Loaded Data in Hercules-Explorer and sum.block.block File

Select net84 from the unmatched schematic nets, set the Domain and Type and the Schematic Net, and then click the Send Selected button. Using the arrow keys, pan in Composer until you see your selected net. Select nets N_21 and then N_8 from the Unmatched Layout Nets, making sure each time to change your Domain and Type setting to Layout Net, and click Send Selected for each of these nets. At this time you should notice there is an OPEN between N_21 and N_8. A VIA sref is missing from the design. Figure 138 shows this missing VIA. The two highlighted nets intersect where the arrow points in the figure. This point is

388

HLVS Migration with Hercules-Explorer Debugging with Hercules-Explorer Connected to Virtuoso and Composer

where the VIA sref should be located. Figure 140 shows the schematic net that these two layout nets should match. Figure 138 Missing Via

389

HLVS Migration with Hercules-Explorer Debugging with Hercules-Explorer Connected to Virtuoso and Composer

Figure 139

Figure 140 Schematic Net that N_21 and N_8 Should Match

If you would like to fix this error, you can add an SREF of the VIA cell to the ADFULAH cell and save the cell. Remember that you have to stream out a new GDS file for Hercules to see the edit. You can also simply rerun Hercules with the ad4ful_fix.gds file provided, by changing the INLIB variable in the ad4ful_lvs.ev runset to ad4ful_fix.gds.

390

HLVS Migration with Hercules-Explorer Detailed Flow: Dracula Rule Files to Hercules LVS Output

Detailed Flow: Dracula Rule Files to Hercules LVS Output

In the preceding example, all of the translation and setup from the Dracula rule file and CDL netlist to the Hercules LVS output required only the following operations: Translate the Dracula rule file with Drac2He. Stream out the LAYOUT to GDSII file. Generate the CDL netlist from Composer. Execute Hercules with output from Drac2He.

If you went through the LVS tutorials in Chapters 7 and 8, you know that many other steps are automatically taking place for this flow to work. For example, Hercules requires a Hercules-formatted netlist, so the CDL netlist is translated automatically. Also, the Hercules LVS uses a list of equivalence points for the hierarchical comparison. This file is generated automatically as well. Figure 141shows a flow diagram of the processes that take place automatically during the Hercules LVS execution. We go through each of these processes in detail, explaining how and when to run them individually for more complicated translation examples. We explain how to debug the results of each step if they do not complete successfully.

391

HLVS Migration with Hercules-Explorer Detailed Flow: Dracula Rule Files to Hercules LVS Output

Figure 141 Detailed Hercules Execution during LVS Migration

PHYSICAL GDSII Layout Database FILES ad4ful_lvs.ev - Runset ad4ful.cdl - Schematic

Hercules LVS RUN

NOTE: NetTran can be run on the command line for combination CDL/Verilog or other complicated netlist translations. hercules - EXECUTION

nettran- xlate CDL Schematic to Hercules Schematic

ev_engine - Device Extraction NOTE: gdsin can be run on the command line for complicated GDSII translations.

ev_netlist Layout Netlist Generation

lsh - Schematic Global, EQUATE, and Equivalence File Generation

lsh - Schematic vs Layout Comparison

PHYSICAL Enterprise Error Database

FILES SUMMARY ERROR HIERARCHY ./compare

The block.RESULTS file contains a summary of the steps found in this diagram. It shows the results of the run you just completed. In the following sections we describe each of these steps, the data created, possible errors you might encounter, and the proper way to debug these errors.

392

HLVS Migration with Hercules-Explorer Detailed Flow: Dracula Rule Files to Hercules LVS Output

Example 62 AD4FUL.RESULTS File from a Hercules HLVS Migration Run

HERCULES (R) Hierarchical Design Verification, DATA OMITTED (C) Copyright Synopsys. All rights reserved.

Called as: hercules ad4ful_lvs.ev - Parsing runset "/l0/group/namrata/tutorial/03.12/tutorial/ Getting_Started_Drac2he_LVS/migration_lvs/ad4ful_lvs.ev" ... DONE - Checking input conditions ... DONE - Translating input schematic netlist ... DONE - Performing DRC checks and/or device extraction ... DONE ### Layout errors, refer to AD4FUL.LAYOUT_ERRORS - Outputting Hercules netlist ... DONE - Performing layout vs schematic comparison ... DONE ### LVS errors, refer to AD4FUL.LVS_ERRORS - Creating EVaccess data ... DONE This Hercules run has performed operations that do not need to be duplicated in subsequent runs. Use the following Hercules command-line option(s) to avoid that unnecessary processing: -s AD4FUL.sch_out Hercules Run: Time= Hercules is done. 0:00:21 User=5.110 System=1.46

Hercules Parses the Output of Drac2He as Input

The first step in the Hercules run is for Hercules to read the runset output from Drac2He and parse it. Below is a list of possible problems you might face at this stage.

393

HLVS Migration with Hercules-Explorer Detailed Flow: Dracula Rule Files to Hercules LVS Output

If you did not check the error.out file you created during the Drac2He translation, you might encounter a parser error at this point in the run, due to a translation error that you missed. If the paths and/or names of your GDSII or CDL files were not correct in your original Dracula rule file, Hercules is not able to find these files and generates an error.

You want to edit the Hercules runset and see if you can correct any translation errors and path or file names. If you are not sure of the reason for the translation error, contact Synopsys Technical Support with a description of the translation problem. If you feel uncomfortable editing the Hercules runset, you can fix the path or file name errors in the Dracula rule file and retranslate before running Hercules.

Reading and Converting the CDL Netlist

Hercules requires a Hercules-formatted netlist for LVS. You have specified the SCHEMATIC_FORMAT as CDL, so Hercules must call the NetTran utility to execute the CDL-to-Hercules format translation. Hercules generates a block.sch_out file, where BLOCK in our example is AD4FUL. This automatic process works only if you are using a single CDL file. Below are a list of other flows that you might encounter during an LVS migration. Multiple CDL Files Combination of CDL and Verilog files Special CDL translation options necessary for NetTran to translate your CDL netlist correctly

For any of these flows, there are two ways to run the NetTran utility with options, rather than the defaults that are set during the Drac2He translation: 1. Run the NetTran utility on the UNIX command line prior to executing Hercules. Or, 2. Set the NETTRAN_OPTIONS in the OPTIONS section of the Hercules runset. The first way to use NetTran options is to run the NetTran utility on the UNIX command line prior to executing Hercules. In this case, you need to update your SCHEMATIC and SCHEMATIC_FORMAT variables in the HEADER section of your runset to reflect the new schematic netlist and format. You choose the name of the schematic netlist, but the SCHEMATIC_FORMAT

394

HLVS Migration with Hercules-Explorer Detailed Flow: Dracula Rule Files to Hercules LVS Output

should be changed to Hercules. For a complete list of the available NetTran options, refer to the Hercules Reference Manual. The second way to use NetTran options is to set the NETTRAN_OPTIONS in the OPTIONS section of the Hercules runset. NETTRAN_OPTIONS allows you to specify a variety of options, such as multiple schematic netlists and formats, special CDL translation options, and other format translation options. For a list of the options available through the NETTRAN_OPTIONS variable, refer to the Hercules Reference Manual. NETTRAN_OPTIONS is listed under the section on OPTIONS and in the Alphabetical List of All Options.

Streaming in Your GDSII File with gdsin

The next step in the Hercules run is to translate the GDSII layout data to the LTL format. Hercules calls the gdsin utility for this translation. Hercules uses the default gdsin utility options. There are two ways to run the gdsin utility with options other than the default: 1. Run the gdsin utility on the UNIX command line prior to executing Hercules. Or, You need to update your INLIB variable to reflect the name of the LTL database you create, and set your LAYOUT_PATH to the location of the ./ layout directory and your FORMAT to LTL (instead of GDSII). For a complete list of the available gdsin options, refer to the Hercules Reference Manual. 2. Set the GDSIN_OPTIONS in the OPTIONS section of the Hercules runset. GDSIN_OPTIONS allows you to specify any special gdsin option inside the Hercules runset, and therefore you do not need to run the gdsin utility on the UNIX command line. Hercules still automatically runs the gdsin utility. For a complete list of the options available through the GDSIN_OPTIONS variable, refer to the Hercules Reference Manual. GDSIN_OPTIONS is listed under the section on OPTIONS and in the Alphabetical List of All Options.

Device Extraction and Connectivity

After Hercules has successfully parsed the runset and translated the CDL and GDSII files, the main Hercules DRC and extraction program, ev_engine, is run. You should not run this program from the UNIX command line, but instead always have Hercules call this program.

395

HLVS Migration with Hercules-Explorer Detailed Flow: Dracula Rule Files to Hercules LVS Output

Ev_engine executes all of the BOOLEAN and other data creation operations. It also extracts the devices and connects the devices and nets. Remember, your device extraction errors appear in the block.LAYOUT_ERRORS file or under Layout Extraction Errors in the Hercules-Explorer LVS window. The errors or warnings from this step in our example are found in the AD4FUL.LAYOUT_ERRORS file.

Generic Differences in Hercules and Dracula Device Extraction

There are fundamental differences in how Dracula and Hercules process data; thus, in rare cases, there is no clearly defined translation from Dracula to Hercules. Specifically, the two tools do not work the same way when they are extracting devices. The next few paragraphs explain the fundamental differences between Draculas and Hercules definitions of device extraction layers, and some general rules to keep in mind when debugging any device extraction errors that occur using a translated runset. Hercules and Dracula both require a recognition layer for every device extraction command. The main difference between the two tools is that the device terminal layers in Dracula do not necessarily contain the device polygons in their layers. The Dracula terminal layers might be conductor layers that only connect to the device terminals instead of actually being the device terminals. In the case of MOSFETS, the Dracula conductor layer polygons are the actual polygons that make up the device terminals, but this is not guaranteed and, in the case of DIODES and RESISTORS, is frequently not true. Note: You might experience some translation errors in versions of Drac2He older than 99.4 because of the use of conductor layers. If this occurs, try translating with a newer version of Drac2He.

MOSFET Device Extraction

In Dracula, a typical MOSFET extraction command looks like the one in our sample rule file, migration_lvs.drac:
ELEMENT MOS[N] NGATE POLY NSD NWELL

The POLY, NSD, and NWELL layers are called conductor layers. These are usually the actual device polygons, but they might be layers that are merely connected to the device polygons. Drac2He translates this as follows:

396

HLVS Migration with Hercules-Explorer Detailed Flow: Dracula Rule Files to Hercules LVS Output

NMOS MN_dev ngate nsd nsd PWELL

Because Hercules requires the actual gate polygon, the device recognition layer (ngate) is used instead of the gate conductor layer (POLY). The NSD layer is the Dracula source/drain conductor layer and is almost always the correct diffusion layer for Hercules. Although Hercules makes a distinction between PMOS and NMOS devices, both extractions work the same way. The translator converts Dracula MOS commands to NMOS Hercules commands unless the device name has a P in it that is not preceded by N, E, or D.

BIPOLAR Device Extraction (BJTs)

In Dracula, a lateral PNP device extraction might look like this:
ELEMENT BJT[PL] COLL CCNT BASE EMIT

Here the COLL layer is the device recognition layer and the CCNT, BASE, and EMIT layers represent conductor layers for the collector, base, and emitter device layers, respectively. As with the MOS device, these layers are frequently, but not always, the same as the actual device polygons. Drac2He would translate this device as:
PNP QPL_dev COLL BASE EMIT { bjt_topology = lateral; bjt_multi_term_layer = collector; }temp=_generated_output_layer

A Dracula command for a vertical NPN device extraction might look like this:
ELEMENT BJT[NV] EMIT COLL BASE ECNT BULK

The emitter is the device recognition layer, and the conductor layers for the collector, base, emitter, and bulk are, respectively, COLL, BASE, ECNT, and BULK. Drac2He would translate this device as:
NPN QNV_dev EMIT BASE COLL SUBSTRATE { bjt_topology = normal; }temp=_generated_output_layer

The BJT translation is the device extraction translation that is most likely to need manual intervention. The translator must determine the correct topology from the name of the device. If there is an L in the device name that is not preceded by a V, Drac2He converts the topology to lateral. Otherwise, the BJT

397

HLVS Migration with Hercules-Explorer Detailed Flow: Dracula Rule Files to Hercules LVS Output

device is assumed to have a normal vertical topology. Dracula is not as strict about the topology and you can specify the Dracula command incorrectly and still get a clean Dracula device extraction. The key to identifying this problem is to look at the graphical data. If the emitter and collector polygons interact at all, the device is definitely not a lateral device. If the collector polygon is completely enclosed in the emitter polygon, the device topology is inverted.

DIODE Device Extraction

In Dracula, a diode extraction command might look like this:
ELEMENT DIO[P] PDIO PSD NSUB

The PDIO layer is the recognition layer for this device. The PSD and NSUB layers are conductor layers for the diode terminals. Drac2He would translate this device as:
DIODE DP_dev pdio psd nsub { diode_type = PN } temp=_generated_output_layer

The translator decides on the DIODE_TYPE by looking for the first occurrence of an N or P in the device name. Because Hercules and Dracula have similar device definitions for diodes, there are seldom translation problems related to diodes. As with all devices, a problem might occur if the Dracula command uses layers that are merely connected to device polygon layers rather than themselves actual device polygon layers. If you are using a version of Drac2He older than 99.4 and this occurs, try a newer version.

CAPACITOR Device Extraction

In Dracula, a capacitor extraction command might look like this:
ELEMENT CAP[CP] PDIO PSD NSUB

The PDIO layer is the recognition layer for this device. The PSD and NSUB layers are conductor layers for the capacitor terminals. Drac2He would translate this device as:
CAP CP_dev pdio psd nsub { }temp=_generated_output_layer

Because Hercules and Dracula have similar device definitions for capacitors, there are seldom translation problems related to capacitors. As with all devices, a problem might occur if the Dracula command uses layers that are merely

398

HLVS Migration with Hercules-Explorer Detailed Flow: Dracula Rule Files to Hercules LVS Output

connected to the device polygon layers rather than themselves actual device polygon layers. If you are using a version of Drac2He older than 99.4 and this occurs, try a newer version.

RESISTOR Device Extraction

In Dracula, a resistor extraction command might look like this:
ELEMENT RES[PD] PDIF RES_CONT

The PDIF layer is the recognition layer for this device and the RES_CONT layer is the conductor layer for the terminals. Drac2He would translate this device as:
RES RPD_dev pdif res_cont res_cont { }temp=_generated_output_layer

One situation where this translation might cause problems is where there is more than one terminal layer polygon at each end of the resistor body. If you are using a version of Drac2He older than 99.4 and this occurs, try a newer version. In rare cases, Hercules is not able to resolve the connectivity of the multiple terminals and you might need to use a SIZE OVER_UNDER command on the RES_CONT layer to merge the multiple polygons.

Layout Netlist Generation

Following the completion of the device extraction and connectivity generation, Hercules calls the ev_netlist program. This program generates the block.net file, which contains the layout netlist in Hercules format. The next program, lsh, reads this file along with the Hercules-formatted schematic netlist, block.sch_out. In rare cases, this operation does not complete correctly. For example, you might run out of disk space during the layout netlist generation of a very large design. If this occurs, you can clean up your disk space and re-execute Hercules with the -N option, which tells Hercules to skip the device extraction and connectivity phase that already completed, and simply call ev_netlist to generate your layout netlist.

399

HLVS Migration with Hercules-Explorer Detailed Flow: Dracula Rule Files to Hercules LVS Output

Generating Schematic Globals, Equates, and the Equivalence File

Once the Hercules ev_netlist program has completely generated the layout netlist, Hercules calls the lsh program to complete the generation of the Hercules runset needed for the schematic versus layout netlist comparison. If you look at the ad4ful_lvs.ev runset output from Drac2He, you notice that there are no SCHEMATIC_GLOBALS, SCHEMATIC_POWER, or SCHEMATIC_GROUND variables defined in the HEADER section. The EQUATE commands are generic and you did not provide an equivalence file. In Example 63 the generic EQUATE commands and COMPARE section in the ad4ful_lvs.ev runset are shown. Example 63 Generic EQUATE Commands Generated by Drac2He
EQUATE PMOS auto_sch_pmos=MP_dev _auto_gate _auto_src _auto_drn _auto_bulk { FILTER=TRUE MERGE_PARALLEL=TRUE MERGE_PARALLEL_CHAINS=TRUE MERGE_SERIES=TRUE MERGE_PATHS=TRUE CHECK_PROPERTIES = {Length Width } FILTER_OPTIONS = { PMOS-1 } TOLERANCE[Length]= { +5.000, -5.000 } TOLERANCE[Width]= { +5.000, -5.000 } } EQUATE NMOS auto_sch_nmos=MN_dev _auto_gate _auto_src _auto_drn _auto_bulk { FILTER=TRUE MERGE_PARALLEL=TRUE MERGE_PARALLEL_CHAINS=TRUE MERGE_SERIES=TRUE MERGE_PATHS=TRUE CHECK_PROPERTIES = {Length Width } FILTER_OPTIONS = { NMOS-1 } TOLERANCE[Length]= { +5.000, -5.000 } TOLERANCE[Width]= { +5.000, -5.000 } } COMPARE { COMPARE_PROPERTIES=TRUE DETECT_PERMUTABLE_PORTS=TRUE EQUATE_BY_NET_NAME=TRUE EXPLODE_ON_ERROR=TRUE FILTER=TRUE MERGE_PARALLEL=TRUE MERGE_PATHS=TRUE MERGE_SERIES=TRUE PARALLEL_MERGE_RATIO=TRUE

400

HLVS Migration with Hercules-Explorer Detailed Flow: Dracula Rule Files to Hercules LVS Output

PROPERTY_WARNING=TRUE PUSH_DOWN_PINS=TRUE PUSH_DOWN_DEVICES=TRUE REMOVE_DANGLING_NETS=TRUE SHORT_EQUIVALENT_NODES=FALSE RETAIN_NEW_DATA=TRUE RETAIN_PREVIOUS_DATA=FALSE TEXT_RESOLVES_PORT_SWAP=FALSE MERGE_PATHS_DEVICE_LIMIT=30 NET_PRINT_LIMIT=100 }

The lsh program creates a new directory within the directory in which you executed the hercules command. The new directory, ./lvsflow (in the run_details directory) contains a file, lvs_include.ev, that is added to the ad4ful_lvs.ev runset. Example 64 shows the file that was created in our tutorial example. Example 64 ./run_details/lvsflow/lvs_include.ev File from the AD4FUL Migration
OPTIONS { SCHEMATIC_GLOBAL = { GND! VDD! } SCHEMATIC_GROUND = { GND! } SCHEMATIC_POWER = { VDD! } } HEADER { EQUIVALENCE = run_details/lvsflow/equiv } EQUATE NMOS MN=MN_DEV GATE SRC DRN BULK { FILTER=TRUE MERGE_PARALLEL=TRUE MERGE_PARALLEL_CHAINS=TRUE MERGE_SERIES=TRUE MERGE_PATHS=TRUE RESTRICT_MERGE_SERIES=TRUE RESTRICT_MERGE_BY_LENGTH=TRUE RESTRICT_MERGE_BY_WIDTH=TRUE USE_TOTAL_WIDTH=TRUE CHECK_PROPERTIES = {Length Width } FILTER_OPTIONS = { NMOS-1 } TOLERANCE[Width]= { +5.000, -5.000 } TOLERANCE[Length]= { +5.000, -5.000 } } EQUATE PMOS MP=MP_DEV GATE SRC DRN BULK { FILTER=TRUE MERGE_PARALLEL=TRUE MERGE_PARALLEL_CHAINS=TRUE MERGE_SERIES=TRUE

401

HLVS Migration with Hercules-Explorer Detailed Flow: Dracula Rule Files to Hercules LVS Output

MERGE_PATHS=TRUE RESTRICT_MERGE_SERIES=TRUE RESTRICT_MERGE_BY_LENGTH=TRUE RESTRICT_MERGE_BY_WIDTH=TRUE USE_TOTAL_WIDTH=TRUE CHECK_PROPERTIES = {Length Width } FILTER_OPTIONS = { PMOS-1 } TOLERANCE[Width]= { +5.000, -5.000 } TOLERANCE[Length]= { +5.000, -5.000 } }

You should notice the OPTIONS section that is appended to the one output from Drac2He. It now includes SCHEMATIC_GLOBALS, SCHEMATIC_POWER, and SCHEMATIC_GROUND. For a complete explanation of how these are generated, review the explanation of these variables in Chapter 4 of the Hercules Reference Manual. Also notice the HEADER section that is appended to the one output from Drac2He. It now includes a path to the EQUIVALENCE file, which is generated automatically after the EQUATES are generated. Finally, notice the new EQUATEs for NMOS and PMOS. These now reflect the correct device names and terminal names based on a search of the layout and schematic netlists.

Details on Filter Option Translation

Part of the function of the EQUATE command for each device is to specify the FILTER_OPTIONS. Filtering options in a Dracula rule file are specified by the commands FILTER-OPT, FILTER-LAY-OPT, and FILTER-SCH-OPT. If the F or G option is used in the LVSCHK command, device filtering is enabled. The F option specifies different filter options for the layout and schematic, while the G option results in the two netlists having the same filter options. There is a predetermined set of filter options for both the F and G options. The FILTEROPT commands allow you to override the preset options. The preset options are: LVSCHK[F]: FILTER-LAY-OPT = BCDEFGHIJKO FILTER-SCH-OPT = FGHIJKO LVSCHK[G] FILTER-OPT = BCDEFGHIJKO Filtering options in a Hercules runset are specified by the FILTER_OPTIONS, FILTER_LAYOUT_OPTIONS, and FILTER_SCHEMATIC variables that are part

402

HLVS Migration with Hercules-Explorer Detailed Flow: Dracula Rule Files to Hercules LVS Output

of the EQUATE command. There are tables in the Hercules Reference Manual (in Chapter 5 under the EQUATE command) that explain each of the FILTER_OPTIONS in detail. Some of the Dracula filter options involving filtering based on path tracing to PADs are not currently supported by Hercules.

Details of Merging, Gate Formation, and Filtering Options

Hercules and Dracula have different terminology relating to the merging of devices, gate formation, and filtering devices. Below is a list of some of these terms. Table 3
Dracula Term

Dracula Versus Hercules Terminology

Hercules Term COMPARE Option Note

LVSCHK Option

Smash parallel devices

Merge parallel devices

MERGE_ PARALLEL = TRUE

Dracula merges (smashes) all MOS, LDD, resistor, capacitor, and diode devices by default, but does not merge BJT devices. MERGE_PARALLEL in Hercules merges all devices including BJTs. You must also set MERGE_PARALLEL = FALSE in the EQUATE commands for PNP or NPN to disable the merging of these devices.

Smash Pseudo Parallel Devices or MOS split-gates Form CMOS gates

Short equivalent nodes

SHORT_ EQUIVALENT_ NODES= TRUE

Gate Recognition

GATE_ RECOGNITION =TRUE

403

HLVS Migration with Hercules-Explorer Detailed Flow: Dracula Rule Files to Hercules LVS Output

Table 3
Dracula Term

Dracula Versus Hercules Terminology

Hercules Term COMPARE Option Note

LVSCHK Option

Filtering Layout and Schematic separately

Filtering in the layout and/or schematic with separate options

FILTER=TRUE

The F option in Dracula turns on a default set of filtering options under the FILTER-LAYOPT command and the FILTER-SCH-OPT command. You must specify the type of layout filtering and type of schematic filtering under the EQUATE command to cause Hercules to do any filtering. The options to do this are FILTER_SCHEMATIC_ OPTIONS and FILTER_LAYOUT_OPTIONS. See the Hercules Reference Manual for more details on filtering options. The G option in Dracula turns on a default set of filtering options under the FILTER-OPT command. The FILTER=TRUE option in Hercules only enables filtering. You must still specify the type of filtering options under the EQUATE command to cause Hercules to do any filtering. The option to do this is FILTER_OPTIONS. See the Hercules Reference Manual or more details on filtering options.

Filtering Layout and Schematic with the same options

Filtering in the layout and schematic

FILTER=TRUE

How the EQUIVALENCE File Is Generated

Once the ./lvsflow directory is complete and the lvs_include.ev file is created, lsh automatically generates an equivalence file. Lsh does a complete name matching and substring name matching analysis, as well as a device and netlist count analysis to determine equivalence points. For this reason, you do not

404

HLVS Migration with Hercules-Explorer Whats Next?

need to have schematic and layout blocks with the same names to get a complete set of equivalence points. Because lsh might generate a number of equivalence points that do not match, your initial LVS run might take slightly longer than is optimal to work through the bad equivalence points. After the first LVS run, a ./run_details/lvsflow/ block.ignore_equiv file is generated that includes all equivalence points that do not match. In the case of our example, ADDER1=ADFULAH is included in this file because that block had an error. From this file you can remove any equivalence points that you want as part of your EQUIVALENCE file and append the file to the end of the ./run_details/lvsflow/equiv file to generate a more accurate EQUIVALENCE file.

Comparing the Layout and Schematic Netlists

Hercules is now ready to perform the layout versus schematic comparison. Hercules calls lsh to run this process. The COMPARE section created during the Drac2He translation contains all the necessary changes to default settings to allow Hercules to match your Dracula results. If you have gone through the tutorial in Chapter 7, as suggested, you should recognize and understand the purpose of all the variable settings in the COMPARE section. Review Chapter 7 for a complete explanation of all the output files generated by Hercules during the comparison operation. If you need to correct something in the COMPARE section of the runset, you can rerun only the COMPARE section using the -C option with the hercules command.

Whats Next?
You have now completed a Dracula to Hercules translation, job execution, and debug example for an LVS rule file. If you plan to write Hercules runsets in the future, or if you want more details on Hercules commands, go back and complete Chapter 8.

405

HLVS Migration with Hercules-Explorer Whats Next?

406

11
Runset Debugger11
This chapter introduces the Hercules Runset Debugger. This tool acts as an interface between Hercules and a graphical editor, automating the process of creating, storing, and viewing the data used to analyze Hercules operation. Any commands that create graphical data, including DRC commands, data creation commands, and device extraction commands, can be monitored using this tool.

About This Chapter

With the following tutorial, you learn how to use the Runset Debugger to analyze and correct a Hercules runset containing both DRC and LVS commands. The Hercules Runset Debugger interfaces to the Synopsys layout editor, Enterprise, and the Cadence layout editor, Virtuoso. This chapter contains a tutorial for each interface, found in the sections Enterprise Interface Tutorial and the Virtuoso Interface Tutorial. Note: If you are using the Enterprise interface, you need an Enterprise license as well as the HERCULES_DEBUGGER license.

407

Runset Debugger About This Chapter

Summary of Progress to This Point

If you have completed the recommended chapters, as outlined in the Learning Schedule, in About This Tutorial, you should at this point have a complete understanding of Hercules and Hercules-Explorer. This includes knowledge of how Hercules DRC and LVS runsets are constructed, how to execute Hercules DRC and LVS jobs, and how to use Hercules-Explorer with either Enterprise or Virtuoso to debug Hercules DRC and LVS results.

Learning Objectives for This Chapter

The tutorial in this chapter is intended to simulate a real design environment for a Hercules runset writer. With this example you learn the following: General applications of the Runset Debugger How to execute the Runset Debugger The major components and functions of the Runset Debugger GUI interface How to choose which command output or check output you want to view in the layout editor How to use the command output or check output to determine errors in your runset design

Before You Start

You should have completed, at a minimum: Chapter 1, Installation and Setup, Chapter 2, An Error-Free Design for DRC. Chapter 3, Single Design Error for DRC, Chapter 4, A Complete Design for DRC, and Chapter 7, Introduction to Hercules HLVS.

If you are unfamiliar with Enterprise, you should also complete the Appendix A, Using Enterprise With Hercules-Explorer.

408

Runset Debugger General Applications of the Runset Debugger

Learning Method: the Design Example

To learn the Hercules Runset Debugger, you use the same four-bit full adder from the examples in Chapters 2 and 3.

General Applications of the Runset Debugger

The Hercules Runset Debugger is designed with the runset writer in mind. In most design environments, you are given a design rule specification and a series of Quality Assurance (QA) cells. In some cases, you might also have small designs with known errors. The Runset Debugger is intended to assist you in constructing a runset or part of a runset by allowing you to look at the intermediate stages in each of the design rules or device extraction commands you are writing. There are two general approaches to analyzing each of your runset commands. The first approach is to construct your entire runset and then, in a UNIX shell, run Hercules on the runset against a set of QA cells. For each command where the output is not what you expected, you can use the Runset Debugger to analyze that command. The second approach is to construct your runset a few commands at a time. After each group of commands is written, use the Runset Debugger to set analysis points and call Hercules to check each command as you write it.

In this tutorial you are going to use the second approach. You have a runset with a few DRC checks and two device extraction commands. You work your way through analyzing each of these commands on a clean design to make sure they are written correctly. If you continue with this approach after you go through the tutorial, your next step is to add a few more DRC commands to the runset and then select those as analysis points.

The Runset File

The runset in this example performs two tasks. The first task is a typical series of DRC checks on the diffusion contacts. The second task is to extract all MOS devices in the design. The Hercules runset is shown in Example 65.

409

Runset Debugger The Runset File

Example 65 Hercules Runset

/* ** Hercules Runset Debugger AD4FUL Tutorial Runset */ HEADER { BLOCK = AD4FUL LAYOUT_PATH = . INLIB = DEBUG.GDS OUTLIB = DEBUG_ref GROUP_DIR = group FORMAT = GDSII } OPTIONS { explorer_data = text_rect = check_ref_lib = err_prefix = ignore_case = layout_ground = layout_power = net_prefix = } true 0.1 false ERR false { VSS } { VDD } net_

ASSIGN { tox (1) poly (5) cont (6) met1 (8) text (63) met2 (10) text (63) psel (14) via (19) pwell (31) } PREPROCESS_OPTIONS { CHECK_PATH_ENDPOINTS = TRUE CHECK_PATH_45 = TRUE CHECK_PATH_90 = FALSE } BOOLEAN psel AND tox BOOLEAN tox NOT ptox BOOLEAN poly AND ntox BOOLEAN poly AND ptox { } { } { } { } temp = ptox temp = ntox temp = ngate temp = pgate

410

Runset Debugger The Runset File

BOOLEAN ptox AND pwell { } BOOLEAN ptox AND pwell { } BOOLEAN ntox NOT pwell { } BOOLEAN ntox NOT pwell { }

temp = pplug temp = pact temp = nact temp = nplug

BOOLEAN pact NOT pgate { } temp = psd BOOLEAN nact NOT ngate { } temp = nsd BOOLEAN cont NOT met1 { COMMENT = "Contact must be covered by met1" VERB0SE = TRUE } (100) ENCLOSE cont BY met1 { COMMENT = "met1 must overlap contact by at least 0.50 um" SPACING < 0.50 TOUCH = TRUE OVERLAP = TRUE } (100) BOOLEAN cont AND nsd { } TEMP = ncont BOOLEAN cont AND psd { } TEMP = pcont BOOLEAN ncont OR pcont { } TEMP = dev_cont SIZE met1 { UNDER_OVER = 2.5 } TEMP = wide_met1 BOOLEAN dev_cont NOT wide_met1 { COMMENT = "contacts in MOS's must be in met1 >= 5.00 um" } (100) SELECT cont INTERACT pplug { } TEMP = pplug_cont SELECT cont INTERACT nplug { } TEMP = nplug_cont BOOLEAN pplug_cont OR nplug_cont { } TEMP = plug_cont BOOLEAN plug_cont NOT wide_met1 { COMMENT = "contacts in wellties or subties must be in met1 >= 5.00 um" } (100) PMOS p pgate psd psd temp = pdev NMOS n ngate nsd nsd temp = ndev CONNECT poly BY pgate

411

Runset Debugger The Runset File

CONNECT CONNECT CONNECT CONNECT CONNECT

poly BY ngate met1 poly nsd psd pplug nplug BY cont met1 met2 BY via pwell BY pplug substrate BY nplug

TEXT { met1 BY met1.text met2 BY met1.text poly BY met1.text } NETLIST GRAPHICS_PROP { net_name (1) instance_name (4) } GRAPHICS_NETLIST { met1 (8) cont (6) tox (1) poly (5) met2 (10) psel (14) via (19) pwell (31) met1.text (63) met2.text (63) ntox (50) ptox (51) ngate (52) pgate (53) nplug (54) pplug (55) nact (56) pact (57) ndev (58) pdev (59) nsd (60) psd (61) explorer_layers }

412

Runset Debugger Enterprise Interface Tutorial

DRC Checks in the Runset

The first two DRC checks, emphasized in Example 65, ensure that all contacts in the design are covered by met1, and that they are enclosed by at least 0.500 m of met1. The other two DRC checks, also emphasized, are specific to the diffusion contacts, those which connect met1 to any tox derivative layers, such as nsd, psd, nplug or pplug. In the runset these contacts are referred to by the dev_count layer and the plug_count layer. The checks make sure that any of these dev_count or plug_count polygons are covered by met1 that is at least 5.00 m wide.

LVS Checks in the Runset

The next set of commands, emphasized in Example 65, are the MOS extraction commands, PMOS and NMOS. You use the Runset Debugger to make sure the device layers for these commands are derived correctly and that all the MOS devices are extracted without errors.

Enterprise Interface Tutorial

The next section of the tutorial shows you how to start Enterprise and then the Runset Debugger through the Enterprise GUI. If you are not using Enterprise, you can skip this section and proceed to the Virtuoso Interface Tutorial.

How to Run the Hercules Runset Debugger with Enterprise

Be sure that you are in the directory where your debug.ev file is located, your_path/tutorial/Getting_Started_Runset_Debugger/debugger/. Enter the command: Enterprise & Look to the upper-right of the Enterprise menu and choose Verification > Debug Runset. Figure 142 shows the Enterprise window and menu. If, for some reason, this menu option is not available, you can also start the Runset Debugger by entering the command hdiDebugger in the Enterprise command window.

413

Runset Debugger Enterprise Interface Tutorial

Figure 142 Enterprise with Runset Debugger Menu Option

This should successfully start the Runset Debugger. Figure 143 shows the Runset Debugger GUI with the Setup window selected.

414

Runset Debugger Enterprise Interface Tutorial

Figure 143 Runset Debugger Setup Window

Using the Setup Window in the Runset Debugger

Now review the fields in the Runset Debugger Setup window, shown in Figure 143. Below is a list of the fields, in the order in which they appear, and a description of their purposes.

415

Runset Debugger Enterprise Interface Tutorial

Runset: You can use this field to tell the Runset Debugger the name of the Hercules runset you are testing. Hercules Options: You can enter Hercules command-line options in this field. These are included when you execute Hercules. For example, if you want to run only a sub-block of a design, enter -b block_name on this line. MILKYWAY button: By default, the Runset Debugger outputs data using the WRITE_MILKYWAY command. Output library path: This field specifies where you want to place the output data from the Runset Debugger. Output library name: This field specifies the name of the output library that you want the Runset Debugger to create. This is not the same as the output library created by Hercules, and it should have a separate name. Starting capture layer: This field specifies the layer number assigned to the first layer included in the WRITE_MILKYWAY command used to generate the output database. Subsequent layers are assigned successive layer numbers.

Filling in the Setup Window

Fill in the Setup window as described below and shown in Figure 144. In the Runset field, enter: debug.ev In the Output library path field, enter: ./ In the Output library name field, enter: tutorial_debug_out

416

Runset Debugger Enterprise Interface Tutorial

Figure 144 Completed Setup Window

Analyzing the Errors window

When you tell the Runset Debugger to start processing a runset, the first thing it does is check the runset for syntax errors and other parse errors or warnings.

417

Runset Debugger Enterprise Interface Tutorial

It also locates any necessary macros or #INCLUDE files and incorporates them into the runset. If any errors are found that would prevent Hercules from running, the Runset Debugger opens the Errors window (shown in Figure 145). The Errors window displays a full list of parsing errors or warnings. In the example, you see a RUNSET ERROR for the undefined keyword VERB0SE. Figure 145 Runset Debugger Errors Window

Correcting Errors
Runsets cannot be edited within the Runset Debugger. In order to fix this RUNSET ERROR, you need to edit the runset. Open the debug.ev runset file in an editor. We use vi for this example. Go to a UNIX window and execute the following: vi debug.ev You find that the O in VERB0SE is actually spelled with a zero by mistake. Correct the spelling to VERBOSE and save the file.

Verifying Corrected Errors

Choose the Setup tab at the top of the Runset Debugger GUI.

418

Runset Debugger Enterprise Interface Tutorial

Click the Apply button at the bottom of the Runset Debugger GUI to reprocess your debug.ev runset. This time the Runset Debugger skips a display of the Errors window and goes directly to the Watchpoints window. Because there are no errors found in the runset, the Runset Debugger goes on to the next step, preparing you to set your watchpoints for debugging. (It is still a good idea to check the contents of the Errors window, though, because it might contain WARNINGS that you should know about.) The Watchpoints window (shown in Figure 146) should appear automatically after the Runset Debugger processes your change to the runset file.

419

Runset Debugger Enterprise Interface Tutorial

Figure 146 Runset Debugger Watchpoints Window

Using the Watchpoints and Review Windows in the Runset Debugger

In Figure 146 you see your processed runset in the Watchpoints window. This is the window where you select the commands you want to analyze. As you

420

Runset Debugger Enterprise Interface Tutorial

scroll through the window, you see that some commands are preceded by a small box. If you click on the box, a pair of eyeglasses appears (see Figure 147), indicating that this command has been selected as a watchpoint. In the next processing step, the Debugger isolates all the commands you selected and any commands upon which they depend. Figure 147 Watchpoints Window

Generally, only a single pane is present in the Watchpoints window. However, for runsets that have multiple parts, such as #INCLUDE or MACRO files, there are two panes present. Figure 148 shows an example of a dual-pane window. The top pane shows the file containing the highlighted command, while the bottom pane shows the complete runset after all the individual files have been combined. The name of the file being displayed is given above each pane.

421

Runset Debugger Enterprise Interface Tutorial

Figure 148 Dual-Pane Watchpoints Window

422

Runset Debugger Enterprise Interface Tutorial

Selecting Watchpoints
Now choose some watchpoints for the Runset Debugger to process. There are search fields in the Watchpoints window above the runset. You can use the down arrow to select the kind of search and the field to the right of the search type to enter a keyword for your search. As mentioned earlier, you are going to work your way through each of the commands in the runset to verify that they are written correctly. For this tutorial, you work on a clean design or QA cell where, if the runset is correct, all MOSFETs should be extracted correctly and there should be no DRC errors. Start by choosing the device extraction commands PMOS and NMOS to verify that the extraction algorithms are correct. Either by using the search feature or by scrolling down in the runset, select the boxes to the left of the PMOS and NMOS extraction commands. Your window should look like the one in Figure 149.

423

Runset Debugger Enterprise Interface Tutorial

Figure 149 Selecting Watchpoints PMOS and NMOS

Using the Review Window

In order to view the new runset with the commands you selected and their dependent commands, click the Review tab to the right of the Watchpoints tab. If you scroll down to the Boolean and device extraction commands, you should see a screen similar to the one in Figure 150.

424

Runset Debugger Enterprise Interface Tutorial

Figure 150 Runset Debugger Review Window

In the Review window, notice that the WRITE_MILKYWAY command has been added to your runset. This command creates the output library you specified in your initial setup, and writes out all of the data in any of the layers referred to by the commands you selected. Scroll through the Review window so that the Boolean commands and WRITE_MILKYWAY command are all showing.

425

Runset Debugger Enterprise Interface Tutorial

Select a few of the Boolean commands as watchpoints and notice how the layers used in these commands are added to the WRITE_MILKYWAY command. At this time you can choose to select one or all of the boxes to the left of the commands in your new runset. For the tutorial, use the Set All button in the upper-left corner of the window to select all of the commands for viewing. Figure 151 shows how your window should look. Figure 151 Selecting Watchpoints in the Review Window

426

Runset Debugger Enterprise Interface Tutorial

Both the Watchpoints and Review windows allow you to select commands for data output. Remember, the Watchpoints window is for selecting the primary commands you want to debug. The Review window is for selecting additional commands for debug, commands upon which the ones you selected in the Watchpoints window are dependent.

Using the Exec Window to Run Hercules and Generate Debug Data
You are now ready to execute Hercules from the Runset Debugger in order to generate the data for the layers you selected as watchpoints, as well as to see if there are any errors in the PMOS and NMOS commands. Click the Exec tab, which is to the right of the Review tab, to execute Hercules. You should notice that the window starts by saying it is running on a run_only.ev runset. The run_only.ev runset is the one you just had the Debugger create for processing. It is saved in your current run directory, ./debugger. As the job runs, the Exec window should show the standard output from your Hercules jobs. Figure 152 shows the Exec window after your job is complete. Notice the END OF RUN message at the bottom of the window.

427

Runset Debugger Enterprise Interface Tutorial

Figure 152 Runset Debugger Exec Window

Scroll up in the Exec window until you see the results of your PMOS and NMOS commands. Figure 153 shows that you have unrecognized devices in both commands.

428

Runset Debugger Enterprise Interface Tutorial

Figure 153 PMOS and NMOS Errors in Exec Window

Using the Results Window and Debugging

Now that you have executed Hercules and identified the commands in your runset that are producing incorrect results, you are ready to use the Runset Debugger to determine why your results are not as expected.

429

Runset Debugger Enterprise Interface Tutorial

Click the Results tab to open the Results window. Figure 154 shows the Results window that should have appeared. This window displays all the commands you selected as watchpoints and has a select button for each layer in the command. These buttons are used to turn the display of each layer on and off. Figure 154 Runset Debugger Results Window

At the top of the Results window there are four buttons that allow you to control the viewing of the layout data the Runset Debugger created. Start by opening a library and a cell to view.

Opening the Output Library and Cell

Click the Open capture library button in the Results window to open the output library in the layout editor. Because you specified the output library in the Runset Debugger, the correct library opens automatically and no dialog box is displayed. Click the Open cell button to select the cell you wish to view. You should see the dialog box shown in Figure 155 with the Library Name field complete.

430

Runset Debugger Enterprise Interface Tutorial

Note: You might want to open your AD4FUL.LAYOUT_ERRORS file in a UNIX shell to see which of the cells in your design has a device extraction error. Because no devices were successfully extracted, you can assume that any of the cells show the error. Click the browse button to the right of the Cell Name field in the Open Cell dialog box, to open the Browse Cell dialog box. This box is shown in Figure 155 on the right, although at this point yours is not complete. The Browse Cell dialog box opens with no cells listed. You need to click the All Cells button to show all of the cell views. Select the TGATE cell from the Cell list in the Browse Cell dialog box. Click OK in the Open Cell dialog box to open the TGATE.HOUT cell. Figure 155 Open Cell and Browse Cell Dialog Boxes

Figure 156 shows the Enterprise window with the Runset Debugger data you have selected to view.

431

Runset Debugger Enterprise Interface Tutorial

Figure 156 Runset Debugger Output Data in TGATE.HOUT Cell

Viewing Options
The cell you are going to use to debug is now open, with all layers and levels of hierarchy viewable. The View Depth button, located to the right of the Open cell button in your Runset Debugger window, allows you to select between viewing the top level of hierarchy or the entire hierarchy. In the example, both of these views are the same because the device layers are all at level 0 in the TGATE cell. The Unmark All button, which is next to the View Depth button, allows you to deselect all of the layers at once so that you can more easily view them one at a time. The select boxes associated with each command in the main Results window are used to control viewing of individual layers. Take a minute to turn on and off some of the layers to see how this viewing works.

432

Runset Debugger Enterprise Interface Tutorial

Solving the Device Extraction Errors

Now go through the device extraction errors using the Results window. Analyze the PMOS devices and leave the NMOS devices as an exercise to do on your own. Before you begin analyzing the PMOS devices, you should know that a PMOS device is designed using a p-type diffusion, ptox in this example, inside of an Ntype well or substrate. Because you have pwell, assume the substrate is of Ntype. In other words, anything NOT pwell is N-type substrate. Start by clicking the Unmark All button in the Debugger window to deselect all layers. Next, select the psel and tox layers and verify the location of the p-type diffusion, ptox. Figure 157 shows the ptox layer. Figure 157 ptox Layer in TGATE

Now select the pwell layer in the Results window. As stated previously, PMOS devices should be located in an N-type well (in this case, not in the pwell).

433

Runset Debugger Enterprise Interface Tutorial

If you look for the Boolean command containing ptox and pwell, which forms the pact layer, you see that no pact layer is generated. Because it is empty and also the layer from which the psd device layer is derived, you are not going to get any PMOS devices. The fact that the pact and psd layers are empty should cause you to look at the Boolean generating the pact layer and realize that it is the wrong relationship between the ptox and pwell layers. Remember, the PMOS devices are located where ptox is, in N-type substrate or NOT pwell. At this time you can make the necessary correction to the debug.ev runset using an editor such as vi, or you can continue and try to find the error with the NMOS device extraction. Your directory has a runset, debug1.ev, with the necessary corrections for the NMOS and PMOS device extraction.

Checking the Updated Runset

Once you think you have identified the cause of the problems in the device extraction commands, you want to correct your runset and execute Hercules again to verify your corrections. Because the flow in this tutorial is designed to check both the DRC and LVS commands, reload the corrected runset, debug1.ev, and rerun Hercules on the entire runset. In cases where you are not sure your changes are correct, you probably want to rerun only the section you have corrected. For the purposes of this tutorial, rerun the entire runset. Click the Setup tab in your Debugger window and enter the runset, debug1.ev. After you also enter the Output library path and the Output library name, your Setup window should look like the one in Figure 158.

434

Runset Debugger Enterprise Interface Tutorial

Figure 158 Runset Debugger Setup Window

Click the Apply button at the bottom of the Setup window. You are now in the Watchpoints window. Select the four commands that send their error output to layer (100). As shown in Figure 159, you should have selected a BOOLEAN NOT, ENCLOSE, and then two more BOOLEAN NOT commands. Finally, also select the PMOS and NMOS commands, and then click the Review tab.

435

Runset Debugger Enterprise Interface Tutorial

Figure 159 Watchpoints Window with DRC and MOS Commands Selected

Figure 160 shows all the commands you selected as they appear in the Review window. You scroll down past the HEADER and ASSIGN sections to see these commands.

436

Runset Debugger Enterprise Interface Tutorial

Figure 160 Review Window with DRC and MOS Commands Selected

Adding the DRC Checks as Debug Points

Before you rerun the corrected runset, select the commands that are associated with the DRC checks you have not verified. Select all of these as

437

Runset Debugger Enterprise Interface Tutorial

watchpoints, in case there are any errors in the DRC checks that you need to debug. For the first two DRC checks, ASSIGN layers are used, so you do not need to select additional commands. For the second two DRC checks, select all of the preceding data creation commands; that is, all commands between the second DRC check (ENCLOSE) and the last DRC check. See the boxes checked in Figure 161.

438

Runset Debugger Enterprise Interface Tutorial

Figure 161 Review Window with All Watchpoints Selected

Once you have selected all of the correct watchpoints, click the Exec tab. When the job is complete, scroll up in the Exec window to make sure there are no device extraction errors in the PMOS and NMOS commands (see Figure 162).

439

Runset Debugger Enterprise Interface Tutorial

Figure 162 Exec Window with No MOS Extraction Errors

440

Runset Debugger Enterprise Interface Tutorial

Solving the DRC Check Errors

As you scroll through the Exec window output, notice that the first BOOLEAN check and the ENCLOSE check output no errors. The following two BOOLEAN checks, however, both output errors. These are the commands you now debug. Click the Results tab. Click the Open capture library button at the top of the Results window. Click the Open cell tab and the Open Cell dialog box appears. You should see the TGATE.HOUT cell in the list of Last Opened Cells. Select TGATE.HOUT from the list and click OK. Figure 163 shows the Open Cell dialog box. Figure 163 Open Cell Dialog Box

Because both Boolean checks involve the wide_met1 layer, start by clicking the Unmark All button in the Debugger window, and then mark the wide_met1 layer. Notice that the wide_met1 layer does not appear in the Enterprise window.

441

Runset Debugger Enterprise Interface Tutorial

Because the design rule states that all MOS contacts and wellties or subties must be covered by metal >=5.00, and you have created this layer and called it wide_met1, you can expect this layer to contain data. However, it is empty, so there is probably an error in the creation of the wide_met1 layer. Select the dev_cont layer to verify that you do have MOS contacts in this cell. Select the met1 layer to verify that there is metal 1 in the cell. You should see that there is metal 1 overlaying the dev_cont layer. You might want to measure the metal 1 layer to verify that it is indeed 5 m wide and should be considered wide_met1. Look at the creation of wide_met1. Because you are undersizing the metal by 2.5, you are actually removing all skinny metal that is less than or equal to 5 m. According to your design rule, you need to remove only the skinny metal that is less than 5 m, so that the wide metal that is left is greater than or equal to 5 m. To fix the problem in the runset you need to change the UNDER_OVER value from 2.5 to 2.49. If you want to verify that this change to the UNDER_OVER value catches the errors with the plug_cont layer, open the ADFULAH cell and go through the same process you did with the dev_cont layer in the TGATE cell.

Verifying the Debugged Runset

Once you have made the change to the UNDER_OVER value, you are ready to verify that your runset is correct. To do this, run Hercules from a UNIX shell or from Hercules-Explorer and verify that you have an empty block.LAYOUT_ERRORS file, or, if you are running in Hercules-Explorer, that no errors are listed in Hercules-Explorer. Below is a sample command for executing Hercules from the command line, using the correctly debugged runset provided by the tutorial directory. You can substitute your own edited runset. hercules debug.ev.clean Once Hercules has completed its run, be sure that you do not have any errors by checking the block.LAYOUT_ERRORS file. Your block.LAYOUT_ERRORS file should look like the one in Example 66. Example 66 AD4FUL.LAYOUT_ERRORS File after Running debug.ev.clean
Library name: DEBUG.DB Structure name: AD4FUL

442

Runset Debugger Summary

Summary
You have now completed the Hercules Runset Debugger tutorial with the Enterprise Layout Editor. You should be able to use the Hercules Runset Debugger in conjunction with Enterprise to construct an error-free Hercules runset. If you do not have the Virtuoso Layout Editor, proceed to the next chapter.

Virtuoso Interface Tutorial

This section is the beginning of the tutorial for the Hercules Debugger in the Virtuoso environment. The tutorial shows you how to start Virtuoso and the Runset Debugger from the pull-down menus.You can skip this section if you do not have the Virtuoso Layout Editor.

Before You Start

The Virtuoso menu files for Hercules-Explorer also contain the Runset Debugger. You should have the SKILL files, skill_menu_4.4.il, skill_filter_4.4.il, and HercDebug_4.4.il, loaded into Virtuoso. Because the Debugger captures graphical data to be displayed by Virtuoso, it needs to create new entries in a temporary techfile. The Cadence design environment allows a site to fully choose the drawing colors and fill patterns in a the site design. The Debugger needs to be told which drawing packets are available in the primitives library for your site. These packets can be found in the display.drf file. Some of these drawing packets are not usable. For example, drawing solid black on a black background would not allow you to see the captured geometry. High contrasting colors and non-overlapping fill patterns show the inputs and outputs of a command with clarity. If you or some of your co-workers are colorblind, color choice is important. Given all of these factors, you need to enter your available drawing packets in the evp.dat resource file. Locate your evp.dat file with the which evp.dat command. Edit this file and locate the section that begins with DFII_TECHFILE_PACKETS. This list defines the available drawing packets and the order in which you would like to see them.

443

Runset Debugger Virtuoso Interface Tutorial

Note: If you find it a problem to change files in the system-wide installation directory, you can create a custom private copy of the evp.dat file. Copy the evp.dat file to the current working directory: cp 'which evp.dat' Place a symbolic link to the EVP executable into the current working directory: ln -s 'which evp' Verify that which evp now reports ./evp. If not, you need to place a dot (.) earlier in your PATH. Edit ./evp.dat to make the changes. Use the drDefinePacket section of ./display.drf for the names of the available packets. The screen shots were taken using: cyan, greendots_S, lime, Unrouted4, yellow, orange, blue, cyandot3dashed, limelhdashed, Unrouted8, and white.

How to Run the Hercules Runset Debugger with Virtuoso

To run the Hercules runset debugger with Virtuoso, from your_path/tutorial/ Getting_started_Runset_Debugger/Virtuoso (or the equivalent location for your site), enter the command: Virtuoso &

Loading Synopsys SKILL Code

In your CIW window, enter: load "{$HERCULES_HOME_DIR}/bin/{$AVANTI_SYSTYPE}/ skill_menu_4.4.il" A successful setup of the Opus environment with the Synopsys tools results in the following message in your icfb window:
function avntLF redefined function avntLM redefined Done. /***********************************/ t

444

Runset Debugger Virtuoso Interface Tutorial

Explorer Explorer Explorer Synopsys t

Msg: Msg: Msg: SKILL

Defined <Key>g -- Probe Selected Object. Defined <Key>p -- Probe Layout Point. Defined <Key>r -- Remove Highlights. environment setup is done

Note: If your SKILL load fails, include an explicit path. For example: load "/l0/synopsys/bin/SUN32_58/skill_menu_4.4.il"

Streaming Out the QA Cells

Before you get started with the Runset Debugger, arrange the layout data from the QA test cells, which is in a dfII database, into a form that Hercules can process. You need to export the data, in stream format, to a GDSII file. Begin the transfer by choosing File > Export > Stream (see Figure 164). Figure 164 Stream

Fill out the dialog box as shown in Figure 165.

445

Runset Debugger Virtuoso Interface Tutorial

Figure 165 Virtuoso Stream Out

Click OK. There should be one warning. See the log file ./PIPO.LOG for more details.

Starting the Runset Debugger

In Virtuoso window, choose File > Open. Choose an existing layout design and open it as read-only. Open the AD4FUL cell in the AD4FUL library by clicking OK. See Figure 166.

446

Runset Debugger Virtuoso Interface Tutorial

Figure 166 Open Cell in Virtuoso

Choose Synopsys Tools > Start Hercules Debugger (see Figure 167).

447

Runset Debugger Virtuoso Interface Tutorial

Figure 167 Starting the Runset Debugger Inside Virtuoso

You should now have successfully started the Runset Debugger. Figure 168 shows the Runset Debugger GUI with the Setup window selected.

448

Runset Debugger Virtuoso Interface Tutorial

Figure 168 Runset Debugger Setup Window

Using the Setup Window in the Runset Debugger

Now review the fields in the Runset Debugger Setup window, shown in Figure 168. The following is a list of the fields, in the order in which they appear, and a description of their purposes.

449

Runset Debugger Virtuoso Interface Tutorial

Runset: Use this field to tell the Runset Debugger the name of the Hercules runset you are testing. Hercules Options: Enter Hercules command-line options in this field. These are included when you execute Hercules. For example, if you want to run only a sub-block of a design, enter: -b block_name

Filename of techfile for layout: This field specifies the path to the techfile of the design data. This matches your QA cells. Output library name: This is the name of the library that is created by the Debugger to hold the captured layer information. Stream-In templatefile: This filename specifies the templatefile that holds the settings used to stream the GDSII data back into the dfII capture library. See the following information on how to create this file. Starting capture layer: This field specifies the layer number assigned to the first layer included in the GRAPHICS_NETLIST command used to generate the output database. Subsequent layers are assigned successive layer numbers.

Filling in the Setup Window

Fill in the Setup window as described here and shown in Figure 174. In the Runset field, enter: debug.ev In the Hercules Options field, enter: -nro In the Filename of techfile for layout field, enter: techfile.txt To create the ASCII version of the technology file, choose Tools > Technology File Manager (see Figure 169).

450

Runset Debugger Virtuoso Interface Tutorial

Figure 169 Tools > Technology File Manager Menu

Choose the Dump option as shown in Figure 170. Figure 170 Technology File Tool Box

Fill in the Dump Technology File dialog box and click OK. See Figure 171.

451

Runset Debugger Virtuoso Interface Tutorial

Figure 171 Dump Technology File

Close the Technology File Manager panel by choosing File > Close. In the Output library name field, enter: tutorial_debug_out To create the stream-in templatefile, choose File > Import > Stream, as shown in Figure 172.

452

Runset Debugger Virtuoso Interface Tutorial

Figure 172 Import > Stream Menu

Fill in the dialog box as shown in Figure 173. The Template File field is the same as the Stream-In template field. The Input File is the same as specified in the runset. The Library Name field must match the Output library name field.

Click the Save button to write the template file. Because we do not want to load the data now, click the Cancel button.

453

Runset Debugger Virtuoso Interface Tutorial

Figure 173 Virtuoso Stream In

In the Stream-In templatefile field, enter: streamIn.il

454

Runset Debugger Virtuoso Interface Tutorial

Figure 174 Completed Setup Window

Click the Apply button to analyze the runset.

Analyzing the Errors Window

When you tell the Runset Debugger to start processing a runset, the first thing it does is check the runset for syntax errors and other parse errors or warnings.

455

Runset Debugger Virtuoso Interface Tutorial

It also locates any necessary macros or #INCLUDE files and incorporates them into the runset. If any errors are found that would prevent Hercules from running, the Runset Debugger opens the Errors window (shown in Figure 175). The Errors window displays a full list of parsing errors or warnings. In the example, you see a RUNSET ERROR for the undefined keyword VERB0SE. Figure 175 Runset Debugger Errors Window

Correcting Errors
Runsets cannot be edited from directly within the Runset Debugger. In order to fix this runset error, you need to edit the runset. Open the debug.ev runset file in an editor. We use vi for this example. Go to a UNIX window and execute the following: vi debug.ev You see that the O in VERB0SE is actually spelled with a 0 by mistake. Correct the spelling to VERBOSE and save the file.

Verifying Corrected Errors

Click the Setup tab at the top of the Runset Debugger GUI. Click the Apply button at the bottom of the Runset Debugger GUI to reprocess your debug.ev runset.

456

Runset Debugger Virtuoso Interface Tutorial

This time the Runset Debugger skips a display of the Errors window and goes directly to the Watchpoints window. Because there are no errors found in the runset, the Runset Debugger goes on to the next step, preparing you to set your watchpoints for debugging. (You should still check the contents of the Errors window, though, because it might contain WARNINGS you should know about.) Figure 176 shows the Watchpoints window that should appear automatically after the Runset Debugger processes your change to the runset file. Figure 176 Runset Debugger Watchpoints Window

457

Runset Debugger Virtuoso Interface Tutorial

Using the Watchpoints and Review Windows in the Runset Debugger

In Figure 176 you see your processed runset in the Watchpoints window. This is the window where you select the commands you want to analyze. As you scroll through the window, you see that some commands are preceded by a small box. If you click on the box, a pair of eyeglasses appears (see Figure 177), indicating that this command has been selected as a watchpoint. In the next processing step, the Debugger isolates all the commands you selected and any commands upon which they depend. Figure 177 Watchpoints Window

Generally, only a single pane is present in the Watchpoints window. However, for runsets that have multiple parts, such as #INCLUDE or MACRO files, there are two panes present. Figure 178 shows an example of a dual-pane window. The top pane shows the file containing the highlighted command, while the bottom pane shows the complete runset after all the individual files have been combined. The name of the file being displayed is given above each pane.

458

Runset Debugger Virtuoso Interface Tutorial

Figure 178 Dual-Pane Watchpoints Window

Selecting Watchpoints
Now choose some watchpoints for the Runset Debugger to process. There are search fields in the Watchpoints window above the runset. You can use the

459

Runset Debugger Virtuoso Interface Tutorial

down arrow to select the kind of search and the field to the right of the search type to enter a keyword for your search. As mentioned earlier, you are going to work your way through each of the commands in the runset to verify that they are written correctly. For this tutorial, you work on a clean design or QA cell where, if the runset is correct, all MOSFETs should be extracted correctly and there should be no DRC errors. Start by choosing a few of the Boolean commands that are used to calculate the derived regions in the transistors of the chip. Put a watchpoint on lines 50, 56, 58, and 60, as shown in Figure 179. These are the calculations of pplug, nplug, psd, and nsd.

460

Runset Debugger Virtuoso Interface Tutorial

Figure 179 Selecting Watchpoints

Using the Review Window

Next click the Review tab to the right of the Watchpoints tab. To view the new runset with the commands you selected and their dependent commands. If you scroll down to the Boolean and device extraction commands, you should see a screen similar to the one in Figure 180.

461

Runset Debugger Virtuoso Interface Tutorial

Figure 180 Runset Debugger Review Window

While you are displaying the Review window you should also notice that the GRAPHICS_NETLIST command has been added to your runset. This command creates the output library you specified in your initial setup, and writes out all the data in any of the layers referred to by the commands you selected. Scroll through the Review window so that the Boolean commands and GRAPHICS_NETLIST command are all showing.

462

Runset Debugger Virtuoso Interface Tutorial

Select a few of the Boolean commands as watchpoints and notice how the layers used in these commands are added to the GRAPHICS_NETLIST command. At this time you can choose to select one or all of the boxes to the left of the commands in your new runset. For the tutorial, use the Set All button in the upper-left corner of the window to select all of the commands for viewing. Figure 181 shows what your window should look like. Figure 181 Selecting Watchpoints in the Review Window

Both the Watchpoints and Review windows allow you to select commands for data output. Remember, the Watchpoints window is for selecting the primary

463

Runset Debugger Virtuoso Interface Tutorial

commands you want to debug. The Review window is for selecting additional commands for debug, commands upon which the ones you selected in the Watchpoints window are dependent.

Using the Exec Window to Run Hercules and Generate Debug Data
You are now ready to run Hercules from the Runset Debugger in order to generate the data for the layers you selected as watchpoints, as well as to see if there are any errors in the PMOS and NMOS commands. Click the Exec tab to the right of the Review tab to execute Hercules. You should notice that the window starts by saying it is running on a run_only.ev runset. The run_only.ev runset is the one you just had the Debugger create for processing and is saved in your current run directory. As the job runs, the Exec window should show the standard output from your Hercules jobs. Figure 182 shows the Exec window after your job is complete. Notice the END OF RUN message at the bottom of the window.

464

Runset Debugger Virtuoso Interface Tutorial

Figure 182 Runset Debugger Exec Window

Using the Results Window and Debugging

Now that you have executed Hercules and identified the commands in your runset that are producing incorrect results, you are ready to use the Runset Debugger to determine why your results are not as expected.

465

Runset Debugger Virtuoso Interface Tutorial

Click the Results tab to the right of the Exec tab to open the Results window. Figure 183 shows the Results window that should appear. This window displays all the commands you selected as watchpoints and has a select button for each layer in the command. These buttons are used to turn the display of each layer on and off. Figure 183 Runset Debugger Results Window

Look at the top of the Results window under the Runset Debugger tabs. There are three buttons that allow you to control the viewing of the layout data the Runset Debugger created. Start by opening a library and a cell to view.

466

Runset Debugger Virtuoso Interface Tutorial

Opening the Output Library and Cell

Click the Open capture library button at the top of the Results window to open the output library in the layout editor. The Runset Debugger at this time is creating the design library called tutorial_debug_out in dfII. A techfile that matches your captured data is attached to the new library. The PIPO command is invoked with the streamIn.il file to load the OUTPUT.GDS file into the design library. You should see the dialog box shown in Figure 184 with the Library Name field complete. For our investigation, we examine the simple inverter contained in the INV cell. Select the cell name INV. Click OK. Figure 184 Open Cell Dialog Box

Figure 185 shows the Virtuoso window with the Runset Debugger data you selected to view.

467

Runset Debugger Virtuoso Interface Tutorial

Figure 185 Runset Debugger Output Data in INV Cell

Viewing Options
The cell you are going to use to debug is now open, with all layers and levels of hierarchy viewable. The View Depth button, located to the right of the Open cell button in your Runset Debugger window, allows you to select between viewing the top level of hierarchy or the entire hierarchy. In the example, both of these views are the same because the device layers are all at level 0 in the TGATE cell. The Unmark All button next to the View Depth button allows you to deselect all of the layers at once so that you can more easily view them one at a time. The

468

Runset Debugger Virtuoso Interface Tutorial

select boxes associated with each command in the main Results window are used to control viewing of individual layers. Take a minute to turn on and off some of the layers to see how this viewing works.

Solving the Device Extraction Errors

Now go through the device extraction errors using the Results window. Analyze the PMOS devices and leave the NMOS devices as an exercise to do on your own. Before you begin analyzing the PMOS devices, you should know that a PMOS device is designed using a p-type diffusion, ptox in the case of this example, inside of an N-type well or substrate. Because you have pwell, assume the substrate is of N-type. In other words, anything NOT pwell is N-type substrate. Start by clicking the Unmark All button in the Debugger window to deselect all layers. Next select the psel and tox layers and verify the location of the p-type diffusion, ptox. Figure 186 shows the tox and psel layers.

469

Runset Debugger Virtuoso Interface Tutorial

Figure 186 tox and psel Layers in INV Cel

Verify the location of the p-type diffusion, ptox. Figure 187shows that the ptox layer looks correct, with p-type diffusion around the upper transistor of the inverter, and part of the well tie below.

470

Runset Debugger Virtuoso Interface Tutorial

Figure 187 ptox Layer in INV Cell

Click Unmark All. Look at the calculation of pgate, the gate area in the PMOS device. This is done in the fourth Boolean command. Select the inputs, the ptox and poly layers. See Figure 188.

471

Runset Debugger Virtuoso Interface Tutorial

Figure 188 ptox and poly Layers in INV Cell

Now deselect them, and click pgate. This appears to be the gate in the PMOS device. In the fifth Boolean, calculate the P plug around the well tie. Deselect all, and select the fifth Boolean input layers, pwell and ptox. See Figure 189.

472

Runset Debugger Virtuoso Interface Tutorial

Figure 189 pwell and ptox Layers in INV Cell

Now deselect them and click on pplug. See Figure 190.

473

Runset Debugger Virtuoso Interface Tutorial

Figure 190 pplug Layer in INV Cell

This appears to be the p-type plug material in the well tie structure. In the sixth Boolean, calculate the active area for PMOS devices. Select only the inputs to the sixth Boolean, pwell and ptox. See Figure 191.

474

Runset Debugger Virtuoso Interface Tutorial

Figure 191 pwell and ptox Layers in INV Cell

Now deselect them and click pact. See Figure 192.

475

Runset Debugger Virtuoso Interface Tutorial

Figure 192 pact Layer in INV Cell

What is shown in Figure 192 does not look like the active area of the PMOS device. Our calculation was BOOLEAN ptox AND pwell {} TEMP=pact. Instead, you should NOT away the ptox that is within the pwell. Close the Virtuoso window for INV by choosing Window > Close. Edit the debug.ev file and change the BOOLEAN command on line 52. It should now read BOOLEAN ptox NOT pwell {} TEMP=pact. Exit from the editor and click the Setup tab. Click Apply so that the runset is reexamined. Select all the Boolean commands and click the Review tab. Click the Exec tab to rerun Hercules on the changed runset. Click the Results tab.

476

Runset Debugger Virtuoso Interface Tutorial

Select Open capture library. Select the INV cell again. Click the Unmark All button. Select the inputs to the calculation of the pact layer. It should look the same. Now deselect them, and click pact. See Figure 193. Figure 193 The Revised pact Layer in INV Cell

What we see in Figure 193 looks like the active area of a PMOS device. Look at the calculation of the source-drain area in the PMOS device. It is layer psd, which is calculated in the penultimate Boolean on your watch list. Deselect all and select the input layers, pgate and pact. See Figure 194.

477

Runset Debugger Virtuoso Interface Tutorial

Figure 194 pgate and pact Layers in INV Cell

Now deselect them and click psd. See Figure 195.

478

Runset Debugger Virtuoso Interface Tutorial

Figure 195 psd Layer in INV Cell

What we see in Figure 195 appears to be the source and drain side of the PMOS device. The PMOS device extraction command in the runset is:
PMOS p pgate psd psd temp = pdev

The calculation of pgate and psd appears to produce correctly three touching regions for the device extraction.

Looking at NMOS Devices

The NMOS device extraction command in the runset is:

479

Runset Debugger Virtuoso Interface Tutorial

NMOS n ngate nsd nsd temp = ndev

Rather than go through all the steps you performed for the PMOS device calculations, look at the final results first to see if everything is correct at the offset. Click Unmark All. Select ngate and nsd. See Figure 196. Figure 196 ngate and nsd Layers in INV Cell

The gate is visible, but where are the source and drain? If ngate is correct, find out what happened to layer nsd. Looking at the last Boolean, select the inputs ngate and nact. See Figure 197.

480

Runset Debugger Virtuoso Interface Tutorial

Figure 197 ngate and nact Layers in INV Cell

The active area of NMOS devices, layer nact, is calculated incorrectly in the seventh Boolean. Select only the inputs pwell and ntox. See Figure 198.

481

Runset Debugger Virtuoso Interface Tutorial

Figure 198 pwell and ntox Layers in INV Cell

The P well marker (pwell) around the active area of the lower N channel device is visible. It looks like the proper N-type thin oxide. N active was calculated incorrectly using the command BOOLEAN ntox NOT pwell {} TEMP=nact. To change the command to a Boolean AND, close the Virtuoso window for INV with Window > Close. Edit debug.ev and change the Boolean on line 54. It should now read BOOLEAN ntox AND pwell {} TEMP=nact. Exit the editor and click the Setup tab. Click the Apply button so that the runset is reexamined. Select all the Boolean commands and click the Review tab.

482

Runset Debugger Virtuoso Interface Tutorial

Click the Exec tab to rerun Hercules on the changed runset. Click the Results tab. Click Open capture library. Select the INV cell again. Select Unmark All. Select the inputs to the calculation of the nact layer. It should look the same. Now deselect them and select nact. See Figure 199. Figure 199 The Revised nact Layer in INV Cell

Now lets see if we have a proper three-terminal region for NMOS extraction. Select only the ngate and nsd layers. See Figure 200.

483

Runset Debugger Summary

Figure 200 The Revised ngate and nsd Layers in INV Cell

Summary
You have now completed the Hercules Runset Debugger tutorial with the Virtuoso Layout Editor. You should be able to use the Hercules Runset Debugger in conjunction with Virtuoso to construct an error-free Hercules runset.

484

A
Using Enterprise With Hercules-Explorer A
In this section you learn how to use the Hercules-Explorer viewing tool in the Enterprise layout editing system. You should already have Enterprise installed on your system and ready for use. As you go through the steps, you might see alternate ways to navigate and activate various components of the GUI, and you are encouraged to try them out.

Introduction to Running Enterprise

Go to the addertest2/ directory you used for the tutorial in Chapter 3, Single Design Error for DRC, your_path/tutorial/addertest2. To bring up the Enterprise window, execute: Enterprise & This starts Enterprise in background mode with the default start-up settings. Two windows appear, as shown in the following figures.

489

Using Enterprise With Hercules-Explorer Introduction to Running Enterprise

Figure 201 Top Window of Enterprise

Figure 202 Bottom Window of Enterprise

In order to stream in a library in Enterprise, you must create a new library and open it first.

Create Library
To create a new library in Enterprise, choose Library > Create from the pulldown menu, in either the top or bottom window.

490

Using Enterprise With Hercules-Explorer Introduction to Running Enterprise

The Create Library dialog box is displayed, as shown in Figure 203. Fill in the Library Name and Tech File Name, as shown. The milkyway.tf techfile is in your addertest2 directory and the Library Path should also be set to the addertest2 directory. Figure 203 Create Library Dialog Box

Click OK in the Create Library dialog box to dismiss it.

Open the Library

To open a library in Enterprise, choose Library > Open from the pull-down menu, in either the top or bottom window. The Open Library dialog box is displayed, as shown in Figure 204.

491

Using Enterprise With Hercules-Explorer Introduction to Running Enterprise

Figure 204 Open Library Dialog Box

Note: Enterprise keeps track of the last five libraries you opened and displays the library information in the Show: Last Opened Library(s) field. Using this list, you can open a library by double clicking its name. Make sure EX_ADDER_2 is in the Library Name field. If it is not, enter the command: EX_ADDER_2 Click OK in the Open Library dialog box to dismiss it. You should get the following message in the console window indicating the library opened successfully:
Opened library "/l0/synopsys/tutorial/addertest2/EX_ADDER_2" successfully in write mode

Stream In the Library

Now that we have created a new library and opened it, we are ready to stream the EX_ADDER_2.GDS file into Enterprise.

492

Using Enterprise With Hercules-Explorer Introduction to Running Enterprise

Using the pull-down menus in the top Enterprise window, choose Utilities > Stream In. You see an empty version of the dialog box shown in Figure 205. Figure 205 Stream In Dialog Box

Fill in the text fields with the information above, including the Stream File Name and Library Name. Click OK when you are finished. In the console window you should see the messages shown in Figure 206. Figure 206 Enterprise Window After Filling in Stream In Dialog Box

Because the library was opened before streaming in, we can now open a cell from the EX_ADDER_2 library.

493

Using Enterprise With Hercules-Explorer Introduction to Running Enterprise

Open a Cell
From the console window, enter: gxwOpenCell Or, from the pull-down menu, choose Cell > Open. In either case, you see the Open Cell dialog box. Figure 207 Open Cell Dialog Box

Navigating this dialog box is similar to working with the previous dialog boxes. Click the browse button immediately to the right of the Cell Name field (indicated by the arrow in Figure 207). Figure 208 shows the Browse Cell dialog box.

494

Using Enterprise With Hercules-Explorer Introduction to Running Enterprise

Figure 208 Browse Cell Dialog Box

Select a Structure
Select INV.CEL;1 in the Browse Cell dialog box, and click OK. The image shown in Figure 209 appears in the main display window. Note: You can also type the information into the text fields in the Open Cell dialog box: Library Name: EX_ADDER_2 Cell Name: INV

495

Using Enterprise With Hercules-Explorer Running Hercules from Enterprise

Figure 209 INV in Main Display Window

Running Hercules from Enterprise

Enterprise has a Verification pull-down menu that allows you to execute Hercules through a GUI interface. On the right side of the menu bar, choose Verification > Hercules-User Runset. You should get the Execute Hercules dialog box shown in Figure 210.

496

Using Enterprise With Hercules-Explorer Running Hercules from Enterprise

Figure 210 Execute Hercules Dialog Box

Fill in the runset file name with adderdrc2_mw.ev, as we did in Figure 210. This is the same runset as adderdrc2.ev, except for two commands in the HEADER section shown here:
OUTLIB = EX_ADDER_2_OUT FORMAT = MILKYWAY

Because we edited the Milkyway database that we streamed into Enterprise, the FORMAT option in the HEADER section is updated to Milkyway in this new runset. We also had to create a new Enterprise output library, EX_ADDER_2_OUT. Our original output library has a default character length maximum of 32. When you use a Milkyway input database, the default character length maximum is 127 for the output database. It is illegal to write this new output data (with

497

Using Enterprise With Hercules-Explorer Using Hercules-Explorer with Enterprise

character lengths of 127) into our old database (with character lengths of 32), therefore we had to create a new output library. Click OK once you have filled in the runset name. After you click OK, Hercules executes. Quickly check your UNIX shell to make sure the Hercules job is running correctly. Hercules must be able to write to the shell, so be sure you do not have any files open while Hercules is executing.

Using Hercules-Explorer with Enterprise

Now that you know how to stream in and create a Milkyway database, we manually open a library and cell and execute Hercules from the Enterprise pulldown menus. We now look at how to use Hercules-Explorer to open our library and cells with DRC errors automatically.

Close Any Open Libraries

Make sure that all libraries are closed. From the pull-down menu in either the top or bottom window, choose Library > Close. The Close Library dialog box appears, as shown in Figure 211. Figure 211 Close Library Dialog Box

498

Using Enterprise With Hercules-Explorer Using Hercules-Explorer with Enterprise

Click OK in the Close Library dialog box. You should get the following message in the console window indicating your library closed successfully:
Saved and closed library "your_path/tutorial/addertest2/ EX_ADDER_2" successfully

Load Hercules-Explorer
In the pull-down menu of the top Enterprise window, choose Verification > Explorer-Explorer DRC. Because you already executed Hercules in your current directory, HerculesExplorer automatically loads the Hercules output. You should see the following Hercules-Explorer and Enterprise windows on your screen. Slide your Hercules-Explorer window over so it is not overlaying the Enterprise window, as we did in Figure 212. Figure 212 Hercules-Explorer and Enterprise Windows

Now we check for errors.

499

Using Enterprise With Hercules-Explorer Using Hercules-Explorer with Enterprise

In the Hercules-Explorer window, select INV in the Layout Block field, automatically opening the EX_ADDER_2 library. Next select 1 : EXTERNAL met1 in the Error Check field. This displays the DRC error in the layout window, as shown in Figure 213. Figure 213 DRC Error Display of INV

Fixing the Error

Now we fix the error and rerun Hercules from the Hercules-Explorer GUI. You should still have the EX_ADDER_2 library and the INV cell open. Edit the vertical M1 polygon to fix the error. You need to shorten this polygon by 1 m. There are various ways to do this. For this example, we choose Edit > Cut in Enterprise and cut a 1-m piece of the polygon. Figure 214 shows how the new INV should appear on your screen.

500

Using Enterprise With Hercules-Explorer Using Hercules-Explorer with Enterprise

Figure 214

New INV

Save the INV cell by choosing Cell > Save from the pull-down menu.

Rerunning Hercules from Hercules-Explorer

Finally, we rerun Hercules from the Hercules-Explorer GUI to determine whether our design is now clean. From the top of the Hercules-Explorer GUI choose File > Execute Hercules. At the top of the Execute Hercules dialog box, click Options. Figure 215 shows of the dialog box that should appear.

501

Using Enterprise With Hercules-Explorer Using Hercules-Explorer with Enterprise

Figure 215 Execute Hercules Dialog Box

Verify that the dialog box is correct and then click Execute at the top of the box. Notice that your Input Library is EX_ADDER_2 and the Output Library is EX_ADDER_2. The Runset File should be adderdrc2.ev. Once Hercules has completed its run, the Hercules-Explorer GUI is updated. If you correctly fixed the design error, you should see NO ERRORS in the Hercules-Explorer GUI, as shown in Figure 216.

502

Using Enterprise With Hercules-Explorer Summary

Figure 216 Clean Hercules-Explorer GUI

Note: If you did not have the Enterprise Grid or Snap feature on, you might get SNAP errors on the polygon you edited.

Summary
You have now completed an example using Hercules, Hercules-Explorer, and Enterprise together to run DRC commands, debug the commands, fix errors, and then rerun in order to verify that you have a clean design. We suggest that you go through a similar exercise on your own with the runset and GDS stream file used in Chapter 4, A Complete Design for DRC, which is an example of multiple errors in a design.

503

Using Enterprise With Hercules-Explorer Summary

504

Index
Numerics
45-degree angles 15, 75 environment 132, 374 version 133, 379 Capacitor extraction 170 Capacitors 175 CASE of LAYERS 121 Case sensitivity 378 CDL 377, 382, 394 CHECK_PROPERTIES 172 CIW window 134, 379, 444 CMP-XX messages 271, 276 code files 3 COMMENT Option 121 COMMENTS in the Hercules runset 121 COMPARE option 296 COMPARE. See HLVS comparison phase 147 COMPARE_DIR 165 COMPARE_PROPERTIES 173 Composer 372 Configuration files initializing 5 CONJUNCTIVE command 121 Connectivity commands and options 171 COPY command 121 COREHI 277 Corner checks as DRC option 71 CONVEX_TO_CONVEX option 76 used in EXTERNAL check 73 used in INTERNAL check 75, 76 CREATE_PORTS 271 Creating ports

A
Accounting file 194 AD4FUL design hierarchy tree 31 layout topology 65 AD4FUL.sum 20, 53 AD4FUL.tech 44 AD4FUL.tech and AD4FUL.vcell 44 AD4FUL.tree0 31 AD4FUL.tree3 40 AD4FUL.vcell 44 ADFUL.tree1 35 ALL_PORTS_TEXTED 262 AND-OR-INVERT logic 177 AREA check 77 ASSIGN section 14 ASSIGN_LAYERS 121 ATTACH_TEXT 149, 168

B
Bipolar transistor extraction 170 BLOCK 12 BOOLEAN commands 170, 426, 463 Bulk pin connections 175, 177

C
Cadence Opus

505

in top block 260 CUT check 76 ENCLOSED 76 TOUCH 74, 76

D
DAC96 LAYOUT_ERRORS 193 DAC96.acct 194 DAC96.cmperr 218 DAC96.cmpsum 208 DAC96.LVS_ERRORS 208 DAC96.sum 196 Data Creation Boolean operator AND example 78, 79 forming new layers with 71 layer used with INTERNAL 80 NOT example 79, 81 check 78 commands 121 new layers added 89, 96 statements 73 Data Creation commands written to TEMP layers 121 Debugging large designs 264 Derived layers 114 DETECT_PERMUTABLE_PORTS 180, 263 Device connectivity 395 definitions 170 netlisting 265 placing in child cell 267 Device extraction 271, 395, 433, 469 BIPOLAR 170, 397 BJTs 397 CAPACITOR 170, 398 DIODE 398 MOSFET 396 RESISTOR 399 Device layers 147 generation 170 Dimensional check with -rc and -N options 122 Directories creating for Hercules setup 2 Documentation downloading 4 Downloading

documentation 4 manuals 4 Drac2He 112 conversion of EDTEXT and HEDTEXT files 376 ERRORS in 133, 376 EXPLORER_DATA option 133, 376 how to run 374 INLIB 133 -N option 114 -N options 122 -OutType option 113 -rc 122 -rc option 114 running 116 Dracula case sensitivity 378 differences between Hercules and 396, 399 DRACULA_DEFAULTS 120 EVACCESS_OPTIONS section 375 filter options 402 HEADER section 375 OPTIONS section 375 output 117, 375 rule file 112, 391 rule file translator 112 syntax matching Hercules syntax 121, 403 translations 391, 396, 399 translator options 113 DRACULA_DEFAULTS OPTIONS section 120 Drain/Source pins 175, 177 DRAM block 263 DRC checks 413 translation 395 translation options 114 window 138 drc3.ev 132, 135

E
EDTEXT file 159, 167, 187, 376, 382 syntax example 187 ENCLOSE check 82 Enterprise and Enterprise output library 497 and Milkyway 497 correcting errors 500

506

how to run 489 running Hercules from 413, 496, 501 running Runset Debugger from 413 selecting a structure 495 short fixing in 318 using Explorer with 498 Enterprise commands gxwOpenCell 57 gxwOpenLibrary 56 Environment accommodating Hercules 4 EQUATE commands 400 option 296 EQUATE_BY_NET_NAME 178 EQUIV option 296 Equivalence file 150, 159, 165, 188 generating 265, 404 guidelines 265 in strict LVS flow 264 setting options and variables 151 Equivalence points 154, 158 matching 266, 404 Error file 19, 52, 85 geometric representation of 52 ERROR hierarchy 120 Error hierarchy 58, 59, 113 alternatives for output files 67 assigning layer number 16, 73 ERR_PREFIX option 67 OUTPUT_BLOCK 12 used for dimensional checks 67 Error highlight options 314 Error output 132, 372 Error vector defined 52 illustrated 52 list in Explorer Checks window 106 output hierarchy options 67 error.out 128 ERRORS 270 in Drac2He 133, 376 in Migration2 example 125 ERRORS and WARNINGS in Drac2He 125, 128 setting up messages for 270 EVACCESS 44 AD4FUL.ev file in 44

OPTIONS section 46 EVACCESS directory 44 AD4FUL.ev file example 44 Explode 174, 287 EXPLODE_ON_ERROR 158, 174, 264, 287 Explorer Checks window 106 connecting to Composer 380 connecting to Virtuoso 380 for error debug 132, 386 HXDRC main window 102 in Composer 372, 386 in Virtuoso 132, 372, 386 information window 121 linking html output to 333 locating shorts in 309, 319 using hxlvs for debug 339 viewing errors in 311 EXPLORER_DATA 166 EXPLORER_DATA option for Drac2He 376 Explorer_DATA option for Drac2He 133 EXTERNAL check 15, 73 error vector created 52 example 67, 73 TOUCH option illustrated 75

F
File transfer protocol (ftp) 1 Filter options 173, 174, 337, 402 FIND_SHORTEST_PATH_BETWEEN_SHORTS. See FSPBTS 326 Flat netlists 152 FLATTEN 261 Floating 156 FORMAT 13 FSPBTS finding shorts with 326 running Hercules with 329

G
Gate pins 175 GDSII 11, 13, 395 and Hercules run options 135, 136 format for Drac2He output 133, 375 layout output from Virtuoso 382 user property separator 135

507

Graphical output 171 GRAPHICS command 73 GRAPHICS_NETLIST 462 Grid checking 168 Ground nets 179 Group files 12 GROUP_DIR 12

H
HEADER as keyword in Runset 164 section BLOCK 12 FORMAT 13 GROUP_DIR 12 INLIB 11 LAYOUT_PATH 11 OUTLIB 12 OUTPUT_BLOCK 12 HEADER section BLOCK 19 HEDTEXT file 376 Hercules and GDSII 135, 136 and STAR-RC 266 case sensitivity 378 COMMENTS 121 comparison phase 172, 180 creating setup directories 2 differences between Dracula and 396, 399 equivalence file 150 ev_engine 395 extraction phase 170, 172, 395 HLVS 145, 146 how to run 188, 413, 444 improving runtimes 264 in the Opus environment 378 licensing 5 LVS device extraction output files 193 LVS html interface 259 output problems and solutions 190, 393 preprocessing options 168 processing hierarchy 152 rerunning 339, 357, 405, 434 results file 191, 193 running 84 running FSPBTS with 329

Runset Debugger. See Runset Debugger 407 runset file results 189 runset OPTIONS 166 schematic netlist file 180, 394, 400 setup 5 syntax matching Dracula syntax 121, 403 texting options 168 Hercules/Explorer/Opus environment 136, 385 HERCULES_HOME_DIR 2, 4 Hierarchical device extraction 147 netlist comparison 150 texting 149 Hierarchical LVS. See HLVS 147 Hierarchy tree AD4FUL design 31 files 30 Highlighting 314, 355 in Virtuoso and Composer 385 nets and devices 349, 385 HLVS 147, 153 comparison phase 147, 153, 156, 157, 405 difficulties presented by 156 extraction phase 147, 156 migration flow 372 versus flat LVS 153 html debug interface 208, 259 HTML documentation 4

I
icfb window 134, 379, 444 IGNORE_CASE 166 INLIB 11 for Drac2He 133, 375 Input layers 114 Installing Hercules executables 3 installing code files 3 Interaction of Data Across a Hierarchy 148 INTERNAL check 75, 120, 121 checking Data Creation layers 78 corner option illustrated 75, 76 DIMENSION option 80 EDGE_45 option 75 example 75 INTERNAL, first dimensional command 120

508

IP blocks, reuse of 264

L
Layer assignments 169 Layout netlisting 171, 271 Layout window in Opus 134, 379 LAYOUT_GROUND 167 LAYOUT_POWER 167 Library cells 155 Licensing Hercules 5 locating TEXT shorts 309 lsh 404 LVS 146 Hierarchical. See HLVS 147 strict flow comparison 260, 296 LVS comparison options 173 COMPARE_PROPERTIES 173 DETECT_PERMUTABLE_PORTS 180 EQUATE_BY_NET_NAME 178 EXPLODE_ON_ERROR 174 FILTER 174 MERGE_PARALLEL 176 MERGE_PATHS 177 MERGE_SERIES 175 PROPERTY_WARNING 173 PUSH_DOWN_DEVICES 179, 270 PUSH_DOWN_PINS 179 REMOVE_DANGLING_NETS 179 RETAIN_NEW_DATA 174 STOP_ON_ERROR 174 LVS comparison output files /lvsflow directory structure 236 DAC96.cmperr 218 DAC96.cmpsum 208 DAC96.lvsdebug 208 LVS comparison phase comparison options 173 LVS device equate options 172 output files 207 LVS debug 304 device extraction ERRORS 298, 300 filtering options missing 304 LAYOUT POWER or LAYOUT GROUND definitions missing 305 merging options missing 304 POWER/GROUND shorts 305 quick checklist 298

schematic globals missing 306 text open ERROR 302 text short ERROR 303 unused text ERROR 301 where to start 341 LVS device equate options CHECK_PROPERTIES 172 FILTER_OPTIONS 173 REL_TOLERANCE 172 LVS device extraction output files 193 AD4FUL.sum 196 DAC96.acct 194 DAC96.LAYOUT_ERRORS 193 DAC96.net 207 technology option files 207 tree files 207 LVS netlist extraction 170 connectivity commands and options 171 device definitions 170 device layer generation 170 graphical output 171 layout netlisting command 171 texting commands 171, 413 lvsflow Directory Structure 236

M
Macros 155 reuse of 264 Manuals downloading 4 Marker layer 261 Memory block 155 MERGE_PARALLEL 176 MERGE_PATHS 177 MERGE_SERIES 175 MESSAGE_ENABLE 271 MESSAGE_ERROR 271 MESSAGE_IDENTIFIERS 271 MESSAGE_SUPPRESS 271 Migration.lvs 375 Miscompares 270 Mistexting 150 MOS_REFERENCE_LAYER 266

N
Naming

509

blocks 155 ports 156 NET_PREFIX 168 NetTran 181, 394 -cdl-chop option 377 NETTRAN_OPTIONS 394, 395

O
Options for Dracula translator 113 for DRC translations 114 priority of EQUATE, EQUIV, or COMPARE 296 OPTIONS section 82, 133, 166, 376 CHECK_REF_LIB 13 EDTEXT 167 ERR_PREFIX 67 EXPLORER_DATA 166 IGNORE_CASE 166 LAYOUT_GROUND 167 LAYOUT_POWER 167 NET_PREFIX 168 SCHEMATIC_GLOBAL 166 SCHEMATIC_GROUND 167 SCHEMATIC_POWER 167 WIDTH 13 Opus 378 environment 132, 374 layout window 134, 379 version 133, 379 OUTLIB 12 Output 72 Dracula 117 hierarchy 120 when OutType option is set to ERROR 122 with PERM omitted 121 Output files 72 OUTPUT_BLOCK 12 OUTPUT_FORMAT for Drac2He 133, 375

in top-level holding structure 59 OUTLIB name for 12 VERBOSE option 68 when output omits 121 Permanent output 72 Pin text 149 Polygon data 147 Port relationships 151, 152 swappability 157 Power nets 179 Preprocessing options 13, 168 ASSIGN_LAYERS 15 CHECK_45 15 CHECK_PATH_45 14 CHECK_PATH_90 14 GRID_CHECK 15 Preserve, sensitivity setting 135 Proper hierarchy 148 PROPERTY_WARNING 173 PUSH_DOWN_DEVICES 179, 270 PUSH_DOWN_PINS 179

R
Redraw command 386 Registering with Synopsys 5 REL_TOLERANCE 172 Release notes 4 REMOVE_DANGLING_NETS 179 REQUIRE_TEXTED_PORTS_MATCH 262 RES_REFERENCE_LAYER 266 Resistors 175 RETAIN_NEW_DATA 174 Rule file 112 Runset OPTIONS section 13 rules, explanation of 71 Runset Debugger 407 correcting errors 418, 433, 441, 456, 469 exec window 427, 440, 464 opening a library and a cell 430, 466 results window 429, 465 review window 424, 437, 439, 461 run_only.ev 427, 464 setup window 415, 435, 449 verifying the debugged runset 442

P
PAD layer 261 Parallel merging 177 Path merging 178 PERM layers 72, 113 example 67, 79, 81 for Data Creation statements 78

510

viewing options 432, 468 watchpoints window 419, 420, 436, 457, 458 Runset file 160 COMMENTS 121 components of 9, 146, 409 example 9, 82, 160 in Hercules LVS 159 running Hercules on 50, 409 Runset header information 164 COMPARE_DIR 165 EQUIV 165 SCHEMATIC 165 SCHEMATIC_FORMAT 165 Runset OPTIONS EDTEXT 167 EXPLORER_DATA 166 IGNORE_CASE 166 LAYOUT_GROUND 167 LAYOUT_POWER 167 NET_PREFIX 168 SCHEMATIC_GLOBAL 166 SCHEMATIC_GROUND 167 SCHEMATIC_POWER 167 Runset rule options CONVEX_TO_CONVEX 76 CUT_OUTSIDE 76, 77 DIMENSION 80 EDGE_45 75 LONGEDGE 74 LONGEDGE_TO_EDGE 74 OVERLAP 82 PARALLEL 82 RANGE 78 SPACING 67, 73, 74, 75, 76, 82 TOUCH 74, 82 Runset setting option 132, 372 translating from Dracula 132, 372

how to freeze 16, 189, 272, 286, 307 how to restart 16, 189, 272, 286, 307 Series chain devices 175 Series merging 176 Setup Hercules 5 Shortest path tool 313 Shorts fixing 318 locating 309 Source drain overlap 266 SPACING value for dimensional checks 76 SPICE 377 Standard cells 155 STAR-RC 266 Start and stop points 321 manually selecting 324 STOP_ON_ERROR 174, 287 Strict LVS flow 259 comparing top-block ports 260 examples 271, 295 general requirements 260 MOS_REFERENCE_LAYER 266 requiring all ports be texted 262 requiring ports to match by name 262 Substrate pin connections 175, 177 SUBSTRATE processing differences 125 Summary (.sum) file 20, 53, 208 error messages written to 67 in LVS job 196 Swappability 157, 263 Symmetry 263 Synopsys registration 5 System-on-Chip (SOC) environment 153

T
TEMP layers 114, 121 VERBOSE option 68 when to use 67, 81 Temporary output 73 TEXT_OPTIONS section 149 Texting commands 171 Texting options 168 ATTACH_TEXT 168 Tolerance 172 Top-level holding structure

S
Schematic netlist 146, 159, 165, 180, 186, 268,

400
SCHEMATIC_FORMAT 165, 394 SCHEMATIC_GLOBAL 166 SCHEMATIC_GLOBALS 400 SCHEMATIC_GROUND 167, 400 SCHEMATIC_POWER 167, 400 Screen scrolling

511

HERCULES_OUT setting 59 OUTPUT_BLOCK setting 12 TOUCH 76 TOUCH and CUT checks 76 Touch options 74 Tree file 30 design statistics definitions 32

W
WARNINGS 270 on the SUBSTRATE translation 128 suppressing 279 WARNINGS and ERRORS in Drac2He 125, 128 Width checks, poly and metal 75 WRITE_MILKYWAY 425

U
Unmatched devices 348, 353 Unmatched nets 348, 353 Using Enterprise With Explorer 489

X
XPROBE 133, 379

Z V
VERBOSE option 68, 120 Virtuoso 372, 378 Virtuoso interface in the Opus environment 133, zipped files, extracting 3

378

512