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 reader’s 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? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviii

Note to Dracula Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviii
Document Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviii
Learning Schedule. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xx
Related Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxii
Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxii
Customer Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii

1. Installation and Setup

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

iii
 Licensing Hercules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Getting Hercules to Run: Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
How to Set Up Your Account . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
What’s Next? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

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

iv
 How to Run Hercules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Run File Results. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
What if My Output Is Not Correct? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Explanation of Error and Summary Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
AD4FUL.RESULTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
AD4FUL.LAYOUT_ERRORS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
AD4FUL.sum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Design Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Hierarchical Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Horizontal Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Efficient Versus Inefficient Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Explanation of Output Tree Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Hierarchy Tree Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
AD4FUL.tree0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
ADFUL.tree1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
AD4FUL.tree3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Miscellaneous Output Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
AD4FUL.tech and AD4FUL.vcell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
evaccess/ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
evaccess/AD4FUL.ev. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
What’s Next? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

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

v
 Viewing Data in Enterprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Layout Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Output Hierarchy Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
What’s Next? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

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

vi
 From Rules to Runsets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Running Hercules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Output Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Error File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Summary File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Viewing Data Creation Layers in Enterprise . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Introducing Hercules-Explorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Running Hercules-Explorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Viewing Errors Using Hercules-Explorer . . . . . . . . . . . . . . . . . . . . . . . . . 104
Using the Checks Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Running Hercules Inside of Hercules-Explorer . . . . . . . . . . . . . . . . . . . . 108
What’s Next? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

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

vii
 -rc and -N Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Running Drac2He with Warnings and Errors . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Translation Results for Migration2 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Output of Translated migration2.drc File . . . . . . . . . . . . . . . . . . . . . . . . . 125
error.out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
What’s Next? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

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

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

viii
 Hierarchical Netlist Comparison. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Designing to Benefit from Hierarchical LVS . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Match the Hierarchy Between Schematic and Layout . . . . . . . . . . . . . . . 153
Defining the Most Beneficial Equivalence Points . . . . . . . . . . . . . . . . . . 154
Match Layout Block Name to Schematic Block Name . . . . . . . . . . . . . . . 155
Match Block Port Names for Blocks That Will Be Equivalence Points . . . 156
Difficulties Presented by Hierarchy in LVS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Devices Floating Out of Equivalence Points. . . . . . . . . . . . . . . . . . . . . . . 156
Port Swappability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Detecting Swappable Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Equivalence Points That are Resolved in Their Parent . . . . . . . . . . . . . . 158
Different Number of Instances of a Cell in the Layout and Schematic . . . 158
Overview of Required and Optional Input Files for LVS . . . . . . . . . . . . . . . . . . 159
The Runset File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Example of an Actual Runset File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
General Runset File Sections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Runset Header Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
General Runset Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Preprocessing Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Texting Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Layer Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
LVS Netlist Extraction Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Device Layer Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Device Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Connectivity Commands and Options . . . . . . . . . . . . . . . . . . . . . . . 171
Texting Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Layout Netlisting Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Graphical Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
LVS Comparison Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
LVS Device Equate Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
LVS Comparison Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
The Schematic Netlist File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
NetTran. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Executing NetTran as a UNIX Shell Command . . . . . . . . . . . . . . . . 181
Executing NetTran by Specifying a SCHEMATIC_FORMAT . . . . . . 185
The EDTEXT File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
The Equivalence File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
Running Hercules LVS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
How to run Hercules LVS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

ix
 Run File Results. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
What if Your Output Is Not Correct? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
Overview of Hercules LVS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
LVS Device Extraction Output Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
DAC96.LAYOUT_ERRORS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
DAC96.acct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
DAC96.sum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
DAC96.net . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Tree Files and Technology Option Files . . . . . . . . . . . . . . . . . . . . . . 207
LVS Comparison Output Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
DAC96.LVS_ERRORS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
DAC96.cmpsum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
DAC96.cmperr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Compare Directory Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
./lvsflow Directory Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
Progress Review of Hercules LVS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
What’s Next? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239

8.
HLVS Advanced Concepts
Learning Objectives for This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
Before You Start. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
General Requirements of a Strict LVS Flow Comparison . . . . . . . . . . . . . . . . 260
Comparing Top-Block Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
Requiring Ports to Match by Name . . . . . . . . . . . . . . . . . . . . . . . . . 262
Requiring All Ports to be Texted . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
Symmetry: Independent and Dependent Swappability . . . . . . . . . . . . . . 263
Guaranteeing Equivalence Point Matching . . . . . . . . . . . . . . . . . . . . . . . 264
Reuse of IP Blocks and Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
Debugging Large Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
Guidelines for a Good Equivalence File . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
Hercules Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
Running Hercules LVS for Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
Runfile Results for Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
Running Hercules LVS for Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 286

x
 Runfile Results for Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
EQUATE, EQUIV, and COMPARE—Which Setting Takes Priority? . . . . . . . . . 296
What’s Next? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296

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

xi
 Correcting the VDD/GND Short . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
Short Finding with FSPBTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
Running Hercules with FSPBTS . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
Viewing the Shortest Path Output . . . . . . . . . . . . . . . . . . . . . . . . . . 330
Running Hercules After All block.LAYOUT_ERRORS Errors Are Fixed . . . . . 332
Step 2: Review your TEXT_OPTIONS, ASSIGN, and TEXT Sections. . . 333
Step 3: Debug All Device Extraction Errors.. . . . . . . . . . . . . . . . . . . . . . . 333
Step 4: Rerun Your Hercules LVS Job . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
Step 5: Review the Equivalence Points.. . . . . . . . . . . . . . . . . . . . . . . . . . 333
Linking Hercules-Explorer to HTML Interface . . . . . . . . . . . . . . . . . 333
Reviewing the LVSDEBUG File . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
Using Hercules-Explorer hxlvs to Debug Specific COMPARE Errors . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356
When Do You Rerun Hercules? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
What’s Next? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357

10. HLVS Migration with Hercules-Explorer

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

xii
 Netlisting Consistency Between Composer and Hercules-Explorer . . . . 377
Case Sensitivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378
Setting up Hercules in the Opus Environment . . . . . . . . . . . . . . . . . . . . . . . . . 378
Starting Opus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379
Loading Synopsys SKILL Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379
Opening Your Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380
Connecting Hercules-Explorer to Virtuoso and Composer . . . . . . . . . . . 380
Executing Hercules LVS in the Opus Environment . . . . . . . . . . . . . . . . . . . . . 382
Highlighting in Virtuoso and Composer . . . . . . . . . . . . . . . . . . . . . . . . . . 385
Debugging with Hercules-Explorer Connected to Virtuoso and Composer . . . 386
Opening the sum.block.block File in Hercules-Explorer. . . . . . . . . . . . . . 386
Detailed Flow: Dracula Rule Files to Hercules LVS Output . . . . . . . . . . . . . . . 391
Hercules Parses the Output of Drac2He as Input . . . . . . . . . . . . . . . . . . 393
Reading and Converting the CDL Netlist . . . . . . . . . . . . . . . . . . . . . . . . . 394
Streaming in Your GDSII File with gdsin . . . . . . . . . . . . . . . . . . . . . . . . . 395
Device Extraction and Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395
Generic Differences in Hercules and Dracula Device Extraction . . . 396
MOSFET Device Extraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396
BIPOLAR Device Extraction (BJTs) . . . . . . . . . . . . . . . . . . . . . . . . . 397
DIODE Device Extraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398
CAPACITOR Device Extraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398
RESISTOR Device Extraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399
Layout Netlist Generation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399
Generating Schematic Globals, Equates, and the Equivalence File . . . . 400
Details on Filter Option Translation . . . . . . . . . . . . . . . . . . . . . . . . . 402
Details of Merging, Gate Formation, and Filtering Options . . . . . . . 403
How the EQUIVALENCE File Is Generated . . . . . . . . . . . . . . . . . . . 404
Comparing the Layout and Schematic Netlists . . . . . . . . . . . . . . . . . . . . 405
What’s Next? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405

11. Runset Debugger

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

xiii
 The Runset File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
DRC Checks in the Runset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413
LVS Checks in the Runset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413
Enterprise Interface Tutorial. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413
How to Run the Hercules Runset Debugger with Enterprise . . . . . . . . . . 413
Using the Setup Window in the Runset Debugger . . . . . . . . . . . . . . . . . . 415
Filling in the Setup Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416
Analyzing the Errors window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417
Correcting Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418
Verifying Corrected Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418
Using the Watchpoints and Review Windows in the Runset Debugger . . 420
Selecting Watchpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423
Using the Review Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424
Using the Exec Window to Run Hercules and Generate Debug Data . . . 427
Using the Results Window and Debugging . . . . . . . . . . . . . . . . . . . . . . . 429
Opening the Output Library and Cell . . . . . . . . . . . . . . . . . . . . . . . . 430
Viewing Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432
Solving the Device Extraction Errors . . . . . . . . . . . . . . . . . . . . . . . . 433
Checking the Updated Runset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434
Adding the DRC Checks as Debug Points . . . . . . . . . . . . . . . . . . . . 437
Solving the DRC Check Errors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441
Verifying the Debugged Runset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
Virtuoso Interface Tutorial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
Before You Start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
How to Run the Hercules Runset Debugger with Virtuoso . . . . . . . . . . . 444
Loading Synopsys SKILL Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444
Streaming Out the QA Cells. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445
Starting the Runset Debugger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446
Using the Setup Window in the Runset Debugger . . . . . . . . . . . . . . . . . . 449
Filling in the Setup Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450
Analyzing the Errors Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455
Correcting Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456
Verifying Corrected Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456
Using the Watchpoints and Review Windows in the Runset Debugger . . 458
Selecting Watchpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459
Using the Review Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461
Using the Exec Window to Run Hercules and Generate Debug Data . . . 464
Using the Results Window and Debugging . . . . . . . . . . . . . . . . . . . . . . . 465
Opening the Output Library and Cell . . . . . . . . . . . . . . . . . . . . . . . . 467

xiv
 Viewing Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468
Solving the Device Extraction Errors . . . . . . . . . . . . . . . . . . . . . . . . 469
Looking at NMOS Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484

A. Using Enterprise With Hercules-Explorer

Introduction to Running Enterprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489

Create Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490
Open the Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491
Stream In the Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492
Open a Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494
Select a Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495
Running Hercules from Enterprise. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496
Using Hercules-Explorer with Enterprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498
Close Any Open Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498
Load Hercules-Explorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499
Fixing the Error. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 500
Rerunning Hercules from Hercules-Explorer . . . . . . . . . . . . . . . . . . . . . . 501
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503

Index

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 1–3 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 1–3,
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 1–3 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
1–3, 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 1–3, 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 1–3 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 Description

Courier Indicates command syntax.

Courier italic Indicates a user-defined value in Synopsys syntax, such as

object_name.

Regular italic A user-defined value that is not Synopsys syntax, such as

a user-defined value in a Verilog statement.

Courier bold Indicates user input—text you type verbatim—in Synopsys

syntax and examples.

Regular bold 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]

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

Control-c 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.

Edit > Copy Indicates a path to a menu command, such as opening the
Edit menu and choosing 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 [email protected] from within North America.
- Find other local support center e-mail addresses at
http://www.synopsys.com/support/support_ctr.
• Telephone your local support center.
- 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.

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:

1
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
Important:
This page includes Synopsys product directories and their locations.

2
 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.

3
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.

4
 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.

5
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/

What’s 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.

6
 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

7
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.”

8
 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

9
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 GDSII-
formatted 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-to-
one 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 polygon’s 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.tree3 evaccess
AD4FUL.tech AD4FUL.tree1 AD4FUL.vcell 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
Be sure to verify that the
• 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

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= 0:00:14 User=11.42 System=0.43

Hercules is done.

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. You can look in the
AD4FUL.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 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 User=0.01 Sys=0.00 Mem=6.302

smart delete of "via"

smart delete of "met2"
smart delete of "cont"
smart delete of "psel"
smart delete of "well"
smart delete of "poly"
smart delete of "tox"

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 A
Cell B

Cell Cell
C 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 = 5
Unique cells = 9
Hierarchical placements = 109
Total design placements = 749
Exploded references = 0
Exploded placements = 0
Total rect count = 1709
Total poly count = 148
Total path count = 204

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

Total vect count = 0

Total data count = 2061
SREF placements = 749
AREFS = 0
AREF placements = 0
DATA = 120
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
POLYHD Level=3 Count= 3 3 0
TGATE Level=3 Count= 2 2 0
CONT Level=4 Count= 6 6 0
VIA Level=3 Count= 2 2 0
INV Level=2 Count= 6 6 0
CONT Level=3 Count= 8 8 0
INVH Level=2 Count= 2 2 0
CONT Level=3 Count= 13 13 0
POLYHD Level=2 Count= 8 8 0
VIA Level=2 Count= 31 31 0
VIA Level=1 Count= 20 20 0

**********************************************************************

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 Ver.Obj
---- -------- ----------- -------------------- ------- ---- ------
met1 20/0 8:0 (0.00, 18.50) (394.00, 337.50) 1458.50 CEL 1
met2 9/0 10:0 (0.50, 0.00) (372.00, 348.00) 3348.00 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 = 4
Unique cells = 6
Hierarchical placements = 18
Total design placements = 73
Exploded references = 8
Exploded placements = 91
Total rect count = 1709
Total poly count = 148
Total path count = 204
Total vect count = 0
Total data count = 2061
SREF placements = 73
AREFS = 0
AREF placements = 0
DATA = 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 = 1
Flat Placements = 1
SREFS = 4
AREFS = 0
AREF placements = 0
Exploded references = 1
Exploded placements = 20
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
Hierarchical Placements = 4
Flat Placements = 4
SREFS = 11
AREFS = 0
AREF placements = 0
Exploded references = 2
Exploded placements = 39
DATA = 156
TEXT = 0
Via = 0
Current Data Counts for Cell:

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

Name Data Text

----- ----- -----
poly 12 0
cont 8 0
met1 59 0
met2 46 0
via 31 0

CELL = INV
Hierarchical Placements = 6
Flat Placements = 24
SREFS = 0
AREFS = 0
AREF placements = 0
Exploded references = 1
Exploded placements = 8
DATA = 19
TEXT = 0
Via = 0
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 = 3
Flat Placements = 12
SREFS = 2
AREFS = 0
AREF placements = 0
Exploded references = 2
Exploded placements = 5
DATA = 23
TEXT = 0
Via = 0
Current Data Counts for Cell:
Name Data Text
----- ----- -----
poly 7 0
cont 3 0

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

met1 8 0
met2 3 0
via 2 0

CELL = INVH
Hierarchical Placements = 2
Flat Placements = 8
SREFS = 0
AREFS = 0
AREF placements = 0
Exploded references = 1
Exploded placements = 13
DATA = 29
TEXT = 0
Via = 0
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 = 2
Flat Placements = 24
SREFS = 0
AREFS = 0
AREF placements = 0
Exploded references = 1
Exploded placements = 6
DATA = 16
TEXT = 2
Via = 0
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

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

CELL = VIA
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

CELL = POLYHD
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
----- ----- -----
poly 1 0
cont 1 0
met1 1 0

CELL = CONT
Hierarchical Placements = 0
Flat Placements = 0
SREFS = 0
AREFS = 0
AREF placements = 0
Exploded references = 0
Exploded placements = 0

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

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

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 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 following levels to the tree0 file:

Hierarchical levels = 4
Unique cells = 6
Hierarchical placements = 18
Total design placements = 73
Exploded references = 7
Exploded placements = 71
Total rect count = 1709
Total poly count = 148
Total path count = 204
Total vect count = 0
Total data count = 2061
SREF placements = 73
AREFS = 0
AREF placements = 0
DATA = 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

AD4FUL Level=0 Count= 1 1 0
ADFULAH Level=1 Count= 4 4 0

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

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
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
What’s Next?

What’s 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
What’s 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 Hercules-
Explorer 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 left-
hand 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

met1 layer
error
polygon

(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 Error-
Free 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
INVH

INVH
INV

INV
INV

INV
INV
INV
ADFULAH

DGATE

DGATE

DGATE
INVH

INVH

INV
INV
INV

INV
INV

INV
ADFULAH

DGATE

DGATE

DGATE
INVH

INVH
INV

INV
INV

INV
INV
INV
ADFULAH
DGATE

DGATE

DGATE
INVH

INVH

INV
INV
INV

INV
INV

INV
ADFULAH

From the hierarchy tree shown in Figure 5 on page 31 in Chapter 2, “An Error-
Free 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

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
What’s 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).

What’s 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 Hercules-
Explorer, 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-to-
edge 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
task—creating 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 = true
} (100)

/* ----------------------------------- 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 ) ( upper right x, y ) Distance
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ADFULAH (103.500, 17.000) (104.000, 58.500) 0.500
AD4FUL (4.500, 60.000) (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 ) ( upper right x, y ) Distance
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
DGATE (28.500, 8.000) (28.500, 18.000) 0.000
DGATE (28.500, 23.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 ) ( upper right x, y ) Distance
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
DGATE (21.090, 16.090) (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 ) ( upper right x, y ) Distance
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ADFULAH (204.000, 53.000) (207.000, 60.000) 3.000
AD4FUL (368.000, 268.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 ) ( upper right x, y )
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
INV (11.500, 6.500) (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 ) ( upper right x, y ) Distance
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
TGATE (11.500, 0.000) (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 (14.500, 9.000) (16.500, 12.000) 0.000

TGATE (21.500, 20.500) (21.500, 23.500) 0.000
TGATE (3.500, 1.000) (4.000, 4.000) 0.500
TGATE (4.000, 0.500) (7.000, 1.000) 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 (6)
met1 (8)
met2 (10)
via (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 Hercules-
Explorer 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
What’s Next?

What’s 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 Error-
Free 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 Description

-BaseCell cellname Specifies gate array base cell. Uses double quotes
around the list when specifying more than one.

-DupDevice Turns on LPE_OPTION,

MOS_ALLOW_DUPLICATE_DEVICE.

-E errorfile Writes errors to file.

-explorer Sets options for debugging with Hercules-Explorer.

-FE errorfile Writes only fatal errors to file.

-IncTechDefs Includes default TECHNOLOGY_OPTIONS section in

runset.

-LvlSize Sets LEVEL_NON_ORTHOGONAL for all SIZE

commands.

-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.

-N Produces non-commented runset.

-nofixtemp Turns off optimization of Dracula TEMPORARY-

LAYERS.

-outgds Sets output format to GDS.

-OutType error | perm Chooses error hierarchy or PERM output definitions for
Dracula OUTPUT cells.

-Parse Parses only command file.

-rc Retains case for all layers as specified in the Dracula

rule file.

115
Hercules DRC Migration
How to Run Drac2He

Argument Description

-ShareBaseCell Turns on SHARED_BASE_CELL for gate array

designs.

-Size number Value by which to increment SIZE.

-text_map textfile Uses a TEXT_MAP file for lower-level text.

-tsub Uses CELL_EXTENT instead of BUILDSUB to

translate Dracula substrate layers.

-V Prints Drac2He version.

-Version Prints product and library version.

commandfile Dracula command file.

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)

/* LENGTH COMMAND TRANSLATED ABOVE */

/* LENGTH MET1 GT 10 OUTPUT e02420_Out 80 */

/* ;metal 1 to metal 2 spacing not less than 1.0

*/

/* 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)

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
/*Converted runset drac2he: VERSION DATA OMITTED */

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 (1)
POLY (5)
WELL (31)
PSEL (14)
CONT (6)
MET1 (8) text(63)
MET2 (10)
VIA (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) /* SAL = 8 */

POLY (11) /* POLY = 11 */
CON (12) /* CON = 12 */
GUARD(26) /* 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 Drac2He Error Output File with -E Option: error.out
/*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*/

/* 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
What’s Next?

drac2he -E error.out migration2.drc > drc2_errorout.ev

The error.out file should no longer contain any errors.

What’s 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
What’s 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 Hercules-
Explorer 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
What’s 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 Hercules-
Explorer 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.

What’s 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
What’s 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 7–9. 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 co
rx 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 less-
than-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 Layout

{ block b
{ port A TOP-NET
{ inst m1=n
{pin A=GATE... } block b
}
A

{block topblock
{ inst x1=block b m1
{ pin TOP-NET=A... }
}

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 A=A { }
EQUIV B=B { }
EQUIV C=C { }
EQUIV I=I { }
EQUIV J=J { }
EQUIV F=F { }
EQUIV G=G { }
EQUIV K=K { }
EQUIV 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 A

B C
C
D
B
E F G
F G
I J H I J
M N
K L K L

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. Sub-
blocks 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 sub-
block 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 Layout

Top Top

A C A C

B D B D

Figure 56 Poor Hierarchical Correlation

Schematic Layout

Top Top

B
A C A F

C E
B D

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 Recommended Schematic Matches Layout
Level N Schematic Layout

Good:

block name buffer buffer

Bad:

block name buffer buf_0

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 Matched vs. Unmatched Block Port Names
Level N Schematic Layout
block A

Good:

port list PYI PYO YI YO PYI PYO YI YO

Bad:

port list PYI PYO YI YO PY PYO Y 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 X
B Y

OUT
C X
D 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 Layout
Block Block
Buffer Buffer

INV INV INV INV

Buffer

INV INV INV INV

After AUTO_EXCLUDE_EQUIV

Schematic Layout
Block Block

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 temp=pdev

BOOL NDIFF NOT NWELL temp=ndev

BOOL PDIFF NOT NWELL temp=subtie

BOOL NDIFF AND NWELL temp=welltie

BOOL POLY AND ndev temp=ngate

BOOL POLY AND pdev temp=pgate

BOOL ndev NOT ngate temp=nsd

BOOL pdev NOT pgate temp=psd

BOOL POLY NOT ngate temp= temp_field

BOOL temp_field NOT pgate temp= tmp_field_poly
BOOL tmp_field_poly AND RESP temp = rpoly
BOOL 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 terminal bulk {
options....} temp = output_definition

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, PMOS-
3, 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
D
G1
G1 G#1 SD#1

G2 G2 G#2

G3 G#3
G3 SD#2
S
S

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 D

G G

S S

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 D

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

S S

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

C G3
B G#2
SD#2

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][-edif-
pa] [-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 Description

-V Print product version.

-Version Print product and library version.

-usage Print NetTran usage.

-cdl file ... Input CDL format netlist(s).

181
Introduction to Hercules HLVS
The Schematic Netlist File

Argument Description

-edif file ... Input EDIF 2 0 0 format netlists.

-edif3 file ... Input EDIF 3 0 0 format netlists.

-hercules file ... Input Hercules format netlists.

-silos file ... Input SILOS format netlists.

-sp file ... Input Spice format netlists.

-verilog file ... Input Verilog format netlists.

-cdl-a Preserve all passive devices (resistors,

capacitors, diodes).

-cdl-chop Remove first character of all instance names.

-cdl-chopDev Remove first character of all device names.

-cdl-fopen model_name... Filter-out devices with specific 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 map file.

-cdl-p Translate instance param to prop if the model has

no instances.

-cdl-P Multiply scale_factor by param_global.

-cdl-R Include unused parameters in the Hercules

netlist.

-cdl-renameDev Prefix device names with type to resolve identical

name conflict.

-cdl-s Don't treat slash as delimiter.

-cdl-U Convert cdl input to upper case.

-edif-f Force EDIF primitives in Hercules netlist.

182
 Introduction to Hercules HLVS
The Schematic Netlist File

Argument Description

-edif-globalNets netName List of EDIF global nets.

...

-edif-p Convert EDIF properties.

-edif-pa Convert all EDIF properties.

-edif-U Convert edif input to upper case.

-sp-fopen model_name ... Filter-out devices with specific model-name.

-sp-fshort model_name ... Filter-out R&C devices with specific model-

name, the two pins will be shorted.

-sp-finst inst_name ... To filter out devices with specific inst_name

(accept wildcard '*').

-sp-fp delimiter Filters out parasitic resistors.

-sp-od pattern Define the order of the output ports from Verilog
to Spice.

-sp-m number Device property multiplication factor.

-sp-S Set '.options scale=1u'

-sp-topCell cell Set name of top cell.

-sp-topCellPorts portName Add ports to Spice/CDL topcell portslist. Must

use option -sp-topCell to specify topcell.

-sp-U Convert spice input to upper case.

-sp-voltThresh number Voltage source threshold value for shorts.

-verilog-b0 netName Verilog global ground net.

-verilog-b1 netName Verilog global power net.

-verilog-R Retain backlashes on verilog net names.

-verilog-U Convert verilog input to upper case.

183
Introduction to Hercules HLVS
The Schematic Netlist File

Argument Description

-verilog-busLSB Verilog bus starts with least significant bit (0) first.

-acct Write accounting file nettran.acct.

-acctFile file Write accounting file file.

-dup Choose the nearest one of duplicate cells.

-equiv file Output skeletal equivalence filename.

-forceGlobalsOn Forced global ports connect to global nets.

-herc-globalNets netName List of Hercules global nets.

...

-logFile file NetTran summary log filename. (default is

nettran.log)

-mprop Expand M property in Hercules netlist.

-msgError NTR-# ... List of messages to upgrade to error.

-msgId Include message ID in message.

-msgSuppress NTR-# ... List of messages to suppress reporting.

-msgTable Print message table and exit.

-namePrefix prefix Prefix for names used in output netlist (default is

NT_ ).

-noflatten Do not flatten cell to instantiate parameters

-rootCell cell Set root cell for netlist output.

-slash Use slash (/) as the hierarchical delimiter.

-undef Write undefined cells to the file undef.log.

-wireLog file Dissolved Nets log filename.

-outType netlist_type Output netlist type: edif, edif3, spice, verilog,

milkyway, and hercules (default).

184
 Introduction to Hercules HLVS
The Schematic Netlist File

Argument Description

-outName file 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 W=13}
{PIN OUT=D IN=G GND=S GND=VBB}}
{INST $1I2=P
{PROP L=1}{PROP W=20.5}
{PIN VDD=D IN=G 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 y-
coordinate 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 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. 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.eqv dac96lvs1.ev
DAC96.LVS_ERRORS dac96.gds dac96lvs1_gds.ev
DAC96.RESULTS dac96.hrc group
DAC96.net dac96.text hercules.log.01_06_15_18
compare dac96_out run_details
dac96 dac96_out.tf

compare:
DAC96 buf4x4 mux or3_ga
Device buf4x8 mux16 or3b
IOBUF corehi mux4 or3c
IPAD corelow nand2 pc_256
/

........... SOME FILES IN THIS DIRECTORY OMITTED ..........

bsel invc nor3c wdec256

bsel8 latr or2 xfer
bsel_a1 lowdec8 or2_ga
bsel_a2 meddec8 or2b
buf4x membidir or2c

189
Introduction to Hercules HLVS
Running Hercules LVS

compare/DAC96:
lay.DAC96 sch.DAC95 sum.DAC95.DAC96

compare/IOBUF:
lay.IOBUF sch.IOBUF sum.IOBUF.IOBUF

compare/IPAD:
lay.IPAD sch.IBUF sum.IBUF.IPAD

.......... SUBDIRECTORIES OF compare/ OMITTED ..........

compare/xfer:
lay.xfer sch.XFER sum.XFER.xfer

group:
dac96_out
HOUT lib lib_1 lib_bck

run_details:
DAC96.acct DAC96.cmpsum DAC96.tree0 DAC96.vcell
DAC96.bbox DAC96.sum DAC96.tree1 evaccess
DAC96.cmperr DAC96.tech DAC96.tree3 lvsflow evaccess
DAC96.bbox DAC96.cmpsum DAC96.tech DAC96.tree1 DAC96.vcell
lvsflow

run_details/evaccess:
DAC96 DAC96.errstr DAC96.msg VA.libs
DAC96.errbin DAC96.ev DAC96.net

run_details/evaccess/DAC96:
#1 #3 #5 #7 #9 compare
#2 #4 #6 #8 cellTOC viewTOC

.
run_details/lvsflow:
lay.tree sch.tree

.................. 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= 0:02:24 User=93.71 System=13.18

Hercules is done.

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 User=0.03 Sys=0.04 Mem=28.799

Check time = 0:00:00 User=0.03 Sys=0.02 Mem=28.799

Check time = 0:00:00 User=0.01 Sys=0.02 Mem=25.767

Check time = 0:00:00 User=0.01 Sys=0.01 Mem=24.767

Check time = 0:00:00 User=0.01 Sys=0.00 Mem=23.799

Check time = 0:00:00 User=0.00 Sys=0.00 Mem=23.799

Total Text time = 0:00:00 User=0.18 Sys=0.17 Mem=33.783

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 V-

2003.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 Hercules-
formatted 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 = TRUE all_ports_texted = FALSE

auto_exclude_equiv = TRUE calculate_class = FALSE
combine_output_files = FALSE compare_properties = TRUE
detect_permutable_ports = TRUE equate_by_device_name = FALSE
equate_by_net_name = TRUE equiv_by_name = FALSE
explode_on_error = TRUE filter = TRUE
find_additional_equivs = FALSE find_duplicate_equivs = FALSE
gate_recognition = FALSE match_by_property = FALSE
matched_ports_continue = FALSE memory_array_comparison = TRUE
merge_parallel = TRUE merge_paths = FALSE
merge_series = FALSE merge_series_gates = FALSE
one_connection_warning = FALSE optional_pins = TRUE
parallel_merge_ratio = FALSE port_swap_on_top_block = FALSE
property_errors_continue = FALSE property_warning = FALSE
push_down_devices = TRUE push_down_pins = TRUE
remove_dangling_nets = TRUE restrict_merge_by_length= FALSE
restrict_merge_by_width = FALSE restrict_merge_series = FALSE
restrict_parallel_merging = FALSE restrict_series_merging = FALSE
require_texted_nets_match = FALSE
require_texted_ports_match = FALSE
retain_new_data = TRUE retain_previous_data = FALSE
schematic_vs_schematic = FALSE short_equivalent_nodes = FALSE
stop_on_error = FALSE stop_on_no_explode_error = FALSE
static_equated_nets = TRUE text_resolves_port_swap = TRUE
use_total_width = FALSE write_netlists = TRUE

209
Introduction to Hercules HLVS
Overview of Hercules LVS

zero_connection_warning = FALSE
evaccess_create_msg = TRUE evaccess_create_netlist = TRUE
evaccess_create_xref = TRUE explorer_data = TRUE
ignore_case = FALSE
net_print_limit = 10 property_tolerance = 0.10
merge_net_warning = 100 merge_net_error = 1000
merge_paths_device_limit = [none]
tolerance_device_count = [none] tolerance_net_count = [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: level 0

DAC95 == DAC96

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 : XX_17
GATE : VDD
Cell : and2c
BULK : VDD
DRN : OUT
SRC : XX_7
GATE : VDD

Layout:
Shared Device : cs_add_ovlp/M3
Cell : nor2c
BULK : GND
DRN : XX_23
SRC : XX_21
GATE : GND
Cell : and2c
BULK : GND
DRN : XX_13
SRC : OUT
GATE : 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 layout = DAC96

Exploding instances of cell "IPAD8"
Exploding instances of cell "OPAD8"
Exploding instances of cell "OGRP1"
Exploding instances of cell "IGRP1"
Partitioning 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: level 0

DAC95 == DAC96

**** 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 sub-
blocks 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 = FALSE auto_exclude_equiv = TRUE

calculate_class = FALSE combine_output_files = FALSE
compare_properties = TRUE detect_permutable_ports = TRUE
equate_by_device_name = FALSE equate_by_net_name = TRUE
filter = TRUE ignore_case = FALSE
match_by_property = FALSE memory_array_comparison = TRUE
merge_parallel = TRUE merge_paths = FALSE
merge_series = FALSE merge_series_gates = FALSE
one_connection_warning = FALSE optional_pins = TRUE
parallel_merge_ratio = FALSE port_swap_on_top_block = FALSE
property_errors_continue = FALSE property_warning = FALSE
push_down_devices = TRUE push_down_pins = TRUE
remove_dangling_nets = TRUE require_texted_nets_match= FALSE
require_texted_ports_match = FALSE restrict_merge_by_length = FALSE
restrict_merge_by_width = FALSE restrict_merge_series = FALSE
short_equivalent_nodes = FALSE static_equated_nets = TRUE
text_resolves_port_swap = TRUE use_total_width = FALSE
zero_connection_warning = FALSE
merge_paths_device_limit = [none] tolerance_device_count = [none]
tolerance_net_count = [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 PushDown Filter Parallel Path/Ser Final

------- -------- ------ -------- -------- -----
8 0 0 0 0 8 INVA
3 0 0 0 0 3 N
1 0 0 0 0 1 NAND2
1 0 0 0 0 1 NOR2
1 0 0 0 0 1 P
------- -------- ------ -------- -------- -----
14 0 0 0 0 14 Total Devices

Initial PushDown Dangle 0 Connect Path/Ser Final

------- -------- ------ -------- -------- -----
17 0 0 0 0 17 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 inva
3 0 0 0 0 3 n
1 0 0 0 0 1 nand2
1 0 0 0 0 1 nor2
1 0 0 0 0 1 p
------- -------- ------ -------- -------- -----
14 0 0 0 0 14 Total Devices

Initial PushDown Dangle 0 Connect Path/Ser Final

------- -------- ------ -------- -------- -----
17 0 0 0 0 17 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 Layout
--------- ------
8 8 [INVA, (inva, invb)]
3 3 [N, n]

233
Introduction to Hercules HLVS
Overview of Hercules LVS

1 1 [NAND2, (nand2, nand2b)]

1 1 [NOR2, (nor2, nor2b)]
1 1 [P, p]
--------- ------
14 14 Total Devices

17 17 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 User=0.00 Sys=0.00 Mem=11.529

Matching Time = 0:00:00 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 Schematic Layout

Unmatched Unmatched
--------- --------- ---------
8 0 0 [INVA, (inva, invb)]
3 0 0 [N, n]
1 0 0 [NAND2, (nand2, nand2b)]
1 0 0 [NOR2, (nor2, nor2b)]
1 0 0 [P, p]
--------- --------- ---------
14 0 0 Total Devices

17 0 0 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 Cross-
Reference 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 Generated Port Sch Net /

Sch Port Lay Port Class Lay Net
--------- --------- ----- ---------
4 BL / BL
5 BLB / BLB
6 DIO / DIO
1 DO / DO
7 GND / GND
2 RD / RD
3 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 = 0

CELL = PADVIA
Flat Placements = 180

CELL = datbidir
Flat Placements = 32

CELL = samp1_a1
Flat Placements = 32

CELL = adr3dec8
Flat Placements = 12

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

CELL = nand2b
Flat Placements = 48

CELL = nand2c
Flat Placements = 24

CELL = pc_64_l_endcell
Flat Placements = 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 = 4

CELL = DFFR4
Flat Placements = 68

CELL = XFER
Flat Placements = 1312

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

CELL = NOR2
Flat Placements = 128

CELL = NOR3
Flat Placements = 16

CELL = PC_256
Flat Placements = 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
What’s Next?

What’s 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
What’s 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 BUF4X4=buf4x4 {}
EQUIV ADR3DEC8=adr3dec8 {}
EQUIV DFFR4=dffr4 {}
EQUIV SAMP4=samp4 {}
EQUIV ADD4B=add4_ovlp {}
EQUIV ADD4B=add4_ga {}
EQUIV MUX_16=mux16 {}
EQUIV PC_256=pc_256 {}
EQUIV BUF4X8=buf4x8 {}
EQUIV MEDDEC_8=meddec8 {}
EQUIV DOUT1=dout1 {}
EQUIV DFFR16=dffr16 {}
EQUIV WDEC_256=wdec256 {}
EQUIV DOUT4=dout4 {}
EQUIV DOUT8=dout8 {}
EQUIV RAM64K=ram64k {}
EQUIV 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.
As stated above, following these guidelines serves two purposes:
• 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.
The two extremes of less-than-optimal performance are:
• Too many equivalence points—In 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 points—In 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.
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 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 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}}
}
}

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 substrate
{mos_reference_layer = "poly";} TEMP=pgates
NMOS n ngate nsd nsd well
{mos_reference_layer = "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 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. 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 Use scroll bar to look further

(with and without errors) down in this file
Note:
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 COMPARE—Which Setting Takes Priority?

EQUATE, EQUIV, and COMPARE—Which 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 }

What’s 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 Hercules-
Explorer 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 = test.ev
root = 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 = TRUE use_total_width = FALSE

write_netlists = TRUE zero_connection_warning = 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 Hercules-
Explorer 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 Hercules-
Explorer 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 cross-
referencing 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 interfaces—here 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 PMOS-
8 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 Hercules-
Explorer 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
What’s 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.

What’s 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
What’s 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 Hercules-
Explorer 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 cross-
probing
• 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 Drac2He

(layout and schematic) (rule file and edtext translation)

CDL GDSII hedtext

runset.ev
Schematic Layout
Runset Runset
Netlist Database

Hercules LVS RUN

PHYSICAL FILES
SUMMARY
Enterprise ERROR
Error Database 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 Hercules-
Explorer/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 Hercules-
Explorer 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 12.500000 22.000000
structure ADFULAH
VSS 51 255 1.400000 2.900000
VDD 51 255 1.700000 45.050000
structure INV
VSS 51 255 17.300000 2.100000
VDD 51 255 15.800000 43.750000
structure DGATE
VSS 51 255 48.300000 3.750000
VDD 51 255 47.700000 45.100000
structure INVH
VSS 51 255 18.200000 2.350000
VDD 51 255 17.750000 42.850000
structure TGATE
VSS 51 255 16.750000 -5.250000
VDD 51 255 16.450000 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 Hercules-

Explorer
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 SPICE-
compatible. 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 cross-
probe 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 Hercules-
Explorer, 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 Hercules-
Explorer 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 Hercules-
Explorer 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 FILES
GDSII
Layout ad4ful_lvs.ev - Runset
Database ad4ful.cdl - Schematic

Hercules LVS RUN

NOTE: NetTran can be run
on the command line for
hercules - EXECUTION
combination CDL/Verilog or
other complicated netlist
translations. nettran- xlate CDL Schematic to
Hercules Schematic

ev_engine - Device Extraction

NOTE: gdsin can be

ev_netlist -
run on the command
Layout Netlist Generation
line for complicated
GDSII translations.
lsh - Schematic Global,
EQUATE, and Equivalence
File Generation

lsh - Schematic vs
Layout Comparison

PHYSICAL FILES

SUMMARY
Enterprise ERROR
Error Database 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= 0:00:21 User=5.110 System=1.46

Hercules is done.

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 Dracula’s 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 FILTER-
OPT 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 Versus Hercules Terminology
Dracula LVSCHK Hercules COMPARE Note
Term Option Term Option

Smash b Merge MERGE_ Dracula merges (smashes) all

parallel parallel PARALLEL = MOS, LDD, resistor, capacitor,
devices devices TRUE 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 S Short SHORT_

Pseudo equivalent EQUIVALENT_
Parallel nodes NODES= TRUE
Devices or
MOS
split-gates

Form C Gate GATE_

CMOS Recognition RECOGNITION
gates =TRUE

403
HLVS Migration with Hercules-Explorer
Detailed Flow: Dracula Rule Files to Hercules LVS Output

Table 3 Dracula Versus Hercules Terminology

Dracula LVSCHK Hercules COMPARE Note
Term Option Term Option

Filtering F Filtering in FILTER=TRUE The F option in Dracula turns

Layout the layout on a default set of filtering
and and/or options under the FILTER-LAY-
Schematic schematic OPT command and the
separately with FILTER-SCH-OPT command.
separate You must specify the type of
options 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.

Filtering G Filtering in FILTER=TRUE The G option in Dracula turns

Layout the layout on a default set of filtering
and and options under the FILTER-OPT
Schematic schematic command. The FILTER=TRUE
with the option in Hercules only enables
same filtering. You must still specify
options 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.

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
What’s 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.

What’s 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
What’s 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 = true
text_rect = 0.1
check_ref_lib = false
err_prefix = ERR
ignore_case = false
layout_ground = { VSS }
layout_power = { VDD }
net_prefix = 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 { } temp = ptox

BOOLEAN tox NOT ptox { } temp = ntox

BOOLEAN poly AND ntox { } temp = ngate

BOOLEAN poly AND ptox { } temp = pgate

410
 Runset Debugger
The Runset File

BOOLEAN ptox AND pwell { } temp = pplug

BOOLEAN ptox AND pwell { } temp = pact

BOOLEAN ntox NOT pwell { } temp = nact

BOOLEAN ntox NOT pwell { } 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 poly BY ngate

CONNECT met1 poly nsd psd pplug nplug BY cont
CONNECT met1 met2 BY via
CONNECT pwell BY pplug
CONNECT 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 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 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 color-
blind, 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 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"

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 let’s 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 pull-
down 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 pull-
down 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, Hercules-
Explorer 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 environment 132, 374

45-degree angles 15, 75 version 133, 379
Capacitor extraction 170
Capacitors 175
A CASE of LAYERS 121
Accounting file 194 Case sensitivity 378
AD4FUL design
CDL 377, 382, 394
hierarchy tree 31
CHECK_PROPERTIES 172
layout topology 65
CIW window 134, 379, 444
AD4FUL.sum 20, 53
AD4FUL.tech 44 CMP-XX messages 271, 276
code files 3
AD4FUL.tech and AD4FUL.vcell 44
COMMENT Option 121
AD4FUL.tree0 31
COMMENTS
AD4FUL.tree3 40
in the Hercules runset 121
AD4FUL.vcell 44 COMPARE option 296
ADFUL.tree1 35
COMPARE. See HLVS comparison phase 147
ALL_PORTS_TEXTED 262 COMPARE_DIR 165
AND-OR-INVERT logic 177
COMPARE_PROPERTIES 173
AREA check 77
Composer 372
ASSIGN section 14 Configuration files
ASSIGN_LAYERS 121 initializing 5
ATTACH_TEXT 149, 168 CONJUNCTIVE command 121
Connectivity commands and options 171
B COPY command 121
Bipolar transistor extraction 170 COREHI 277
BLOCK 12 Corner checks
as DRC option 71
BOOLEAN commands 170, 426, 463
CONVEX_TO_CONVEX option 76
Bulk pin connections 175, 177
used in EXTERNAL check 73
used in INTERNAL check 75, 76
C CREATE_PORTS 271
Cadence Opus Creating ports

505
 in top block 260 documentation 4
CUT check 76 manuals 4
ENCLOSED 76 Drac2He 112
TOUCH 74, 76 conversion of EDTEXT and HEDTEXT files 376
ERRORS in 133, 376
EXPLORER_DATA option 133, 376
D how to run 374
DAC96 LAYOUT_ERRORS 193 INLIB 133
DAC96.acct 194 -N option 114
DAC96.cmperr 218 -N options 122
DAC96.cmpsum 208 -OutType option 113
DAC96.LVS_ERRORS 208 -rc 122
DAC96.sum 196 -rc option 114
Data Creation running 116
Boolean operator Dracula
AND example 78, 79 case sensitivity 378
forming new layers with 71 differences between Hercules and 396, 399
layer used with INTERNAL 80 DRACULA_DEFAULTS 120
NOT example 79, 81 EVACCESS_OPTIONS section 375
check 78 filter options 402
commands 121 HEADER section 375
new layers added 89, 96 OPTIONS section 375
statements 73 output 117, 375
Data Creation commands rule file 112, 391
written to TEMP layers 121 rule file translator 112
Debugging large designs 264 syntax matching Hercules syntax 121, 403
Derived layers 114 translations 391, 396, 399
DETECT_PERMUTABLE_PORTS 180, 263 translator options 113
Device DRACULA_DEFAULTS
connectivity 395 OPTIONS section 120
definitions 170 Drain/Source pins 175, 177
netlisting 265 DRAM block 263
placing in child cell 267 DRC
Device extraction 271, 395, 433, 469 checks 413
BIPOLAR 170, 397 translation 395
BJTs 397 translation options 114
CAPACITOR 170, 398 window 138
DIODE 398 drc3.ev 132, 135
MOSFET 396
RESISTOR 399
E
Device layers 147
EDTEXT file 159, 167, 187, 376, 382
generation 170
syntax example 187
Dimensional check with -rc and -N options 122
Directories ENCLOSE check 82
creating for Hercules setup 2 Enterprise
Documentation and Enterprise output library 497
downloading 4 and Milkyway 497
Downloading correcting errors 500

506
 how to run 489 OPTIONS section 46
running Hercules from 413, 496, 501 EVACCESS directory 44
running Runset Debugger from 413 AD4FUL.ev file example 44
selecting a structure 495 Explode 174, 287
short fixing in 318 EXPLODE_ON_ERROR 158, 174, 264, 287
using Explorer with 498 Explorer
Enterprise commands Checks window 106
gxwOpenCell 57 connecting to Composer 380
gxwOpenLibrary 56 connecting to Virtuoso 380
Environment for error debug 132, 386
accommodating Hercules 4 HXDRC main window 102
EQUATE in Composer 372, 386
commands 400
in Virtuoso 132, 372, 386
option 296
information window 121
EQUATE_BY_NET_NAME 178 linking html output to 333
EQUIV option 296 locating shorts in 309, 319
Equivalence file 150, 159, 165, 188 using hxlvs for debug 339
generating 265, 404 viewing errors in 311
guidelines 265 EXPLORER_DATA 166
in strict LVS flow 264 EXPLORER_DATA option for Drac2He 376
setting options and variables 151
Explorer_DATA option for Drac2He 133
Equivalence points 154, 158
EXTERNAL check 15, 73
matching 266, 404
error vector created 52
Error file 19, 52, 85 example 67, 73
geometric representation of 52 TOUCH option illustrated 75
ERROR hierarchy 120
Error hierarchy 58, 59, 113
alternatives for output files 67 F
assigning layer number 16, 73 File transfer protocol (ftp) 1
ERR_PREFIX option 67 Filter options 173, 174, 337, 402
OUTPUT_BLOCK 12 FIND_SHORTEST_PATH_BETWEEN_SHORTS.
used for dimensional checks 67 See FSPBTS 326
Error highlight options 314 Flat netlists 152
Error output 132, 372 FLATTEN 261
Error vector Floating 156
defined 52 FORMAT 13
illustrated 52 FSPBTS
list in Explorer Checks window 106 finding shorts with 326
output hierarchy options 67 running Hercules with 329
error.out 128
ERRORS 270 G
in Drac2He 133, 376
Gate pins 175
in Migration2 example 125
ERRORS and WARNINGS GDSII 11, 13, 395
in Drac2He 125, 128 and Hercules run options 135, 136
setting up messages for 270 format for Drac2He output 133, 375
layout output from Virtuoso 382
EVACCESS 44
AD4FUL.ev file in 44 user property separator 135

507
Graphical output 171 Runset Debugger. See Runset Debugger 407
GRAPHICS command 73 runset file results 189
GRAPHICS_NETLIST 462 runset OPTIONS 166
Grid checking 168 schematic netlist file 180, 394, 400
Ground nets 179 setup 5
syntax matching Dracula syntax 121, 403
Group files 12
texting options 168
GROUP_DIR 12
Hercules/Explorer/Opus environment 136, 385
HERCULES_HOME_DIR 2, 4
H Hierarchical
HEADER device extraction 147
as keyword in Runset 164 netlist comparison 150
section texting 149
BLOCK 12 Hierarchical LVS. See HLVS 147
FORMAT 13 Hierarchy tree
GROUP_DIR 12 AD4FUL design 31
INLIB 11 files 30
LAYOUT_PATH 11 Highlighting 314, 355
OUTLIB 12 in Virtuoso and Composer 385
OUTPUT_BLOCK 12 nets and devices 349, 385
HEADER section
HLVS 147, 153
BLOCK 19
comparison phase 147, 153, 156, 157, 405
HEDTEXT file 376
difficulties presented by 156
Hercules
extraction phase 147, 156
and GDSII 135, 136
migration flow 372
and STAR-RC 266
versus flat LVS 153
case sensitivity 378
html debug interface 208, 259
COMMENTS 121
comparison phase 172, 180 HTML documentation 4
creating setup directories 2
differences between Dracula and 396, 399 I
equivalence file 150 icfb window 134, 379, 444
ev_engine 395
IGNORE_CASE 166
extraction phase 170, 172, 395
INLIB 11
HLVS 145, 146
for Drac2He 133, 375
how to run 188, 413, 444
Input layers 114
improving runtimes 264
Installing
in the Opus environment 378
Hercules executables 3
licensing 5
installing
LVS device extraction output files 193
code files 3
LVS html interface 259
Interaction of Data Across a Hierarchy 148
output problems and solutions 190, 393
INTERNAL check 75, 120, 121
preprocessing options 168
checking Data Creation layers 78
processing hierarchy 152
corner option illustrated 75, 76
rerunning 339, 357, 405, 434
DIMENSION option 80
results file 191, 193
EDGE_45 option 75
running 84
example 75
running FSPBTS with 329
INTERNAL, first dimensional command 120

508
IP blocks, reuse of 264 schematic globals missing 306
text open ERROR 302
text short ERROR 303
L unused text ERROR 301
Layer assignments 169 where to start 341
Layout netlisting 171, 271 LVS device equate options
Layout window in Opus 134, 379 CHECK_PROPERTIES 172
LAYOUT_GROUND 167 FILTER_OPTIONS 173
LAYOUT_POWER 167 REL_TOLERANCE 172
Library cells 155 LVS device extraction output files 193
Licensing Hercules 5 AD4FUL.sum 196
locating TEXT shorts 309 DAC96.acct 194
lsh 404 DAC96.LAYOUT_ERRORS 193
DAC96.net 207
LVS 146
technology option files 207
Hierarchical. See HLVS 147
tree files 207
strict flow comparison 260, 296
LVS netlist extraction 170
LVS comparison options 173
connectivity commands and options 171
COMPARE_PROPERTIES 173
device definitions 170
DETECT_PERMUTABLE_PORTS 180
device layer generation 170
EQUATE_BY_NET_NAME 178
graphical output 171
EXPLODE_ON_ERROR 174
layout netlisting command 171
FILTER 174
texting commands 171, 413
MERGE_PARALLEL 176
MERGE_PATHS 177 lvsflow Directory Structure 236
MERGE_SERIES 175
PROPERTY_WARNING 173 M
PUSH_DOWN_DEVICES 179, 270 Macros 155
PUSH_DOWN_PINS 179 reuse of 264
REMOVE_DANGLING_NETS 179 Manuals
RETAIN_NEW_DATA 174 downloading 4
STOP_ON_ERROR 174 Marker layer 261
LVS comparison output files
Memory block 155
/lvsflow directory structure 236
MERGE_PARALLEL 176
DAC96.cmperr 218
DAC96.cmpsum 208 MERGE_PATHS 177
DAC96.lvsdebug 208 MERGE_SERIES 175
LVS comparison phase MESSAGE_ENABLE 271
comparison options 173 MESSAGE_ERROR 271
LVS device equate options 172 MESSAGE_IDENTIFIERS 271
output files 207 MESSAGE_SUPPRESS 271
LVS debug 304 Migration.lvs 375
device extraction ERRORS 298, 300 Miscompares 270
filtering options missing 304 Mistexting 150
LAYOUT POWER or LAYOUT GROUND
MOS_REFERENCE_LAYER 266
definitions missing 305
merging options missing 304
POWER/GROUND shorts 305 N
quick checklist 298 Naming

509
 blocks 155 in top-level holding structure 59
ports 156 OUTLIB name for 12
NET_PREFIX 168 VERBOSE option 68
NetTran 181, 394 when output omits 121
-cdl-chop option 377 Permanent output 72
NETTRAN_OPTIONS 394, 395 Pin text 149
Polygon data 147
Port
O relationships 151, 152
Options swappability 157
for Dracula translator 113
Power nets 179
for DRC translations 114
Preprocessing options 13, 168
priority of EQUATE, EQUIV, or COMPARE 296
ASSIGN_LAYERS 15
OPTIONS section 82, 133, 166, 376
CHECK_45 15
CHECK_REF_LIB 13
CHECK_PATH_45 14
EDTEXT 167
CHECK_PATH_90 14
ERR_PREFIX 67
GRID_CHECK 15
EXPLORER_DATA 166
IGNORE_CASE 166 Preserve, sensitivity setting 135
LAYOUT_GROUND 167 Proper hierarchy 148
LAYOUT_POWER 167 PROPERTY_WARNING 173
NET_PREFIX 168 PUSH_DOWN_DEVICES 179, 270
SCHEMATIC_GLOBAL 166 PUSH_DOWN_PINS 179
SCHEMATIC_GROUND 167
SCHEMATIC_POWER 167 R
WIDTH 13
Redraw command 386
Opus 378
Registering with Synopsys 5
environment 132, 374
layout window 134, 379 REL_TOLERANCE 172
version 133, 379 Release notes 4
OUTLIB 12 REMOVE_DANGLING_NETS 179
Output 72 REQUIRE_TEXTED_PORTS_MATCH 262
Dracula 117 RES_REFERENCE_LAYER 266
hierarchy 120 Resistors 175
when OutType option is set to ERROR 122 RETAIN_NEW_DATA 174
with PERM omitted 121 Rule file 112
Output files 72 Runset
OUTPUT_BLOCK 12 OPTIONS section 13
OUTPUT_FORMAT for Drac2He 133, 375 rules, explanation of 71
Runset Debugger 407
correcting errors 418, 433, 441, 456, 469
P exec window 427, 440, 464
PAD layer 261 opening a library and a cell 430, 466
Parallel merging 177 results window 429, 465
Path merging 178 review window 424, 437, 439, 461
PERM layers 72, 113 run_only.ev 427, 464
example 67, 79, 81 setup window 415, 435, 449
for Data Creation statements 78 verifying the debugged runset 442

510
 viewing options 432, 468 how to freeze 16, 189, 272, 286, 307
watchpoints window 419, 420, 436, 457, 458 how to restart 16, 189, 272, 286, 307
Runset file 160 Series chain devices 175
COMMENTS 121 Series merging 176
components of 9, 146, 409 Setup
example 9, 82, 160 Hercules 5
in Hercules LVS 159 Shortest path tool 313
running Hercules on 50, 409 Shorts
Runset header information 164 fixing 318
COMPARE_DIR 165 locating 309
EQUIV 165 Source drain overlap 266
SCHEMATIC 165 SPACING value for dimensional checks 76
SCHEMATIC_FORMAT 165 SPICE 377
Runset OPTIONS Standard cells 155
EDTEXT 167
STAR-RC 266
EXPLORER_DATA 166
Start and stop points 321
IGNORE_CASE 166
manually selecting 324
LAYOUT_GROUND 167
LAYOUT_POWER 167 STOP_ON_ERROR 174, 287
NET_PREFIX 168 Strict LVS flow 259
SCHEMATIC_GLOBAL 166 comparing top-block ports 260
SCHEMATIC_GROUND 167 examples 271, 295
SCHEMATIC_POWER 167 general requirements 260
Runset rule options MOS_REFERENCE_LAYER 266
CONVEX_TO_CONVEX 76 requiring all ports be texted 262
CUT_OUTSIDE 76, 77 requiring ports to match by name 262
DIMENSION 80 Substrate pin connections 175, 177
EDGE_45 75 SUBSTRATE processing differences 125
LONGEDGE 74 Summary (.sum) file 20, 53, 208
LONGEDGE_TO_EDGE 74 error messages written to 67
OVERLAP 82 in LVS job 196
PARALLEL 82 Swappability 157, 263
RANGE 78 Symmetry 263
SPACING 67, 73, 74, 75, 76, 82 Synopsys registration 5
TOUCH 74, 82 System-on-Chip (SOC) environment 153
Runset setting option 132, 372
translating from Dracula 132, 372
T
TEMP layers 114, 121
S VERBOSE option 68
Schematic netlist 146, 159, 165, 180, 186, 268, when to use 67, 81
400 Temporary output 73
SCHEMATIC_FORMAT 165, 394
TEXT_OPTIONS section 149
SCHEMATIC_GLOBAL 166
Texting commands 171
SCHEMATIC_GLOBALS 400
Texting options 168
SCHEMATIC_GROUND 167, 400 ATTACH_TEXT 168
SCHEMATIC_POWER 167, 400 Tolerance 172
Screen scrolling Top-level holding structure

511
 HERCULES_OUT setting 59 W
OUTPUT_BLOCK setting 12 WARNINGS 270
TOUCH 76 on the SUBSTRATE translation 128
TOUCH and CUT checks 76 suppressing 279
Touch options 74 WARNINGS and ERRORS
Tree file 30 in Drac2He 125, 128
design statistics definitions 32 Width checks, poly and metal 75
WRITE_MILKYWAY 425
U
Unmatched devices 348, 353 X
Unmatched nets 348, 353 XPROBE 133, 379
Using Enterprise With Explorer 489
Z
V
VERBOSE option 68, 120 zipped files, extracting 3
Virtuoso 372, 378
Virtuoso interface in the Opus environment 133,
378

512