StarRC User Guide And Command Reference Star RC

StarRC_User_Guide

User Manual:

Open the PDF directly: View PDF .
Page Count: 934 [warning: Documents this large are best viewed by clicking the View PDF Link!]

Preface
Part I: StarRC User Guide
Part II: StarRC Command Reference

StarRC™

User Guide and Command Reference

Version F-2011.06, June 2011

StarRC User Guide and Command Reference, version F-2011.06 ii

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, AEON, AMPS, ARC, Astro, Behavior Extracting Synthesis Technology, Cadabra, CATS, Certify, Chipidea,

CHIPit, CODE V, CoMET, Confirma, CoWare, Design Compiler, DesignSphere, DesignWare, Eclypse, EMBED-IT!,

Formality, Galaxy Custom Designer, Global Synthesis, HAPS, HapsTrak, HDL Analyst, HSIM, HSPICE, Identify, Leda,

LightTools, MAST, MaVeric, METeor, ModelTools, NanoSim, NOVeA, OpenVera, ORA, PathMill, Physical Compiler,

PrimeTime, SCOPE, SiVL, SNUG, SolvNet, Sonic Focus, STAR Memory System, Syndicated, Synplicity, Synplify,

Synplify Pro, Synthesis Constraints Optimization Environment, TetraMAX, the Synplicity logo, UMRBus, VCS, Vera, and

YIELDExplorer are registered trademarks of Synopsys, Inc.

Trademarks (™)

AFGen, Apollo, ASAP, Astro-Rail, Astro-Xtalk, Aurora, AvanWaves, BEST, Columbia, Columbia-CE, Cosmos, CosmosLE,

CosmosScope, CRITIC, CustomExplorer, CustomSim, DC Expert, DC Professional, DC Ultra, Design Analyzer, Design

Vision, DesignerHDL, DesignPower, DFTMAX, Direct Silicon Access, Discovery, Encore, EPIC, Galaxy, HANEX, HDL

Compiler, Hercules, Hierarchical Optimization Technology, High-performance ASIC Prototyping System, HSIMplus,

i-Virtual Stepper, IICE, in-Sync, iN-Tandem, Intelli, Jupiter, Jupiter-DP, JupiterXT, JupiterXT-ASIC, Liberty, Libra-Passport,

Library Compiler, Macro-PLUS, Magellan, Mars, Mars-Rail, Mars-Xtalk, Milkyway, ModelSource, Module Compiler,

MultiPoint, ORAengineering, Physical Analyst, Planet, Planet-PL, Polaris, Power Compiler, Raphael, RippledMixer,

Saturn, Scirocco, Scirocco-i, SiWare, Star-RCXT, Star-SimXT, StarRC, System Compiler, System Designer, Taurus,

TotalRecall, TSUPREM-4, VCSi, VHDL Compiler, VMC, and Worksheet Buffer 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.

Saber is a registered trademark of SabreMark Limited Partnership and is used under license.

All other product or company names may be trademarks of their respective owners.

iii

Contents

What’s New in This Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxviii

About This User Guide and Command Reference . . . . . . . . . . . . . . . . . . . . . . . . . . xxix

Customer Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxi

Part I: StarRC User Guide

1. Introduction to StarRC

Extraction in the Basic Design Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2

Extraction Tool Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2

Interaction With Other Synopsys Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2

Interfacing With External CAD Tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3

Supported Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3

Physical Tool Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3

Block or Cell Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3

User Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4

Licensing Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4

2. Running StarRC

StarRC Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2

Batch Mode Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3

Graphical User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4

Contents iv

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Selective Job Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4

Distributed Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6

Manual Submission of Distributed Processing Jobs . . . . . . . . . . . . . . . . . . . . . 2-7

Automatic Submission of Distributed Processing Jobs . . . . . . . . . . . . . . . . . . . 2-7

Summary File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-9

Performance Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-11

Licensing Requirements for Distributed Processing . . . . . . . . . . . . . . . . . . . . . 2-11

StarRC Licensing Features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-11

Tiered Licensing Checkout Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-11

License Queuing Not Enabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-12

License Queuing Enabled. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-12

StarRC Command File Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-14

3. Process Characterization Interface

Process Characterization Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3

The Interconnect Technology Format File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-4

Creating the ITF File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-4

Process Effects That Affect Resistance and Capacitance . . . . . . . . . . . . . . . . . . . . 3-6

Gate-To-Diffusion Capacitance Extraction Based on Capacitance Tables . . . . . . . . 3-7

Device-Specific Contact Etch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-8

Device-Dependent Gate-to-Diffusion Capacitance Table . . . . . . . . . . . . . . . . . . . . . 3-9

Defining Additional Extraction Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-10

Handling Special Process Effects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-10

Conformal Dielectrics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-11

Conductor Cutting Dielectric . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-12

Covertical Conductors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13

Drop Factor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-14

Modeling a Double-Poly Process Using DROP_FACTOR . . . . . . . . . . . . . . . . . 3-17

Dielectric Air Gaps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-18

Layer Etch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-19

Metal Fill (Emulated) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-19

When An Antenna Diode is in Your Design Database . . . . . . . . . . . . . . . . . . . . 3-21

45-Degree Angles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-22

Chapter 1: Contents

1-v

Contents v

StarRC User Guide and Command Reference Version F-2011.06

Diffusion Resistance Extraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-22

Spacing- and Width-Dependent Etch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-23

Running grdgenxo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-23

CAPACITIVE_ONLY and RESISTIVE_ONLY. . . . . . . . . . . . . . . . . . . . . . . . . . . 3-23

Determining WMIN and SMIN Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-23

Retaining Coupling Capacitance Between Top and SKIP_CELL Levels . . . . . . 3-24

Handling Overlapping Wells. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-24

Defining Sheet Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-25

Modeling Thickness Variation With StarRC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-28

Measuring Bottom Conductor Thickness Variation. . . . . . . . . . . . . . . . . . . . . . . . . . 3-35

Interconnect Parasitics Extraction Based on CMP Simulators . . . . . . . . . . . . . . . . . 3-37

Microloading Effect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-41

Damage Modeling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-42

Translation of Routing DEF Blockage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-44

Temperature Derating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-44

Transparent Half-Node Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-45

Generating TLUPlus Models. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-48

Via Merging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-50

Output Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-50

Mapping File Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-51

Examples of Via Merging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-51

Writing a Mapping File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-58

4. Physical Databases

Introduction to Physical Databases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2

Milkyway Database Extraction Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2

Place-and-Route Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3

Setting the Reference Library Control File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3

Milkyway Database Command Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3

LEF/DEF Database Extraction Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4

Timing-Driven Design Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-6

Merging Library GDSII. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-6

Contents vi

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

LEF/DEF Database Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-6

Calibre Connectivity Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-7

Hercules Database Extraction Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-15

GDSII to XTR View Translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-17

Cross-Referenced Extraction in the Hercules Flow . . . . . . . . . . . . . . . . . . . . . . 4-19

Hercules Database Command Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-20

HSIM Reliability Flow Placement Information . . . . . . . . . . . . . . . . . . . . . . . . . . 4-21

IC Validator Extraction Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-22

Steps in the IC Validator Extraction Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-24

Examples of Script Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-24

Cross-Referenced Extraction in IC Validator . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-25

Cross-Referencing in Transistor Level Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-26

XREF:NO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-26

XREF:YES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-26

XREF:COMPLETE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-30

Cross-Referenced Extraction Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-32

Parameterized Cells (PCELL). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-33

How LVS Handles Parameterized Cells. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-34

Extracting PCELLS Using StarRC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-38

SKIP_PCELLS Extraction Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-39

SKIP_PCELLS Netlist Behavior. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-40

Metal Fill . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-41

Emulated Metal Fill . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-42

Using Emulated Metal Fill in StarRC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-42

Real Metal Fill . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-43

Handling Coupling Capacitance on Floating Metal Fills . . . . . . . . . . . . . . . 4-44

Guidelines for Using Metal Fill . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-45

How StarRC Handles Metal Fill . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-46

Grounded Metal Fill . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-46

Floating Metal Fill . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-46

Floating and Grounded Metal Fill . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-46

Accuracy Validation With Metal Fill . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-47

Shared Database Command Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-47

Chapter 1: Contents

1-vii

Contents vii

StarRC User Guide and Command Reference Version F-2011.06

5. Incremental Extraction

Incremental Extraction Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2

Input to StarRC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2

Output from Incremental Extraction Runs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2

Fixing a Design Using Engineering Change Orders . . . . . . . . . . . . . . . . . . . . . 5-3

Reasons to Perform ECOs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3

Identification and Extraction of Nets Affected by ECOs. . . . . . . . . . . . . . . . . . . 5-6

Incremental Extraction Using StarRC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7

Input Files for Incremental Extraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-9

Output Files From Incremental Extraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-9

Unsupported Commands During Incremental Extraction . . . . . . . . . . . . . . . . . 5-10

Running Incremental Extraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-10

Incremental Netlist Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-15

6. Parasitic Extraction

Extraction Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2

SingleShot Extraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2

Extraction Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-5

Processing Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-6

7. Rapid3D Field Solver

Introduction to Rapid3D Extraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2

Running Rapid3D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2

Distributed Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3

LSF System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-4

Gridware System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-4

General Network With a List of Machines. . . . . . . . . . . . . . . . . . . . . . . . . . 7-4

Notes on Distributed Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-5

Licensing Requirement for Distributed Processing . . . . . . . . . . . . . . . . . . 7-5

Input and Output Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-5

Input Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-5

Technology File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-5

Design File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-6

Net File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-6

Output File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-6

Contents viii

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Trapezoidal Conductors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-7

Conductor Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-7

Nets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-8

Net Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-8

Ground Nets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-8

Fill Nets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-9

Capacitance Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-9

Boundary Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-10

Controlling Accuracy and Runtime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-11

Specifying Convergence Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-11

Specifying the Accuracy Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-12

Specifying the Consistency of Results. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-13

Specifying the grids_per_meter Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-13

Specifying Pattern Matching for Symmetric Nets. . . . . . . . . . . . . . . . . . . . . . . . 7-14

8. Timing Analysis

Timing Analysis Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-2

Net-Specific Modes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-4

Simulation Options in the StarRC Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-6

Netlist Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-7

9. Noise Analysis

Noise Analysis Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-2

Smart Decoupling of Coupling Capacitances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-3

Noise Analysis Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-4

10. Graphical User Interface

Graphical User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2

Files Needed to Run StarRC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2

Starting StarRC Using the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3

Starting a Timing or Noise Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3

Starting a SingleShot Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-6

Chapter 1: Contents

1-ix

Contents ix

StarRC User Guide and Command Reference Version F-2011.06

Interface Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-8

Control Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-8

File Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-9

Setup Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-10

Noise Menu. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-15

Viewer Menu. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-16

Entering Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-17

Entry Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-17

Analysis Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-19

List of Nets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-20

Creating a Mapping File in the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-20

11. Variation-Aware Extraction

Introduction to Variation-Aware Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-2

Pessimism of Traditional Corner Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-2

Pitfalls of Traditional Corner Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-5

Time-to-Market Challenges With Traditional Corner Analysis . . . . . . . . . . 11-8

Random Versus Systematic Variations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-8

Systematic or Intra-Die Process Modeling . . . . . . . . . . . . . . . . . . . . . . . . . 11-9

Random or Inter-Die Process Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-10

Comparing Random Versus Systematic Variations . . . . . . . . . . . . . . . . . . . . . . 11-11

Parasitic Extraction to Static Timing Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-12

The Traditional Analysis Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-13

Statistical Extraction and Static Timing Analysis . . . . . . . . . . . . . . . . . . . . . . . . 11-14

The Concept of Sensitivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-17

Calculating Sensitivity Coefficients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-18

Characterizing the Effect on Capacitance Values. . . . . . . . . . . . . . . . . . . . 11-18

Computing the Thickness Sensitivity of a Dielectric Layer . . . . . . . . . . . . . 11-18

Defining Capacitance Sensitivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-18

Defining Resistance Sensitivity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-20

Running StarRC With Sensitivities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-20

Example Calculations With Sensitivities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-21

User-Defined Corner and Sensitivity Calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-23

User Interface Modeling Parameters and Their Variation . . . . . . . . . . . . . . . . . . . . . 11-24

Creating a Variation-Aware ITF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-25

Appending Variation Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-25

Contents x

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Single Variation Parameters and Dependent Parameters . . . . . . . . . . . . . 11-25

Specifying Intra-Metal Dielectric Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-26

Variation-Aware ITF Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-26

Example of a Variation-Aware ITF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-28

Handling Temperature Variation in StarRC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-30

Temperature Variation Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-30

Defining a Corner (UDC) File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-31

Sensitivity Command File Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-32

Formatting the Corner File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-32

Example of a User-Defined Corner File (UDC) . . . . . . . . . . . . . . . . . . . . . . . . . 11-33

Sensitivity Netlist With Geometry Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-33

SPICE Syntax for Parasitic Sensitivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-34

Header Section Variation Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-34

Header Section Model Card For Temperature Variation . . . . . . . . . . . . . . . . . . 11-37

Parasitic Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-38

SPEF Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-38

Adding Sensitivity to an SPEF Format Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . 11-39

Extension Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-40

Parasitic Variation Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-41

Sensitivity Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-43

Header for SPEF Sensitivity Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-46

Variation-Aware Extraction Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-46

Unsupported ITF Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-47

12. Parasitic Extraction Integration With the Virtuoso Custom Design Platform

Introduction to Virtuoso Integration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-2

Creating Parasitic Views for Netlisting and Simulation . . . . . . . . . . . . . . . . . . . 12-2

Generating Graphical Data From Extracted Polygons and Subnodes. . . . . . . . 12-2

Probing Parasitics From Parasitic and Schematic Views. . . . . . . . . . . . . . . . . . 12-2

Packaging, Installation, and Software Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . 12-3

Installation Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-3

Installation Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-3

Licensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-4

Software Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-4

Chapter 1: Contents

1-xi

Contents xi

StarRC User Guide and Command Reference Version F-2011.06

Flow Configuration and Related Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-4

Preparing an Ideal and Parasitic Device DFII Mapping File . . . . . . . . . . . . . . . 12-5

Preparing a Runset-Layer-to-DFII Layer Mapping File . . . . . . . . . . . . . . . . . . . 12-7

Customizing an LVS Device Extraction Job. . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-9

Customizing a StarRC Parasitic Extraction Job. . . . . . . . . . . . . . . . . . . . . . . . . 12-10

View Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-11

Net and Instance Name Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-11

Port and Terminal Connectivity Characteristics . . . . . . . . . . . . . . . . . . . . . . . . 12-13

Instance Property Annotation from the Schematic View . . . . . . . . . . . . . . . . . . 12-14

The Default Mode of StarRC Instance Property Annotation . . . . . . . . . . . . 12-14

Property Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-16

Instance Name Matching Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-17

Subnode Marker and Parasitic Device Visualization . . . . . . . . . . . . . . . . . . . . . 12-18

User-Defined Callbacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-20

Pre-Extraction Callback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-20

View Preprocessing Callback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-21

View Postprocessing Callback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-21

Instance Creation Callback. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-22

Callback Flow Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-23

Temperature Sensitivity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-24

StarRC Parasitic Generation Cockpit GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-25

Populating the Cockpit Fields Automatically . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-27

Advanced Save and Load Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-29

Using the Functions in the StarRC Parasitic View Generation Dialog Box . . . . 12-30

Run Cockpit Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-31

Device Extraction Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-32

Extract Parasitics Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-36

Output Parasitics Tab. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-38

Load Sharing Facility Job Submission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-39

File and Path Browsers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-41

Using Selected Net Parasitics and Selective Netlisting Modes . . . . . . . . . . . . . 12-43

Selecting and Customizing the Analysis Options . . . . . . . . . . . . . . . . . . . . . . . 12-43

StarRC OA View Creation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-45

Open Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-45

Environment Setup for Writing Open Access . . . . . . . . . . . . . . . . . . . . . . . 12-46

Linking Open Access Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-46

Contents xii

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Linking StarRC Open Access Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-46

Setting the Tcl Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-46

StarRC Command File Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-47

Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-47

Parasitic Probing in the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-49

StarRC Parasitic Prober. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-49

StarRC Parasitic Browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-50

StarRC Parasitic Netlist Browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-51

View Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-52

Flyline Viewing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-52

Point-to-Point Resistance Probing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-53

Parasitic View Probing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-55

Schematic View Probing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-55

Probed Results Log and Cross-Probing . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-56

Capacitance Probing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-56

Parasitic View Probing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-56

Schematic View Probing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-56

Probe Results Log and Cross-Probing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-57

Prober File Input and Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-57

Schematic Annotation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-57

View Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-59

Dynamic Flylines for Probing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-59

Point-to-Point Resistance Probing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-60

Parasitic View Probing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-60

Schematic View Probing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-61

Probed Results Log and Cross-Probing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-61

Prober File Input and Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-62

Schematic Annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-62

Virtuoso Integration Skill Procedures and Related Variables . . . . . . . . . . . . . . . . . . 12-63

GUI Integration with a Custom Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-64

Batch Mode Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-64

RCGenParaViewBatch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-65

RCGenParaViewBatch2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-67

RCCockpitRun . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-67

General Notes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-68

Specifying Relative Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-68

Hierarchy Separator for Calibre Connectivity Interface . . . . . . . . . . . . . . . . . . . 12-68

Chapter 1: Contents

1-xiii

Contents xiii

StarRC User Guide and Command Reference Version F-2011.06

13. Examples

Command File Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-2

Netlist Format Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-2

SPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-3

STAR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-4

SPEF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-5

CONLY. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-6

NETNAME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-7

NETLIST_IDEAL_SPICE_FILE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-8

XREF Command SPF Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-10

XREF: NO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-10

XREF: YES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-10

XREF: COMPLETE (SPF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-11

Fast SPICE Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-11

14. Transistor-Level Runset Creation

Preparing Hercules Runsets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-2

Runset Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-2

Required Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-5

Sample Runset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-7

Marker Generation in Hercules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-11

Example of Text-Based Markers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-11

Example of ID-Layer Markers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-11

Example of Connection-Based Markers . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-12

Preparing IC Validator Runsets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-13

Runset Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-13

Required Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-16

Hierarchy Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-17

Hierarchy Options Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-18

Sample Runset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-19

Marker Generation in IC Validator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-21

Text-Based Marker Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-21

Multifinger Device Support in IC Validator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-23

Preparing Calibre Rule Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-24

Rule File Creation Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-24

Contents xiv

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Required Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-26

Support for Calibre Preprocessor Directives and Include Statements. . . . . . . . 14-27

Sample Rule File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-28

Preparing the Mapping File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-31

Mapping Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-31

Sample Mapping File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-33

Running the Calibre Query Server for Output to StarRC . . . . . . . . . . . . . . . . . . . . . 14-33

Optional Calibre Query Server Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-35

Preparing the StarXtract Command File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-37

Options for Transistor Level in Hercules Flow . . . . . . . . . . . . . . . . . . . . . . . . . . 14-37

Options for Transistor Level in Calibre Connectivity Interface Flow . . . . . . . . . . 14-37

Other Important Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-37

Interconnect Technology Format File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-39

Preparing the ITF File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-39

Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-40

Sample ITF File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-40

General Limitations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-41

Limitations in XREF Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-41

15. Advanced Extraction Features

Feedthrough Nets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-2

Feedthrough - First Issue. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-3

Port Renaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-4

Feedthrough - Second Issue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-4

Runset Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-5

Via Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-5

Determining the Coverage and Landing Areas

(VIA_COVERAGE_OPTION_FILE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-6

Determining the Coverage and Landing Areas (VIA_COVERAGE) . . . . . . . . . 15-8

Positive and Negative Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-9

Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-10

Via Coverage Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-12

Reading the Output Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-13

Long Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-15

Chapter 1: Contents

1-xv

Contents xv

StarRC User Guide and Command Reference Version F-2011.06

User-Defined Diffusion Resistance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-17

Modifying the ITF File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-17

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

Modifying the Mapping File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-17

Modifying the StarRC Command File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-18

Postprocessing the Netlist File to Compute Diffusion Resistance . . . . . . . . . . . 15-20

Example of Tcl Script for Netlist Postprocessing . . . . . . . . . . . . . . . . . . . . 15-21

16. Hercules GENDEV Device Extraction and Netlist Generation

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-2

Device Recognition and Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-2

Scheme Extraction Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-4

Hercules LVS With GENDEV Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-6

Scheme Property Comparison Functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-7

GENDEV Netlist Generation in StarRC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-9

Part II: StarRC Command Reference

17. StarRC Commands

ANALOG_SYMMETRIC_NETS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-2

AUTO_RUNSET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-3

BLOCK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-5

BLOCK_BOUNDARY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-7

BUS_BIT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-9

CALIBRE_LVS_DEVICE_TYPE_CAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-10

CALIBRE_LVS_DEVICE_TYPE_MOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-11

CALIBRE_LVS_DEVICE_TYPE_RES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-12

CALIBRE_OPTIONAL_DEVICE_PIN_FILE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-13

CALIBRE_PDBA_FILE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-14

CALIBRE_QUERY_FILE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-15

CALIBRE_RUNSET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-17

Contents xvi

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

CASE_SENSITIVE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-18

CELL_TYPE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-19

COMPARE_DIRECTORY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-20

CONLY_NETS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-21

CONVERT_DIODE_TO_PARASITIC_CAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-23

COUPLE_NONCRITICAL_NETS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-25

COUPLE_NONCRITICAL_NETS_PREFIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-27

COUPLE_NONCRITICAL_NETS_SUBNODE_SUFFIX. . . . . . . . . . . . . . . . . . . . . . 17-28

COUPLE_TO_GROUND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-29

COUPLE_TO_PCELL_PINS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-30

COUPLING_ABS_THRESHOLD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-31

COUPLING_AVG_THRESHOLD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-32

COUPLING_MULTIPLIER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-33

COUPLING_REL_THRESHOLD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-34

COUPLING_REPORT_FILE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-35

COUPLING_REPORT_NUMBER. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-36

COUPLING_THRESHOLD_OPERATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-37

DENSITY_BASED_THICKNESS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-38

DENSITY_OUTSIDE_BLOCK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-39

DETECT_FUSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-40

EVACCESS_DIRECTORY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-42

EXTRA_GEOMETRY_INFO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-43

EXTRACTION. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-45

EXTRACT_VIA_CAPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-46

EXTRACT_RES_BODY_COUPLING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-48

FS_DP_STRING. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-49

FS_EXTRACT_NETS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-51

FSCOMPARE_COUPLING_RATIO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-53

Chapter 1: Contents

1-xvii

Contents xvii

StarRC User Guide and Command Reference Version F-2011.06

FSCOMPARE_FILE_PREFIX. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-54

FSCOMPARE_OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-55

FSCOMPARE_THRESHOLD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-59

GDS_FILE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-60

GDS_LAYER_MAP_FILE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-61

HIERARCHICAL_SEPARATOR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-65

HN_NETLIST_MODEL_NAME. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-67

HN_NETLIST_SPICE_TYPE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-69

ICV_ANNOTATION_FILE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-71

ICV_RUNSET_REPORT_FILE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-73

IGNORE_CAPACITANCE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-74

IGNORE_FIELDPOLY_DIFFUSION_COUPLING . . . . . . . . . . . . . . . . . . . . . . . . . . 17-77

INCREMENTAL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-79

INCREMENTAL_FORCE_DP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-81

INSTANCE_PORT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-82

INSTANCE_PORT_OPEN_CONDUCTANCE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-86

INTRANET_CAPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-87

KEEP_VIA_NODES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-88

LEF_FILE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-89

LEF_USE_OBS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-91

LPE_DEVICES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-92

LPE_PARAM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-93

MACRO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-95

MACRO_DEF_FILE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-96

MAGNIFICATION_FACTOR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-97

MAGNIFY_DEVICE_PARAMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-98

MAPPING_FILE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-99

MARKER_GENERATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-100

Contents xviii

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

MERGE_INSTANCE_PORTS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-101

MERGE_MULTI_CORNER. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-103

MERGE_VIAS_IN_ARRAY. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-106

METAL_FILL_GDS_FILE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-108

METAL_FILL_GDS_FILE_NET_NAME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-109

METAL_FILL_GDS_MAG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-110

METAL_FILL_GDS_OFFSET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-111

METAL_FILL_OASIS_FILE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-112

METAL_FILL_OASIS_FILE_NET_NAME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-113

METAL_FILL_OASIS_MAG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-114

METAL_FILL_OASIS_OFFSET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-115

METAL_FILL_POLYGON_HANDLING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-116

METAL_SHEET_OVER_AREA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-118

MILKYWAY_ADDITIONAL_VIEWS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-120

MILKYWAY_CELL_VIEW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-121

MILKYWAY_DATABASE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-122

MILKYWAY_EXPAND_HIERARCHICAL_CELLS. . . . . . . . . . . . . . . . . . . . . . . . . . . 17-123

MILKYWAY_EXTRACT_VIEW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-124

MILKYWAY_REF_LIB_MODE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-125

MODE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-127

MODEL_TYPE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-128

MOS_GATE_CAPACITANCE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-130

MOS_GATE_DELTA_RESISTANCE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-131

NET_SEGMENT_CUT_LENGTH. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-133

NET_TYPE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-135

NETLIST_CAPACITANCE_UNIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-136

NETLIST_COMMENTED_PARAMS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-137

NETLIST_COMMENTS_FILE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-138

Chapter 1: Contents

1-xix

Contents xix

StarRC User Guide and Command Reference Version F-2011.06

NETLIST_COMPRESS_COMMAND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-139

NETLIST_CONNECT_OPENS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-141

NETLIST_CONNECT_SECTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-142

NETLIST_CORNER_FILE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-143

NETLIST_CORNER_NAMES. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-145

NETLIST_COUPLE_UNSELECTED_NETS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-146

NETLIST_DELIMITER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-148

NETLIST_DEVICE_LOCATION_ORIENTATION . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-149

NETLIST_FILE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-151

NETLIST_FORMAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-152

NETLIST_GROUND_NODE_NAME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-154

NETLIST_HIER_PROBE_NODES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-155

NETLIST_IDEAL_SPICE_FILE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-156

NETLIST_IDEAL_SPICE_HIER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-157

NETLIST_IDEAL_SPICE_TYPE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-158

NETLIST_INCREMENTAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-159

NETLIST_INPUT_DRIVERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-161

NETLIST_INSTANCE_SECTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-162

NETLIST_LOGICAL_TYPE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-164

NETLIST_MAX_FILE_SIZE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-165

NETLIST_MAX_LINE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-167

NETLIST_MERGE_CORNERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-168

NETLIST_MERGE_SHORTED_PORTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-169

NETLIST_MINCAP_THRESHOLD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-170

NETLIST_MINRES_HANDLING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-171

NETLIST_MINRES_THRESHOLD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-172

NETLIST_MMC_FORMULA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-173

NETLIST_MMC_FORMULA_NAMES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-174

Contents xx

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

NETLIST_NAME_MAP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-176

NETLIST_NODE_SECTION. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-177

NETLIST_NODENAME_NETNAME. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-178

NETLIST_PARA_VIEW. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-180

NETLIST_PARASITIC_RESISTOR_MODEL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-181

NETLIST_PASSIVE_PARAMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-184

NETLIST_POSTPROCESS_COMMAND. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-186

NETLIST_POWER_FILE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-187

NETLIST_PRECISION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-188

NETLIST_PRINT_CC_TWICE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-189

NETLIST_REMOVE_DANGLING_BRANCHES . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-191

NETLIST_RENAME_PORTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-192

NETLIST_RESISTANCE_UNIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-193

NETLIST_SELECT_NETS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-194

NETLIST_SIM_OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-195

NETLIST_SUBCKT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-197

NETLIST_TAIL_COMMENTS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-198

NETLIST_TIME_UNIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-200

NETLIST_TOTALCAP_THRESHOLD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-201

NETLIST_TYPE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-202

NETLIST_UNSCALED_COORDINATES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-204

NETLIST_USE_M_FACTOR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-205

NETS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-206

NETS_FILE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-208

NONCRITICAL_COUPLING_REPORT_FILE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-209

NUM_PARTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-211

OA_DEVICE_MAPPING_FILE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-212

OA_LAYER_MAPPING_FILE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-213

Chapter 1: Contents

1-xxi

Contents xxi

StarRC User Guide and Command Reference Version F-2011.06

OA_LIB_DEF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-214

OA_LIB_NAME. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-215

OA_MARKER_SIZE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-216

OA_PORT_ANNOTATION_VIEW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-217

OA_PROPERTY_ANNOTATION_VIEW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-218

OA_READ_FILL_VIEW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-219

OA_READ_LIB_NAME. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-220

OA_READ_VIEW_NAME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-221

OA_SKIPCELL_MAPPING_FILE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-222

OA_VIEW_NAME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-223

OASIS_FILE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-224

OASIS_LAYER_MAP_FILE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-225

OBSERVATION_POINTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-228

OPERATING_TEMPERATURE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-230

PIN_CUT_THRESHOLD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-232

PIO_FILE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-234

PLACEMENT_INFO_FILE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-235

POWER_EXTRACT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-237

POWER_NETS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-240

POWER_PORTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-241

POWER_REDUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-242

PRINT_SILICON_INFO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-243

PROBE_TEXT_FILE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-245

PROCESS_CORNER. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-247

REDUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-248

REDUCTION_MAX_DELAY_ERROR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-250

REMOVE_DANGLING_NETS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-251

REMOVE_FLOATING_NETS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-252

Contents xxii

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

REMOVE_NET_PROPERTY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-253

RETAIN_CAPACITANCE_CAP_MODELS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-254

RETAIN_GATE_CONTACT_COUPLING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-256

RING_AROUND_THE_BLOCK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-258

RING_AROUND_THE_BLOCK_SMIN_MULTIPLIER . . . . . . . . . . . . . . . . . . . . . . . 17-260

SENSITIVITY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-261

SHEET_COUPLE_TO_NET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-263

SHEET_COUPLE_TO_NET_LEVEL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-264

SHORT_PINS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-265

SHORT_PINS_IN_CELLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-269

SKIP_CELL_AGF_FILE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-270

SKIP_CELL_PORT_PROP_FILE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-272

SKIP_CELLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-274

SKIP_CELLS_COUPLE_TO_NET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-276

SKIP_CELLS_COUPLE_TO_NET_LEVEL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-277

SKIP_CELLS_FILE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-278

SKIP_INSTANCES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-279

SKIP_PCELLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-280

SKIP_PCELL_LAYERS_FILE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-282

SLEEP_TIME_AFTER_FINISH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-284

SPICE_SUBCKT_FILE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-285

STAR_DIRECTORY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-286

SUBSTRATE_EXTRACTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-287

SUMMARY_FILE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-289

SYNOPSYS_LIB_FILE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-290

TARGET_PWRA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-291

TCAD_GRD_FILE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-293

TEMPERATURE_SENSITIVITY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-294

Chapter 1: Contents

1-xxiii

Contents xxiii

StarRC User Guide and Command Reference Version F-2011.06

THICKNESS_VARIATION_FILE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-296

TOP_DEF_FILE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-297

TRANSLATE_DEF_BLOCKAGE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-298

TRANSLATE_FLOATING_AS_FILL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-299

TRANSLATE_RETAIN_BULK_LAYERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-300

TVF_ADJUSTMENT_TABLES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-302

USER_DEFINED_DIFFUSION_RES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-303

VIA_COVERAGE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-304

VIA_COVERAGE_OPTION_FILE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-306

WIDE_DEVICE_TERM_RESISTANCE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-310

XREF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-312

XREF_FEEDTHRU_NETS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-314

XREF_LAYOUT_INST_PREFIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-315

XREF_LAYOUT_NET_PREFIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-316

XREF_SWAP_MOS_SD_PROPERTY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-317

XREF_USE_LAYOUT_DEVICE_NAME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-318

ZONE_COUPLE_TO_NET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-319

ZONE_COUPLE_TO_NET_LEVEL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-320

18. ITF Statements and Options

AIR_GAP_VS_SPACING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-3

AREA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-5

ASSOCIATED_CONDUCTOR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-6

BACKGROUND_ER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-8

BOTTOM_DIELECTRIC_ER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-9

BOTTOM_DIELECTRIC_THICKNESS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-10

BOTTOM_THICKNESS_VS_SI_WIDTH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-13

CAPACITIVE_ONLY_ETCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-16

Contents xxiv

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

CONDUCTOR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-17

CRT_VS_AREA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-21

CRT_VS_SI_WIDTH. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-23

CRT1, CRT2, and T0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-25

DAMAGE_ER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-27

DAMAGE_THICKNESS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-28

DENSITY_BOX_WEIGHTING_FACTOR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-29

DIELECTRIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-30

DROP_FACTOR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-31

DROP_FACTOR_LATERAL_SPACING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-33

ER. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-34

ETCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-35

ETCH_VS_CONTACT_AND_GATE_SPACINGS . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-36

ETCH_VS_WIDTH_AND_LENGTH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-41

ETCH_VS_WIDTH_AND_SPACING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-44

FILL_RATIO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-48

FILL_SPACING. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-49

FILL_TYPE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-50

FILL_WIDTH. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-51

FROM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-52

GATE_TO_CONTACT_SMIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-53

GATE_TO_DIFFUSION_CAP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-55

GLOBAL_TEMPERATURE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-58

HALF_NODE_SCALE_FACTOR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-59

ILD_VS_WIDTH_AND_SPACING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-62

IS_CONFORMAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-65

IS_PLANAR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-67

LAYER_TYPE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-68

Chapter 1: Contents

1-xxv

Contents xxv

StarRC User Guide and Command Reference Version F-2011.06

MEASURED_FROM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-70

POLYNOMIAL_BASED_THICKNESS_VARIATION . . . . . . . . . . . . . . . . . . . . . . . . . 18-72

RESISTIVE_ONLY_ETCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-75

RHO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-76

RHO_VS_SI_WIDTH_AND_THICKNESS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-77

RHO_VS_WIDTH_AND_SPACING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-80

RPSQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-81

RPSQ_VS_SI_WIDTH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-82

RPSQ_VS_WIDTH_AND_SPACING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-84

RPV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-86

RPV_VS_AREA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-87

SIDE_TANGENT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-89

SMIN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-91

SW_T . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-92

TECHNOLOGY. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-93

THICKNESS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-94

THICKNESS_VS_DENSITY. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-95

THICKNESS_VS_WIDTH_AND_SPACING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-97

TO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-99

TSV. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-100

TVF_ADJUSTMENT_TABLES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-102

TW_T . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-104

USE_SI_DENSITY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-105

VARIATION_PARAMETERS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-106

VIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-107

WMIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-109

Contents xxvi

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

19. The grdgenxo Command

Command Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-2

Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-3

Incremental grdgenxo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-6

Reference Indications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-7

Error and Warning Conditions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-8

20. Mapping File Commands

conducting_layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-2

via_layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-5

marker_layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-7

remove_layers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-8

viewonly_layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-9

ignore_cap_layers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-10

Appendix A. ITF Examples

Fully Planar Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-2

Conformal Dielectric Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-3

Gate Poly Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-4

Local Interconnect Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-5

Dielectric Air Gaps Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-6

Layer Etch Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-7

Metal Fill Process (Emulated). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-8

Transistor-Level Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-9

Through-Silicon Via Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-10

Appendix B. Command Lists

Command List With Task Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-2

Command List With Flow and License Information. . . . . . . . . . . . . . . . . . . . . . . . . . B-11

Command List With -clean Option Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-20

xxvii

Preface

This preface includes the following sections:

•What’s New in This Release

•About This User Guide and Command Reference

•Customer Support

Preface

What’s New in This Release xxviii

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

What’s New in This Release

Information about new features, enhancements, and changes, along with known problems

and limitations and resolved Synopsys Technical Action Requests (STARs), is available in

the StarRC Release Notes in SolvNet.

To see the StarRC Release Notes,

1. Go to the Download Center on SolvNet located at the following address:

https://solvnet.synopsys.com/DownloadCenter

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.

2. Select StarRC, and then select a release in the list that appears.

Chapter 1: Preface

About This User Guide and Command Reference 1-xxix

Preface

About This User Guide and Command Reference xxix

StarRC User Guide and Command Reference Version F-2011.06

About This User Guide and Command Reference

The StarRC tool performs layout parasitic extraction of connected databases. This manual

describes StarRC in two parts:

• User Guide – Describes the use of StarRC for parasitic extraction.

• Command Reference – Contains detailed descriptions of commands and statements that

you can use in your StarRC setup files.

Audience

This manual is intended for circuit and layout design engineers working with circuits at the

deep submicron level.

Related Publications

For additional information about StarRC, see the documentation on SolvNet at the following

address:

https://solvnet.synopsys.com/DocsOnWeb

You might also want to see the documentation for the following related Synopsys products:

• PrimeTime Suite

• IC Compiler

• Custom Designer

•IC Validator

•Hercules

Preface

About This User Guide and Command Reference xxx

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Conventions

The following conventions are used in Synopsys documentation.

Convention Description

Courier Indicates syntax, such as write_file.

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

write_file design_list.

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

examples, such as

prompt> write_file top

[ ] Denotes optional arguments in syntax, such as

write_file [-format fmt]

... Indicates that arguments can be repeated as many

times as needed, such as

pin1 pin2 ... pinN

|Indicates a choice among alternatives, such as

low | medium | high

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.

Chapter 1: Preface

Customer Support 1-xxxi

Preface

Customer Support xxxi

StarRC User Guide and Command Reference Version F-2011.06

Customer Support

Customer support is available through SolvNet online customer support and through

contacting the Synopsys Technical Support Center.

Accessing SolvNet

SolvNet includes a 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, and technical support.

To access SolvNet, go to the following address:

https://solvnet.synopsys.com

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 HELP in the top-right menu bar.

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 support case to your local support center online by signing in to SolvNet at

https://solvnet.synopsys.com, clicking Support, and then clicking “Open A Support Case.”

• Send an e-mail message to your local support center.

• E-mail support_center@synopsys.com from within North America.

• Find other local support center e-mail addresses at

http://www.synopsys.com/Support/GlobalSupportCenters/Pages

• Telephone your local support center.

• Call (800) 245-8005 from within North America.

• Find other local support center telephone numbers at

http://www.synopsys.com/Support/GlobalSupportCenters/Pages

Preface

Customer Support xxxii

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Part I: StarRC User Guide

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

1-1

Introduction to StarRC 1

StarRC is a software tool that extracts parasitics—such as resistors, capacitors, and

inductors—from connected databases that represent integrated circuit layout designs.

You can use StarRC to generate netlists to conduct a timing, clock, noise, or power analysis.

This chapter contains the following sections:

•Extraction in the Basic Design Flow

•Extraction Tool Tasks

•Interaction With Other Synopsys Tools

•Interfacing With External CAD Tools

•Supported Formats

•Physical Tool Requirements

•Block or Cell Analysis

•User Interfaces

•Licensing Requirements

Chapter 1: Introduction to StarRC

Extraction in the Basic Design Flow 1-2

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Extraction in the Basic Design Flow

StarRC is an accurate parasitic extraction solution that has many applications in the design

cycle. StarRC can extract resistance and capacitance information from a fully routed design

block.

Extraction Tool Tasks

StarRC performs these extraction tasks:

• Produces accurate, full-chip parasitics for noise, signal electromigration, voltage (IR)

drop, and timing verification.

• Performs selective extraction and netlisting for critical path analysis.

• Provides a complete, production-proven solution for different design types, such as ASIC,

full custom, microprocessor, memory, and analog designs.

• Offers consistent interconnect modeling for physical design and optimization. Efficient

post-layout analysis enables fast timing convergence and rapid time-to-market.

• Includes advanced process effects such as copper interconnect, local interconnect,

silicon on insulator (SOI), and in-die process variation.

• Creates process characterization files for StarRC, which can also be obtained from major

foundries.

• Integrates into existing design flows.

• Provides hierarchical extraction and distributed processing that can be performed.

Interaction With Other Synopsys Tools

StarRC is integrated with Synopsys timing verification tools (PrimeTime SI), simulation tools

(HSPICE, NanoSim), and the Galaxy platform. It is also integrated with the

layout-versus-schematic verification tools, IC Validator and Hercules.

Post-layout optimization for timing, power, and noise is achieved by integration with the IC

Compiler, PrimeTime, NanoSim, PrimeRail and Astro-Xtalk tools.

Chapter 1: Introduction to StarRC

Interfacing With External CAD Tools 1-3

Chapter 1: Introduction to StarRC

Interfacing With External CAD Tools 1-3

StarRC User Guide and Command Reference Version F-2011.06

Interfacing With External CAD Tools

StarRC integrates into many design flows through standard design data formats like

Milkyway, Library Exchange Format/Design Exchange Format (LEF/DEF), Standard

Parasitic Exchange Format (SPEF), Standard Parasitic Format (SPF), and Calibre®

Connectivity Interface. In fact, widespread use of StarRC in third-party design flows as well

as Synopsys design flows is occurring today. This includes integration with static timing

analysis tools and third-party place-and-route tools directly through the use of LEF/DEF and

the Calibre Connectivity Interface. You can also use GDSII by using Hercules (Milkyway

XTR view) files.

Supported Formats

StarRC supports these industry-standard formats:

Input formats

•LEF/DEF

•GDSII

•Milkyway

Output Netlist Formats

•SPICE

• Synopsys Binary Parasitic Format (SBPF)

• SPEF

• Detailed Standard Parasitic Format (DSPF)

Physical Tool Requirements

StarRC accepts input from GDSII, LEF/DEF, and IC Compiler formats.

Block or Cell Analysis

StarRC extracts billions of capacitors for a typical design. Then it generates the smallest

possible netlist to achieve accurate results by using a proprietary parasitic reduction

algorithm. For increased throughput, StarRC can run in hierarchical and distributed

Chapter 1: Introduction to StarRC

User Interfaces 1-4

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

processing modes. It supports extraction of advanced process technologies such as copper

interconnect, local interconnect, low-κ dielectric, silicon on insulator (SOI), and in-die

process variations.

To facilitate design convergence, StarRC generates accurate process models through the

characterization interface used by the IC Compiler place-and-route tool . StarRC also runs

directly from Synopsys Milkyway database and provides the IC Compiler place-and-route

user a consistent link between extraction and final verification. This flow includes the

following benefits:

• Full-chip extraction at any time during the design cycle—shorted nets, open nets, and

incomplete blocks are handled properly and reported with warning messages

• Accurate parasitic extraction for layouts with physical routing

• Fast selective extraction of nets modified by engineering change orders (ECOs)

• Accurate post-layout optimization for timing, power, and noise through integration with IC

Compiler, PrimeTime, NanoSim, PrimeRail, and Astro-Xtalk optimization tools

User Interfaces

You can use StarRC

• From the StarRC graphical user interface

• From IC Compiler

• In batch mode on the command line

Licensing Requirements

StarRC operates on a three-tier licensing and packaging scheme. The three packages are

as follows:

• StarRC Custom – Performs high-accuracy extraction at the block or transistor level.

• StarRC – Performs full-chip extraction at the gate and transistor level.

• StarRC Ultra – Performs large design extraction and includes advanced features such as

variation-aware extraction.

For information about the availability of specific features in each package, see “Command

List With Flow and License Information” in Appendix B.

2-1

Running StarRC 2

This chapter covers running the StarRC tool in the following main sections:

•StarRC Overview

•Batch Mode Operation

•Graphical User Interface

•Selective Job Processing

•Distributed Processing

•StarRC Licensing Features

•StarRC Command File Conventions

Chapter 2: Running StarRC

StarRC Overview 2-2

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

StarRC Overview

StarRC is a layout parasitic extraction tool that extracts connected databases. StarRC can

be used at any physical design cycle stage to extract accurate parasitics.

• StarRC reads Milkyway place and route, LEF/DEF, Calibre Connectivity Interface, or

Hercules connected databases directly, without external processing.

• Extracted parasitics can be written into the Synopsys centralized Milkyway database for

use by analysis and optimization tools.

Because StarRC gracefully handles designs with layout versus schematic (LVS)

violations, including opens and shorts, timing convergence can be ensured before the

physical verification cycle begins.

• StarRC SingleShot extraction flow produces several netlists for each postextraction

analysis; you only need to rerun netlisting.

Figure 2-1 illustrates the StarRC design flow.

Figure 2-1 StarRC Design Flowchart

Milkyway Milkyway

LEF/DEF

StarRC

SPICE_SUBCKT_FILE

star_cmd

MAPPING_FILE

TCAD_GRD_FILE

TIMING

SPF

SPEF

STAR

Milkyway

NOISE

COUPLING

Connected layout database

XTR

SBPF

AGF

CCI

REPORT

GDS

Chapter 2: Running StarRC

Batch Mode Operation 2-3

Chapter 2: Running StarRC

Batch Mode Operation 2-3

StarRC User Guide and Command Reference Version F-2011.06

Batch Mode Operation

You can run StarRC in batch mode by providing a command file or files on the command

line. The StarXtract command invokes StarRC and uses the following syntax:

StarXtract

[-cleanXREF][-cleanD][-cleanFS][-cleanXFS]

[-cleanTFS][-cleanN]

[-cleanX starrc_command: new_value][-cleanT][-clean]

[-gui]

[-ultra | -custom]

[-cdnlicsvr]

[-tech_out]

[-v]

[-h]

[-iapinetmap]

[-iapixindump]

[-pio]

[-skip]

star_cmd_file [nets_cmd]

Argument Description

-cleanXREF Cleans xref

-cleanD Cleans all processes and minimizes the StarRC run directory size

-cleanFS Cleans field solver process

-cleanXFS Cleans extraction and field solver process

-cleanTFS Cleans translation and field solver process

-cleanN Cleans netlisting process

-cleanX Cleans extraction process

-cleanT Cleans translation process

-clean Cleans all processes

-gui Invokes StarRC GUI

-ultra Uses the STAR-RC2_ULTRA_MANAGER license key only

-custom Uses the STAR-RC2_CUSTOM_MANAGER license key only

Chapter 2: Running StarRC

Graphical User Interface 2-4

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

If you specify duplicate command options, options that can be specified only once are

overwritten (the last takes precedence), whereas options that can be specified more than

once are appended.

Graphical User Interface

StarRC includes an easy-to-use, interactive graphical user interface (GUI) that provides an

intuitive environment for the extraction and analysis of physical designs. Invoke the GUI with

the following command:

% StarXtract -gui

For more information about the StarRC GUI, see Chapter 10, “Graphical User Interface.”

Selective Job Processing

StarRC is designed to run sequentially through a series of independent processing

modules. This means that you can restart a job that was interrupted for some reason,

without revisiting previously completed tasks. It also gives you the ability to selectively

-cdnlicsvr Runs the Virtuoso® Integration License Server

-tech_out Displays a list of StarRC command options and their defaults, if

applicable

-v Displays the version information

-h Displays the command usage report

-iapinetmap Displays the net name/id mapping for IAPI

-iapixindump Displays the ascii xin output for IAPI

-pio Dumps the Star-DC PIO file from Milkyway

-skip Dumps the skip cells from Milkyway models

star_cmd_file Specifies the StarRC command file

nets_cmd Specifies the nets for extraction

Argument Description

Chapter 2: Running StarRC

Selective Job Processing 2-5

Chapter 2: Running StarRC

Selective Job Processing 2-5

StarRC User Guide and Command Reference Version F-2011.06

reconfigure a job without starting from scratch. Guidelines for using selective processing are

detailed in the following section. Selective processing is available both through the GUI and

with batch mode operation.

Note:

You can significantly speed up the runtime by executing StarXtract on a local hard drive.

StarXtract executes tasks in several independent stages and keeps a record after

successful completion of each stage so that results can be reused. With no command-line

options specified, StarXtract attempts to restart the job after the last stage that was

successfully completed (if applicable). If all stages have been previously completed,

StarXtract does not take any action. Command-line options let you control which stages are

executed. Any of the command-line execution options can be specified for a single

StarXtract job.

The valid -clean options for each StarXtract stage are shown in Table 2-1. For a complete list

of specifict commands and their valid -clean options, see Ta bl e B-3 on page B-20.

Table 2-1 Valid -clean Options in the StarXtract Stages

Stage

-clean

-cleanT

-cleanX

-cleanFS

-cleanTFS

-cleanXFS

-cleanN

-cleanXREF

Setup XXXXXXX

HN X

XrefHN X X

Translate X X X

XrefIDX X X

xTract XXX XX

FS X X X X

Netlist XXX(X) (X) (X) X X

(X) means the following: for EXTRACTION:FSCOMPARE

The -cleanFS, -cleanTFS, and -cleanXFS options do not perform netlisting, but

FS_EXTRACT_NETS does the netlisting with these three command-line options.

Chapter 2: Running StarRC

Distributed Processing 2-6

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

You should not use the -cleanXREF option when you are selecting nets by schematic name

for extraction. If the design contains symmetry, the schematic-layout mapping does not

always remain the same from run to run.

Alterations can be made to the command file to reconfigure a partially completed job. This

is especially useful if, for example, you want to extract a new netlist format from a database

that has already been extracted. To accomplish this task, first change the list of nets in the

technology file and then type the following command to produce a netlist containing the new

netlist format (without repeating the previous stages):

StarXtract -cleanN star_cmd

Note:

The rerunning of selective jobs (such as -cleanN) must be done on the same software

version and platform as the original job.

Another use of a -clean option is when you want to change the value of a certain command.

For example, if you change the COUPLE_TO_GROUND: YES command to

COUPLE_TO_GROUND: NO, this affects the extraction in the xTract and netlist stages. In this

case, specify the -cleanX command. StarRC then takes advantage of the results from the

run's previous stages and continues with the -cleanX function in the Xtract stage. The

-cleanX option refreshes the files beginning with the Xtract stage and continues refreshing

the files into the netlist stage.

The -cleanX option uses the following syntax:

StarXtract -cleanX starrc_command: new_value

Distributed Processing

Distributed processing in StarRC partitions the run, based on user input, during translation.

Each partition is spawned off to a separate CPU for extraction. After each CPU has finished

extracting its partition, StarRC integrates the results on a single CPU and generates a

netlist.

To invoke distributed processing, specify the NUM_PARTS command in the star_cmd file:

NUM_PARTS: number_of_partitions

The master CPU executes the StarXtract command, performs the initial translation, and

partitions the run as uniformly as possible among all of the available CPUs. After extraction

is finished on all CPUs, the master CPU compiles the results and generates the final netlist.

The various commands with -clean options can be executed only on the master CPU; they

cannot be issued on a slave CPU. To clean your partition stage (for example, to change the

partitions with the NUM_PARTS command), use the -cleanX command.

Chapter 2: Running StarRC

Distributed Processing 2-7

Chapter 2: Running StarRC

Distributed Processing 2-7

StarRC User Guide and Command Reference Version F-2011.06

If the master CPU fails on a -clean run, the slave CPU that picks up the incomplete job will

not run with -clean.

If one of the processing jobs terminates abnormally or crashes, the incomplete job is placed

in the task queue for completion by an active CPU, even if the failed CPU was the master

CPU. Slave CPUs check the task queue every 90 seconds, so there is a brief delay before

an idle CPU picks up an incomplete job. The extraction results are not merged until all

partitions have been processed.

Manual Submission of Distributed Processing Jobs

Distributed processing for the StarXtract command is similar to distributing processing for

the grdgenxo command; you must begin a job on a single CPU and then use a remote login

to execute jobs on other machines.

LSF System

A Load Sharing Facility (LSF) automatically distributes jobs to multiple CPUs. The

environment setup might differ between LSF clusters, but the usage should be similar to that

of the bsub command to submit jobs.

The following script example distributes a job across three CPUs:

bsub StarXtract star_cmd

Non-LSF System

If you are not using an LSF system, you must log into multiple remote machines to distribute

the extraction. On each CPU, run StarRC with the following commands:

% xterm

% cd /home/directory

% StarXtract star_cmd

% rlogin remote_machine

% cd /home/directory

% StarXtract star_cmd

You must execute the StarXtract command in the same directory for all machines.

Automatic Submission of Distributed Processing Jobs

StarRC provides automatic distributed processing job submission. You can start a single run

and let StarRC automatically submit multiple jobs according to your specifications.

Chapter 2: Running StarRC

Distributed Processing 2-8

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

To enable automatic job submission, use the following syntax:

STARRC_DP_STRING: job_details

STARRC_DP_STRING can be set as an environment variable or as a command in the

star_cmd file. If it is set in both places, the setting in the star_cmd file takes precedence.

You can use distributed processing in the following computing environments:

•LSF System

•Gridware System

•General Network With a List of Machines

The number of jobs to be submitted is determined by number of partitions specified by the

NUM_PARTS command.

To enable automatic distributed processing job submission, you must run the StarXtract

command with the -clean, -cleanX, -cleanT, -cleanN, -cleanD, or -cleanXREF option.

The license requirement for this feature is the same as that required by manual submission

for the same number of jobs.

When using Gridware system or the list of machines, a _starrcdp.csh shell script is written

to the current working directory and then invoked by a grid command (for a Gridware

system) or the rsh command (for a list of machines).

The executions of the distribution are reported at the beginning of the star_sum file.

LSF System

In an LSF system, you can specify STARRC_DP_STRING as

• An environment variable before launching the tool. Be sure to enclose the LSF command

in single quotes. For example,

% setenv STARRC_DP_STRING 'bsub -a amd64 -R "rusage[mem=5000]"'

• A statement in the star_cmd file. For example,

STARRC_DP_STRING: bsub -a amd64 -R "rusage[mem=5000]"

Gridware System

In a Gridware system, you can specify STARRC_DP_STRING as

• An environment variable before launching the tool. Be sure to enclose the Gridware

command in single quotes. For example,

% setenv STARRC_DP_STRING 'qsub -P bnormal -l "mem_free=1G

Chapter 2: Running StarRC

Distributed Processing 2-9

Chapter 2: Running StarRC

Distributed Processing 2-9

StarRC User Guide and Command Reference Version F-2011.06

mem_avail=1G"'

• A statement in the star_cmd file. For example,

STARRC_DP_STRING: qsub -P bnormal -l "mem_free=1G mem_avail=1G"

General Network With a List of Machines

For a general network with a list of machines, you can specify STARRC_DP_STRING as

• An environment variable before launching the tool. Be sure to enclose the list in single

quotes. For example,

% setenv STARRC_DP_STRING 'list mars jupiter uranus'

• A statement in the star_cmd file. For example,

STARRC_DP_STRING: list mars jupiter uranus

When using a general network with a list of host machines,

• Each machine must be available through a the UNIX rsh command without a password

• The list keyword can only be followed by machine names; it does not support any other

options

• If the specified number of machines does not match NUM_PARTS, the number of jobs to be

dispatched is the minimum of these two numbers

• For multicore machines, you can specify the machine name multiple times

Summary File

In previous releases, distributed processing runs were reported in the star_sum file as a

simple concatenation of summaries from each CPU.

After the distributed processing is complete, StarRC provides a distributed processing report

in the summary file. The report includes the following information:

• Stage summary – Reports run time, memory consumption, CPU or host on which the job

was executed, and job completion timestamp.

• Distributed processing summary for distributed stages – Shows the maximum and

average runtime for each CPU.

• Total runtime – Shows timestamps for the beginning and the end of the run, in addition to

the total runtime.

• Pre-extraction and post extraction times - Reports the runtime information of

pre-extraction and post-extraction stages.

Chapter 2: Running StarRC

Distributed Processing 2-10

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

The following example shows a summary file for a StarXtract -clean run:

Example 2-1 Summary File for a -clean Run

--------------------------------------------------------------------------------------

CPU# | STAGE SUMMARY | END TIME |HOSTNAME

--------------------------------------------------------------------------------------

CPU_01 |*Layers Elp=00:00:01 Cpu=00:00:00 Mem=48.8 | Feb 10 17:45:58 | yak068

CPU_01 |*Models Elp=00:00:00 Cpu=00:00:00 Mem=45.7 | Feb 10 17:46:00 | yak068

CPU_01 |*HN Elp=00:01:05 Cpu=00:00:13 Mem=124.7 | Feb 10 17:47:11 | yak068

CPU_01 |*Cells Elp=00:00:37 Cpu=00:00:02 Mem=121.2 | Feb 10 17:47:50 | yak068

CPU_01 |*Translate Elp=00:01:25 Cpu=00:00:41 Mem=231.2 | Feb 10 17:49:19 | yak068

CPU_01 |*NetlistSetup Elp=00:00:00 Cpu=00:00:00 Mem=45.6 | Feb 10 17:49:23 | yak068

CPU_01 |*Partition Elp=00:00:21 Cpu=00:00:15 Mem=49.1 | Feb 10 17:49:49 | yak068

CPU_01 |*Sort_part1 Elp=00:00:05 Cpu=00:00:04 Mem=104.8 | Feb 10 17:49:59 | yak068

CPU_04 |*Sort_part2 Elp=00:00:04 Cpu=00:00:03 Mem=103.7 | Feb 10 17:50:01 | cow135

CPU_02 |*Sort_part3 Elp=00:00:05 Cpu=00:00:03 Mem=103.3 | Feb 10 17:50:06 | cow118

CPU_03 |*Sort_part4 Elp=00:00:04 Cpu=00:00:03 Mem=106.0 | Feb 10 17:50:08 | cow158

CPU_03 |*xTract_part4 Elp=00:05:21 Cpu=00:05:18 Mem=498.5 | Feb 10 17:55:35 | cow158

CPU_01 |*xTract_part1 Elp=00:05:40 Cpu=00:05:36 Mem=463.6 | Feb 10 17:55:41 | yak068

CPU_04 |*xTract_part2 Elp=00:06:26 Cpu=00:06:22 Mem=486.5 | Feb 10 17:56:27 | cow135

CPU_02 |*xTract_part3 Elp=00:06:19 Cpu=00:06:13 Mem=467.2 | Feb 10 17:56:34 | cow118

CPU_01 |*xTractPP Elp=00:00:29 Cpu=00:00:19 Mem=114.1 | Feb 10 17:57:08 | yak068

CPU_02 |*Netlist_part4 Elp=00:00:16 Cpu=00:00:13 Mem=398.1 | Feb 10 17:57:39 | cow118

CPU_01 |*Netlist_part1 Elp=00:00:43 Cpu=00:00:36 Mem=349.6 | Feb 10 17:57:58 | yak068

CPU_04 |*Netlist_part2 Elp=00:00:45 Cpu=00:00:42 Mem=504.9 | Feb 10 17:58:02 | cow135

CPU_03 |*Netlist_part3 Elp=00:00:42 Cpu=00:00:40 Mem=507.7 | Feb 10 17:58:04 | cow158

CPU_01 |*Netlist_merge Elp=00:00:10 Cpu=00:00:00 Mem=28.3 | Feb 10 17:58:17 | yak068

--------------------------------------------------------------------------------------

Maximum and average run time (Elp) for distributed stages:

Sort max=00:00:05 avg=00:00:04

xTract max=00:06:26 avg=00:05:56

Netlist max=00:00:45 avg=00:00:36

--------------------------------------------------------------------------------------

Start Time: Thu Feb 10 17:45:56 2011

End Time: Thu Feb 10 17:58:28 2011

Total Wall Time: 00:12:32

Time on PreXtraction: 00:04:05

Time on Xtraction: 00:06:35

Time on PostXtraction: 00:01:52

--------------------------------------------------------------------------------------

The following example shows a summary file for a StarXtract –cleanN run:

Example 2-2 Summary File for a -cleanN Run

--------------------------------------------------------------------------------------

CPU# | STAGE SUMMARY | END TIME |HOSTNAME

--------------------------------------------------------------------------------------

CPU_01 |*NetlistSetup Elp=00:00:00 Cpu=00:00:00 Mem=45.6 | Feb 11 14:36:43 | yak048

CPU_01 |*xTractPP Elp=00:00:22 Cpu=00:00:17 Mem=114.1 | Feb 11 14:37:14 | yak048

CPU_04 |*Netlist_part4 Elp=00:00:12 Cpu=00:00:10 Mem=398.1 | Feb 11 14:37:37 | dog124

CPU_01 |*Netlist_part1 Elp=00:00:32 Cpu=00:00:29 Mem=349.6 | Feb 11 14:37:49 | yak048

CPU_03 |*Netlist_part3 Elp=00:00:31 Cpu=00:00:29 Mem=507.7 | Feb 11 14:37:55 | yak726

CPU_02 |*Netlist_part2 Elp=00:00:36 Cpu=00:00:34 Mem=504.9 | Feb 11 14:37:58 | dog131

CPU_01 |*Netlist_merge Elp=00:00:05 Cpu=00:00:00 Mem=28.3 | Feb 11 14:38:06 | yak048

--------------------------------------------------------------------------------------

Maximum and average run time (Elp) for distributed stages:

Netlist max=00:00:36 avg=00:00:27

Chapter 2: Running StarRC

StarRC Licensing Features 2-11

Chapter 2: Running StarRC

StarRC Licensing Features 2-11

StarRC User Guide and Command Reference Version F-2011.06

--------------------------------------------------------------------------------------

Start Time: Fri Feb 11 14:36:40 2011

End Time: Fri Feb 11 14:38:16 2011

Total Wall Time: 00:01:36

Time on PreXtraction: 00:00:08

Time on Xtraction: 00:00:03

Time on PostXtraction: 00:01:25

--------------------------------------------------------------------------------------

Performance Optimization

To optimize performance, ensure that the STAR_DIRECTORY directory is located on the

machine that executes the first StarXtract command. Running the translation across a

network drastically increases the runtime.

You should also keep the number of CPUs equal to the number of partitions, as specified by

theNUM_PARTS command. Failing to do so might result in an inefficient use of computing

resources; if the number of jobs exceeds the number of partitions, the extra jobs would not

run.

Licensing Requirements for Distributed Processing

You must have a StarRC or StarRC Ultra license to run distributed multicore processing; the

StarRC Custom package supports only single-core processing.

StarRC Licensing Features

The StarXtract command has two options related to licensing:

• The -custom option is designed for customers who have only one Custom license in their

license server. This option supports only the StarRC Custom features specified in

Table B-2 on page B-11. With this option, multicore processing and upper-tier commands

are not allowed.

• The -ultra option allows you to check out only an Ultra license key. By specifying this

option, you can indicate a preference to wait until an Ultra license is available, rather than

needing to checking out two StarRC licenses or four Custom licenses.

Tiered Licensing Checkout Policy

When all three types of license keys are available in your license pool, multiple lower-tier

keys can be used to run upper-tier features, as detailed in Figure 2-2. For example, two

StarRC keys or four Custom license keys can run a job with an Ultra feature. Similarly, two

Custom license keys can run one job with a StarRC feature.

Chapter 2: Running StarRC

StarRC Licensing Features 2-12

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

However, if the -custom option is specified, then StarRC runs only with an available Custom

license. Similarly, if the -ultra option is specified, then StarRC runs only with an available

Ultra license.

Figure 2-2 Tiered Licensing Checkout Policy Without License Queuing

License Queuing Not Enabled

License queuing is not enabled when the UNIX environment variable

STARRC_LICENSE_WAIT is not set to YES. As shown in Figure 2-2, StarRC does not run when

the appropriate licenses are not available and license queuing is disabled.

License Queuing Enabled

To queue a StarRC job when the appropriate licenses are not available, you can enable

license queuing by activating the UNIX environment variable STARRC_LICENSE_WAIT as

follows:

$ setenv STARRC_LICENSE_WAIT yes

Chapter 2: Running StarRC

StarRC Licensing Features 2-13

Chapter 2: Running StarRC

StarRC Licensing Features 2-13

StarRC User Guide and Command Reference Version F-2011.06

Figure 2-3 shows the tiered licensing checkout procedure with license queuing. When the

appropriate licenses are not available, then StarRC queues the job according to the

StarXtract command options and the features that are used:

• If the -custom option is specified in the command line, then the job queues for one

Custom license.

• If the -ultra option is specified in the command line, then the job queues for one Ultra

license.

• If neither option is specified, but the job uses an Ultra feature, then the job queues for two

StarRC licenses; if no Ultra feature is used, then the job queues for one StarRC license.

Figure 2-3 Tiered Licensing Checkout Policy With License Queuing

License Queuing Daemon

To use StarRC license queuing, specify the license server as

/full/path/to/license/file or port@host. Download and install the 10.9.2 (or higher)

version of the snpslmd combined vendor daemon.

Chapter 2: Running StarRC

StarRC Command File Conventions 2-14

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

StarRC Command File Conventions

All StarRC command options fall into one of nine specification categories. Each category

has a fixed structure that is interpreted consistently by all StarRC modules. Table 2-2 lists

the command types, including a brief description of the input format. Throughout the

remainder of this manual, all command definitions refer to one of these types.

File and directory paths can be specified as either absolute or relative paths in both the GUI

and the batch command file; however, relative paths are always resolved with respect to the

StarRC working directory (not the location of the command file itself). An exception is that

STAR_DIRECTORY cannot be specified with an absolute path.

Use an asterisk (*) at the beginning of a line to indicate a comment.

StarRC command options are not case-sensitive. In batch mode, command options should

be listed in the command file in the following format: command: value

Table 2-2 Command Types

Type Description Multi Format Example

BOOLEAN Simple Boolean flag. NO command: YES | NO CASE_SENSITIVE: YES

DIRECTORY Valid directory name

with full or relative

path. Symbolic links

are acceptable.

NO command:

directory_name

MILKYWAY_DATABASE: design

FILE Valid file name with full

or relative path,

symbolic links are

acceptable.

NO command: file_name NETLIST_FILE: ../star.spf

FILE LIST List of valid file names

with full or relative

paths delimited by

white spaces.

Symbolic links are

acceptable.

YES command: file_name

... file_name

LEF_FILE: tech.lef ../

macroA.lef

FLOAT Floating-point number

can be expressed

exponentially or with

character suffix to

define unit. Must not

contain white space.

NO command:

float[a|f|p|u|n|m|K|

Meg|Gig]

FSCOMPARE_THRESHOLD: 1e-15

CLOCK_SIMULATION_TIME: 200n

INT Integer. NO command: integer NELIST_MAX_LINE: 80

Chapter 2: Running StarRC

StarRC Command File Conventions 2-15

Chapter 2: Running StarRC

StarRC Command File Conventions 2-15

StarRC User Guide and Command Reference Version F-2011.06

LINE String that can contain

white space. Only one

string per line is

allowed.

YES command: sentence

command: sentence

NET_VOLTAGE: vdd 2.5

NET_VOLTAGE: vss 0.0

LIST White space delimited

list of strings.

YES command: string ...

string

NETS: net1 net2 net3

STRING Single word that must

not contain white

space.

NO command: string BLOCK: top

Table 2-2 Command Types (Continued)

Type Description Multi Format Example

Chapter 2: Running StarRC

StarRC Command File Conventions 2-16

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

3-1

Process Characterization Interface 3

This chapter describes how you or your foundry defines the foundry process used to

manufacture your design. It involves writing a description of the technology process cross

section in an Interconnect Technology Format (ITF) file.

This chapter contains the following sections:

•Process Characterization Basics

•The Interconnect Technology Format File

•Creating the ITF File

•Process Effects That Affect Resistance and Capacitance

•Defining Additional Extraction Characteristics

•Defining Sheet Zones

•Modeling Thickness Variation With StarRC

•Interconnect Parasitics Extraction Based on CMP Simulators

•Microloading Effect

•Damage Modeling

•Translation of Routing DEF Blockage

•Temperature Derating

Chapter 3: Process Characterization Interface

3-2

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

•Transparent Half-Node Flow

•Generating TLUPlus Models

•Via Merging

•Writing a Mapping File

Chapter 3: Process Characterization Interface

Process Characterization Basics 3-3

Chapter 3: Process Characterization Interface

Process Characterization Basics 3-3

StarRC User Guide and Command Reference Version F-2011.06

Process Characterization Basics

Process characterization is composed of those steps you take to define the chip’s physical

layer composition, before you run the grdgenxo command to generate the nxtgrd database.

See Figure 3-1. To begin the process characterization, specify the content of each layer in

an Interconnect Technology Format (ITF) file. Normally, you need to define only one ITF file

for each process technology you plan to extract.

The ITF file consolidates all process information into one source file.

Figure 3-1 ITF File Generation

ITF

FILE

grdgenxo nxtgrd

database

User-created ITF Executable

command output database

Process characterization

The nxtgrd File

The nxtgrd (New Xtraction Generic Regression Database) output file is a database

containing capacitance, resistance, and layer information, which can be encrypted. The ITF

file is also included in the database output file. An internal field solver operating on an

extensive set of primitive structures generates the nxtgrd file. StarRC uses the nxtgrd file to

calculate the parasitics of the actual layout by pattern matching.

You can encrypt the ITF file copy, located at the top of the binary capacitance tables in the

nxtgrd file, by using the -encrypt option of the grdgenxo command:

% grdgenxo -encrypt itf_file

For more information about the grdgenxo command, see Chapter 19, “The grdgenxo

Command.” For details about StarRC compatibility with nxtgrd files generated by earlier

versions of StarRC, see the StarRC Release Notes.

Chapter 3: Process Characterization Interface

The Interconnect Technology Format File 3-4

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

The Interconnect Technology Format File

The ITF file defines a cross section profile of the process. This is an ordered list of conductor

and dielectric layer definition statements. The layers are defined from the topmost dielectric

layer, to the bottommost dielectric layer, excluding substrate. As you read the text of the ITF

file, the layers are defined in the same order in which you would see them in a cross section

view of the process. The ITF cross section layer spatial parameters are specified layer by

layer in a way that is consistent with the physical process.

The lowest layer in the ITF cross section should always be a DIELECTRIC layer. SUBSTRATE

is a reserved keyword and refers to a special conductor whose top plane is at 0 height; it is

assumed to be underneath the lowest defined dielectric. You do not define SUBSTRATE in the

ITF file.

Statements defining via layers follow the process cross section and are defined only relative

to valid conducting layers.

The heights of the conductors and dielectrics are determined exclusively by the order in

which they are specified and by the thicknesses of the lower layers. When you are specifying

a new conductor or dielectric layer, the bottom plane of that layer is exactly the top plane of

the lowest dielectric layer unless a MEASURED_FROM statement is included to explicitly specify

the location of the bottom plane. The lowest dielectric—the lowest physical layer—listed in

the ITF file is automatically measured from the SUBSTRATE layer. A fully planar process, in

which the process cross section does not contain any vertically intersecting conductors at

different heights, is the simplest model. You can find cross section ITF examples in

Appendix A, “ITF Examples.”

Creating the ITF File

To manually create a basic ITF file, follow these steps:

1. Define the TECHNOLOGY statement.

TECHNOLOGY = process_name

The TECHNOLOGY statement is mandatory. You assign process_name as the value

assigned to the TECHNOLOGY statement. The TECHNOLOGY statement should precede all

other statements, but it does not have to be the first line. The output of the grdgenxo

command is stored in the process_name.nxtgrd file.

The TECHNOLOGY statement provides a way of naming a process for tracking and

identification purposes; the statement can be any single word.

Chapter 3: Process Characterization Interface

Creating the ITF File 3-5

Chapter 3: Process Characterization Interface

Creating the ITF File 3-5

StarRC User Guide and Command Reference Version F-2011.06

2. A background dielectric can be specified after the TECHNOLOGY statement, although it is

not required. A background dielectric globally fills the cross section with material of the

given dielectric constant to an infinite height. DIELECTRIC commands specified in the ITF

process cross section locally override the global background dielectric. The default for the

background dielectric is 1.0, or air.

BACKGROUND_ER = float

Note:

This constant background dielectric extends to an infinite height, so it effectively

replaces air as the operating medium for the chip.

3. After defining the TECHNOLOGY statement (or background dielectric definition), define the

following basic layer characteristics and information for all the CONDUCTOR and

DIELECTRIC layers.

ITF layer naming restrictions for CONDUCTOR, DIELECTRIC, and VIA statements are as

follows:

• Layer names must contain only alphanumeric characters and underscores (_).

• Layer names must begin with an alphabetic character.

The following are layer characteristics to be defined:

• Thickness of each CONDUCTOR or DIELECTRIC

• Minimum width and spacing of each CONDUCTOR (design rule spacing)

• Resistivity information of each CONDUCTOR

• Permittivity of each DIELECTRIC

• Resistivity information of each VIA

• Connectivity information of each VIA

4. After you have defined these basic ITF requirements, you can add more definitions to

model other processes.

The following are additional definitions you can use to model other processes:

• Conformal dielectrics

• Vertically overlapping conductors (local interconnect)

• Width-and-spacing-dependent resistance

• Temperature-dependent resistance

• Process-variation-dependent resistance

• Layer-specific or width and spacing etch effects

Chapter 3: Process Characterization Interface

Process Effects That Affect Resistance and Capacitance 3-6

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

• Dielectric air gaps

• Metal fill

• Thickness variation based on local density

5. Add other statements between the TECHNOLOGY statement and the layer definitions.

Other statements might be BACKGROUND_ER or GLOBAL_TEMPERATURE.

The following example shows a basic ITF file:

TECHNOLOGY = SIMPLE

DIELECTRIC TOP { THICKNESS = 3.600 ER = 3.9 }

CONDUCTOR M2 {

THICKNESS = 0.250 WMIN = 0.5

SMIN = 0.5 RPSQ = 0.05 }

DIELECTRIC D3 { THICKNESS = 0.300 ER = 3.9 }

CONDUCTOR M1 {

THICKNESS = 0.212 WMIN = 0.5

SMIN = 0.5 RPSQ = 0.05 }

DIELECTRIC D2 { THICKNESS = 0.200 ER = 4.2 }

CONDUCTOR POLY{

THICKNESS = 0.100 WMIN = 0.3

SMIN = 0.3 RPSQ = 10.0}

DIELECTRIC D1 { THICKNESS = 0.300 ER = 3.9 }

VIA via1 { FROM=M1 TO=M2 RHO=0.263 }

VIA polyCont { FROM=POLY TO=M1 RHO=0.352 }

VIA diffCont { FROM=SUBSTRATE TO=M1 RHO=0.500 }

Process Effects That Affect Resistance and Capacitance

The process effects specified in the ITF that can affect resistance are RPSQ,

RPSQ_VS_SI_WIDTH, and RPSQ_VS_WIDTH_AND_SPACING.

The following options affect resistance or capacitance, depending on whether you specify

the RESISTIVE_ONLY option:

THICHKNESS_VS_DENSITY (affects resistance and capacitance)

THICKNESS_VS_WIDTH_AND_SPACING (affects resistance and capacitance)

ETCH (affects resistance and capacitance)

ETCH_VS_WIDTH_AND_SPACING (affects resistance and capacitance)

The following two options affect both resistance and capacitance:

POLYNOMIAL_BASED_THICKNESS_VARIATION

BOTTOM_THICKNESS_VS_SI_WIDTH

Chapter 3: Process Characterization Interface

Gate-To-Diffusion Capacitance Extraction Based on Capacitance Tables 3-7

Chapter 3: Process Characterization Interface

Gate-To-Diffusion Capacitance Extraction Based on Capacitance Tables 3-7

StarRC User Guide and Command Reference Version F-2011.06

The following two options affect only resistance:

CRT

CRT_VS_SI_WIDTH

Note:

The SIDE_TANGENT option does not change the resistance as the CENTER WIDTH of the

conductor does not change and the resistance depends on that center width.

Gate-To-Diffusion Capacitance Extraction Based on Capacitance

Tables

In UDSM design flows, a seamless interface between parasitic extraction and circuit

simulation tools (for example, StarRC and HSPICE™) is crucial for accurate circuit behavior

predictability in silicon. The pieces from extraction (for example, parasitics) and simulation

(for example, SPICE models) must integrate tightly to avoid double counting or the

elimination of critical layout dependent device parasitics, such as gate-to-contact and

gate-to-diffusion capacitance as shown in Figure 3-2. As process nodes continue to shrink,

it is common practice to remove the constant, spatially independent, device-level parasitics

from SPICE models and expect parasitic tools such as StarRC to extract these critical

components.

Figure 3-2 Layout Dependent Parasitics

DIFF

GATE

This section describes the ability to extract the gate-to-diffusion capacitance component

only when the IGNORE_CAPACITANCE:ALL setting is specified. The gate-to-diffusion intra

device capacitance is of interest for parasitic extraction tools because of the strong layout

dependency of this capacitance component. The gate-to-contact capacitance is extracted

using the EXTRACT_VIA_CAPS:YES command in the StarRC command file.

Chapter 3: Process Characterization Interface

Device-Specific Contact Etch 3-8

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

To retain the gate-to-diffusion (Cf) coupling component when IGNORE_CAPACITANCE: ALL is

specified during a StarRC parasitic extraction, use the following command:

IGNORE_CAPACITANCE:ALL RETAIN_GATE_TO_DIFFUSION_COUPLING

For IGNORE_CAPACITANCE settings other than ALL (DIFF, NONE) in which the

gate-to-diffusion capacitance is retained by default, StarRC extracts this component as

requested.

When you specify this option, StarRC uses the following methods to extract the

gate-to-diffusion component:

• Based on precharacterized models, similar to other capacitances extracted by StarRC

• Based on a 2-D capacitance table look-up dependent on layout parameters

See also GATE_TO_DIFFUSION_CAP and IGNORE_CAPACITANCE.

Device-Specific Contact Etch

StarRC allows you to apply different contact etch values based on the device type. Use the

following syntax to specify multiple contact-bias tables within the VIA statement:

ETCH_VS_CONTACT_AND_GATE_SPACINGS CAPACITIVE_ONLY {

NUMBER_OF_TABLES = num_of_tables

name_of_table1 {

CONTACT_TO_CONTACT_SPACING { c1 c2 c3 ... }

GATE_TO_CONTACT_SPACING { s1 s2 s3 ... }

VALUES { v(c1,s1) v(c2,s1) ...

v(c1,s2) v(c2,s2) ...

...

}

name_of_table2 {

CONTACT_TO_CONTACT_SPACING { c1 c2 c3 ... }

GATE_TO_CONTACT_SPACING { s1 s2 s3 ... }

VALUES { v(c1,s1) v(c2,s1) ...

v(c1,s2) v(c2,s2) ...

...

}

...

}

Note:

You must specify NUMBER_OF_TABLES to define multiple contact etch tables in the ITF.

Specify the values for CONTACT_TO_CONTACT_SPACING, GATE_TO_CONTACT_SPACING,

and VALUES microns.

Example 3-1 shows a VIA statement with multiple contact etch tables.

Chapter 3: Process Characterization Interface

Device-Dependent Gate-to-Diffusion Capacitance Table 3-9

Chapter 3: Process Characterization Interface

Device-Dependent Gate-to-Diffusion Capacitance Table 3-9

StarRC User Guide and Command Reference Version F-2011.06

Example 3-1 VIA Statement With Multiple Contact Etch Tables

VIA diffCont {

FROM=diff TO=metal1

AREA=0.0036 RPV=55

CRT1=9.56e-04 CRT2=-3.68e-07

ETCH_VS_CONTACT_AND_GATE_SPACINGS CAPACITIVE_ONLY {

NUMBER_OF_TABLES=2

NMOS {

CONTACT_TO_CONTACT_SPACINGS {0.08 0.12}

GATE_TO_CONTACT_SPACINGS {0.04 0.08}

VALUES {0.008 0.009

0.003 0.005}

}

PMOS {

CONTACT_TO_CONTACT_SPACINGS {0.08 0.12}

GATE_TO_CONTACT_SPACINGS {0.04}

VALUES {0.004 0.002}

}

Device-Dependent Gate-to-Diffusion Capacitance Table

You can specify a Cf table based on the device type. The following syntax defines multiple

gate-to-diffusion capacitance tables in the ITF. Note that the number of tables and the table

name must be specified when multiple gate-to-diffusion tables are specified in the ITF.

GATE_TO_DIFFUSION_CAP {

NUMBER_OF_TABLES = num_of_tables

model_name1{

CONTACT_TO_CONTACT_SPACINGS {c1 c2 c3 ...}

GATE_TO_CONTACT_SPACINGS {s1 s2 s3 ...}

CAPS_PER_MICRON { v(c1,s1) v(c2,s1)...

v(c1,s2) v(c2,s2)... }

}

model_name2{

CONTACT_TO_CONTACT_SPACINGS {c1 c2 c3 ...}

GATE_TO_CONTACT_SPACINGS {s1 s2 s3 ...}

CAPS_PER_MICRON { v(c1,s1) v(c2,s1)...

v(c1,s2) v(c2,s2)... }

}

...

}

A contact etch table and a gate-to-diffusion capacitance table for the same type of device

should have the same table names, as shown in Example 3-2.

Chapter 3: Process Characterization Interface

Defining Additional Extraction Characteristics 3-10

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Example 3-2 Multiple Gate-to-Diffusion Capacitance Tables in a CONDUCTOR Statement

CONDUCTOR gpoly {

THICKNESS= 0.080000 WMIN= 0.040 SMIN= 0.100 RPSQ=12.000

GATE_TO_CONTACT_SMIN=0.040 CRT1=1.924e-03 CRT2=-8.751e-07

GATE_TO_DIFFUSION_CAP {

NUMBER_OF_TABLES=2

NMOS{

CONTACT_TO_CONTACT_SPACINGS {0.08 0.12}

GATE_TO_CONTACT_SPACINGS {0.04 0.08}

CAPS_PER_MICRON {0.062 0.088

0.080 0.096}

}

PMOS{

CONTACT_TO_CONTACT_SPACINGS {0.08 0.12}

GATE_TO_CONTACT_SPACINGS {0.04 0.08}

CAPS_PER_MICRON {0.088 0.120

0.108 0.128}

}

Defining Additional Extraction Characteristics

To perform more extensive extraction tasks, you can add these characteristics to the ITF:

• Conformal dielectrics

• Vertical overlapping

• Width-dependent conductor resistance

• Layer-specific etch effects

• Dielectric air gaps

• Metal fill

• 45-degree angles

• Diffusion resistance extraction

Handling Special Process Effects

Certain effects require special processing while running StarRC.

•Conformal Dielectrics

•Conductor Cutting Dielectric

Chapter 3: Process Characterization Interface

Defining Additional Extraction Characteristics 3-11

Chapter 3: Process Characterization Interface

Defining Additional Extraction Characteristics 3-11

StarRC User Guide and Command Reference Version F-2011.06

•Covertical Conductors

•Drop Factor

•Dielectric Air Gaps

•Layer Etch

•Metal Fill (Emulated)

•45-Degree Angles

•Diffusion Resistance Extraction

•Spacing- and Width-Dependent Etch

•CAPACITIVE_ONLY and RESISTIVE_ONLY

•Determining WMIN and SMIN Values

•Retaining Coupling Capacitance Between Top and SKIP_CELL Levels

•Handling Overlapping Wells

The ways in which you can handle these are discussed in the following sections.

Conformal Dielectrics

The MEASURED_FROM statement provides the ability to customize the model to account for

such process characteristics as conformal dielectrics, mixed conformal and planar

dielectrics, and covertical conductors. When used with a DIELECTRIC layer definition, the

MEASURED_FROM keyword can refer to a lower dielectric or can have the value TOP_OF_CHIP.

When used with a CONDUCTOR layer definition, the MEASURED_FROM keyword can refer only to

a lower PLANAR dielectric. See specific examples in Appendix A, “ITF Examples.”

The TOP_OF_CHIP keyword value facilitates the creation of conformal dielectrics. It creates

the bottom plane from the layers already present below the new layer and mimics the

topology of the existing base (copies any existing nonplanarities to the new layer, which has

a conformal thickness).

The TOP_OF_CHIP keyword value is required only if you are creating a conformal layer

whose topology is based on the top of the chip. If you want to create a conformal layer that

is on top of an existing conformal dielectric, you can measure either from TOP_OF_CHIP or

the existing conformal layer.

Note:

A MEASURED_FROM statement in CONDUCTOR definitions must always refer to a planar

dielectric.

Chapter 3: Process Characterization Interface

Defining Additional Extraction Characteristics 3-12

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Note that if you create a layer (defined in a MEASURED_FROM command) referring to a planar

layer, the new layer is also planar, regardless of whether or not you define TW_T and SW_T.

To regain layer planarity after a conformal dielectric has been defined, you need to take the

following steps when defining the new planarized layer:

1. Use the MEASURED_FROM statement to reference a planar dielectric somewhere lower in

the process cross section.

2. Adjust the thickness for the new layer so it is equal to its actual physical thickness plus

the thickness of any layer on top of the MEASURED_FROM layer.

If you place another dielectric layer on top of the conformal layer without using

MEASURED_FROM to regain planarity, use SW_T and TW_T to set the sidewall and top wall

thickness because the new layer is also conformal.

Conductor Cutting Dielectric

If you use the MEASURED_FROM statement with a conductor and that conductor layer is

measured from a dielectric layer that is placed below another dielectric layer, the conductor

might cut through the intermediate dielectric.

Consider the following example:

TECHNOLOGY = SIMPLE

DIELECTRIC TOP { THICKNESS = 3.600 ER = 3.9 }

CONDUCTOR M1 { THICKNESS = 0.600 WMIN = 0.5

SMIN = 0.5 RPSQ = 0.05 }

DIELECTRIC D3 { THICKNESS = 0.300 ER = 3.9 }

CONDUCTOR POLY{ THICKNESS = 0.200 WMIN = 0.3

SMIN = 0.3 RPSQ = 10.0

MEASURED_FROM = D1 }

DIELECTRIC D2 { THICKNESS = 0.100 ER = 4.2 }

DIELECTRIC D1 { THICKNESS = 0.300 ER = 3.9 }

The process cross section is shown in Figure 3-3, where POLY cuts through dielectric D2.

Chapter 3: Process Characterization Interface

Defining Additional Extraction Characteristics 3-13

Chapter 3: Process Characterization Interface

Defining Additional Extraction Characteristics 3-13

StarRC User Guide and Command Reference Version F-2011.06

Figure 3-3 Conductor Cuts an Intermediate Dielectric

POLY

D 1

D 2

D 3 0.2

0.1

0.3

M 1

TOP

3.6

SUBSTRATE

Covertical Conductors

StarRC supports covertical (vertically overlapping) conductors. See example file information

about gate poly and local interconnect processes in Appendix A, “ITF Examples.” The

examples illustrate the ITF handling of covertical conductors that might have unique

thicknesses, as in the case of local poly interconnect.

In this case, the layout database should be modified for the covertical layers, so that those

layers (Gate and Field Poly or Poly and Local Interconnect) do not overlap each other. This

can be done in the Hercules runset by use of BOOLEAN operations:

BOOLEAN POLY NOT LI {} TEMP=POLY

BOOLEAN POLY AND LI {} TEMP=LI_OVERLAP

BOOLEAN POLY NOT LI_OVERLAP {} TEMP=POLY

BOOLEAN LI NOT LI_OVERLAP {} TEMP=LI

In the latter case, both LI and LI_OVERLAP are mapped to the Local Interconnect layer in the

nxtgrd file, and the CONNECT sequence in the Hercules runset should be modified

accordingly.

Chapter 3: Process Characterization Interface

Defining Additional Extraction Characteristics 3-14

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Another potential use for covertical conductors is to handle “metal cheesing” (also known as

wide metal slotting); it creates two metal layers and gives them different sheet resistances,

which can be done in the mapping file without changing anything in the ITF, as follows:

conducting_layers

M5 metal5 RPSQ=10

M5_cheese metal5 RPSQ=100

Note that making separate layers in the ITF for covertical conductors is suitable only for

capacitive modeling; you should not use it for only resistance differences.

Drop Factor

The drop factor feature handles the case in which a conducting layer is at different heights

because of the absence of a lower conducting layer. For example, if Metal2 runs over

Metal1, Metal2 is uniform at a certain height above Metal1. If Metal2 is layered over a

location where there is no Metal1, Metal2 is layered at a lower height. The drop factor feature

considers the differences between the conducting layer heights and calculates the area and

lateral capacitance correctly. An illustration of the process is shown in Figure 3-4.

Figure 3-4 Nonplanar Process Where Conductor Heights Vary As a Function of the Absence of

Lower Conductors

SUBSTRATE

DM1

M1 M1

DM1

DM1+M2 M3

DM2

Nonplanar conductor modeling is typically required for legacy processes at process nodes

above 0.18 micron with smaller numbers of metal conducting layers. The following

observations have been made:

• Such processes typically contain three metals or less.

• Nonplanarities can be introduced by any missing layer in the physical cross section.

Chapter 3: Process Characterization Interface

Defining Additional Extraction Characteristics 3-15

Chapter 3: Process Characterization Interface

Defining Additional Extraction Characteristics 3-15

StarRC User Guide and Command Reference Version F-2011.06

• Both area and lateral capacitance effects are relevant between two metals that are

consecutive in height. Depending on the degree of drop of an upper conductor, the drop

could introduce a covertical overlap between consecutive conductors that would

introduce a potentially significant lateral capacitance effect. See Figure 3-5.

Figure 3-5 Lateral and Area Capacitance Effects Introduced by Large Drop Factor Values

SUBSTRATE

DM1

Clateral Carea

Drop Factor Error Conditions

The following are error conditions that StarRC might find in your design:

• Specifying the DROP_FACTOR ITF statement option should not cause different horizontally

consecutive levels of the same conductor to become noncovertical with each other. In

other words, if a piece of conductor routing undergoes a different cumulative drop factor

as the number of lower conductors vary along the length of the route, the conductor

should never drop such that it can no longer abut with itself. Horizontally adjacent pieces

of a conductor can cause fail to be covertical because of an excessive cumulative drop

factor. See Figure 3-6.

Chapter 3: Process Characterization Interface

Defining Additional Extraction Characteristics 3-16

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Figure 3-6 Drop Factor Error Condition 1

M2M2 DM1

No covertical area

M2M2 DM1

Covertical area

Horizontally adjacent pieces of a conductor fail to

be coverticle because of excessive cumulative drop

factor.

Satisfactory condition for drop factor, in which

horizontally adjacent pieces of the same conductor

have coverticle overlap over the length of the

conductor.

• No conductor can be modeled at a height below conductors represented at lower levels

in the ITF cross sectional description. If this is the case grdgenxo produces an error. See

Figure 3-7.

Figure 3-7 Drop Factor Error Condition 2

DM1 Error:

M2 falls below M1

Error condition in which an upper conductor (M2)

M2 base remains

above M1 base

Satisfactory condition for drop factor in which all

falls below excessive drop factor associated with

the lower conductors.

levels of upper conductors (M2) maintain a base

height above the base height of all levels of lower

conductors.

Chapter 3: Process Characterization Interface

Defining Additional Extraction Characteristics 3-17

Chapter 3: Process Characterization Interface

Defining Additional Extraction Characteristics 3-17

StarRC User Guide and Command Reference Version F-2011.06

• Drop factor is not supported with processes that have these features:

• Covertical layers like gate and field polysilicon or polysilicon and local interconnect

• Metal fill emulation using FILL_SPACING, FILL_WIDTH, and FILL_RATIO

• Conformal dielectrics

• Up to four conductors can have the DROP_FACTOR specified.

Modeling a Double-Poly Process Using DROP_FACTOR

To model a double-polysilicon process in StarRC, you can set the IS_CONFORMAL and

ASSOCIATED_CONDUCTOR options in the DIELECTRIC layers of the ITF. The IS_PLANAR

command is necessary in this case to make the metals above the poly layers planar. For

more information, see the IS_PLANAR ITF option.

See an example of this cross section in Figure 3-8.

Figure 3-8 Conformal Dielectric and Poly Layers

Substrate

BSD

LAT_ACT

ACTIVE

U_P_D

POLY_A

C_D_PA_A

POLY_B

POLY_A

C_D_PA_A

U_P_D

ILD_B

ILD_A

C_D_PB

POLY_B

C_D_PA_B

TD TD TD TD

Chapter 3: Process Characterization Interface

Defining Additional Extraction Characteristics 3-18

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Example 3-3 Modeling a Double-Polysilicon Process in the ITF

DIELECTRIC ILD_B { THICKNESS=0.3 MEASURED_FROM=ILD_A ER=4.2 }

DIELECTRIC C_D_PB { IS_CONFORMAL ER=7 SW_T=0.03 TW_T=0.03

ASSOCIATED_CONDUCTOR=POLY_B}

DIELECTRIC S{IS_CONFORMAL ER=6 SW_T=0.055 TW=0.0

ASSOCIATED_CONDUCTOR=POLY_B}

CONDUCTOR POLY_B { THICKNESS=0.15 WMIN=0.08 SMIN=0.07 RPSQ=10.0 }

DIELECTRIC ILD_A { THICKNESS=0.10 MEASURED_FROM=TD ER=4.2 }

DIELECTRIC TD { ER=7 MEASURED_FROM=U_P_D THICKNESS=0.03 }

DIELECTRIC C_D_PA_B { IS_CONFORMAL ER=7 SW_T=0.03 TW_T=0.03

ASSOCIATED_CONDUCTOR=POLY_A }

DIELECTRIC C_D_PA_A { IS_CONFORMAL ER=3.9 SW_T=0.04 TW_T=0.01

ASSOCIATED_CONDUCTOR=POLY_A }

CONDUCTOR POLY_A { THICKNESS=0.12 WMIN=0.05 SMIN=0.05 RQSP=849

DROP_FACTOR=0.13 }

DIELECTRIC U_P_D { THICKNESS=0.05 ER=3.9 }

DIELECTRIC LAT_ACT { THICKNESS=0.19 ER=4 }

CONDUCTOR ACTIVE { THICKNESS=0.19 WMIN=0.1 SMIN=0.14 RPSQ=0.0001 }

DIELECTRIC BSD { THICKNESS=0.19 ER=4 }

Dielectric Air Gaps

Air gaps in the surrounding dielectric are constructed as part of the CONDUCTOR definition

with the AIR_GAP_VS_SPACING command. The dimensions of the air gap are determined by

these parameters given in this command definition within the CONDUCTOR ITF definition as

shown in the following examples.

In Figure 3-9, all the dimensions of the air gap are determined by the spacing between the

metal lines.

Figure 3-9 Process With Dielectric Air Gaps

M1 AIR M1

S = neighboring lines

(SPACINGS)

W =

(AIR_GAP_WIDTH)

T =

gap formed

(AIR_GAP_THICKNESS)

B =

of the airgap from the

bottom of metal

(AIR_GAP_BOTTOM_HEIGHT)

L = metal and air gap ((S-W) /2)

spacing between the

height of the bottom

thickness of the air

width of the air gap

spacing between

Chapter 3: Process Characterization Interface

Defining Additional Extraction Characteristics 3-19

Chapter 3: Process Characterization Interface

Defining Additional Extraction Characteristics 3-19

StarRC User Guide and Command Reference Version F-2011.06

Layer Etch

You can make an adjustment for layer etch effects that cause the manufactured line width of

a conductor to be different from its drawn width in the ITF process file. The keyword ETCH

can be specified as a part of any CONDUCTOR definition as shown in Figure 3-10.

Both conductor sidewalls retreat or expand by the number specified in the ETCH command,

resulting in a net width difference of twice the ETCH value. A positive ETCH value shrinks the

CONDUCTOR width, and a negative ETCH value increases the CONDUCTOR width.

WMIN and SMIN values are not affected by ETCH, because StarRC does the ETCH adjustments

internally.

Figure 3-10 Process Using Layer Etch Adjustment

CONDUCTOR

ETCH

DW = drawn width

MW = modeled width

MW = DW - 2 *ETCH

ETCH

See Appendix A, “ITF Examples” for an example of a process with layer etch.

Metal Fill (Emulated)

Extracting layout databases containing metal fill objects can make runtime and memory

requirements unacceptable to account for a relatively small effect. You can make an

approximation for the capacitive effects that proximal floating metal objects can have on

routed signals in the design simply and effectively in the ITF. Handling metal fill effects during

grdgenxo is extremely beneficial, because this one-time operation eliminates the need to

extract layout databases containing millions of fill objects.

StarRC ITF metal fill modeling is designed to estimate the capacitive effect of small, floating

fill shapes within the routed core area. This effect is calculated by embedding a fine dust in

the empty areas of the core according to the fill specifications in the ITF. You should not

model ITF metal fill for designs with grounded fill or for regions with large fill plates, which

behave as though they are grounded. Grounded fill is handled by normal extraction.

Chapter 3: Process Characterization Interface

Defining Additional Extraction Characteristics 3-20

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Capacitances are modeled as a function of the global metal density for each extracted

conducting layer. As an optional argument in the CONDUCTOR definition, metal coverage is

specified in the ITF with the FILL_RATIO keyword. When FILL_RATIO is specified for a layer,

any empty space encountered during the extraction is modeled as though it were filled with

floating metal of the same layer. When used by itself, the FILL_RATIO keyword affects only

the vertical capacitance, as shown in Figure 3-11, because fill objects are placed only in

areas where they do not generate any significant lateral capacitance with their neighboring

objects.

Figure 3-11 FILL_RATIO Command

CROSS SECTION

M2FILL

+ Cc

(M1,M3)

For process technologies that allow lateral crowding of signal nets by fill objects, you can

specify the FILL_WIDTH and FILL_SPACING commands in addition to FILL_RATIO.

FILL_TYPE can be specified for treating lateral capacitance of fill as floating or grounded.

FILL_WIDTH and FILL_SPACING are used to define the dimensions of modeled fill objects

within any empty space in the design big enough to accommodate them. FILL_WIDTH is the

width of the fill object. See Figure 3-12. FILL_SPACING is the distance from a signal net to

a fill object.

Chapter 3: Process Characterization Interface

Defining Additional Extraction Characteristics 3-21

Chapter 3: Process Characterization Interface

Defining Additional Extraction Characteristics 3-21

StarRC User Guide and Command Reference Version F-2011.06

Figure 3-12 FILL_SPACING and FILL_WIDTH Commands

M 2

TOP VIEW

M2FILL

dd = FILL_SPACING

w = FILL_WIDTH

M 2

When viewed from a distance, metal fill increases the effective dielectric constant. For lateral

objects close to the filled region, the fill-width and fill-spacing numbers are used to create

grounded “phantom” polygons, which represent the metal fill for objects adjoining the fill

region. No polygons are actually added in the design to represent the metal fill. Instead, the

coefficients in the GRD file are modified to model the impact of metal fill.

In cases that have possible conflicts, such as Poly and Local Interconnect, no fill is placed.

Fill is placed only in areas that can accommodate the fill properly.

Usually, all three fill parameters are determined by the design rules for the process

technology. See Appendix A, “ITF Examples” for an example of a process with metal fill.

There is no way to turn off the emulation fill commands—FILL_RATIO, FILL_WIDTH, and

FILL_SPACING—in the star_cmd file. The emulation fill flow accounts for fill effects, you

should not use it for production purposes. You must regenerate a new nxtgrd without the fill

commands.

When An Antenna Diode is in Your Design Database

In the Milkyway database, when an antenna diode cell is inserted by place and route tools,

the diode cell type is automatically set to a standard filler type. However, some antenna

diode cells might be inserted manually by hand or through Hercules, and the cell type could

be set wrong. This causes StarRC to extract and netlist these incorrect diode cell types.

StarRC can detect standard filler cell types automatically and ignores them during netlisting

in the output parasitic file.

Chapter 3: Process Characterization Interface

Defining Additional Extraction Characteristics 3-22

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

You can query the diode cell instances to confirm the CELL FLAG property, set the antenna

cell type to standard filler, and convert the pin type to DIODE-PIN type.

Diode cells should not be netlisted in the output parasitic file as they are not part of the

original Verilog or SPICE netlist. They create parasitic back-annotation errors/warnings in

PrimeTime.

45-Degree Angles

StarRC has the capability to extract resistance and capacitance for 45-degree routed nets.

This capability is in StarRC by default and no additional commands are required.

Diffusion Resistance Extraction

For ITF definition, diffusion is defined as a CONDUCTOR for a standard shallow trench isolation

process. By default, If diffusion is not defined in the ITF, no resistance is extracted.

Diffusion resistance is extracted as mesh by default. The gate and diffusion overlap is

assumed to be equipotential surface (line node).

Figure 3-13 MOS Device Diffusion Extraction

Ri= RPSQ * li/ wi

l10

w10

R10

MOS Device

Mesh Extraction - Line Node

Chapter 3: Process Characterization Interface

Defining Additional Extraction Characteristics 3-23

Chapter 3: Process Characterization Interface

Defining Additional Extraction Characteristics 3-23

StarRC User Guide and Command Reference Version F-2011.06

Spacing- and Width-Dependent Etch

Spacing- and width-dependent etch can be implemented in the nxtgrd file by use of the

ETCH_VS_WIDTH_AND_SPACING option in the CONDUCTOR statement of the ITF.

With this feature, StarRC can consider the actual fabricated patterns in extracting parasitic

components. This is important, because optical proximity correction (OPC) cannot fix all

proximity effects and the actual patterns might be different from the drawn mask patterns.

Running grdgenxo

If you have added ETCH_VS_WIDTH_AND_SPACING in your existing ITF, you have to rerun

grdgenxo after removing the working directory.

ETCH_VS_WIDTH_AND_SPACING can be used with ETCH, EFFECTIVE_RPSQ_TABLE, or

CLAD_RPSQ. If these are used together, ETCH_VS_WIDTH_AND_SPACING is applied first, ETCH

is added, and then EFFECTIVE_RPSQ_TABLE, RPSQ_VS_SI_WIDTH, or CLAD_RPSQ is

calculated.

CAPACITIVE_ONLY and RESISTIVE_ONLY

ETCH_VS_WIDTH_AND_SPACING affects both capacitance and resistance; if this is

undesirable, you can use ETCH_VS_WIDTH_AND_SPACING CAPACITIVE_ONLY or

ETCH_VS_WIDTH_AND_SPACING RESISTIVE_ONLY, which affect only capacitance or

resistance, respectively. These options use the same ITF syntax as

ETCH_VS_WIDTH_AND_SPACING, with their own tables.

These two options can be used together within a given CONDUCTOR statement but cannot be

used in conjunction with normal ETCH_VS_WIDTH_AND_SPACING. RESISTIVE_ONLY and

CAPACITIVE_ONLY can each be defined only once within any given CONDUCTOR statement.

Determining WMIN and SMIN Values

It is important to have a correct set of WMIN and SMIN values for the CONDUCTOR that has the

ETCH_VS_WIDTH_AND_SPACING statement.

Inappropriate WMIN and SMIN values can cause unwanted opens or shorts of the neighboring

layers by applying the etch values provided in the table. In such a case, a message is printed

during the grdgenxo run. For the entries corresponding to the WMIN in the WIDTHS table, if

positive etch values are greater than or equal to half of the WMIN, an “open” warning is

issued. Similarly, for the entries corresponding to the SMIN in the SPACINGS table, if absolute

values of the negative etch are greater than or equal to half of SMIN, a “short” warning is

issued.

Chapter 3: Process Characterization Interface

Defining Additional Extraction Characteristics 3-24

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

The WMIN and the SMIN of the CONDUCTOR that is described by ETCH_VS_

WIDTH_AND_SPACING can be the same as the smallest value (or the first entry) in the WIDTHS

and SPACINGS tables, respectively.

Retaining Coupling Capacitance Between Top and SKIP_CELL

Levels

You can use the COUPLE_NONCRITICAL_NETS feature to retain coupling capacitance

between top-level parent routing and SKIP_CELL child net routing, where the fully routed

child (DEF or .CEL view) routing netnames are used for coupling node names.

This feature exists for the Milkyway flow using the SPEF netlist format.

To specify which noncritical nets are to be retained with an added prefix, use the

COUPLE_NONCRITICAL_NETS and

COUPLE_NONCRITICAL_NETS_PREFIX commands.

Use the COUPLE_NONCRITICAL_NETS_SUBNODE_SUFFIX command to add a subnode suffix

to the noncritical nets. Use the NONCRITICAL_COUPLING_REPORT_FILE command to specify

an output file containing all the capacitances coupled to the noncritical nets.

Handling Overlapping Wells

StarRC has added a method by which you can deterministically set the vertical profile of

SUBSTRATE. You specify MAPPING_FILE syntax that sets the vertical precedence for

layers mapped to SUBSTRATE.

conducting_layers

db_layer1 SUBSTRATE precedence=pos_integer

db_layer2 SUBSTRATE precedence=pos_integer

...

Any layer mapped to SUBSTRATE, and only layers mapped to SUBSTRATE, accepts an

integer-based precedence value that establishes the layer’s position in the vertical

SUBSTRATE profile. Larger numbers denote higher vertical precedence, while smaller

numbers denote lower vertical precedence. The argument of the precedence keyword is a

positive integer denoting the relative precedence of the layer. It is not necessary for values

to be sequential.

If two layers have the same precedence value, and polygons from those two layers overlap

in layout, StarRC randomly determines the topmost layer for purposes of coupling

capacitance attachment and IGNORE_CAP command functionality. SUBSTRATE-mapped

layers for which precedence is not specified have a precedence value of zero, meaning that

they take precedence below all other layers.

Chapter 3: Process Characterization Interface

Defining Sheet Zones 3-25

Chapter 3: Process Characterization Interface

Defining Sheet Zones 3-25

StarRC User Guide and Command Reference Version F-2011.06

The following is an example of a mapping file used to establish vertical precedence for a

buried well profile. The profile of a physical well for a buried well process and a profile for a

discrete well are shown in Figure 3-14.

conducting_layers

SUBS SUBSTRATE precedence=1

DEEP_NW SUBSTRATE precedence=2

NW SUBSTRATE precedence=3

PSUB2 SUBSTRATE precedence=3

PSUB SUBSTRATE precedence=3

Figure 3-14 Physical Well and Discrete Buried Well Profile

VDD VSS2 VDD VSS

NW NW

PSUB2 PSUB

PSUB

DEEP_NW

Physical well profile for buried well process

VDD VSS2 VDD VSS

PSUB2 PSUB

SUBS

Discrete buried well profile for parasitic extraction

NW NW

DEEP_NW

Defining Sheet Zones

A sheet zone is a location in which you model the insertion of a metal sheet over a specific

area as shown in Figure 3-15. This allows you to measure the coupling capacitance of a

given metal sheet, which has a user-defined net name. You can also provide a suffix to the

netname. By using sheet zone modeling, you can either specify one sheet or many thin

strips of metal with this same command interface.

Chapter 3: Process Characterization Interface

Defining Sheet Zones 3-26

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

You must ensure that any added sheet zone resides in an area that does not cause metal

shorts.

Figure 3-15 Sheet Zone Modeling

Block A

net 1

net 2

Block A

net 1

net 2

Zone Sheet

Anticipate worst-case

coupling as sheet

over an area

output netlist

*D_NET net1 1.5e-15

...

*CAP

1 net1 1.5e-15

...

*D_NET net2 2.0e-15

...

*CAP

1net2 2.0e-15

...

output netlist

*D_NET net1 1.5e-15

...

*CAP

1 net1 1.5e-15

2 net1 zone_sheet 1e-15

*D_NET net2 2.0e-15

...

*CAP

1net2 2.0e-15

...

Specify the METAL_SHEET_OVER_AREA command in your command file followed by the metal

layer name and four coordinates. These coordinates pinpoint the X and Y locations of a

single sheet as shown in Figure 3-16. Then specify the SHEET_COUPLE_TO_NET to designate

a unique net name or name prefix. Optionally, you can specify the SHEET_COUPLE_TO_LEVEL

command. This command enables a layer-level number to be output as the net name suffix

in the output netlist.

Chapter 3: Process Characterization Interface

Defining Sheet Zones 3-27

Chapter 3: Process Characterization Interface

Defining Sheet Zones 3-27

StarRC User Guide and Command Reference Version F-2011.06

Figure 3-16 Specifying a Sheet Zone or Sheet Strips

Block A

net 1

net 2

Zone Sheet Zone Strips

net 2

net 1

Block A

Y1 Y2

X1 X2

Y1 Y2

The following example shows the order in which you specify these commands for a single

zone sheet.

METAL_SHEET_OVER_AREA METAL2 0 0 100 100

METAL_SHEET_OVER_AREA METAL2 200 200 400 400

METAL_SHEET_OVER_AREA METAL4 0 0 100 100

SHEET_COUPLE_TO_NET: zone_sheet

SHEET_COUPLE_TO_NET_LEVEL:YES

The following example shows the order in which you specify these commands for several

sheet strips.

METAL_SHEET_OVER_AREA METAL2 0 5 10 10

METAL_SHEET_OVER_AREA METAL2 8 13 10 10

METAL_SHEET_OVER_AREA METAL2 16 21 10 10

METAL_SHEET_OVER_AREA METAL2 23 28 10 10

METAL_SHEET_OVER_AREA METAL2 31 36 10 10

METAL_SHEET_OVER_AREA METAL2 38 43 10 10

SHEET_COUPLE_TO_NET:zone_strips

SHEET_COUPLE_TO_NET:YES

Limitations

The following limitations accompany the metal sheet capability:

• You must verify that the metal sheet zones you specify do not cause a short.

• The prefix or root net name specified with the SHEET_COUPLE_TO_NET command must be

unique.

Chapter 3: Process Characterization Interface

Modeling Thickness Variation With StarRC 3-28

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Modeling Thickness Variation With StarRC

The contemporary copper process is affected by a dishing effect on copper lines. This effect

causes a change in cross section that affects the resistance and capacitance of the copper

interconnect. The amount of dishing on a given copper line segment is dependent on its

environment. The environment is specified by the density of a layer, the spacing to its

neighbor, and its own width. Because of these effects, you need an extraction tool to

calculate the variation of thickness and to compute the correct resistance and capacitance.

This enables good correlation with silicon.

StarRC computes the density surrounding a given segment, calculates the thickness

variation, specifies multiple density boxes of varying sizes, and applies weighting factors to

each box to calculate the effective density. You can specify in the StarRC process file at least

one of the following:

• The variation of thickness with density

• The weighting factors for different density boxes

• The variation of thickness with width and spacing of conductors

• The orders of density and width for modeling thickness variation using a polynomial

equation and the coefficients of the polynomial equation

Single-Box Method (Linear Table)

This is a special case of a multiple-box method, where only one box is used for density

calculation. In this method, you choose a single box size and specify the variation of

thickness of the conductor in a table. The box is assumed to be always a square. The

maximum size of the box is 500 microns. This method is simple and does not require an

exhaustive characterization like the multiple box method. If specified alone for a conductor

in the process file, then it does not model local density thickness variation. To do linear table

modeling, you need to specify a multipoint thickness variation versus density table in the

process file.

The THICKNESS_VS_DENSITY statement uses the following syntax:

THICKNESS_VS_DENSITY [ RESISTIVE_ONLY | CAPACITIVE_ONLY ]

{(D1 R1) (D2 R2) (D3 R3) (D4 R4) ... }

D1, D2, D3, D4 represent the various density values; R1, R2, R3, R4 represent the

relative change in thickness; (dT/Tnominal), negative R(dT/T) indicates decrease in

thickness and vice versa; even though R(dT/T) can be any number between -1 and 1, a

number close to 1 or -1 is undesirable. R(dT/T) cannot be –1.

The THICKNESS_VS_DENSITY variation affects both resistance and capacitance. However, if

the coefficients for resistance and capacitance are different, then use the RESISTIVE_ONLY

and CAPACITIVE_ONLY options.

Chapter 3: Process Characterization Interface

Modeling Thickness Variation With StarRC 3-29

Chapter 3: Process Characterization Interface

Modeling Thickness Variation With StarRC 3-29

StarRC User Guide and Command Reference Version F-2011.06

If no DENSITY_BOX_WEIGHING_FACTOR is specified, the default density box size of 50

microns is used with a weighting factor of unity.

Example

CONDUCTOR metal3 {

THICKNESS_VS_DENSITY {

(0.1, -0.1) (0.2 0.1) (0.3 0.2) (0.4 0.3)} THICKNESS=0.5

SMIN=0.2 WMIN=0.22 RPSQ=0.06

}

Multiple-Box Method

In this method you specify multiple-box size and its weighting factor for effective density

calculation. This method requires that you characterize the wafer in greater detail than the

previous method. This method is preferred when the single-box method does not reflect the

process behavior. The density box is assumed to be a square. The maximum size of the

density box is 50 microns and the maximum number of boxes is 5. To use this method you

need to specify the following for a conductor in the process file.

THICKNESS_VS_DENSITY { ( D1 R1) (D2 R2) (D3 R3) (D4 R4) }

DENSITY_BOX_WEIGHTING_FACTOR { (S1 W1) (S2 W2) (S3 W3) (S4

W4) (S5 W5)}

The following explains the previous example:

• S is the size of the density box in microns

• W is the weighting factor

• S1, S2, S3, S4, S5 are integers in microns and are within (0 < S < 500)

S1 < S2 < S3 < S4 < S5; W is a floating-point number and is within this range

(-10 < W < 10)

• If W is set to 0, then the pair (S W) is ignored

R1, R2, R3, R4 are relative to the change in thickness

(dT/Tnominal) negative R(dT/T) indicates decrease in thickness and vice versa.

Calculation of Effective Density

All density calculation is based on drawn width and spacing. When multiple density boxes

are specified, the effective density is calculated as shown in Figure 3-17.

Chapter 3: Process Characterization Interface

Modeling Thickness Variation With StarRC 3-30

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Figure 3-17 Effective Density Calculation

Deff = Σ D(Xi)*W(Xi)

i=0 to i=5

D(Xi) - Density of box Xi of size Si

W(Xi) - Weighting factor of Xi of Size

Multiple boxes

In Figure 3-17 there are three boxes - X0, X1, and X2. StarRC calculates the density for

each box for a given segment. The effective density is computed as shown in the equation

in Figure 3-17. After computing the effective density, the variation in thickness is computed

based on the THICKNESS_VS_DENSITY table. Both resistance and capacitance for a given

segment are calculated after thickness modification is taken into account.

Make sure to choose a weighting factor in such a way that calculated effective density is less

than unity.

If the computed density exceeds the limit of the density table in the ITF, the closest density

value is picked to calculate the thickness variation.

The following is an ITF example:

CONDUCTOR METAL3 {

THICKNESS = 0.35

WMIN = 0.2

SMIN = 0.21

DENSITY_BOX_WEIGHTING_FACTOR {

(10, 1) (30, 0.23) (20, 0.29)

(40, 0.18) (50, -0.12 ) }

THICKNESS_VS_DENSITY { (0.1, -0.1) (0.2 0.1)}

}

Chapter 3: Process Characterization Interface

Modeling Thickness Variation With StarRC 3-31

Chapter 3: Process Characterization Interface

Modeling Thickness Variation With StarRC 3-31

StarRC User Guide and Command Reference Version F-2011.06

Width and Spacing-Dependent Thickness Variation

In this method, the variation of thickness as a function of the width of a conductor and the

relative spacing to its neighbor is modeled. This thickness variation can be either negative

or positive. As can be noted, this is a very local phenomenon and is independent of the

density box. If specified with either single or multiple boxes, this thickness variation is

computed independently of the density box.

The effective thickness is calculated with the following equation:

T Tnom 1 RTf Deff()RTf W S,()RTf SiW()++ +()×=

where

• Tnom is the nominal thickness specified in the ITF.

• RTf(Deff) is the relative change in thickness based on density.

• RTf(W,S) is the relative change in thickness based on width and spacing.

• RTf(SiW) is the relative change in thickness based on silicon width.

The resistance and capacitance is computed after effective thickness is computed. You can

model this variation in a process file with the THICKNESS_VS_WIDTH_AND_SPACING

statement for a conductor, as shown in the following syntax:

THICKNESS_VS_WIDTH_AND_SPACING [RESISTIVE_ONLY | CAPACITIVE_ONLY] {

SPACINGS { S1 S2 }

WIDTH { W1 W2 }

VALUES {v(S1 W1) v(S2 W1) v(S1 W2) v(S2 W2) }

}

Argument Description

S1, S2 Spacings in microns

W1, W2 Widths of a conductor in microns

V(Sx Wy) Relative change in thickness for a conductor

Note:

V(Sx Wy) can take any value between –1 and +1, but a value close to –1 or +1 might be

unrealistic.

The THICKNESS_VS_WIDTH_AND_SPACING variation affects both resistance and capacitance.

However, if the coefficients for resistance and capacitance are different, use the

RESISTIVE_ONLY and CAPACITIVE_ONLY options.

Chapter 3: Process Characterization Interface

Modeling Thickness Variation With StarRC 3-32

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Unsupported Flows

The following flows are not supported by the THICKNESS_VS_DENSITY capability:

•THICKNESS_VS_DENSITY table cannot be combined with THICKNESS_VS_DENSITY

[RESISTIVE_ONLY].

•THICKNESS_VS_DENSITY table cannot be combined with THICKNESS_VS_DENSITY

[CAPACITIVE_ONLY].

•DENSITY_BOX_WEIGHING_FACTOR cannot be used without THICKNESS_VS_DENSITY

table.

Error and Warning Messages

The following is a list of error and warning messages associated with the noted commands.

THICKNESS_VS_DENSITY

If an older process file is used, StarRC issues an error message. This is applicable if and

only if THICKNESS_VS_DENSITY is specified.

ERROR: (841) ITF**

ERROR: THICKNESS_VS_DENSITY format changed;

ERROR: THICKNESS_VS_DENSITY { (D1, T1) (D2, T2) ... (Dn, Tn) }

If the DENSITY_BOX_WEIGHTING_FACTOR is not specified for a conductor that has

THICKNESS_VS_DENSITY, the following warning is issued:

WARNING: (924) ITF**

WARNING: DENSITY_BOX_WEIGHTING_FACTOR table is not provided

for

WARNING: DENSITY_BOX_WEIGHTING_FACTOR table is not provided

for

WARNING: layer <layer_name>; Default density box of 50m x

50m with

WARNING: weighting factor of 1 will be used

THICKNESS_VS_DENSITY table should have at least two points.

ERROR: (827) ITF**

ERROR: At least two points must be entered in

THICKNESS_VS_DENSITY

ERROR: table

A warning is issued if relative thickness variation is 1 or –1.

WARNING: (831) ITF**

WARNING: Suspicious value(s) for relative thickness

change(s) in

WARNING: THICKNESS_VS_DENSITY for layer <layer_name>

Chapter 3: Process Characterization Interface

Modeling Thickness Variation With StarRC 3-33

Chapter 3: Process Characterization Interface

Modeling Thickness Variation With StarRC 3-33

StarRC User Guide and Command Reference Version F-2011.06

Density values are reordered when the table is not in ascending order.

WARNING: (832) ITF**

WARNING: Density values in THICKNESS_VS_DENSITY table are

not in

WARNING: ascending order; Reordering the values...

If density values are repeated, the following error message is issued:

ERROR: (850) ITF**

ERROR: THICKNESS_VS_DENSITY table contains repeated

densities

ERROR: <density_value>

If the width values in the THICKNESS_VS_DENSITY table are not sorted, grdgenxo sorts

them.

ERROR: (876) ITF**

ERROR: the width values in the thickness table must be sorted

ERROR: ascending order in layer <layer_name>

DENSITY_BOX_WEIGHTING_FACTOR

A maximum of only 5 density boxes is allowed.

ERROR: (842) ITF**

ERROR: Too many entries; Up to 5 density weighting factors

can be

ERROR: defined in DENSITY_BOX_WEIGHTING_FACTOR

DENSITY_BOX_WEIGHTING_FACTOR with no entry leads to the following error:

ERROR: (843) ITF**

ERROR: At least one density box weighting factor must be

defined

ERROR: in DENSITY_BOX_WEIGHTING_FACTOR

A density box with 0 weighting factor is ignored.

WARNING: (796) ITF**

WARNING: Ignoring 0 weighting factor in

DENSITY_BOX_WEIGHTING_FACTOR

If DENSITY_BOX_WEIGHING_FACTOR is specified without THICKNESS_VS_DENSITY for a

conductor, the following error message is issued:

ERROR: (923) ITF**

ERROR: DENSITY_BOX_WEIGHTING_FACTOR table cannot be used

without

ERROR: THICKNESS_VS_DENSITY table for layer

Chapter 3: Process Characterization Interface

Modeling Thickness Variation With StarRC 3-34

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

DENSITY_BOX_WEIGHTING_FACTOR should have at least one point.

ERROR: (827) ITF**

ERROR: At least one point must be entered in

ERROR: DENSITY_BOX_WEIGHTING_FACTOR table

The size of the density box should be positive.

ERROR: (844) ITF**

ERROR: In layer <layer_name>, width of a density box entry

should

ERROR: be a positive value

The maximum size of the density box is 50 microns.

ERROR: (845) ITF**

ERROR: In layer <layer_name>, width of a density box entry

cannot

ERROR: exceed 50.0

If weighting factor is larger than 10 or smaller than –10, a warning is issued.

WARNING: (846) ITF**

WARNING: Suspicious value(s) of weighting factor(s) in

WARNING: DENSITY_BOX_WEIGHTING_FACTOR for layer

<layer_name>

If the width of the DENSITY_BOX_WEIGHTING_FACTOR table is not in ascending order, it is

reordered.

WARNING: (847) ITF**

WARNING: Widths of the density boxes in

DENSITY_BOX_WEIGHTING_FACTOR

WARNING: are not in ascending order; Reordering them...

If the width of the DENSITY_BOX_WEIGHTING_FACTOR is repeated, the following warning is

given:

ERROR: (851) ITF**

ERROR: DENSITY_BOX_WEIGHTING_FACTOR contains repeated width

ERROR: <width_value> for layer <layer_name>

THICKNESS_VS_WIDTH_AND_SPACING

Relative thickness change cannot be smaller than –1.

ERROR: (881) ITF**

ERROR: Relative thickness change(s) in

THICKNESS_VS_WIDTH_AND_SPACING

ERROR: for layer <layer_name> cannot be smaller than -1

Chapter 3: Process Characterization Interface

Measuring Bottom Conductor Thickness Variation 3-35

Chapter 3: Process Characterization Interface

Measuring Bottom Conductor Thickness Variation 3-35

StarRC User Guide and Command Reference Version F-2011.06

Relative thickness change cannot be greater than 1.

ERROR: (882) ITF**

ERROR: Suspicious value(s) of relative thickness change(s) in

ERROR: THICKNESS_VS_WIDTH_AND_SPACING for layer

<layer_name>

If THICKNESS_VS_WIDTH_AND_SPACING table is empty, the following message appears:

ERROR: (878) ITF**

ERROR: empty THICKNESS_VS_WIDTH_AND_SPACING table is given

for layer <layer_name>

If the THICKNESS_VS_WIDTH_AND_SPACING table has incorrect values in the value section,

the following message appears:

ERROR: (879) ITF**

ERROR: wrong number of values in

THICKNESS_VS_WIDTH_AND_SPACING table in layer <layer_name>

The spacing values in THICKNESS_VS_WIDTH_AND_SPACING table should be in ascending

order:

ERROR: (877) ITF**

ERROR: the spacing values in the thickness table must be

sorted in

ERROR: ascending order in layer <layer_name>

Measuring Bottom Conductor Thickness Variation

For 45-nm nodes and below, the need to model new process parameters arises for tight

silicon correlation and predictability. Process deficiencies such as conductor trench

thickness become more profound and require parasitic extraction tools to accurately account

for these effects on resistance and capacitance of lines at 45-nm.

The bottom conductor thickness variation, or microloading effect, is caused by the

inaccuracy in the trench depth etching process for thin lines. Microloading effects increase

as wires become thinner and closely spaced. Trench depth variation affects the thickness of

the interconnect and the separation between metal layers, so it affects both resistance and

capacitance.

Modeling of the microloading effect can vary depending on the silicon data available to

foundries.

Chapter 3: Process Characterization Interface

Measuring Bottom Conductor Thickness Variation 3-36

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Modeling Bottom Conductor Thickness Variation

In StarRC, the BOTTOM_THICKNESS_VS_SI_WIDTH ITF command can be used to model

microloading as a function of silicon width (postetch). The ILD_VS_WIDTH_AND_SPACING

option is different from BOTTOM_THICKNESS_VS_SI_WIDTH in that it enables you to model

intralayer dielectric (ILD) variation (because of microloading) as a function of conductor

width and spacing (drawn). Figure 3-18 shows the ILD4 thickness varying as a result of

microloading on the metal3 conductor:

Figure 3-18 Model Microloading in the Form of ILD

ILD5

ILD4

ILD3

ILD2

ILD5

ILD4

ILD3

ILD2

Without ILD Variation of

Microloading Effect

With ILD Variation of

Microloading Effect

Note:

When using BOTTOM_THICKNESS_VS_SI_WIDTH, the thickness of the conductor can

change (increase or decrease). However, for the ILD variation, the conductor thickness

remains constant, but the absolute z-coordinate, or cross section, of the conductor moves

up or down, depending on the direction of ILD variation. This difference might have a

significant impact especially for measuring resistance and coupling capacitance to

neighboring conductors.

For flows where thickness variation information is input through a

THICKNESS_VARIATION_FILE, the ILD variation is automatically turned off, along with all top

thickness variation commands such as PBTV, TVD, and TVWS. It is assumed that the CMP

simulator accounts for the microloading effect while computing the thickness variation.

However, note that the BOTTOM_THICKNESS_VS_SI_WIDTH command is retained in CMP

flows.

Chapter 3: Process Characterization Interface

Interconnect Parasitics Extraction Based on CMP Simulators 3-37

Chapter 3: Process Characterization Interface

Interconnect Parasitics Extraction Based on CMP Simulators 3-37

StarRC User Guide and Command Reference Version F-2011.06

ILD Restrictions

The following restrictions apply to the ILD variation function. Errors are reported to standard

output on the terminal screen if the following occurs:

• The ILD variation is specified for a dielectric layer that does not exist directly below a

conductor, an error is printed.

• The ILD variation specified is greater than 0.2 or less than -0.2, an error is printed.

• The ILD variation table is specified within the same CONDUCTOR statement with a

BOTTOM_THICKNESS_VS_SI_WIDTH table.

Interconnect Parasitics Extraction Based on CMP Simulators

At 90 nm and below, thickness variation of interconnect can change circuit behavior

dramatically. Accurate computation of this variation and its impact on interconnect parasitics

is a must. The extent of the variation depends primarily on the technology node, foundry, and

process control employed for manufacturing.

StarRC produces parasitic netlists with thickness variation effect. It consists of two steps:

• Computes thickness variation for a given interconnect

The computation of thickness variation in StarRC is based on foundry-provided table or

function of how thickness varies as a function of density, width and spacing to next

neighbor. An alternative to this approach is proposed by certain foundries that requires a

CMP simulator to compute thickness variation for interconnects in the design. It’s found

to be more difficult to define rules for thickness variation based on density, width and

spacing.

• Computes resistance and capacitance based on the thickness variation

StarRC computes resistance and capacitance based on changed thickness due to CMP.

This step is independent of whether thickness variation is computed by StarRC or by a

separate CMP simulator.

Single-Layer and MultiLayer Mode

Thickness variation of a given layer can be computed independent of the layers below.

Figure 3-19 describes the single-layer mode for two layers and for two adjacent tiles. The

bottom of the conductor is considered fixed and the top of the conductor can change.

Chapter 3: Process Characterization Interface

Interconnect Parasitics Extraction Based on CMP Simulators 3-38

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Figure 3-19 Conductor Cross Section for a Single-Layer Mode

This model can be further enhanced to comprehend impact of thickness variation for layers

below on a given layer. This is the multilayer mode. In this mode, bottom of the conductor

can move up or down as shown in Figure 3-20. A CMP simulator computes this by modeling

the dielectric thickness variation and then computing the impact at the bottom of the

conductor.

Figure 3-20 Conductor Movement

Using a Thickness Variation Map File

CMP simulators provide a thickness variation map for each layer in the design. StarRC

reads that thickness variation map, calculates the thickness variation for each interconnect

polygon, and writes the value to the internal database.

Chapter 3: Process Characterization Interface

Interconnect Parasitics Extraction Based on CMP Simulators 3-39

Chapter 3: Process Characterization Interface

Interconnect Parasitics Extraction Based on CMP Simulators 3-39

StarRC User Guide and Command Reference Version F-2011.06

To specify a thickness variation map file in the command file, use the

THICKNESS_VARIATION_MAP command.

The thickness variation map file uses the following syntax:

BLOCK block_name

TILE_SIZE tile_size_in_nm

BEGIN ITF_layer_name

x<numx> y<numy> rel_deltaT_top [rel_deltaT_bot]

END ITF_layer_name

BEGIN ITF_layer_name

x<numx> y<numy> rel_deltaT_top [rel_deltaT_bot]

END ITF_layer_name

BEGIN ITF_layer_name

x<numx> y<numy> rel_deltaT_top [rel_deltaT_bot]

END ITF_layer_name

Table 3-1 Syntax Details

Argument Description

block_name Name of the block

tile_size_in_nm Size of the tile in nanometers

ITF_layer_name ITF layer name

x<numx> X-coordinate location in the chip design

y<numy> Y-coordinate location in the chip design

rel_deltaT_top Relative thickness change for the top of the metal

rel_deltaT_bot Relative thickness change for the bottom of the metal (optional)

• Sort TILES with xy coordinates and relative thickness change.

You sort the tiles by x-coordinates first and then by y-coordinates in ascending order;

x0<x1<<x8 and y0<y1<<y8 as shown in Figure 3-21 on page 3-40 and the example.

• The coordinates you specify are absolute coordinates of the lower-left corner of the TILE.

(x8-x7) or (y8-y7), the last column and rows of tiles, might be smaller than the TILE size.

Chapter 3: Process Characterization Interface

Interconnect Parasitics Extraction Based on CMP Simulators 3-40

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

• The xy coordinate of the TILES should match across all layers.

• The TILE description can cover an area larger than the block extent. However, the extent

of the tile description should not be smaller than the extent of the block.

• A relative thickness change is the change from the nominal thickness of the given layer

and is constant for a given tile. If there is no thickness change for a TILE for the layer, it

should be set to 0. The relative thickness change must be in the range from -0.5 to 0.5.

• The file must contain a specified relative thickness change at the top of the conductor

(rel_deltaT_top). If a relative thickness change is provided for the bottom of the conductor

(rel_deltaT_bot), then multilayer mode is invoked automatically.

• Positive relative thickness change implies that the top of the conductor has moved up

(rel_deltaT_top) or the bottom of the conductor has moved down (rel_deltaT_bot). The

sum of the bottom and top thickness change provides the total thickness change and can

be used to calculate the new thickness of the conductor.

• When MAGNIFICATION_FACTOR is used along with THICKNESS_VARIATION_FILE in

StarRC, the coordinates in the TVF file are assumed to be already scaled, or shrunk as

the CMP simulation applies this scaling during simulation.

Figure 3-21 Example of Thickness Variation File Coverage

TILE

x0 x1 x2 x3 x4 x5 x6 x7 x8

Chapter 3: Process Characterization Interface

Microloading Effect 3-41

Chapter 3: Process Characterization Interface

Microloading Effect 3-41

StarRC User Guide and Command Reference Version F-2011.06

Error and Warning Messages

The following error or warning messages might be encountered in certain circumstances:

• If the <block_name> indicated in the thickness variation map file is different from the

block name in the command file, StarRC produces an inconsistent block name error

message and exits.

ERROR: StarXtract

ERROR: Inconsistent block name in the thickness variation

file

ERROR: Block name in command file is xyz

ERROR: Block name in thickness variation file is abc

• If the thickness variation value is out of range [-0.5, 0.5], StarRC gives the error message

that relative thickness change must be within [-0.5, 0.5] and exits.

ERROR: StarXtract

ERROR: Relative thickness change in thickness variation

file is outside [-0.5, 0.5] range

ERROR: 0 0 -0.601909

• If the x- and y-coordinates for tiles do not match across the layers, StarRC issues an error

and exits.

ERROR: StarXtract

ERROR: Tile coordinates in thickness variation file for

layer met2 is different from layer met1

ERROR: Layer met1: 10 70 -0.156

ERROR: Layer met2: 12 75 0.324

• If the TILES do not cover the whole size of the block under analysis, StarRC issues an

error and exits.

ERROR: StarXtract

ERROR: Tile coordinates in thickness variation file

doesn't cover the extent of the design

ERROR: Design extent (in nm): (0,0) to (4799950,

7456200)

ERROR: Thickness variation file extent (in nm): (175,175)

to (4800175, 7460175)

For more information see the THICKNESS_VARIATION_FILE command.

Microloading Effect

Various foundries note that in a low-k dielectric damascene process, one challenge is to etch

accurate depth for metal trenches. Analysis of data indicates that etching accurate depth in

a low-k dielectric process is not only dependent on the materials used, but it is also

dependent on the interconnect dimension and the proximity to the neighboring interconnect.

Chapter 3: Process Characterization Interface

Damage Modeling 3-42

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

The variation in the etch depth for the metal deposition not only affects the thickness of the

interconnect but also affects the vertical distance between metal interconnects. Because of

this, it affects both parasitic resistance and capacitance.

You can model bottom thickness variation with the following command:

BOTTOM_THICKNESS_VS_SI_WIDTH {

(SiW1, DBT1)

(SiW2, DBT2)

...

(SiWN, DBTN)

}

BOTTOM_THICKNESS_VS_SI_WIDTH performs linear interpolation of thickness variation for

wires whose widths fall between entries in the table. StarRC does not extrapolate beyond

the table.

Note:

This feature is available only for conducting layers, because no variations exist for vias or

contacts in standard foundry processes.

Damage Modeling

Changes to process technology continue in an effort to reduce the RC timing delay of

circuits. One of the common process features at this process node is to introduce porosity

into the dielectric film with relative permitivities of 2.5 or less, as a result creating a low-k

dielectric layer. Given the fact that the modulus and hardness of such low-k material is

significantly lower, the porous materials are susceptible to chemical process steps such as

etch and resist strip. The etch and strip processes currently employed cause modifications,

or damage, to the dielectric that nullify the benefit of introducing porosity to features with

dielectric spacers of 70nm or less. The damage on the surface of the metal-low-k dielectric

causes the parasitic capacitance to become significantly larger. At the 45nm process node,

sidewall and bottom wall damage as a consequence of process steps to low-k damage

material can no longer be neglected to accurately predict circuit behavior.

The DAMAGE_THICKNESS ITF option defines the thickness of the damage on the surface of

the conductor and DAMAGE_ER ITF option defines the equivalent permittivity of the damage

layer.

Figure 3-22 shows the various damage modeling cross sections that can be modeled using

the DAMAGE_ER and DAMAGE_THICKNESS options.

Chapter 3: Process Characterization Interface

Damage Modeling 3-43

Chapter 3: Process Characterization Interface

Damage Modeling 3-43

StarRC User Guide and Command Reference Version F-2011.06

Figure 3-22 Damage Modeling Cross Sections

Figure 3-23 Low-K Damage

0.01

0.02

In Figure 3-23, the damage defined for IMD1 models the side wall damage because IMD1 is

the intrametal dielectric for metal1, whereas IMD0 models the bottom wall damage because

metal1 is on top of the dielectric layer IMD0.

Example

The following is a syntax example for Figure 3-23.

DIELECTRIC IMD3 { THICKNESS=0.09 ER=2.9 }

DIELECTRIC IMD2 { THICKNESS=0.07 ER=4.5 }

DIELECTRIC IMD1 { THICKNESS=0.13 ER=2.9

DAMAGE_THICKNESS=0.01 DAMAGE_ER=5.1 }

CONDUCTOR MET1 { THICKNESS 0.20 SMIN=0.1 WMIN=0.1 }

DIELECTRIC IMD0 { THICKNESS=0.10 ER=2.9

DAMAGE_THICKNESS=0.02 DAMAGE_ER=5.1 }

Chapter 3: Process Characterization Interface

Translation of Routing DEF Blockage 3-44

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Translation of Routing DEF Blockage

In a design flow, you can divide the chip into platforms or blocks and perform the routing of

the blocks separately. These blocks are then integrated at the top level. While carrying

out the routing at the block level, you can define routing blockages that actually are the

tracks in which the top-level routing is done.

While you are doing the worst corner (pessimistic) extraction at the block/macro level, you

might like to consider the effect of the top-level signal net on the parasitic extraction of the

block-level nets. Because you do not always have the top-level routing information while

doing the block-level extraction, you need to take the blockages defined for the block as an

approximation for the top-level routing. To do this, you need StarRC to consider the effect of

these routing blockages while carrying out extraction. StarRC, by default, does not read or

translate DEF blockage.

StarRC supports the design flow through the TRANSLATE_DEF_BLOCKAGE command:

TRANSLATE_DEF_BLOCKAGE: YES | NO

This option translates the routing DEF BLOCKAGES from TOP_DEF_FILE only. It ignores

DEF BLOCKAGES from the MACRO_DEF_FILE. This is because the routing information

corresponding to these blockages is already present in the TOP_DEF_FILE. Moreover,

placement blockages in the TOP_DEF_FILE are ignored by this option.

The following is an example of the blockage section in a DEF file:

[BLOCKAGES numBlockages ;

[- LAYER layerName

[+ COMPONENT compName | + SLOTS | + FILLS | + PUSHDOWN]

[+ SPACING minSpacing | + DESIGNRULEWIDTH effectiveWidth]

{RECT pt pt | POLYGON pt pt pt ...} ...

;] ...

[- PLACEMENT

[+ COMPONENT compName | + PUSHDOWN]

{RECT pt pt} ...

;] ...

Temperature Derating

StarRC has the capability of modeling temperature-dependent resistance for conducting

layers and VIAs. The resistances are modeled in the same way as they are in SPICE, by

using the equation:

Chapter 3: Process Characterization Interface

Transparent Half-Node Flow 3-45

Chapter 3: Process Characterization Interface

Transparent Half-Node Flow 3-45

StarRC User Guide and Command Reference Version F-2011.06

R= R0*[1+ CRT1* (T-T0) + CRT2* (T-T0) ^2]

R0 is the resistance value at the nominal temperature T0, CRT1 and CRT2 are linear and

quadratic temperature coefficients, and R is the modeled resistance at the operating

temperature T. Note that the modeled resistance R exactly equals the nominal resistance

(R0) if T=T0, or if both CRT1=0 and CRT2=0.

The statement options CRT1, CRT2, and T0 are specified in the ITF on a per-layer basis. If

either CRT1 or CRT2 is nonzero for a layer (VIAs included), then a nominal temperature is

required for that layer.

The defaults for CRT1 and CRT2 are zero. The default nominal temperature for the layers can

be set globally with the GLOBAL_TEMPERATURE command at the top of the ITF. If the

temperature is set both globally and at a layer, the layer nominal temperature overrides the

global setting.

GLOBAL_TEMPERATURE = temp_in_celsius

Transparent Half-Node Flow

StarRC provides you with a way to perform optical scaling on your layout data. This function

allows you to scale the input data uniformly across all layers without affecting the

connectivity of the layout network. Designers gain an added benefit in shrunk or half-node

design flows that increase the device speed or reduce the die area, especially in newer

processes.

The HALF_NODE_SCALE_FACTOR command allows for a transparent optical shrink flow for the

designers. The flow requires downstream tools, such as implementation, simulation, and

reliability, to interpret this option to handle the shrink in a transparent manner. This

transparent flow produces shrunk electrical properties, for example resistance and

capacitance, but retains the original unshrunk design coordinates for the final netlist. The

HALF_NODE_SCALE_FACTOR function does not require scaling options be set in other tools.

The technology files supplied to the designer (from the foundry or CAD design group)

contain the scaling factor for the particular design flow.

How the Function Works

Set the HALF_NODE_SCALE_FACTOR command in the Interconnect Technology Format (ITF)

file as regular syntax as shown in the following example:

TECHNOLOGY = 65nm_sample

GLOBAL_TEMPERATURE = 25

HALF_NODE_SCALE_FACTOR = 0.9

DIELECTRIC PASS2 {THICKNESS=0.800000 ER=6.9}

$DIELECTRIC PASS1 {THICKNESS=0.700000 ER=4.0}

Chapter 3: Process Characterization Interface

Transparent Half-Node Flow 3-46

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

When StarRC finds a scale factor in the nxtgrd file, StarRC automatically sets the

NETLIST_UNSCALE_COORDINATES:YES and the MAGNIFY_DEVICE_PARAMS:NO commands.

Table 3-2 Scale Factor Effect on Commands

Command Function with HALF_NODE_SCALE_FACTOR

NETLIST_UNSCALE_COORDINATES:YES Ensures that all coordinate information in the netlist is

printed at full node. (Automatically set by StarRC.)

MAGNIFY_DEVICE_PARAMS: NO Ensures that the standard device properties ($w, $l,

$area, and so on) are output at full node in

transistor-level flows. (Automatically set by StarRC.)

NETLIST_DEVICE_LOCATION_ORIENTATION For flows requiring device locations, the full node

(original GDSII) coordinates are printed.

MAGNIFY_DEVICE_PARAMS: YES

NETLIST_UNSCALE_COORDINATES: NO

When set in a command file for a run that uses an

nxtgrd file, a warning is issued with the new value for

the options.

How Scaling Affects The Netlist

The following is an example of coordinates that are affected in a SPICE-like netlist at full

node:

*|I (ZN:F12 M1 SRC B 0 0.48 0.64)

*|P (ZN B 0 0.695 1.115)

*|S (ZN:16 0.53 1.545)

The physical properties of parasitic resistors, used for reliability analysis flows

(NETLIST_TAIL_COMMENTS) are netlisted at full node size:

R1 F9 F8 0.588229 $l=9.9 $w=2 $lvl=1

The HALF_NODE_SCALE_FACTOR command does not change the function of the

MAGNIFICATION_FACTOR option. However, you cannot use the MAGNIFICATION_FACTOR

option with the HALF_NODE_SCALE_FACTOR command. It is not allowed.

Embedding a Scale Factor Value in grdgenxo

If you generated the StarRC nxtgrd file without setting the HALF_NODE_SCALE_FACTOR

command, or you set an incorrect value, and you would like to embed a value of 0.9 into the

nxtgrd file, you can run grdgenxo and generate an updated nxtgrd file by using the following

syntax:

grdgenxo -add_sf 0.9 -i noshrink.nxtgrd -o shrink.nxtgrd

Chapter 3: Process Characterization Interface

Transparent Half-Node Flow 3-47

Chapter 3: Process Characterization Interface

Transparent Half-Node Flow 3-47

StarRC User Guide and Command Reference Version F-2011.06

Running StarRC Without Scaling

If you generated a StarRC nxtgrd file with an HALF_NODE_SCALE_FACTOR value and you

would like to run StarRC without the shrink, you can remove the scaling factor from the

nxtgrd file by using the following command syntax:

grdgenxo -add_sf 1 -i noshrink.nxtgrd -o shrink.nxtgrd

You can set the MAGNIFICATION_FACTOR command in the StarRC command file after

removing the value from nxtgrd file as shown in the previous example. You cannot, however,

simply delete the HALF_NODE_SCALE_FACTOR line from the nxtgrd file as this causes the

nxtgrd file to be corrupt.

Updating a Scaling Value

If you want to update the MAGNIFICATION_FACTOR value in the nxtgrd file, use the following

command:

grdgenxo -add_sf <factor> -i input_nxtgrd_file -o output_nxtgrd_file

Interface to CMP Simulation Flows

To run a CMP simulation, you can specify a thickness variation file (TVF file) that contains

the tiled thickness variation data. Coordinates in this file represent the full node (unscaled)

design that conforms to a transparent design flow. The CMP electrical analysis is performed

by StarRC at half node, but the output files are produced with full node geometries.

Interface to Reliability Flows

Reliability tools read the netlist output from the StarRC. Because the netlist from StarRC

represents full node coordinates, the reliability tool’s electromigration rules are supported at

the full node.

StarRC outputs the half node scale factor as a comment in the final netlist for downstream

analysis tools to compute the physical width for estimation. The following is an example of

this comment in the netlist:

//COMMENTS

//TCAD_GRD_FILE /remote/na4apd/starrc/group/xtQaTestCases/option_2/tcad/

grd

//TCAD_TIME_STAMP Sun Feb 18 12:08:22 2007

//TCADGRD_VERSION 56

//HALF_NODE_SCALE_FACTOR 0.9

Device Location and Orientation Flows

For flows that require device locations and use the

NETLIST_DEVICE_LOCATION_AND_ORIENTATION command in StarRC, the full node (original

GDSII) coordinates are printed in the netlist.

Chapter 3: Process Characterization Interface

Generating TLUPlus Models 3-48

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Generating TLUPlus Models

TLUPlus models describe advanced process effects that can be used by the parasitic

extractors in the Synopsys place-and-route tool for modeling.

TLUPlus models are generated using the grdgenxo command. A description of the process

technology must be provided in the Interconnect Technology Format (ITF) file. This file can

be supplied by the foundry, or you can create this file with the following command:

% grdgenxo -itf2TLUPlus -i ITF_file {-f format_file} -o TLU_file

For more information about ITF creation, see “Creating the ITF File” on page 3-4.

Note:

The grdgenxo command searches for the Galaxy-Common license to generate TLUPlus

models first. If a Galaxy-Common license is not found, grdgenxo looks for an RC2-TCAD

license.

The output TLUPlus model file is in a binary format containing an ASCII header section that

lists the input files used for the binary model. To use TLUPlus in IC Compiler, specify the

TLUPlus files with the set_tlu_plus_files command for extraction.

The grdgenxo -itf2TLUPlus command generates a directory called

technology_name.TLUPlus, which contains the the temporary results. The input ITF and the

format file are saved with the .itf and .format extensions, respectively, in that directory.

Subsequent grdgenxo runs on the same database check the input files for changes from

previous runs and issue an error if there are any differences.

Note:

You can invoke grdgenxo distributed processing with the -itf2TLUPlus option. The

usage of this option is the same as a standard grdgenxo run for nxtgrd file generation.

You can invoke multiple grdgenxo -itf2TLUPlus jobs from the same absolute path of

the directory.

The grdgenxo command assumes the following defaults for TLUPlus models:

• Units of fF, ohm, and micron for the Milkyway technology file

• Nominal operating conditions for CapTable names

• CapTable dimension of 5x16 for width versus spacing

• CapTable grid points are multiples of minimum width and spacing values

Chapter 3: Process Characterization Interface

Generating TLUPlus Models 3-49

Chapter 3: Process Characterization Interface

Generating TLUPlus Models 3-49

StarRC User Guide and Command Reference Version F-2011.06

You need to change the defaults specified in your TLUPlus files if

• You want to create TLUPlus tables for minimum or maximum operating conditions.

• You want to change the dimension of the capacitance table. Larger tables do not

necessarily give you greater accuracy, and smaller tables reduce runtime.

• You want to use nonuniform width and spacing values. This might improve accuracy for

designs by reducing the need for interpolation or extrapolation.

Note:

Dimensions of resistance tables and width points, if applicable, are determined

automatically based on the information in the ITF.

To change the defaults, you can create a format file as an additional parameter to grdgenxo,

as shown in the following file example. You do not have to specify parameters for every layer,

nor do you need to specify the WIDTH and SPACINGS values if you want only to change the

CapTable dimensions, but keep the default width and spacing intervals.

Table 3-3 Example Format File

File content Definition

CAP_UNIT 1e-15 ;CAP_UNIT is capacitance units, in Femtofarads and is fixed.

RES_UNIT l ;RES_UNIT is resistance units in ohms and is fixed.

OPCOND NOM ;OPCOND can be MIN, NOM, or MAX

LAYER poly ;LAYER is the layer name from the ITF (e.g.: ;poly,;metal1, metal2,

etc.)

NUMWIDTH 3 NUMWIDTH is the number of CapTable width points that are

greater than or equal to 2, and less than or equal to 16.

NUMSPACING 3 NUMSPACING is the number of CapTable spacing points that are

greater than or equal to 2, and less than or equal to 16.

WIDTH 0.15 0.3 0.45 ;WIDTH contains the values of the CapTable width points.

SPACING 0.15 0.3 0.45 ;SPACING contains the values of the CapTable spacing ;points.

LAYER metal2

NUMWIDTH 5

NUMSPACING 16

Chapter 3: Process Characterization Interface

Via Merging 3-50

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

itf2TLUPlus Restrictions

The following ITF keywords are not supported for itf2TLUPlus:

• Drop Factor

DROP_FACTOR

DROP_FACTOR_LATERAL_SPACING

•Other

ETCH_VS_CONTACT_AND_GATE_SPACINGS

Format File

The CAP_UNIT and RES_UNIT values in the TLUPlus file are fixed. You are not allowed to

change the units in the TLUPlus files.

Physical Compiler, IC Compiler can accept the hard-coded units in the TLUPlus file and

scale them internally to match the units defined in the technology file. The fixed units are as

follows:

CAP_UNIT 1e-15

RES_UNIT 1

Via Merging

The merging of vias is restricted by the MAX_VIA_ARRAY_LENGTH command. The function

determines how many vias along one side can be merged together. Large via arrays are split

into smaller sets of via arrays for merging, thus reducing the netlist size. Without this option,

a via array with via spacing less than or equal to the MAX_VIA_ARRAY_SPACING value is

reduced to one via and eventually to one resistor.

Output Netlist

The output netlist contains one subnode (*|S) for every resultant via array. The resistors are

listed with an effective resistance value including a summation of area for all individual vias

in the group.

Chapter 3: Process Characterization Interface

Via Merging 3-51

Chapter 3: Process Characterization Interface

Via Merging 3-51

StarRC User Guide and Command Reference Version F-2011.06

Mapping File Syntax

The mapping file syntax for this function is as follows:

VIA GRD_VIA RPV = <value>

Area = <value>

MAX_VIA_ARRAY_SPACING = <value>

MAX_VIA_ARRAY_LENGTH = <value>

Examples of Via Merging

Several cases are explored and suggestions for possible results are included as follows.

Case 1

In an L-shaped via farm, StarRC groups the vias into multiple sets in an arbitrary manner as

shown in Figure 3-24.

Figure 3-24 Case 1 - Before Merge

If you specify MAX_VIA_ARRAY_SPACING: <S1> and MAX_VIA_ARRAY_LENGTH: <L1>, then

the via array can be divided into two groups.

Chapter 3: Process Characterization Interface

Via Merging 3-52

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Figure 3-25 Case 1 - After Merge

The after merge result is shown in Figure 3-25. The output netlist for this case would be as

follows:

R1 no:1 no:2 (1/10)*<via res> $area=10*<via area> $lvl= <num>

R2 no:3 no:4 (1/10)*<via res> $area=10*<via area> $lvl=<num>

R3 no:2 no:3 <value> $w =<num> $l=<num> $lvl =<num>

Another possibility is that StarRC might divide the vias into three groups as shown in

Figure 3-26.

Figure 3-26 Case 1 - Dividing Into Three Groups

The output netlist for three-groups is as follows:

R1 no:1 no:2 (1/6)*<via res> $area=6*<via area>

R2 no:3 no:4 (1/10)*<via res> $area=10*<via area>

R3 no:5 no:6 (1/4)*<via res> $area=4*<via area>

R4 no:2 no:3 <value> $w =<num> $l=<num> $lvl =<num>

R5 no:4 no:5 <value> $w =<num> $l=<num> $lvl =<num>

Chapter 3: Process Characterization Interface

Via Merging 3-53

Chapter 3: Process Characterization Interface

Via Merging 3-53

StarRC User Guide and Command Reference Version F-2011.06

Case 2

If the design has asymmetric via arrays with different pitch, then StarRC groups them

arbitrarily based on the specified MAX_VIA_ARRAY_SPACING and MAX_VIA_ARRAY_LENGTH

as shown in Figure 3-27.

Figure 3-27 Case 2 - Irregular Horizontal Spacing

Horizontal spacing same, but not aligned

Horizontal spacing not the same and not aligned

Possible Output from StarRC

In this illustration, the vertical spacing of center

vias is assumed to be greater than the

MAX_VIA_ARRAY_SPACING

Chapter 3: Process Characterization Interface

Via Merging 3-54

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Figure 3-28 View from Under the Network

Node location

of via

Rv2 Rv1

R4R2

Rv3

M2 Pin

M1 Pin

In Figure 3-28, you can possibly get below the network. However, if the distance between

two via node locations is small, it can be merged. This means R3 and R4 can be shorted.

Chapter 3: Process Characterization Interface

Via Merging 3-55

Chapter 3: Process Characterization Interface

Via Merging 3-55

StarRC User Guide and Command Reference Version F-2011.06

Figure 3-29 View from Under the Network - Multiple Nodes

Node location

of via

Rv2 Rv1

R4R2

Rv3

M2 Pin

M1 Pin

ABCDE

Resulting network

In Figure 3-29, StarRC creates multiple nodes for the vias. It chooses the center for the

via-merged polygon (node C as the merged polygons are aligned). Nodes A, B, D, and E are

created for the individual vias. Because the distance between nodes B, C, and D is small,

the metal resistance is shorted out and the resulting network is shown in the lower portion

of the figure.

Chapter 3: Process Characterization Interface

Via Merging 3-56

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Case 3

If you set an arbitrarily large value (much greater than via-to-via spacing), then it can lead to

shorts or loss of metal resistance as shown in Figure 3-30 on page 3-56.

Figure 3-30 Shorts and Loss of Metal Resistance

S1 S1

Original Layout Shorted layout

Setting a large value can lead to

shorts and loss of resistance.

You should use the

VIA to VIA design rule spacing value

for MAX_VIA_ARRAY _SPACING.

Chapter 3: Process Characterization Interface

Via Merging 3-57

Chapter 3: Process Characterization Interface

Via Merging 3-57

StarRC User Guide and Command Reference Version F-2011.06

Case 4

In a simple rectilinear VIA array, as shown in Figure 3-31, StarRC merges the vias based on

the settings of MAX_VIA_ARRAY_SPACING and MAX_VIA_ARRAY_LENGTH.

Figure 3-31 Simple Rectilinear VIA Array

INPUT

vi1

OUTPUT

MAX_VIA_ARRAY_SPACING: S

MAX_VIA_ARRAY_LENGTH: L

The output netlist for the arrays shown in Figure 3-31 is as follows:

R1 no:1 no:2 (1/10)*<via res> $area=10*<via area>

R2 no:3 no:4 (1/6)* <via res> $area=6* <via area>

Chapter 3: Process Characterization Interface

Writing a Mapping File 3-58

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Case 5

in Case 5, the R network for a multilayer net with via merging is shown in Figure 3-32.

Figure 3-32 R Network for a Multilayer Net

Via nodes

The expected R network is as follows:

M1 Pin

R-M1

Rvia1

R-M2

Rvia2 R-M3

M3 Pin

Writing a Mapping File

The mapping file, which maps the database layer to the tcad_grd layer, is needed for every

StarRC run. You can write the mapping file manually or by using the StarRC GUI.

Chapter 3: Process Characterization Interface

Writing a Mapping File 3-59

Chapter 3: Process Characterization Interface

Writing a Mapping File 3-59

StarRC User Guide and Command Reference Version F-2011.06

Mapping multiple database layers to a single process layer is valid, but the reverse is

prohibited. Each logically connected database layer must be mapped in this file, even if the

layer is derived or used only for intermediate connections with no real physical significance.

In LEF/DEF flows, this means that each layer defined in the technology LEF file must be

mapped (including VIAs).

Map the connected database layers with the following mapping file commands, which can

be specified in any order:

•conducting_layers

•via_layers

•marker_layers

•remove_layers

To ignore capacitive interaction between specific layers, use the ignore_cap_layers

command.

Note:

One of the advantages of using the ITF (see “The Interconnect Technology Format File”

on page 3-4) to describe a process technology is that it eliminates the need to maintain,

support, and cross check parameter sets for consistency. If the sheet resistance

parameters for the process must be altered, it is best to regenerate the tcad_grd file (see

“Process Characterization Basics” on page 3-3). Regenerating the tcad_grd with updated

sheet resistances is very fast, because grdgenxo can use the capacitance solution from

the original run.

Example 3-4 shows an example of a mapping file.

Chapter 3: Process Characterization Interface

Writing a Mapping File 3-60

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Example 3-4 Layer Mapping File

Conducting_layers

fpoly Poly

Bulk Substrate

Poly Poly

Rpoly Poly

Rndiff Od

Ndif Od

Nwell Substrate

apgate Poly

angate Poly

ngate1 Poly

Ngate Poly

Pgate Poly

Nsd Od

Psd Od

Pdif Od

Met4 Metal4

Met3 Metal3

Met2 Metal2

met1 Metal1

Via Layers

Diffcnt Odcont

Plycnt:polycont polyCont

diffcnt:odCont odCont

m3via via3

m2via via2

mvia via1

marker_layers

met1_pin

met2_pin

met3_pin

remove_layers

cont:subCont

diffcnt:subCont

ignore_cap_layers

angate dngate ngate ngate1

pdif psd

ndif rndiff nsd

Ngate Nsd L=0.1

Pgate Psd L=0.1

Nsd BULK L=0.1

Psd BULK L=0.1

4-1

Physical Databases 4

This chapter contains the following sections:

•Introduction to Physical Databases

•Milkyway Database Extraction Flow

•LEF/DEF Database Extraction Flow

•Calibre Connectivity Interface

•Hercules Database Extraction Flow

•IC Validator Extraction Flow

•Cross-Referencing in Transistor Level Flows

•Cross-Referenced Extraction Options

•Parameterized Cells (PCELL)

•Metal Fill

•Shared Database Command Options

Chapter 4: Physical Databases

Introduction to Physical Databases 4-2

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Introduction to Physical Databases

StarRC imports a physical description of the layout for calculating parasitic effects from one

of five possible sources: a Milkyway, Hercules, IC Validator, Calibre® Connectivity Interface,

or LEF/DEF database. No preparation of the database is required before you run StarRC.

StarRC can run on Milkyway or LEF/DEF databases with layouts containing opens or shorts.

Special provisions are made to repair the netlist so that delay calculation can be performed

even on the problem nets. Shorted nets are always netlisted independently and contain only

parasitics for the polygons that really belong to them. Open nets can optionally be

connected with the NETLIST_CONNECT_OPENS command in the StarXtract technology file.

Both opens and shorts are reported explicitly in detailed summary files. However, the

StarRC results might be inaccurate in a design with shorts or opens.

Milkyway Database Extraction Flow

The extraction flow shown in Figure 4-1 shows the Milkyway layout database containing all

network annotation information and is read directly by StarRC. The layout does not need to

be LVS-clean for completion of a successful extraction. Warnings are printed by StarRC for

any open or shorted nets it encounters.

Figure 4-1 Milkyway StarRC Extraction Flow

Netlist formats available:

SPF

SPEF

STAR

NETNAME

PARA (view)

mapfile

command file

nxtgrd

StarXtract

Netlist

Milkyway

database

Chapter 4: Physical Databases

Milkyway Database Extraction Flow 4-3

Chapter 4: Physical Databases

Milkyway Database Extraction Flow 4-3

StarRC User Guide and Command Reference Version F-2011.06

Place-and-Route Flow

StarRC offers a seamless integration into the Galaxy place-and-route environment.

StarRC also integrates directly with IC Compiler for sign-off driven design closure. IC

Compiler uses the sign-off quality parasitic extraction of StarRC to perform optimization on

the design.

Setting the Reference Library Control File

In determining the reference library status of a Milkyway database, StarRC uses the

reference library mode stored within the main Milkyway database with the Milkyway function

dbSetLibRefCtrlFileMode. The dbSetLibRefCtrlFileMode command specifies whether

the reference library tree source is from the Internal Reference Mode or the Reference

Control File Mode.

Unlike previous versions of StarRC, there is no longer a session-specific configuration

option, because the reference library status is saved directly as a property of the library. See

the Milkyway documentation for details about the command dbSetLibRefCtrlFileMode.

Milkyway Database Command Options

The commands shown in Figure 4-2 are specific to Milkyway input databases. For details

about these commands, see Chapter 17, “StarRC Commands.”

Chapter 4: Physical Databases

LEF/DEF Database Extraction Flow 4-4

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Figure 4-2 Milkyway Database Tech Form

LEF/DEF Database Extraction Flow

The Library Exchange Format/Design Exchange Format (LEF/DEF) layout description is

read directly by StarRC as shown in Figure 4-3. LEF/DEF file format versions 5.2 through

5.7 are supported.

Chapter 4: Physical Databases

LEF/DEF Database Extraction Flow 4-5

Chapter 4: Physical Databases

LEF/DEF Database Extraction Flow 4-5

StarRC User Guide and Command Reference Version F-2011.06

Figure 4-3 LEF/DEF Extraction Flow

mapfile

command file

nxtgrd

StarXtract

SPF/SPEF

SBPF

STAR

LEF DEF MACRO DEF

GDSII

Most information about the design is read directly from the LEF/DEF database. StarRC

automatically identifies the following:

• Power nets

• Primary input/output ports

• Top-level block

•Skip cells

Hierarchical LEF/DEF designs are fully supported. You can specify multiple

MACRO_DEF_FILE commands along with a single TOP_DEF_FILE command, to extract a

hierarchically routed design. If a macro DEF file is specified, all subcells referenced in the

macro DEF must have corresponding MACRO definitions within the library LEF files input to

StarRC.

Starting from StarRC version B-2008.12, you do not need to specify the LEF descriptions for

DEF soft macros

In accordance with the LEF specification, the order in which the LEF files are specified is

important. The technology LEF that contains layer definitions is required before any of the

library LEF files are read. Undefined LEF layers cause an error warning that you must fix

before extraction can be completed. Any parasitic capacitance information contained in the

LEF files is ignored by StarRC. The layer resistance specifications are used only if

resistance information is missing from both the TCAD_GRD_FILE and the MAPPING_FILE.

The LEF file must always contain VIA definitions, even if the VIAs are redefined in the DEF

file. The DEF description takes precedence in the extraction whereas the LEF description is

used for layer mapping and initial connectivity.

Chapter 4: Physical Databases

LEF/DEF Database Extraction Flow 4-6

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Timing-Driven Design Flow

StarRC also integrates smoothly with LEF/DEF-based place and route flows. You can read

leaf cells in GDSII format directly and they can be merged during translation into the layout

database.

The StarRC commands associated with LEF/DEF place and route are described in “LEF/

DEF Database Commands” on page 4-6.

Merging Library GDSII

GDSII can be directly merged into the LEF description for library cells or macro blocks.

When you use this feature, StarRC uses only the pin shapes from the LEF MACRO cell

definitions and discards the obstructions and other objects. The actual physical layout from

library GDSII is translated and used to represent the contents of SKIP_CELLS during

extraction.

GDSII layers for inclusion must be equated to a LEF database layer with the

GDS_LAYER_MAP_FILE command. For a description of the mapping file format, see the

GDS_LAYER_MAP_FILE command description. If any GDSII layer is not specified in the

GDS_LAYER_MAP_FILE, it is not translated for extraction and does not contribute to the

parasitics.

Indexes Warning in the Netlist Stage

If there is no port geometry for the pins of the cells in a LEF file, a warning is issued. For

example:

MACRO inv

PIN a

DIRECTION INPUT ;

END a

PIN y

DIRECTION OUTPUT ;

END y

END inv

You must make the necessary correction in the LEF file.

LEF/DEF Database Commands

StarRC features several commands for use in a LEF/DEF flow, listed in Table B-2 on

page B-11. You can specify these commands in the tech form for LEF/DEF databases as

shown in Figure 4-4.

Chapter 4: Physical Databases

Calibre Connectivity Interface 4-7

Chapter 4: Physical Databases

Calibre Connectivity Interface 4-7

StarRC User Guide and Command Reference Version F-2011.06

Figure 4-4 LEF/DEF Database Tech Form

LEF/DEF

Calibre Connectivity Interface

If you use Mentor Graphics® Calibre® as your primary design rule checking (DRC) and

layout versus schematic (LVS) verification tool, StarRC reads Calibre output files and

extracts parasitics for device-level extraction. This is achieved by using the Calibre

Connectivity Interface (CCI). Calibre Connectivity Interface provides the ability to output all

relevant layout, connectivity, port, and cross-referencing information from the Calibre LVS

run in a form that is usable by StarRC. StarRC uses this information to construct a

device-level parasitic netlist in standard DSPF and SPEF formats.

Calibre Connectivity Interface flow extractions output the same Detailed Standard Parasitic

Format (DSPF) and Standard Parasitic Exchange Format (SPEF) netlists available with

other StarRC flows for use with industry simulation and analysis tools.

Chapter 4: Physical Databases

Calibre Connectivity Interface 4-8

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Calibre generates multiple files with information about polygons, connectivity, text net

names, device tables, and LVS cross-referencing tables. StarRC reads the following Calibre

Connectivity Interface information to construct the parasitic netlist:

• Annotated GDSII (AGF) file containing polygon and connectivity information

• Mapping file describing layer mapping between the AGF file and the Calibre runset

• Ideal layout netlist

• Layout net names file

• Calibre device table describing terminal layers for all possible devices in runset

• Top-level ports file

• LVS net cross-referencing table

• LVS instance cross-referencing table

• Calibre runset to interpret layer connectivity

By reading the layout netlist, layout connectivity, and LVS cross-referencing information,

StarRC provides a means for you to perform schematic back-annotation of the layout

parasitics netlist.

StarRC requires only two command file inputs to read all required Calibre Connectivity

Interface information described previously.

• The query command file with which the Calibre Query Server was run

• The Calibre runset in order to interpret layer connectivity

By reading the Calibre query command file directly, StarRC is able to locate all Calibre

Connectivity Interface generated subordinate files relating to the ideal layout netlist, the

annotated GDSII file, and the cross-referencing information. At the same time, StarRC is

able to do error checking on the Calibre query command file to ensure that the Calibre

Query Server was invoked with the required set and ordering of options for use with StarRC.

See Running the Calibre Query Server for Output to StarRC in Appendix B for information

about the Calibre query command file setup for use with StarRC.

Chapter 4: Physical Databases

Calibre Connectivity Interface 4-9

Chapter 4: Physical Databases

Calibre Connectivity Interface 4-9

StarRC User Guide and Command Reference Version F-2011.06

StarRC Command File Preparation

Calibre Connectivity Interface based extraction requires the following commands in the

StarRC command file:

Command Purpose

CALIBRE_RUNSET: filename LVS command file for the Calibre run. An LVS rule deck

contains data creation commands, device creation

commands, device property calculations, layer connect

sequences, and LVS comparison options. StarRC parses the

layer connect sequence from the Calibre runset, including

derived layer connectivity, to determine ideal netlist

connectivity.

CALIBRE_QUERY_FILE: filename Command file used to invoke Calibre Query Server to output

CCI information from Calibre. This file specifies the location of

all CCI outputs required for parasitic extraction including

annotated GDSII layout and layer mapping information,

top-level port information, ideal layout netlist, ideal netlist net

naming information, cross-referencing tables, top-level cell

extents, and layout device terminal layer information.

CALIBRE_QUERY_FILE also performs error checking of the

command file to ensure conformity with StarRC requirements

for Calibre Query Server invocation.

The following example shows a StarRC command file for the Calibre Connectivity Interface

flow:

BLOCK: sample

TCAD_GRD_FILE: sample.nxtgrd

MAPPING_FILE: sample.map

CALIBRE_RUNSET: calibre.runset

CALIBRE_QUERY_FILE: query_input

To generate an ideal netlist, which extracts specific nets connected to certain devices,

1. Use the UNIX grep command to find the nets that are connected to certain instances or

devices.

2. Extract the design with the selected nets from step 1.

The following set of commands help to reduce the runtime for an ideal SPICE netlist

generation:

REDUCTION: HIGH

EXTRACTION: C

MODE: 100

NETS: !*

NETLIST_IDEAL_SPICE_NETLIST:

Chapter 4: Physical Databases

Calibre Connectivity Interface 4-10

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

StarRC and Calibre Connectivity Interface Flow

Follow the StarRC Calibre Connectivity Interface (CCI) workflow steps as illustrated in

Figure 4-5:

1. Generate an LVS or HLVS clean design.

2. Create a collection of CCI input files with the query command file, query_cmd.

% calibre -query svdb < query_cmd

svdb contains the design data from Calibre.

query_cmd is a user-generated file containing the Calibre options that create the CCI

files.

3. Write a StarRC command file containing the CALIBRE_RUNSET and

CALIBRE_QUERY_FILE commands.

4. Run StarRC with the prepared command file.

The CALIBRE_RUNSET and CALIBRE_QUERY_FILE commands find the necessary Calibre

file information and your desired output file is produced.

Chapter 4: Physical Databases

Calibre Connectivity Interface 4-11

Chapter 4: Physical Databases

Calibre Connectivity Interface 4-11

StarRC User Guide and Command Reference Version F-2011.06

Figure 4-5 StarRC Calibre Connectivity Interface Flow

LVS or HLVS “clean” Calibre output

Calibre HLVS -svdb

Calibre CCI Files

StarRC StarRC command file

Parasitic

Netlist

% calibre -query svdb < query_cmd

AGF file

AGF layer map

Layout netlist

Net ID map

IXF

NXF

DEVTAB

CELLS_PORTS

requiring only

CALIBRE_RUNSET

and

CALIBRE_QUERY_FILE

Error Messages

StarRC issues error or warning messages whenever the following conditions exist:

• If GDS NETPROP NUMBER, GDS PLACEPROP NUMBER, or GDS DEVPROP

NUMBER are not specified correctly in the Calibre query command file, StarRC issues an

error similar to the following:

ERROR: StarXtract

ERROR: GDS PLACEPROP NUMBER 1 is not supported.

================================

Please set the following Calibre query server commands

in your rule file and rerun calibre -query.

GDS NETPROP NUMBER 5

GDS PLACEPROP NUMBER 6

GDS DEVPROP NUMBER 7

================================

ERROR:StarXtract

ERROR: Input Calibre query command file error.

Chapter 4: Physical Databases

Calibre Connectivity Interface 4-12

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

The GDS NETPROP NUMBER, GDS PLACEPROP NUMBER, and the GDS DEVPROP

NUMBER must be set in accordance with the Calibre Query File requirements listed in

”Running the Calibre Query Server for Output to StarRC” in Appendix B.

• GDS SEED LAYER ORIGINAL, when specified, must come before the GDS MAP

command in the Calibre query command file. If GDS SEED LAYER ORIGINAL is

specified after GDS MAP, the following warning results.

WARNING: GDS SEED PROPERTY ORIGINAL affects CCI AGF layer

mapping;

WARNING: This command should occur before the GDS MAP

command in Calibre query file.

WARNING: GDS MAP file could be invalid.

For the proper ordering and setup of Calibre query file commands for use with StarRC,

see “Running the Calibre Query Server for Output to StarRC” on page 14-33.

•XREF:COMPLETE is not supported in the Calibre Connectivity Interface flow.

•MACRO command is not supported in the Calibre Connectivity Interface flow.

• Duplicate layer mappings in the Calibre AGF layer mapping file produce an error

condition because data in the AGF might be corrupted as a result. For example, if two

AGF layers are mapped to the same layer number, the following error message appears

during the Translate DB stage:

ERROR:StarXtract

ERROR: different gds layers are mapped to the same gds

layer number:<layer1>, <layer2>, <shared layer number>

This condition can result if a partial layer mapping is provided in the Calibre query server

command file. In general, you should not specify layer mappings (using GDS MAP

commands) in the Calibre query server command file. For information about the query

server command, see “Running the Calibre Query Server for Output to StarRC” on

page 14-33.

• Missing pin (x,y) information in the Calibre ideal netlist produces a warning condition

instructing you to include the relevant Calibre Connectivity Interface query commands in

the Calibre Connectivity Interface query command file.

For example, if the Calibre query server command LAYOUT NETLIST PIN LOCATIONS

YES is not used during the query server run, StarRC issues the following warning during

Translate DB:

WARNING: Unable to determine terminal locations for "0"

of device "n". This instance will not be netlisted.

Chapter 4: Physical Databases

Calibre Connectivity Interface 4-13

Chapter 4: Physical Databases

Calibre Connectivity Interface 4-13

StarRC User Guide and Command Reference Version F-2011.06

Schematic/Layout Cross-Referencing

In the Calibre Connectivity Interface flow, StarRC supports layout-based cross-referencing

with the command XREF:YES. In this mode, all nets and devices that occur in the ideal layout

netlist appear in the parasitic netlist, using schematic net and instance/device names

wherever possible. Special naming techniques for handling various merging situations are

described in the general discussion of the command XREF:YES in this user guide.

Schematic and layout cross-referencing in Calibre Connectivity Interface is purely layout

based, meaning that the parasitic RC netlist mirrors the structure, connectivity, and

quantities of nets, instances, and devices present in the actual layout. Calibre Connectivity

Interface cross-referencing tables are used to annotate schematic names onto these nets,

instances, and devices wherever matches are made during LVS.

For cross-referenced ideal devices, the model name specified with Calibre’s NETLIST

MODEL suboption is netlisted with XREF:YES whenever this suboption exists for a particular

DEVICE command in the Calibre LVS rule file. Otherwise, the default Calibre model name is

used. StarRC always uses the default model name with XREF:NO, because the layout netlist

from Calibre uses that convention.

If a net does not exist in the Calibre NXF file, StarRC uses the layout net name with the prefix

specified with the XREF_LAYOUT_NET_PREFIX command (default: ln_). For example, if layout

net A did not match in LVS and does not exist in the Calibre NXF file, StarRC assigns ln_A

in the parasitic netlist. Similarly, if an instance does not exist in the Calibre IXF file, StarRC

uses the layout instance name with the prefix specified in the XREF_LAYOUT_INST_PREFIX

command (default: ld_).

Calibre Support of LVS Black Box Flow

To enable proper StarRC cross-referencing of Calibre LVS BOX cells, one additional

command is required in the Calibre query server command file to output needed information

in the Calibre Connectivity Interface NXF cross-referencing files. No additional StarRC

commands are required.

Note:

This feature is compatible only with enhanced Calibre Connectivity Interface NXF file

output available in Calibre 2003.06 from Mentor Graphics.

Designers commonly perform LVS verification using incomplete subcell information by

having the LVS tool not compare the functional contents of the subcell. In such cases the cell

is called a black box, meaning that the LVS tool treats all instances of the cell as equivalent

between schematic and layout without comparing the contents of the cell. Hercules uses the

BLACK_BOX and BLACK_BOX_FILE commands to specify black-boxed cells, while Calibre

uses the LVS BOX syntax. The only constraint for a black-box cell is that cell ports must have

correspondence between the schematic and layout.

Chapter 4: Physical Databases

Calibre Connectivity Interface 4-14

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

To cross-reference LVS black-box cells, you must add the following Calibre query server

command to the query command file:

NET XREF WRITE <file_name> [BOX]

This command is already required to enable cross-referencing using the XREF command in

StarRC. To enable Calibre LVS BOX capability, the present command in the Calibre query

server command file should be appended with the keyword BOX. Adding the keyword BOX

has two effects on the NXF file:

• Within the NXF file, Calibre lists hcells (or equivalence points) for all LVS BOX cells.

Equivalence point lines begin with the percent character (%) in the IXF and NXF files.

Note that equivalence points for LVS BOX cells are not listed in the NXF file without the

keyword BOX in the Calibre Query Server command file.

• Under the hcell (equivalence point) described in the NXF file, Calibre lists all matched

ports for the cell. This enables StarRC to cross-reference all ports for LVS BOX cells.

An example of output from the Calibre query server command NET XREF WRITE BOX

follows:

% inv1 4 inv1 6 BOX

0 vss 0 vss

0 vdd 0 vdd

0 b 0 b

0 a 0 a

Using this information, StarRC performs the following:

• Netlists cell instances for all LVS BOX cells using schematic instance names, whenever

a match for the instance has occurred in the Calibre IXF file

• Netlists all port connections to LVS BOX instances using schematic port names,

whenever a match for port names occurs in the Calibre NXF file as illustrated previously

Just as with non-LVS BOX cells, Calibre writes interconnect polygon information to the AGF

file for LVS BOX cells. You should specify Calibre BOX cells as SKIP_CELLS in the StarRC

command file. If you do not do this, StarRC issues a warning and adds the BOX cell to the

StarRC SKIP_CELLS list. Because these cells must be specified as SKIP_CELLS for StarRC,

StarRC treats the contents of LVS BOX cells in a gray-box manner by extracting capacitive

interactions from extracted nets to polygons contained in such cells.

Chapter 4: Physical Databases

Hercules Database Extraction Flow 4-15

Chapter 4: Physical Databases

Hercules Database Extraction Flow 4-15

StarRC User Guide and Command Reference Version F-2011.06

Table 4-1 lists concepts, syntax, and file names for the Calibre black box feature.

Table 4-1 Calibre Black Box Feature

LVS BOX Calibre rule-file syntax for listing cells whose contents are not to be

verified during LVS, but are assumed to be LVS equivalent.

hcell

(or equivalence point)

An expression of LVS equivalence between a schematic cell

master and a layout cell master.

IXF file Calibre query server output file listing all instance (device and cell)

matches between schematic and layout verified during LVS; this

file is required by StarRC whenever XREF is activated.

NXF file Calibre query server output file listing all net matches between

schematic and layout verified during LVS; this file is required by

StarRC whenever XREF is activated.

Hercules Database Extraction Flow

To create a parasitic netlist output using the Hercules flow, you must provide a physical

database, schematic netlist, and Hercules runset as shown in Figure 4-6. To connect the

Hercules runset with StarRC, specify the WRITE_EXTRACT_VIEW command. In the Hercules

runset. In StarRC, you must specify the BLOCK, XREF, CELL_TYPE, and

MILKYWAY_EXTRACT_VIEW in the StarRC command file. Also, the path to the nxtgrd and

mapping file must be specified in the StarRC command file. This connects the data. The

connected Hercules database, or Milkyway XTR view, can be generated as a parasitic netlist

or an ideal extraction of the layout from an original GDSII, or place and route Milkyway

database. Note that a net in the database that is not annotated with layout text is assigned

a numerical net identifier by Hercules.

Chapter 4: Physical Databases

Hercules Database Extraction Flow 4-16

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Figure 4-6 Hercules Extraction Flow

Milkyway

database

GDSII

Hercules

nxtgrdfile

mapfile

StarXtract

Parasitic

runset

Hercules

Output

Milkyway XTR

schematic

netlist

XREF

Information

StarRC

Command

File

MILKYWAY_EXTRACT_VIEW

XREF

CELL_TYPE

BLOCK

Schematic

Netlist

WRITE_EXTRACT_VIEW

Physical database

Ideal

Netlist

processed

Find information

about the processed

schematic netlist in

the directory:

./run_details/evaccess

Find information

about the XREF

information in the

directory:

./run_details/compare/.db

Specify

WRITE_EXTRACT_VIEW

in your Hercules runset.

Specify a nxtgrd file with

the TCAD_GRD_FILE

command.

Specify a map file with the

MAPPING_FILE command.

Chapter 4: Physical Databases

Hercules Database Extraction Flow 4-17

Chapter 4: Physical Databases

Hercules Database Extraction Flow 4-17

StarRC User Guide and Command Reference Version F-2011.06

GDSII to XTR View Translation

A GDSII file contains no layer connectivity or ideal netlist information. Hercules establishes

layer connectivity and extracts an ideal layout netlist using rules defined in the Hercules

runset. A connected version of the database is then stored in the form of a Milkyway XTR

view database for input to StarRC.

Follow these rules when generating the XTR view:

• The term SUBSTRATE is a reserved keyword in the Hercules runset and cannot be

assigned as a TEMP or PERM layer for any Hercules command.

• In the case of a place-and-route Milkyway database, the Milkyway XTR view generated

by Hercules should be written to a unique library because the technology information is

different from that of the original library.

• Hercules runsets for use with StarRC must be prepared in accordance with StarRC rules

for device terminal and connectivity generation. For more information about Hercules

transistor-level runset creation, see “Preparing Hercules Runsets” on page 14-2.

Chapter 4: Physical Databases

Hercules Database Extraction Flow 4-18

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

The following is a sample Hercules runset containing Hercules commands applicable to a

cell-level GDS flow for use with StarRC:

header{

layout_path = .

inlib = library.gds

format = stream

block = top

}

assign_property {

instance_name (4)

}

assign {

poly (1) text(1;1)

cont (2)

metal1 (3) text(3;1)

via1 (4)

metal2 (5) text(5;1)

via2 (6)

metal3 (7) text(7;1)

}

text_polygon metal3.text {

cell_list = { top }

size = 0.1

text_list = { IN1 IN2 OUT }

} temp = io_pin

connect {

poly metal1 by cont

metal1 metal2 by via1

metal2 metal3 by via2

metal3 by io_pin

}

text {

poly by poly

metal1 by metal1

metal2 by metal2

metal3 by metal3

}

write_extract_view {

library_name = TOP

library_path = .

}

You must include a WRITE_EXTRACT_VIEW command as shown in the previous file sample to

enable Hercules to write out a Milkyway XTR view. It is from this XTR view that StarRC

derives the layout net annotation, layout device annotation, and layout connectivity.

Chapter 4: Physical Databases

Hercules Database Extraction Flow 4-19

Chapter 4: Physical Databases

Hercules Database Extraction Flow 4-19

StarRC User Guide and Command Reference Version F-2011.06

The TECHNOLOGY_OPTIONS command in the Hercules runset can have an impact on StarRC

extraction runtime. A command-line option for Hercules, -rcxt, has been implemented to

set the TECHNOLOGY_OPTIONS for optimal StarRC performance; you should use the -rcxt

option for transistor-level or hierarchical designs.

For more information about

• Marker generation, see “Marker Generation in Hercules” on page 14-11.

• Runset creation, see “Preparing Hercules Runsets” on page 14-2.

Cross-Referenced Extraction in the Hercules Flow

Multi-equivalence points in the layout are supported for cross-referenced extraction.

Multi-equivalence points are points in the layout where one or more layout cells equal to a

single schematic cell. The x-y coordinates of the instance ports and top-level ports are

reported.

If the Hercules IGNORE_CASE=TRUE command is specified in the runset, all schematic names

are uppercase in the StarRC netlist. You must set CASE_SENSITIVE=NO in the command file

if IGNORE_CASE=TRUE in the Hercules runset.

Note:

Check that your Hercules runset does not set CREATE_VIEWS=FALSE in the

EVACCESS_OPTIONS section. Successful XREF requires that this option be either set to

TRUE (the default) or left unspecified.

Certain memory designs might encounter errors in the XrefHN step of an XREF-enabled flow.

For example,

ERROR: StarXtract

ERROR: Found layout instance SRAMblock258x532#448 of equiv

ERROR: SRAMblock258x532#448 which is not a valid equiv point

The SRAMblock blocks are generated by the Hercules LVS engine when

MEMORY_ARRAY_COMPARISON is set to TRUE (this is the default). The SRAMblock blocks do

not exist in the original schematic or layout netlists.

In general, the MEMORY_ARRAY_COMPARE variable does not affect the LVS results in most

memory designs. For nonmemory designs, you do not need to change this option. The

StarRC XREF options do not support the MEMORY_ARRAY_COMPARE variable. You should set

it to FALSE for memory designs that encounter this error when running LVS.

As soon as StarRC finds one instance that is connected to the net “0” in the schematic

netlist, the following error message is issued:

Chapter 4: Physical Databases

Hercules Database Extraction Flow 4-20

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Build XrefHN

ERROR: StarXtract

ERROR: Schematic instance "MM15/SRC" is connected

to ground "0". To

ERROR: prevent incorrect result, please rename net

"0" to another

ERROR: name.

Warnings: 0 Errors: 1 (See file xrefhn.sum)

In this case, you should change the net name “0” to a different name in the schematic netlist

and rerun Hercules LVS before starting a new StarRC.

All XREF modes support port ordering with the SPICE_SUBCKT_FILE. The port list should

match in the schematic cell definitions and the SPICE_SUBCKT_FILE .SUBCKT definitions.

StarRC generates net names in the <instance>_<port> format for ports present in the

SPICE_SUBCKT_FILE but missing from the schematic or layout, depending on the value of

XREF, so that the port count and order always match the SPICE_SUBCKT_FILE.

When you specify a series merging in Hercules Compare, StarRC reports ln_ for

non-cross-referenced internal nets. If you want to cross-reference these internal nets, you

should run Hercules version Y-2006.12-4 with the following environmental variable before

running StarRC version Z-2007.06 or later:

setenv WRITE_NEW_CDB

Note:

Earlier versions of StarRC do not accept the cross-reference database generated with

the Compatibility option.

Hercules Database Command Options

There are several Hercules database-specific options, as shown in the Tech Form in

Figure 4-7.

Chapter 4: Physical Databases

Hercules Database Extraction Flow 4-21

Chapter 4: Physical Databases

Hercules Database Extraction Flow 4-21

StarRC User Guide and Command Reference Version F-2011.06

Figure 4-7 Hercules Database Tech Form

HSIM Reliability Flow Placement Information

StarRC interfaces to HSIM through a Detailed Standard Parasitic Format (DSPF) file for both

hierarchical and flat post-layout simulation flows. The Synopsys product HSIM can receive

hierarchical DSPF and flat DSPF to perform hierarchical or flat timing and reliability analysis.

An important output of reliability analysis is a thermal map showing voltage (IR) drop and

electromigration violations provided by HSIM. Because the HSIM product is netlist based,

the reliability analysis thermal map is generated using node information (*|S, *|I, *|P)

provided by StarRC in the DSPF netlist. In a flat extraction, all nodes are shown with respect

to the origin of the top cell and a thermal map can be drawn without ambiguity. However, in

a hierarchical flow, each node in a hierarchical cell’s DSPF is shown with respect to its origin.

In order to map these nodes to the next level of hierarchy, you must know the placement of

the cell in the next level of hierarchy with rotation and flip attributes.

StarRC generates placement information when you specify the following options:

SKIP_CELL_PLACEMENT_INFO_FILE: YES | NO

SKIP_CELL_PLACEMENT_INFO_FILE_NAME: filename

When PLACEMENT_INFO_FILE: is set, StarRC generates the blockname.placement_info file

with the following information:

•Angle

• Reflection

• Cell location

• Cell name

• Cross-referenced instance name

Chapter 4: Physical Databases

IC Validator Extraction Flow 4-22

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

A sample output is as follows:

* PLACEMENT FILE

* VENDOR "Synopsys, Inc."

* PROGRAM "StarRC X-2005.06"

* DATE "Mon Oct 24 17:48:56 2005"

* UNIT " MICRONS"

TOP_CELL = <cell name>

XSI_0 INV1 49 132 0 NO

XSI_50 XOR2 484 132 180 NO

XSI_61 XOR2 124 312 180 YES

IC Validator Extraction Flow

To create a parasitic netlist with the IC Validator transistor level extraction flow, you must

provide a physical database, schematic netlist, and an IC Validator runset script to generate

an IC Validator database as shown in Figure 4-8. The resulting IC Validator database or the

IC Validator runset report file can be used to generate a parasitic netlist, or an ideal

extraction of the layout from an original GDSII database, or a Milkway place and route

database.

Chapter 4: Physical Databases

IC Validator Extraction Flow 4-23

Chapter 4: Physical Databases

IC Validator Extraction Flow 4-23

StarRC User Guide and Command Reference Version F-2011.06

Figure 4-8 IC Validator Flow

Milkyway

database

GDSII IC Validator

nxtgrd file

mapfile

StarXtract

IC Validator

XREF

Information

StarRC

ICV_RUNSET_REPORT_FILE

XREF

BLOCK

Schematic

Netlist

Physical

Milkyway

Open

Access

run script

schematic

netlist

processed

Extract

View

Database

IC Validator Runset Report File

IC Validator

database

Ideal

(optional)

Netlist

Parasitic Output:

netlist

binary netlist

parasitic view

1. Specify input data for

IC Validator

2. Specify pex_runset_report_file

in your runset script.

All IC Validator results or database

information is recorded in the runset

report file.

in the star_cmd file

Chapter 4: Physical Databases

IC Validator Extraction Flow 4-24

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Steps in the IC Validator Extraction Flow

To connect the IC Validator database with StarRC, you must specify the following commands

in your scripts:

• In the IC Validator run script, specify the following command:

pex_runset_report_file

• In the StarRC command file, include these commands:

BLOCK, XREF, CELL_TYPE, and ICV_RUNSET_REPORT_FILE

• In the IC Validator run script, specify the runset report filename of your choice in the

pex_report_handle command. By default, the file name is specified as

pex_runset_report in the $ICV_HOME_DIR/includes/rcxt_public.rh file. This step is

optional.

The first two modifications are the required changes to run the IC Validator transistor

extraction flow. The resulting IC Validator database or IC Validator runset report file, can

then be used to generate a parasitic netlist or an ideal extraction of the layout from an

original GDSII database, or Milkyway place and route database.

Examples of Script Files

This section provides examples of the script files necessary for the IC Validator extraction

flow.

IC Validator Runset Script

The following example shows the required commands in an IC Validator runset script with

the default runset report file name.

pex_report_handle = pex_runset_report_file();

pex_generate_results(

pex_matrix = pex_matrix,

device_extraction_matrix = my_devices,

device_db = device_db,

layout_database = mw_handle,

pex_process_map_file = pex_process_handle,

pex_runset_report_file = pex_report_handle

);

To change the runset report file name, modify the pex_report_handle command

specification, which is shown as my_report in the following example, to the filename of your

choice.

pex_report_handle = pex_runset_report_file("my_report");

Chapter 4: Physical Databases

IC Validator Extraction Flow 4-25

Chapter 4: Physical Databases

IC Validator Extraction Flow 4-25

StarRC User Guide and Command Reference Version F-2011.06

Note:

All paths listed in the runset_report_file command are absolute paths.

StarRC Command File

In the StarRC command file, add the following command:

ICV_RUNSET_REPORT_FILE : pex_runset_report

Cross-Referenced Extraction in IC Validator

Multi-equivalence points in the layout are supported for cross-referenced extraction.

Multi-equivalence points are points in the layout where one or more layout cells equal to a

single schematic cell. The x-y coordinates of instance ports and top-level ports are reported.

IC Validator can support a selective case-sensitive operation. The StarRC

CASE_SENSITIVE:YES|NO command might not cover all IC Validator case sensitivity

combinations.

Specify the pex_generate_results function in IC Validator runset script to run the IC

Validator and StarRC flow, as shown in the following example.

pex_generate_results(

pex_matrix = pex_matrix,

device_extraction_matrix = my_devices,

device_db = device_db,

layout_database = mw_handle,

pex_process_map_file = pex_process_handle,

pex_runset_report_file = pex_report_handle

);

Certain memory designs might encounter errors in the XrefHN step of an XREF-enabled flow.

For example,

ERROR: StarXtract

ERROR: Found layout instance SRAMblock258x532#448 of equiv

ERROR: SRAMblock258x532#448 which is not a valid equiv point

The SRAMblock blocks are generated by IC Validator when the memory_array_compare

variable is set to TRUE. This is the default. The SRAMblock blocks do not exist in the original

schematic or layout netlists.

In general, the memory_array_compare variable does not affect the LVS results in most

memory designs. For nonmemory designs, you do not need to change this option. The

StarRC XREF options do not support the memory_array_compare variable. You should set it

to FALSE for memory designs that encounter this error when running LVS.

Chapter 4: Physical Databases

Cross-Referencing in Transistor Level Flows 4-26

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

As soon as StarRC finds one instance that is connected to the net “0” in the schematic

netlist, the following error message is issued:

Build XrefHN

ERROR: StarXtract

ERROR: Schematic instance "MM15/SRC" is connected

to ground "0". To

ERROR: prevent incorrect result, please rename net

"0" to another

ERROR: name.

Warnings: 0 Errors: 1 (See file xrefhn.sum)

In this case, you need to change the net name “0” to a different name in the schematic netlist

and rerun Hercules LVS before starting a new StarRC run.

All XREF modes support port ordering with the the SPICE_SUBCKT_FILE command. The

port count and port order in the schematic cell definitions and the SPICE_SUBCKT_FILE

.SUBCKT definitions should always match. StarRC generates net names in the

<instance>_<port> format for ports present in the SPICE_SUBCKT_FILE section but missing

in the schematic or layout, depending on the value of XREF.

Cross-Referencing in Transistor Level Flows

The StarRC XREF command and its options can be used with the Calibre, Hercules, and IC

Validator flows. Details about the functions of these command options are as follows:

XREF:NO

If this command is set to NO, StarRC reports the layout net names generated by Hercules

during ideal layout extraction. These layout names are either generated or derived from the

application of text. The layout cell instance names can either be the original GDSII instance

name if the ASSIGN_PROPERTY command in Hercules is used or they can be names

generated by Hercules. For an example of XREF:NO .spf, see “XREF:NO SPF” in “XREF

Command SPF Examples” on page 13-10.

XREF:YES

The XREF:YES command does not use name prefixes for merged devices, and it generates

names that correspond to the premerged schematic names, thereby making analysis easier

during simulation, and improving schematic-based simulation accuracy. The following

section describes how the names are modified. The XREF:YES command is layout-based;

Chapter 4: Physical Databases

Cross-Referencing in Transistor Level Flows 4-27

Chapter 4: Physical Databases

Cross-Referencing in Transistor Level Flows 4-27

StarRC User Guide and Command Reference Version F-2011.06

every layout device and net is reported. If LVS successfully matches layout nets and devices

with schematic nets and devices, the parasitic netlist uses the schematic names for the

matched nets and devices.

For an example of XREF:YES .spf, see “XREF: YES” on page 13-10.

The following section describes how the XREF:YES command handles naming. In the

information provided, the syntax used is x:y, where the left side is the number of schematic

devices, and the right side is the number of layout devices. 1 indicates one device, with m

and n being differing values of more than 1. For example, m:m refers to the same number of

schematic and layout devices, whereas m:n refers to different numbers of layout and

schematic devices, and so on.

The XREF:YES command has methodologies for handling both one-to-one correspondences

between schematic and layout net/device entities as established by the LVS tool, and for

handling merged composite device matching generated during LVS.

One-to-One Correspondence

When the LVS tool establishes a one-to-one match between schematic net/device and

layout net/device names, XREF:YES netlists such layout nets and devices using their

matching schematic names.

Composite of Merged Devices

When the LVS tool creates a composite merged device in the schematic side consisting of

N merged devices, and matches it to a composite merged device on the layout side

consisting of M merged devices, the following rules govern the device names in the netlist

generated by the XREF:YES command:

• M individual devices are netlisted in the parasitic netlist, corresponding to the M layout

devices.

• A one-to-one correspondence is established between the first X devices where X is the

smaller of N or M within the schematic composite device and the layout composite device.

The first X devices are netlisted in the parasitic netlist using their corresponding

schematic device names.

• If the number of schematic devices exceeds the number of layout devices (N>M), the

remaining (N-M) schematic devices are not referenced in the schematic netlist, as shown

in Figure 4-9.

Chapter 4: Physical Databases

Cross-Referencing in Transistor Level Flows 4-28

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Figure 4-9 Merged Device Handling N>M

Schematic composite

device with N

schematic merged

devices

xrefhn.sum file

Layout composite

device with M layout

merged devices

Devices in the parasitic

netlist with XREF:YES

N>M (# schematic> #layout) merged device handling with XREF:YES. Note the same

convention applies to internal nets within merged devices.

• If the number of layout devices exceeds the number of schematic devices (N<M), the

remaining (M-N) layout devices are mapped back to the top of the schematic device list,

appended by @[number] characters, as shown in Figure 4-10.

Figure 4-10 Merged Device Handling N<M

Schematic composite

device with N

schematic merged

devices

S1@2

S2@2

Layout composite

device with M layout

merged devices

Devices in the parasitic

netlist with XREF:YES

N<M (# schematic <#layout) merged device handling with XREF:YES. Note the same

convention applies to internal nets within merged devices.

S3@2

S1@3

Chapter 4: Physical Databases

Cross-Referencing in Transistor Level Flows 4-29

Chapter 4: Physical Databases

Cross-Referencing in Transistor Level Flows 4-29

StarRC User Guide and Command Reference Version F-2011.06

Table 4-2 shows the device naming conventions for devices participating in composite N:M

merged devices with the XREF:YES setting.

Table 4-2 XREF:YES Device Naming Conventions

Schematic: layout

device merging

Device instance names XREF-info report file

1:1 S1

1:N S1

S1@2

S1@3 ...

S1@N

N:N S1

S3 ...

N:M

(N>M)

S3 ...

alias S(M+1) S1

alias S(M+2) S2 ...

N:M

(N<M)

S3 ...

S1@2

S2@2

S3@2 ...

SN@2 ...

N:1 S1 alias S2 S1

alias S3 S1 ...

alias SN S1

0:M

(filtered schematic

devices)

<XREF_LAYOUT_INST_PREFIX>L1

If a layout net is generated within a merged composite device, that net name in the netlist

contains its layout net name with a prefix of XREF_LAYOUT_NET_PREFIX.

Chapter 4: Physical Databases

Cross-Referencing in Transistor Level Flows 4-30

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Table 4-3 lists definitions for XREF command-related terms.

Table 4-3 XREF Command-Related Terms

Term Definition

XREF (also back-annotation

or cross-referencing)

Generation of parasitic netlist containing layout parasitics and

schematic-based net and instance names.

Schematic-based XREF Generation of parasitic netlist containing all devices and nets that

occur in a schematic netlist used for LVS. Available in StarRC using

the XREF:COMPLETE command.

Layout-based XREF Generation of parasitic netlist containing all devices and nets that

occur in the extracted layout netlist used for LVS. Available in StarRC

using the XREF:YES command.

Device merging (also called

smashing)

Series or parallel combinations of multiple devices by the LVS tool for

single electrically equivalent devices. Often necessary to

successfully match schematic devices to corresponding layout

devices that were implemented as electrically equivalent series or

parallel combinations of devices.

Composite device Resulting device created by the LVS tool when individual layout or

schematic devices are merged into series or parallel combinations.

When devices are merged, only composite devices participate in the

actual layout-to-schematic LVS matching.

XREF:COMPLETE

The XREF:COMPLETE command reports every SKIP_CELL and device in the schematic.

Parasitics are generated in the netlist only for nets that have been successfully

cross-referenced to schematic nets. Nets that do not cross-reference to a schematic net are

treated as ideal connections by StarRC. Schematic model names are reported for

SKIP_CELL and primitive devices. Currently the XREF:COMPLETE command is supported in

the Hercules flow only.

Internal nets of the SERIES/PATHS merged devices do not have *|NET sections in

XREF:COMPLETE; the netlist result is ideally included in the Instance Section. For an SPF

example of XREF:COMPLETE, see “XREF: COMPLETE (SPF)” on page 13-11.

XREF:COMPLETE Output Reporting

The following section contains information about how XREF:COMPLETE reports device

properties; the syntax used is x:y, where the left side is the number of schematic devices,

and the right side is the number of layout devices. 1 indicates one device, with m and n being

differing values of more than one. For example, m:m is “same number of schematic and

Chapter 4: Physical Databases

Cross-Referencing in Transistor Level Flows 4-31

Chapter 4: Physical Databases

Cross-Referencing in Transistor Level Flows 4-31

StarRC User Guide and Command Reference Version F-2011.06

layout devices more than one” as shown in Table 4-4. The m:n refers to different numbers of

layout and schematic devices, and so on. Width and Length within the set of n MOS devices

in layout can be different for each device. Width and Length within the set of m MOS devices

in the schematic can also be different for each device.

Table 4-4 Device Property Reporting

Type Width Length AD/AS/PD/PS

MERGE_PARALLEL

1:n Summation of all the

width values of the n

MOS devices in the

layout.

Smallest length

values out of n

layout MOS

devices.

Summation of all the AD/

AS/PD/PS values of the

NMOS devices in the

layout.

m:1 Width of the layout

MOS divided by m for

each device.

Same length of the

layout MOS device

for each device.

AD/AS/PD/PS of the

layout MOS device

divided by m for each

device

m:m Corresponding width

value from the layout.

No calculation is

performed.

Corresponding

length value from

the layout.

Corresponding AD/AS/

PD/PS value from the

layout.

m:n Summation of all the

width values of the

nMOS devices in the

layout, divided by m for

each device.

Smallest length

value of all n layout

MOS devices.

Summation of all the AD/

AS/PD/PS values of the n

MOS devices in the

layout, divided by m for

each device.

MERGE_SERIES

m:m Corresponding width

value from layout. No

calculation is

performed.

Corresponding

length value from

layout. No

calculation is

performed.

Corresponding AD/AS/

PD/PS value from layout.

No calculation is

performed.

Chapter 4: Physical Databases

Cross-Referenced Extraction Options 4-32

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Cross-Referenced Extraction Options

There are several commands you can use for cross-referenced extraction. See “Timing

Extraction/Analysis” on page 13-2.

Cross-referenced extraction options appear in all of the GUI wizards when the Hercules

database is selected; they are otherwise invisible. The XREF Tech Form is shown in

Figure 4-11.

MERGE_SERIES_GATE

1:n Average width of the n

MOS devices in the

layout.

Summation of all

the length values of

the n MOS devices

in the layout.

Summation of all the AD/

AS/PD/PS values of the n

MOS devices in the

layout.

m:1 Same width as the

layout MOS device for

each device.

Length of the layout

MOS divided by m

for each device.

AD/AS/PD/PS of the

layout MOS device

divided by m for each

device.

MERGE_PATHS

MERGE_PATHS is a mixture of the MERGE_PARALLEL, MERGE_SERIES, and

MERGE_SERIES_GATE cases.

If there is a multiple-layout-cell-to-single-schematic-cell equivalency in the LVS, StarRC randomly

chooses only one of the layout cells and uses the layout properties of that cell in when generating the

netlist of all the XREF cells.

Table 4-4 Device Property Reporting (Continued)

Type Width Length AD/AS/PD/PS

Chapter 4: Physical Databases

Parameterized Cells (PCELL) 4-33

Chapter 4: Physical Databases

Parameterized Cells (PCELL) 4-33

StarRC User Guide and Command Reference Version F-2011.06

Figure 4-11 XREF Tech Form

Parameterized Cells (PCELL)

A parameterized cell (or PCELL) is placed in layout to represent a device. The cell’s contents

are sized during placement according to your parameters to achieve certain geometries and

functionality in the device. For simulation and analysis purposes, the entire contents of the

cell are often characterized and modeled as an encapsulated unit, including all conductor

effects inside the cell boundary.

How StarRC Layer-Based Rules Affect Parameterized Cells

By default, StarRC defines the boundary between interconnect parasitic effects and

intradevice effects through layer-based rules for each standard device type.

Capacitance

For example, these rules allow StarRC to discard all capacitance considered to be inside the

device by ignoring capacitance between certain predetermined device terminal layer

combinations.

Resistance

Chapter 4: Physical Databases

Parameterized Cells (PCELL) 4-34

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Similarly, StarRC permits the inclusion or exclusion of parasitic resistance on a

layer-by-layer basis. However, because a parameterized cell is typically characterized as a

complete unit, it becomes simpler and more accurate to use the cell boundary and not

layer-based interactions to separate intradevice parasitic effects that are discarded from

interconnect effects, but retained in the netlist.

StarRC uses gray box extraction techniques to handle parameterized cells. See

“SKIP_PCELLS Extraction Operation” on page 4-39. The StarRC container cell method

obviates the need for the scrutiny of intra device layers versus interconnect layers, because

the cell boundary (instead of the device layers) is used to delineate the device boundary.

The preparation of the device extraction rule file for parameterized cell devices becomes

simpler. Also, because the boundary between interconnect and intra device effects is

defined by the parameterized cell boundary for both the device model and the parasitic

extraction tool, the accuracy of the device and interconnect simulation are maximized.

This extraction method allows you to extract PCELL devices without the need for device

layer manipulation in the extraction rule file.

How LVS Handles Parameterized Cells

During ideal device extraction and LVS, you can use standard device extraction commands

to extract one or more logical devices from polygons inside a parameterized cell. The ideal

layout netlist output then contains a hierarchy level representing the PCELL, referred to as

the container cell. Inside this container cell is the extracted device, which represents the

design down to the lowest level of hierarchy or transistor level.

Conversely, the schematic netlist might or might not contain a level of cell hierarchy

corresponding to the container cell. Possible scenarios include:

Layout Schematic

Single device No container cell

Multiple devices No container cell

One or more devices in container cell Container cell

Single Device in Layout Container Cell and

No Container Cell in Schematic

In one design scenario, the schematic netlist might contain only the device instance, not the

container cell instance, because the parameterized cell is a physical (but not logical)

construct. This creates a non uniform hierarchy between the layout and schematic, because

the layout has an extra level of cell hierarchy not present in the schematic as shown in

Figure 4-12. To match the layout and schematic, LVS expands (explodes) the layout

Chapter 4: Physical Databases

Parameterized Cells (PCELL) 4-35

Chapter 4: Physical Databases

Parameterized Cells (PCELL) 4-35

StarRC User Guide and Command Reference Version F-2011.06

container cell in the layout netlist so that the extracted device appears in the layout netlist’s

top block. This results in an equal hierarchy between the layout and schematic for complete

LVS matching as shown in Figure 4-13.

Figure 4-12 PCELL Layout and Schematic Hierarchy; Single Device Inside Container

LEVEL 2

LEVEL 1

LEVEL 0

Layout Hierarchy Schematic Hierarchy

TOP BLOCK

CONTAINER

CELL

DEVICE

TOP BLOCK

DEVICE

Figure 4-13 LVS Matching of PCELL Devices via Layout PCELL Explosion

TOP BLOCK

DEVICE

PCELL

TOP BLOCK

DEVICE

Layout Hierarchy Schematic Hierarchy

LVS Match

Original Hierarchy

Exploded Hierarchy

Chapter 4: Physical Databases

Parameterized Cells (PCELL) 4-36

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Multiple Devices in Layout Container Cell and

No Container Cell in Schematic

In another scenario, the schematic netlist might contain only the device instance, but not the

schematic container cell instance. However, the layout container cell might contain multiple

instances of device primitives, which might or might not be of the same device type. For

example, a parameterized cell representing a MOSFET might have well diodes extracted

inside the layout container cell as well as the MOS primitive itself as shown in Figure 4-14.

In this case, LVS must once again explode the layout container cell, as shown in Figure 4-15,

because no corresponding cell hierarchy exists in the schematic. Then, all primitives

originally inside the layout container cell hierarchy are matched by LVS processing to

primitives in the schematic.

Figure 4-14 PCELL Layout and Schematic Hierarchy; Multiple Devices Inside Layout Container

Cell

LEVEL 2

LEVEL 1

LEVEL 0

Layout Hierarchy Schematic Hierarchy

TOP BLOCK

CONTAINER

CELL

DEVICE

TOP BLOCK

DEVICE

DEVICE DEVICE

Chapter 4: Physical Databases

Parameterized Cells (PCELL) 4-37

Chapter 4: Physical Databases

Parameterized Cells (PCELL) 4-37

StarRC User Guide and Command Reference Version F-2011.06

Figure 4-15 LVS Matching of PCELL Devices via Layout PCELL Explosion: Multiple Devices

Inside Layout Container Cell

TOP BLOCK

CONTAINER CELL

DEVICE

TOP BLOCK

Layout Hierarchy Schematic Hierarchy

LVS Match

DEVICE DEVICE DEVICE

DEVICE

Original Hierarchy

Exploded Hierarchy

One or More Devices in the Layout Container Cell With

Container Cell in Schematic

In this scenario, the schematic netlist might contain a device instance inside a schematic cell

that has an EQUIV point (Hercules) / HCELL (Calibre) corresponding to the layout container

cell. The layout container cell might contain one or more instances. In this case, LVS

maintains the equivalent schematic and layout hierarchy to match the schematic device to

the layout device as shown in Figure 4-16.

Chapter 4: Physical Databases

Parameterized Cells (PCELL) 4-38

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Figure 4-16 PCELL Layout and Schematic Hierarchy: Container Cell in Schematic

LEVEL 2

LEVEL 1

LEVEL 0

Layout Hierarchy Schematic Hierarchy

TOP BLOCK

CONTAINER

CELL

DEVICE DEVICE

TOP BLOCK

CONTAINER

CELL

DEVICE DEVICE

In a design that has equivalence between the schematic and layout, no explosion is needed

as shown in Figure 4-17. In this case, LVS maintains the equivalent schematic and layout

hierarchy to match the schematic device to the layout device.

Figure 4-17 LVS Matching of PCELL Layout and Schematic Hierarchy

Layout Hierarchy Schematic Hierarchy

TOP BLOCK

CONTAINER

CELL

DEVICE DEVICE

TOP BLOCK

CONTAINER

CELL

DEVICE DEVICE

LVS Match

Extracting PCELLS Using StarRC

To extract a parameterized cell (PCELL) as a fully characterized gray box cell unit during

parasitic extraction, specify the SKIP_PCELLS command in the StarRC command file.

Chapter 4: Physical Databases

Parameterized Cells (PCELL) 4-39

Chapter 4: Physical Databases

Parameterized Cells (PCELL) 4-39

StarRC User Guide and Command Reference Version F-2011.06

SKIP_PCELLS Extraction Operation

During a StarRC SKIP_PCELLS extraction, certain functions are performed differently. The

following functions change when parameterized cells are specified:

Gray Box Handling

Parasitic resistance is extracted up to the instance port (x, y) location for each cell port.

Capacitive interactions between top-level nets and the material inside the cell are extracted

and compiled as ground capacitance in accordance with the StarRC standard gray box

extraction method. Port capacitance is not included in the total capacitance for the net

connecting to the port

IGNORE_CAPACITANCE Command

During extraction, the parameterized cell is treated as a gray-box SKIP_CELL. Functions

related to the IGNORE_CAPACITANCE command are disabled for SKIP_CELL devices (but not

for non-PCELL devices) because layer-based capacitance removal is not required.

Extracting Coupling Capacitances

StarRC reports coupling capacitances for two additional conditions related to PCELL

structures. You can report coupling capacitances between overhead nets to PCELL pins and

coupling capacitances between different PCELL pins reported in the generated netlist. You

can do this by specifying the COUPLE_TO_PCELL_PINS command.

Figure 4-18 Extraction of Overhead Net

pin2

pin1

c1 c2

PCELL Boundary

Overhead Routing

Chapter 4: Physical Databases

Parameterized Cells (PCELL) 4-40

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

With this command, either the coupling capacitances between PCELL pins and overhead

nets are reported or they are grounded, depending on the command syntax. In Figure 4-18

on page 4-39 the extraction of overhead nets to PCELL pins is shown. Figure 4-19 shows

the extraction of overhead nets.

Figure 4-19 Extraction of Overhead Net

pin2

pin1

c1 c2

PCELL Boundary

Overhead Routing Net A

pin2

pin1

cb1 cb2

PCELL Boundary

Overhead Routing Net B

SKIP_PCELLS Netlist Behavior

For compilation purposes, the entire logical content of a PCELL generates a netlist. This

means:

• All devices inside the PCELL container cell are generated in the DSPF instance section.

•All

*|I lines in the DSPF file reflect connections to individual devices inside the container

cell.

The logical content of the DSPF netlist (devices in the instance section,*|I lines) are

identical to a generated netlist if no SKIP_CELLS operation has been performed on the

PCELL container. This allows StarRC to support different LVS configurations of PCELLs.

The netlist result is as follows:

• The devices inside the PCELL container cell are generated with the same device names

used when no SKIP_CELLS operations are performed.

• All geometric device properties belonging to the devices inside the container cell are

generated as normal in the DSPF instance section.

• If the PCELL container cell has a port that is not connected to a device inside the

container cell, that port is ignored during netlist output.

Chapter 4: Physical Databases

Metal Fill 4-41

Chapter 4: Physical Databases

Metal Fill 4-41

StarRC User Guide and Command Reference Version F-2011.06

• Any internal nodes inside the PCELL container cell (for example, nodes that are not

instance ports of the container cell) are output as ideal nets in the DSPF.

• All specified INSTANCE_PORT commands for PCELLS are automatically set to

SUPERCONDUCTIVE.

Metal Fill

In semiconductor manufacturing, each process layer is planarized with chemical mechanical

polishing. This repeated polish causes a conductive layer to settle or “drop down” where

there is no lower-level metal. To avoid conductor layers dropping in to empty spaces

between metals, metal fill is commonly included in the design. This concept is shown in

Figure 4-20.

Figure 4-20 Nonplanar vs. Planar Layers

Dielectric 1

Dielectric 2

Metal1

Metal 2

Dielectric 1

Dielectric 2

Metal1

Metal 2 Metal 2 Metal 2

Metal

Fill

Nonplanar Layers Planar Layers

Metal fill can exist in a variety of shapes and sizes. Typically there are two types of metal fill

structures in a design: grounded metal fill and floating metal fill. Grounded metal fill is

connected to power or ground by via connections; floating metal fill has no connection to

signal, power, or ground nets. Both types can exist in the same layout design.

When running StarRC extraction, you can specify the metal fill to be emulated or real. These

two approaches yield different results depending on the accuracy you desire. However,

emulation fill is used only during the early stages of the place-and-route flow and should not

be used for correlation with the place-and-route flow.

StarRC can extract designs with metal fill (actual) polygons. These polygons can be read

either directly from the design database (Milkyway or LEF/DEF) or from a separate GDSII

file. The effect of metal fill on signal nets can be extracted by treating them as floating or

grounded. You also can completely ignore the metal fill polygons even though they are

present in the database.

Chapter 4: Physical Databases

Metal Fill 4-42

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Note:

StarRC reads metal fill information from the GDS file provided. You can determine how

many polygons were read from different layers by reading the metal fill statistics in the

readDB.sum file located in the directory where StarRC deposits intermediate files.

Emulated Metal Fill

A design database containing emulated metal fill does not actually contain any metal fill

shapes or material, but StarRC can emulate the effect of placing metal fill in the design. The

advantages and disadvantages to this approach are shown in Table 4-5.

Table 4-5 Advantages and Disadvantages of Emulated Metal Fill

Advantages Disadvantages

Fast extraction runtimes Less accurate than drawn metal fill

Allows you to change the design function

independent of the design

Only floating metal fill can be run as emulated.

The emulated fill polygons are taken only as

floating in the layout, meaning these virtual

polygons cannot be tied to any power/ground

net.

Works on all database types such as

Milkyway, LEF/DEF, and GDSII

Note:

Use an emulation fill only during the early stages of the place-and-route flow. You should

not use it for correlation with the place-and-route flow.

Using Emulated Metal Fill in StarRC

Three parameters can be specified in an ITF to describe metal fill: FILL_WIDTH and

FILL_SPACING for lateral capacitive effects and FILL_RATIO for vertical capacitive effects.

Figure 4-21 shows a lateral and vertical fill spacing example.

Chapter 4: Physical Databases

Metal Fill 4-43

Chapter 4: Physical Databases

Metal Fill 4-43

StarRC User Guide and Command Reference Version F-2011.06

Figure 4-21 Emulated Fill Example Spacing

Metal 2 Metal 2

Fill

Metal 2

Fill

Metal 2

Fill Metal 2

FILL_SPACINGFILL_SPACING FILL_WIDTH

FILL_RATIO = 50%

Metal 1 Metal 1 Fill Metal 1

FILL_SPACINGFILL_WIDTHFILL_SPACING

Using the nxtgrd File with Emulated Fills

No specific commands are required for the StarRC run regardless of input database

information. Emulated fills are applied according the definitions you provide in the

accompanying nxtgrd file from an ITF. No new data is needed for the design database. The

fill effects are accounted for in the StarRC capacitance modeling function.

Real Metal Fill

Real metal fill can exist in the design database as drawn shapes. The advantages and

disadvantages to this approach are shown in Table 4-6.

Table 4-6 Advantages and Disadvantages of Real Metal Fill

Advantages Disadvantages

• Provides more accurate results • Creates more data

• Requires longer runtimes

• Requires you to regenerate the fill each time a

change is made

Chapter 4: Physical Databases

Metal Fill 4-44

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

StarRC processes metal fills as floating or as grounded depending on their correct

identification in the database. You identify fill in the database by using the

METAL_FILL_POLYGON_HANDLING command and its options. The options identify and treat

metal fill as follows:

•IGNORE

This is the default option. The command does not translate metal fill even if it is in the

database.

•FLOATING

Processes all metal fill as floating even if the fill has been placed as grounded fill.

•GROUNDED

Processes all metal fill as grounded even if the fill has been placed as floating fill.

•AUTOMATIC

Processes LEF/DEF and Milkyway fills based on the section in which they appear. These

can be LEF/DEF or ROUTE_TYPE for Milkyway.

Handling Coupling Capacitance on Floating Metal Fills

The METAL_FILL_POLYGON_HANDLING and REMOVE_FLOATING_NETS commands have some

similarities and differences.

The similar behavior these two commands share is floating polygons are not generated in

the parasitic netlist. If either of these commands are used, any floating net or fill net/polygon

does not have a *D_NET (SPEF format) or *|NET (spf format) section in the netlist, and no

couplings are shown to these floating nets.

The different behavior of these commands becomes evident when you are also using

REMOVE_FLOATING_NETS:YES. StarRC treats floating nets as noncritical material. StarRC

finds the coupling capacitance that exists from the signal nets to this noncritical material,

and then de-couples these capacitors. This coupling capacitance is then added to the total

ground capacitance of the signal net.

If there are floating metals in the design that are designated as fill (either with the

METAL_FILL_GDS_FILE, or as fill material in the Milkyway or LEF/DEF database), then

StarRC uses a different method to handle coupling capacitance to floating fill polygons.

When METAL_FILL_POLYGON_HANDLING:FLOATING is set, StarRC extracts coupling

capacitance to floating fill polygons. However, the goal is to not generate these fill polygons

for the netlist. Instead of grounding the coupling capacitors to fill polygons, StarRC runs

netlist reduction algorithms on the capacitors that connect to nodes on the fill. This allows

StarRC to compute equivalent capacitances, but eliminate the nodes on the floating fill

polygons. By finding equivalent capacitance, the netlist accounts for capacitive effects

created by the fill polygons without generating the nodes in the netlist associated with the fill.

Chapter 4: Physical Databases

Metal Fill 4-45

Chapter 4: Physical Databases

Metal Fill 4-45

StarRC User Guide and Command Reference Version F-2011.06

Because METAL_FILL_POLYGON_HANDLING:FLOATING finds equivalent capacitance of

capacitors coupling to fill, there are a few distinct advantages as explained as follows:

• If nets couple to each other through fill polygons, then the netlist has a coupling capacitor

between these two nets with METAL_FILL_POLYGON_HANDLING:FLOATING. When using

REMOVE_FLOATING_NETS:YES, the coupling capacitance to the floating nets appears as

additional ground capacitance.

• Nets that normally do not couple to each other can couple to each other after fill is added

to the database. When METAL_FILL_POLYGON_HANDLING:FLOATING is specified, this

effect is captured and a coupling capacitor between these nets shows up in the netlist.

This can increase the accuracy of signal integrity analysis because crosstalk effects

induced by metal fill can now be considered.

Guidelines for Using Metal Fill

You can use Milkyway and LEF/DEF 5.4 or higher databases containing real metal fill input

for StarRC. No other flows are supported. Observe the following guidelines for the particular

database:

•Milkyway

StarRC accepts metal fill polygons either in FILL view or CEL/FRAM view for a given

block. This data can be also be created by IC Compiler.

•LEF/DEF

LEF/DEF versions 5.4 and higher support the FILLS section for floating fill and fill wire for

grounded fills only.

LEF/DEF has two different syntaxes for specifying metal fill. Floating metal fill polygons

are specified in the “FILLS” section of the DEF file. If the fill polygons are tied to power

and ground nets, they are specified in the SPECIALNETS section (part of special Wiring

with SHAPE defined as FILLWIRE) for the power and ground nets. For more information

about the syntax, see LEF/DEF Language Reference.

•GDS

StarRC can read metal fill polygons from a separate GDSII file in addition to the design

database. For this flow, the design database can be in Milkyway, LEF/DEF, or GDSII (a

Milkyway XTR view generated in Hercules or an AGF file generated in Calibre) format.

This GDSII file must have metal fill polygons only, because all the polygons from the file

are considered metal fill objects.

The handling mode for metal fill imported through a METAL_FILL_GDS_FILE can be

specified on either a global or layer-specific basis. See the METAL_FILL_GDS_FILE,

METAL_FILL_GDS_FILE_NET_NAME, and GDS_LAYER_MAP_FILE command descriptions.

Chapter 4: Physical Databases

Metal Fill 4-46

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

No floating fills should exist in the XTR view because StarRC cannot automatically

identify these. You can attach (VSS) text to identify grounded fills in the physical layout

and make them a part of the existing grounded network.

StarRC can accept a GDSII stream file containing only fill shapes and add them to the

design. You can specify a flat GDSII file by using the METAL_FILL_GDS_FILE command.

If you would like to attach all fills to a particular net, use the

METAL_FILL_GDS_FILE_NET_NAME command.

To ensure that your fill structures are identified properly in the database, use the

GDS_LAYER_MAP_FILE command.

How StarRC Handles Metal Fill

StarRC reads various design databases and translates metal fill polygons into the internal

format before performing extraction. Translation depends on the setting of the

METAL_FILL_POLYGON_HANDLING command or on the fill handling setting specified in the

GDS_LAYER_MAP_FILE.

Metal fill can be processed in two ways: as grounded metal fill or floating metal fill.

Grounded Metal Fill

During signal net extraction, the fill polygons are treated just like a polygon belonging to a

power and ground net. There is no special handling of these polygons during extraction.

Floating Metal Fill

In this mode, capacitance is calculated between signal and fill polygons and between

different fill polygons. After extraction, fill nodes are reduced “on the fly” and equivalent

capacitance between signal nets and capacitance to ground for signal nets is calculated.

Floating and Grounded Metal Fill

You can process a combination of floating and grounded metal fills in StarRC. The grounded

fills are created as a part of the power network by using text to identify them as part of the

net. You can alternatively use the METAL_FILL_GDS_FILE_NET_NAME command to make the

fill as grounded in the design. The floating fills are created and used in the design either as

FILL view in Milkyway format, FILLS in DEF format or GDS file.

Note:

The combination of emulated fill and real physical fill is not supported in StarRC.

Chapter 4: Physical Databases

Shared Database Command Options 4-47

Chapter 4: Physical Databases

Shared Database Command Options 4-47

StarRC User Guide and Command Reference Version F-2011.06

Accuracy Validation With Metal Fill

The EXTRACTION:FSCOMPARE command for StarRC provides an automated push-button flow

for analysis of test structures or even selected nets from a chip with an industry standard 3-D

field solver.

A 3-D field solver can handle floating metal fill and StarRC automatically prepares the

appropriate 3-D field solver input deck based on the METAL_FILL_POLYGON_HANDLING

command and/or the layer handling specified in the GDS_LAYER_MAP_FILE.

Shared Database Command Options

There are several shared database command options. See “Command List With Task

Information” on page B-2.

Chapter 4: Physical Databases

Shared Database Command Options 4-48

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

5-1

Incremental Extraction 5

StarRC incremental extraction provides automatic detection of ECO affected nets to create

an incremental or complete netlist. It is supported in the Milkyway and LEF/DEF extraction

flows.

This chapter includes the following sections:

•Incremental Extraction Flow

•Running Incremental Extraction

•Incremental Netlist Examples

•Schematic Examples and Their Netlists

Chapter 5: Incremental Extraction

Incremental Extraction Flow 5-2

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Incremental Extraction Flow

This section explains the various incremental extraction flows and describes how to use

incremental extraction with StarRC, IC Compiler, and PrimeTime. The incremental

extraction feature has specific requirements:

• Only run incremental extraction on large designs and blocks. If the design takes several

hours to run, or has more than 250,000 instances. In a normal extraction, consider using

incremental extraction.

• ECO changes must be performed manually, and not generated with automatic features

within the routing tool. Using such automated features can cause changes on a global

scale and make the incremental extraction runtime longer than a normal extraction.

• Small cases should only be used for initial flow testing and debugging. When incremental

extraction is used on a small design, the runtime is expected to be longer than a normal

extraction.

Incremental runs are mainly run on full chip databases. When performing timing closure and

crosstalk analysis, iterative design and analysis runs are necessary to identify timing and

crosstalk issues, perform engineering change orders (ECOs) to correct those problems, and

verify the resolution of those issues. An ECO can include localized gate placement and

sizing changes, net rerouting, and net addition or deletion. StarRC automatically determines

all nets that have been modified, including those nets that are neighbors to

physically-modified nets. The modified nets and neighboring nets are called ECO affected

nets. All ECO affected nets need to be re-extracted by StarRC.

To run an incremental extraction, specify the INCREMENTAL:YES command in the star_cmd

file.

Input to StarRC

Incremental extraction requires that the first complete chip data has been extracted

successfully. The required inputs to StarRC are:

• STAR directory from previous extraction run (full chip or incremental)

• Updated design database with ECO edits

Output from Incremental Extraction Runs

StarRC can output an incremental netlist in either SPEF or SBPF format.

Chapter 5: Incremental Extraction

Incremental Extraction Flow 5-3

Chapter 5: Incremental Extraction

Incremental Extraction Flow 5-3

StarRC User Guide and Command Reference Version F-2011.06

A full-chip netlist contains the parasitic results for the ECO affected nets and previously

extracted parasitic results for non-affected nets/instances. Timing/SI analysis tools without

incremental analysis capability can then use this as input.

An incremental netlist contains only the ECO affected nets, along with couplings to non-ECO

affected nets. These coupling capacitances appear as dangling within the incremental

netlist itself. However, they are not dangling when downstream tools analyze the netlist

incrementally. For incremental analysis, it is essential that nodes on non-ECO affected nets

maintain the same name as the full-chip netlist.

Fixing a Design Using Engineering Change Orders

When performing timing closure and crosstalk analysis, iterative design and analysis runs

are necessary to identify timing and crosstalk issues. Perform engineering change orders

(ECOs) to correct those problems, and verify the resolution of those issues. An ECO can

include localized gate placement and sizing changes, net rerouting, and net addition or

deletion. Verifying the resolution of issues after an ECO requires repeating parasitic

extraction for the affected nets and instances and rerunning timing and/or crosstalk analyses

using the updated parasitic information.

Reasons to Perform ECOs

You should perform an ECO on a design under the following circumstances:

• Pure logical changes in the net names, instance names, or port names

• Pure physical—routing or placement—changes

• A combination of physical and logical changes

Chapter 5: Incremental Extraction

Incremental Extraction Flow 5-4

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Table 5-1 summarizes the behavior of StarRC under different ECO conditions.

Table 5-1 StarRC Behavior Under Different ECO Conditions

Physical Changes Logical Changes StarRC behavior

No No Terminates with a fatal error and prints an error

message

No Ye s Runs netlist generation only

Ye s No Runs incremental extraction

Ye s Ye s Runs an incremental flow

An efficient analysis, repair, and verification flow for ECOs requires

• An incremental parasitic extraction that re-extracts only those nets and instances affected

by the ECO

• An incremental analysis capability that reads and analyzes only the parasitics that have

changed since the last iteration

If incremental extraction capability is available without an incremental analysis, efficiency is

gained only in the parasitic extraction step, not in the analysis step. Such an incremental

extraction flow is conceptually illustrated in Figure 5-1.

Chapter 5: Incremental Extraction

Incremental Extraction Flow 5-5

Chapter 5: Incremental Extraction

Incremental Extraction Flow 5-5

StarRC User Guide and Command Reference Version F-2011.06

Figure 5-1 Conceptual Flow for Iterative Incremental ECO Extraction Only

Original

Place and Route

Layout Database

Full Chip Flow

Placement/Routing

Full-Chip Timing /

Signal Integrity

Analysis

Full Parasitic Netlist

Full-Chip

StarRC

Extraction

Full-Chip Timing /

Signal Integrity

Analysis

Full Parasitic Netlist

Full-Chip

StarRC

Extraction

ECO-Modified

Place and Route

Database

Timing/Signal Integrity

Violation?

Incremental Extraction Flow

YES

ECO

Router

Design Complete

Chapter 5: Incremental Extraction

Incremental Extraction Flow 5-6

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Identification and Extraction of Nets Affected by ECOs

A proper incremental extraction methodology must identify and re-extract the parasitic

resistance and capacitance of nets affected by the ECO. This means the extraction tool must

identify and re-extract the parasitic resistance and capacitance.

StarRC automatically identifies all nets in the following six categories. These nets are called

ECO affected nets.

• Nets added by the ECO

• Nets deleted by the ECO

• Nets modified by the ECO

• Any coupling capacitance between neighboring nets and the ECO-added nets (new

neighbors of new nets)

• Any coupling capacitance between neighboring nets to the ECO-modified nets that

changed as a result of the ECO (old and new neighbors of modified nets)

• Any coupling capacitance to nets deleted by the ECO (old neighbors of deleted nets)

Note:

Note that the number of nets changed due to ECO (ECO nets) is a subset of ECO

affected nets from resistance and capacitance extraction. All ECO affected nets need to

be re-extracted by StarRC. Figure 5-2 on page 5-7 illustrates the nets that are

re-extracted during an incremental extraction after a database ECO.

Chapter 5: Incremental Extraction

Incremental Extraction Flow 5-7

Chapter 5: Incremental Extraction

Incremental Extraction Flow 5-7

StarRC User Guide and Command Reference Version F-2011.06

Figure 5-2 Nets and Capacitances Extracted During Incremental Extraction

Nets and capacitances extracted during incremental extraction.

All pre-ECO and post-ECO couplings illustrated are re-extracted during

incremental extraction.

Post-ECO Coupling

Pre-ECO Coupling

Incremental Extraction Using StarRC

Incremental extraction in StarRC requires that the first extraction is a full-chip extraction and

that it completes successfully with a full chip netlist. A full-chip extraction can then be

followed by multiple incremental extractions. StarRC reads the ECO database and

compares it with the data from the previous extraction run, which is stored in the temporary

STAR directory, to determine ECO affected nets.

You must maintain the data integrity of the STAR directory otherwise StarRC reports an

error. If the comparison between databases shows no difference, StarRC does not proceed

to extraction, and stops. You can perform a full-chip extraction after an incremental run as

well, followed by incremental runs.

Chapter 5: Incremental Extraction

Incremental Extraction Flow 5-8

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Note:

You should complete at least one final full-chip extraction and timing analysis after timing

has been declared clean.

During a full-chip extraction following an incremental extraction, you can change any

command option. A full-chip extraction after an incremental extraction has the effect of

removing all previous incremental extractions.

Between a full-chip and subsequent incremental extraction runs, only certain command

options can be changed. An incremental extraction run reuses translation and extraction

results from previous extractions, so any command or option that affects the integrity of

those results cannot be changed between the full-chip and incremental extractions. In

addition to all the incremental extraction-related options, the following are the only options

that can be changed between full-chip and incremental extraction:

• Options that describe the location and name of the design database:

MILKYWAY_LIBRARY, TOP_DEF_FILE, MACRO_DEF_FILE, BLOCK. Changing these options

allow you to point to a new ECO database.

• All netlist commands, for example, NETLIST_FILE, NETLIST_FORMAT, and so on.

ECO affected nets can be much larger than the actual ECO nets; this depends on the

congestion of the design and the amount of ECO changes implemented. To enable

convergence, the changed database results from incremental extraction and full-chip

extraction should be within a certain tolerance. StarRC targets a tolerance of 5 percent, or

1fF with MODE: 200 (preferable for 90-nm and smaller designs). The key to such

convergence is accurate identification of ECO affected nets during the incremental stage.

When a large number of ECO affected nets exist, it might not be worthwhile to perform

incremental extraction and analysis. If the number of ECO affected nets for re-extraction is

50 percent or more of the total number of nets in the full-chip post-ECO database, StarRC

produces a warning message and continues.

After incremental extraction, StarRC produces a full-chip, or incremental, netlist (if

NETLIST_INCREMENTAL:YES is specified). The incremental netlist can be created only in

SPEF or SBPF formats. StarRC does not provide logical netlist (Verilog) change information.

If the NETLIST_FILE option is same as the last run, StarRC overrides the existing netlist file.

With an incremental netlist, the subsequent analysis stage is sped up dramatically. Any

downstream tool can analyze a full-chip netlist from incremental extraction without any

modification. However, downstream tools need to be enhanced to accurately analyze an

incremental netlist with coupling capacitances.

Chapter 5: Incremental Extraction

Incremental Extraction Flow 5-9

Chapter 5: Incremental Extraction

Incremental Extraction Flow 5-9

StarRC User Guide and Command Reference Version F-2011.06

Input Files for Incremental Extraction

Incremental extraction in StarRC requires that the first extraction is a successful full-chip

extraction followed by multiple runs of incremental or full-chip extraction. StarRC requires

the following inputs:

• The StarRC directory from a previous full-chip or incremental extraction run

• A new design database with ECO edits

Output Files From Incremental Extraction

StarRC can output the following netlists in either SPEF or SBPF formats:

• Full-chip netlist

The full-chip netlist contains the new parasitic results for ECO affected nets and

previously extracted parasitic results for non-affected nets or instances. Timing and

signal-integrity analysis tools without incremental analysis capability can then use the

full-chip netlist as input.

• Incremental netlist

The incremental netlist contains only the ECO affected nets, along with coupling

capacitances to non-ECO affected nets. These coupling capacitances appear as

dangling within the incremental netlist itself. However, they are not dangling when

downstream tools analyze the netlist incrementally. To allow incremental analysis, nodes

on non-ECO affected nets must maintain the same name as the full-chip netlist.

Chapter 5: Incremental Extraction

Running Incremental Extraction 5-10

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Unsupported Commands During Incremental Extraction

StarRC does not support in-context extraction, power net extraction, or transistor-level

extraction while doing incremental extraction. The commands that are not supported during

incremental extraction are listed in Ta bl e 5-2:

Table 5-2 Unsupported Commands During Incremental Extraction

Command Type Unsupported Commands During Incremental Extraction

In-context

extraction

commands

MACRO, SKIP_CELLS_COUPLE_TO_NET, SKIP_CELLS_COUPLE_TO_NET_LEVEL,

ZONE_COUPLE_TO_NET, ZONE_COUPLE_TO_NET_LEVEL,

COUPLE_NONCRITICAL_NETS, COUPLE_NONCRITICAL_NETS_PREFIX,

RING_AROUND_THE_BLOCK

Power net

extraction

commands

POWER_EXTRACT, POWER_REDUCTION, NETLIST_POWER_FILE

Transistor-level

extraction

commands

MILKYWAY_EXTRACT_VIEW, MAGNIFY_DEVICE_PARAMS,

MOS_GATE_CAPACITANCE, CALIBRE_QUERY_FILE, PROBE_TEXT_FILE,

HN_NETLIST_SPICE_TYPE, TRANSLATE_RETAIN_BULK_LAYERS,

NETLIST_IDEAL_SPICE_FILE, NETLIST_IDEAL_SPICE_TYPE,

NETLIST_IDEAL_SPICE_HIER, NETLIST_USE_M_FACTOR,

NETLIST_PASSIVE_PARAMS, CELL_TYPE, NET_TYPE,

XREF_LAYOUT_NET_PREFIX, XREF_LAYOUT_INST_PREFIX,

XREF_USE_LAYOUT_DEVICE_NAME, XREF_FEEDTHRU_NETS

Other commands SKIP_INSTANCES, EXTRACTION:[R|FSCOMPARE], FS_EXTRACT_NETS,

NETLIST_FORMAT: NONE

Running Incremental Extraction

To perform incremental extraction, a full-chip extraction must be successfully completed and

a netlist produced. Once you have created changes in the database, they can be

re-extracted using the INCREMENTAL:YES command in the StarRC command file to enable

incremental extraction. Several iterations of ECO changes and successive incremental

extractions can be performed as long as

• The changes do not affect more than 50 percent of the nets

• The previous incremental extraction run has completed successfully

Chapter 5: Incremental Extraction

Running Incremental Extraction 5-11

Chapter 5: Incremental Extraction

Running Incremental Extraction 5-11

StarRC User Guide and Command Reference Version F-2011.06

Figure 5-3 Incremental Extraction Work Flow

Full Chip Extraction

Timing

Check

Clean?

YES

Incremental Extraction

Timing Tools

Layout Change

Updated

Full Chip Extraction

SIGNOFF

DEF or Milkyway

Data

Steps for Running Incremental Extraction

You can proceed with the incremental extraction flow shown in Figure 5-3 by following these

five steps:

1. Collect a complete chip database.

2. Perform a complete extraction.

See “Command File Example for Original Extraction” on page 5-12.

3. Perform a timing analysis.

4. If timing violations are found, make corrections in the database.

See “Command File Example for Incremental Extraction” on page 5-12.

5. Perform the complete extraction with INCREMENTAL:YES specified in the StarRC

command file.

Chapter 5: Incremental Extraction

Running Incremental Extraction 5-12

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Note:

Only the following commands can be changed between a full and incremental

extraction:

BLOCK MILKYWAY_DATABASE

TOP_DEF_FILE LEF_FILE

MACRO_DEF_FILE DEF_FILE

INCREMENTAL COUPLING_REPORT_FILE

INCREMENTAL_FORCE_DP COUPLING_REPORT_NUMBER

NETLIST_INCREMENTAL YES | NO

In a LEF/DEF flow, you can delete the old DEF file before running incremental extraction.

Command File Example for Original Extraction

The following StarRC command file is an example that can be used for your original

extraction. See Step 2 in “Steps for Running Incremental Extraction” on page 5-11.

BLOCK: original_top_block

MILKYWAY_DATABASE: design_name

TCAD_GRD_FILE: 90nm.ntxgrd

STAR_DIRECTORY:STAR

NETLIST_FILE:original_pre.spef

NETLIST_FORMAT:SPEF

Command File Example for Incremental Extraction

The following StarRC command file is an example that can be used for your incremental

extraction. See Step 4 in “Steps for Running Incremental Extraction” on page 5-11.

BLOCK:post-eco_top_block

MILKYWAY_DATABASE:design_name

TCAD_GRD_FILE:90nm.ntxgrd

STAR_DIRECTORY:STAR

NETLIST_FILE: original_post.spef

NETLIST_FORMAT: SPEF

INCREMENTAL: YES

Using the -clean Options

The StarRC ability to perform certain stages of extraction in parts is also possible when

using the incremental flow, and the behavior is similar to that of normal extraction. The use

of -cleanT, -cleanX, and -cleanN is permitted when performing an incremental

extraction, but this extraction is performed on the current loop of incremental extraction. If

prior stages have not been completed (that is, you specify -cleanX, but the translation

Chapter 5: Incremental Extraction

Running Incremental Extraction 5-13

Chapter 5: Incremental Extraction

Running Incremental Extraction 5-13

StarRC User Guide and Command Reference Version F-2011.06

stage was not performed), those incomplete stages are performed first. See Figure 5-4. For

a complete list of commands and their respective -clean options, see “Command List With

-clean Option Information” on page B-20.

To begin incremental extraction, add INCREMENTAL:YES in the command file and extract

using -clean. The combination of INCREMENTAL:YES and using -clean begins an iteration

of incremental extraction. The command file should point to the correct post-ECO database

and block. STAR_DIRECTORY should also point to the path of the previous extraction run.

Another incremental extraction iteration can begin only after the previous extraction run has

successfully completed.

Figure 5-4 Using -clean Options With Incremental Extraction

Translation -cleanT

Extraction -cleanX

Netlisting -cleanN

EXTRACTION

StarXtract -clean star_cmd

Iteration

loop N

Next incremental

loop, ensure that

INCREMENTAL:YES

is specified in the

star_cmd file.

To perform a normal

extraction, ensure that

INCREMENTAL:NO

is specified in the

star_cmd file.

Perform ECO changes

Database

To perform normal extraction and exit the incremental iteration loop, specify

INCREMENTAL:NO in the star_cmd file and use -clean to overwrite all the current information

in the STAR directory.

Incremental Extraction -undo Option

In some circumstances, certain ECO operations do not yield an improvement in results. In

this case, you might want to go back to the previous extraction result. You can “undo” a

previous extraction result using the following command-line option:

Chapter 5: Incremental Extraction

Running Incremental Extraction 5-14

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

% StarXtract -undo star_cmd

It is not possible to run the -undo command-line option after a non-incremental run because

there is nothing to undo. It is also not possible to run the -undo option twice consecutively

because the star directory is considered the result of a full run. An error message is issued

if you attempt this.

Using Distributed Processing

You can use distributed processing in an incremental extraction flow using the command

INCREMENTAL_FORCE_DP. Here are two typical command file scenarios:

Scenario 1

(better extraction run time)

Scenario 2

Pre ECO commands:

NUM_PARTS:N

Pre ECO commands:

NUM_PARTS:N

Post ECO commands:

NUM_PARTS:N

INCREMENTAL:YES

INCREMENTAL_FORCE_DP:YES

Post ECO commands:

NUM_PARTS:N

INCREMENTAL:YES

INCREMENTAL_FORCE_DP:NO

In scenario 1, the value specified for the

NUM_PARTS command for Pre ECO and Post

ECO must be the same.

Scenario 2 uses a single partition for Post ECO

processing.

Error Conditions and Warnings

There are several messages that can appear while you attempt to perform incremental

extraction.

ERROR:StarXtract

ERROR: Cannot perform undo on the first incremental run.

If StarRC finds no difference between the original block and the post-ECO block, the

following error message appears:

ERROR: StarXtract

ERROR: found zero difference between pre-ECO and post-ECO

layout, no ERROR: need to proceed for extraction.

ERROR: Please ensure that BLOCK: command is set to the correct

block ERROR: or that INCREMENTAL command is set correctly.

ERROR: Please re-run with -clean

Verify that the ECO changes were applied to the post-ECO block, or that the BLOCK

command is the correct post-ECO block name. It is also possible that the INCREMENTAL

setting was not set correctly. After the corrections have been made, use the -clean

command. Not using the -clean command can result in incorrect netlists being produced.

Chapter 5: Incremental Extraction

Incremental Netlist Examples 5-15

Chapter 5: Incremental Extraction

Incremental Netlist Examples 5-15

StarRC User Guide and Command Reference Version F-2011.06

Incremental Netlist Examples

There are two ECO scenarios in which an incremental netlist generated by StarRC can be

applied: when rerouting a net or when performing gate insertion. Examples of these

scenarios are shown in this section.

An incremental netlist satisfies the following two conditions:

• Any cross-couplings between ECO affected networks and non-ECO affected networks

are assumed to be exactly the same in the incremental parasitic file as in the original

parasitic file.

• The node numbers on RC networks of non-ECO affected networks are exactly the same

as before.

To simplify the description, assume that the ECO affected nets consist of ECO nets and their

adjacent neighbors.

The Scenario of Rerouting a Net

A generated incremental netlist consists of the changed net and its neighbors. Figure 5-6 on

page 5-18 illustrates all parasitics that are part of the incremental netlist. Assume one of the

internal nets, net W3, is rerouted. Note that special dangling coupling capacitances are put

into the netlist between re-extracted nets and non-extracted nets. The incremental netlist

looks like a partial full-chip netlist without the non-extracted nets. This scheme allows tools

like PrimeTime SI to annotate coupling capacitors after it restores saved results from a

full-chip analysis run.

The Scenario of Gate Insertion

Assume that a new inverter I34 is inserted on net W3 between I3 and I4. The two new nets

are called W3_a and W3_b. Figure 5-7 on page 5-20 illustrates all parasitics that are part of

the incremental netlist. The incremental netlist consists of the new nets and their neighbors.

Similar to scenario #1, dangling capacitors are generated in the netlist between ECO

affected nets and their neighbors.

Schematic Examples and Their Netlists

Two schematic and netlist examples, one pre-ECO and the other post-ECO, describe the

differences between the two full-chip netlists.

Consider a block of six-inverter chains with consecutive series nets coupled to one another.

The netlist in Figure 5-5 on page 5-16 reflects the pre-ECO full-chip netlist. For this scenario,

only one coupling capacitance between each pair of adjacent nets is shown.

Chapter 5: Incremental Extraction

Incremental Netlist Examples 5-16

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Figure 5-5 Pre-ECO Six-Inverter Chain Design and Netlist

NET 0 0:3

W5:3

NET W5

W5:2

W4:3

W4:2

W3:3

NET W4

W3:2

W2:3

NET W2

NET W3

NET W1

W1:2

NET I I:2

W2:2

W1:3

Coupling Capacitance

Chapter 5: Incremental Extraction

Incremental Netlist Examples 5-17

Chapter 5: Incremental Extraction

Incremental Netlist Examples 5-17

StarRC User Guide and Command Reference Version F-2011.06

Figure 5-5 is an example of a six-inverter chain design. This netlist represents the pre-ECO

full-chip netlist.

*D_NET I 31.5

*CAP

1 I 2.3

2 I:2 2.4

3 I:3 2.5

4 I:4 2.6

5 I1:A 2.7

6 I:2 W1:3 2.8

*RES

1 I I:2 2.9

2 I:2 I:3 3.0

3 I:3 I:4 3.1

4 I:4 I1:A 3.2

*END

*D_NET W1 26.2

*CAP

1 I1:Z 3.3

2 W1:2 3.4

3 W1:3 3.5

4 W1:4 3.6

5 I2:A 3.7

6 W1:3 I:2 2.8

7 W1:2 W2:3 4.7

*RES

1 I1:Z W1:2 3.8

2 W1:2 W1:3 3.9

3 W1:3 W1:4 4.0

4 W1:4 I2:A 4.1

*END

*D_NET W2 64.3

*CAP

1 I2:Z 4.2

2 W2:2 4.3

3 W2:3 4.4

4 W2:4 4.5

5 I3:A 4.6

6 W2:3 W1:2 4.7

7 W2:2 W3:3 4.8

*RES

1 I2:Z W2:2 4.9

2 W2:2 W2:3 5.0

3 W2:3 W2:4 5.1

4 W2:4 I3:A 5.2

*END

*D_NET W3 61.2

*CAP

1 I3:Z 5.2

2 W3:2 5.3

3 W3:3 5.4

4 W3:4 5.5

5 I4:A 5.6

6 W3:3 W2:2 4.8

7 W3:4 I4:A 6.1

*RES

1 I3:Z W3:2 5.8

2 W3:2 W3.3 5.9

3 W3:3 W3:4 6.0

4 W3:4 I4:A 6.1

*END

*D_NET W4 72.1

*CAP

1 I4:Z 6.2

2 W4:2 6.3

3 W4:3 6.4

4 W4:4 6.5

5 I5:A 6.6

6 W4:3 W3.2 5.7

7 W4:2 W5:3 6.7

*RES

1 I4:Z W4:2 6.8

2 W4:2 W4:3 6.9

3 W4:3 W4:4 7.0

4 W4:4 I5:A 7.1

*END

*D_NET W5 12.2

*CAP

1 I5:Z 7.2

2 W5:2 7.3

3 W5:3 7.4

4 W5:4 7.5

5 I6:A 7.6

6 W5:3 W4:2 6.7

7 W5:2 0:3 7.8

*RES

1 I5:Z W5:2 7.9

2 W5:2 W5:3 8.0

3 W5:3 W5:4 8.1

4 W5:4 I6:A 8.2

*END

*D_NET 0 25.2

*CAP

1 I6:Z 8.2

2 0:2 8.3

3 0:3 8.4

4 0:4 8.5

5 0 8.6

6 0:3 W5:2 7.8

*RES

1 I6:Z 0:2 8.9

2 0:2 0:3 9.1

3 0:3 0:4 9.2

4 0:4 0 9.3

*END

Note: The resistance and capacitance numbers are not real.

Chapter 5: Incremental Extraction

Incremental Netlist Examples 5-18

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Figure 5-6 Post-ECO Netlist of Six-Inverter Chain Design (Net Reroute)

NET 0 0:3

W5:3

NET W5

W5:2

W4:3

W4:2

W3:3

NET W4

W3:2

W2:3

NET W2

NET W3

NET W1

W1:2

NET I I:2

W2:2

W1:3

Coupling Capacitance

COUPLINGS FROM

NEIGHBORING NETS

TO NON-ECO AFFECTED

NETS

Chapter 5: Incremental Extraction

Incremental Netlist Examples 5-19

Chapter 5: Incremental Extraction

Incremental Netlist Examples 5-19

StarRC User Guide and Command Reference Version F-2011.06

Figure 5-6 is an example of a six-inverter chain design after an ECO has been performed on

net W3. The incremental netlist result contains the ECO-modified net reroute, as well as

neighboring nets coupling to the non-ECO modified net. Couplings from neighboring nets to

non-ECO affected nets are generated in the netlist as dangling couplings to be analyzed

incrementally by tools like PrimeTime SI.

*D_NET W2 64.3

*CAP

1 I2:Z 4.2

2 W2:2 4.3

3 W2:3 4.4

4 W2:4 4.5

5 I3:A 4.6

6 W2:3 W1:2 4.7

7 W2:2 W3:3 5.6

*RES

1 I2:Z W2:2 4.9

2 W2:2 W2:3 5.0

3 W2:3 W2:4 5.1

4 W2:4 I3:A 5.2

*END

*D_NET W3 61.2

*CAP

1 I3:Z 4.1

2 W3:2 6.2

3 W3:3 5.1

4 W3:4 3.8

5 I4:A 5.5

6 W3:3 W2:2 5.6

7 W3:2 W4:3 4.8

*RES

1 I3:Z W3:2 5.2

2 W3:2 W3:3 5.1

3 W3:3 W3:4 4.8

4 W3:4 I4:A 6.3

*END

*D_NET W4 72.1

*CAP

1 I4:Z 6.2

2 W4:2 6.3

3 W4:3 6.4

4 W4:4 6.5

5 I5:A 6.6

6 W4:3 W3:2 4.8

7 W4:2 W5:3 6.7

*RES

1 I4:Z W4:2 6.8

2 W4:2 W4:3 6.9

3 W4:3 W4:4 7.0

4 W4:4 I5:A 7.1

*END

Note: The resistance and capacitance numbers are not real.

Figure 5-7 shows a six-inverter chain design, after an ECO has been performed on net W3

with buffer insertion. The incremental netlist result contains the new nets W3_a and W3_b,

as well as all neighboring nets coupling to the ECO nets. Couplings from neighboring nets

to non-ECO affected nets are generated in the netlist as dangling couplings to be analyzed

incrementally by tools like PrimeTime.

Chapter 5: Incremental Extraction

Incremental Netlist Examples 5-20

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Figure 5-7 Post-ECO Buffer Insertion and Netlist of Six-Inverter Chain Design (Gate Insertion)

NET 0 0:3

W5:3

NET W5

W5:2

W4:3

W4:2

NET W4

W2:3

NET W2

NET W1

W1:2

NET I I:2

W2:2

W1:3

I34

W3_a:1 W3_b:1

Net W3_b

Coupling Capacitance

*D_NET W2 64.3

*CAP

1 I2:Z 4.2

2 W2:2 4.3

3 W2:3 4.4

4 W2:4 4.5

5 I3:A 4.6

6 W2:3 W1:2 4.7

7 W2:2 W3_b:3 5.6

*RES

1 I2:Z W2:2 4.9

2 W2:2 W2:3 5.0

3 W2:3 W2:4 5.1

4 W2:4 I3:A 5.2

*END

*D_NET W3_a 30.2

*CAP

1 I3:z 4.1

2 W3_a:1 6.2

3 I34:A 2.5

7 W3_a:1 W4:3 4.8

*RES

1 I3:Z W3_a:1 5.2

2 W3_a:1 I34:A 5.1

*END

*D_NET W3_b 30.2

*CAP

1 I34:Z 1.8

2 W3_b:1 3.8

3 I4:A 5.5

6 W3_b:1 W2:2 5.6

*RES

3 I34:Z 1.8

4 W3_b:1 I4:A 6.3

*END

*D_NET W4 72.1

*CAP

1 I4:Z 6.2

2 W4:2 6.3

3 W4:3 6.4

4 W4:4 6.5

5 I5:A 6.6

6 W4:3 W3_a:2 4.8

7 W4:2 W5:3 6.7

*RES

1 I4:Z W4:2 6.8

2 W4:2 W4:3 6.9

3 W4:3 W4:4 7.0

4 W4:4 I5:A 7.1

*END

Note: The resistance and capacitance numbers are not real.

6-1

Parasitic Extraction 6

This chapter contains the following sections:

•Extraction Overview

•SingleShot Extraction

•Extraction Commands

•Processing Commands

Chapter 6: Parasitic Extraction

Extraction Overview 6-2

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Extraction Overview

The commands documented in this chapter apply to all StarRC flows and determine how the

layout database of choice is processed and extracted and how the parasitics are reported.

Some of the commands described in this chapter are required to perform an extraction. If

you do not specify any of the optional commands in the command file or in the GUI Setup

notebook, StarRC sets the command option to its default.

SingleShot Extraction

The SingleShot Extraction feature of StarRC executes any combination of extraction/

analysis flows within a single StarRC run. SingleShot extraction takes full advantage of the

overlap between extraction and analysis and shares the extracted parasitics between all of

the flows. The amount of work StarRC must do is minimized. SingleShot extraction also

eases the burden of tracking many runs and consolidates the results into a centralized

location for convenient review. Within the StarRC GUI, the SingleShot Extraction Wizard

manages the commands dynamically, so that only those applicable to the selected flows are

displayed.

Chapter 6: Parasitic Extraction

SingleShot Extraction 6-3

Chapter 6: Parasitic Extraction

SingleShot Extraction 6-3

StarRC User Guide and Command Reference Version F-2011.06

The SingleShot Extraction form contains all the available commands for the selected flows.

All of the settings in the SingleShot form apply throughout the StarRC GUI, although they

might not be visible in every Setup form. The SingleShot Extraction form is available through

Setup > SingleShot. See Figure 6-1.

Figure 6-1 SingleShot Extraction Form

Chapter 6: Parasitic Extraction

SingleShot Extraction 6-4

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

As with the other Extraction Wizard forms, clicking OK or Apply sets the command options

for the StarRC run. A SingleShot extraction can be run using the Tech Form (File > Run).

See Figure 6-2.

Figure 6-2 Run Form

Chapter 6: Parasitic Extraction

Extraction Commands 6-5

Chapter 6: Parasitic Extraction

Extraction Commands 6-5

StarRC User Guide and Command Reference Version F-2011.06

Extraction Commands

There are several extraction commands shown in the Extraction tab in Figure 6-3. For details

about these commands, see Chapter 17, “StarRC Commands.”

Figure 6-3 Extraction Tech Form

Chapter 6: Parasitic Extraction

Processing Commands 6-6

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Processing Commands

There are several processing commands in the Processing tab shown in Figure 6-4. For

details about these commands, see Chapter 17, “StarRC Commands.”

Figure 6-4 Tech Fo r m

7-1

Rapid3D Field Solver 7

Rapid3D is a 3-D capacitance extraction tool that solves electrostatic equations using

statistical random-walk methods. Rapid3D is used in conjunction with StarRC to verify the

accuracy of StarRC results when very high levels of accuracy are desired.

The following sections describe Rapid3D:

•Introduction to Rapid3D Extraction

•Running Rapid3D

•Input and Output Files

•Trapezoidal Conductors

•Conductor Types

•Capacitance Types

•Controlling Accuracy and Runtime

Chapter 7: Rapid3D Field Solver

Introduction to Rapid3D Extraction 7-2

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Introduction to Rapid3D Extraction

Rapid3D extracts capacitance by solving the Laplace equations in 3-D. The input structures

are comprised of ideal conductors and dielectrics with fixed dielectric constants. Rapid3D

can handle layouts with millions of conductors and extract thousands of nets without any

restrictions on the number of metal or dielectric layers. The dielectric layers can be planar or

conformal.

Rapid3D considers all 3-D effects and the shielding effects of intervening conductors. It

accounts for the effects of process features such as complex dielectric structures, tapered

conductors and contacts, charge sharing with semiconductor devices, fringing fields, floating

metal (metal fill), density-based thickness variation, etch-vs-width variation, and spacing

variation.

You can control the accuracy and runtime of Rapid3D. In addition, this tool can run on a

single CPU or in distributed processing mode on a Load Sharing Facility (LSF), Gridware, or

a network of machines.

Running Rapid3D

You can invoke Rapid3D seamlessly within StarRC using the FSCOMPARE flow or the

FS_EXTRACT_NETS flow. Ta bl e 7-1 describes the differences between the flows.

Table 7-1 Comparison of Rapid3D Flows

FSCOMPARE flow FS_EXTRACT_NETS flow

Flow description Reports the differences between

the pattern-based extraction results

of StarRC and the random-walk

extraction results of Rapid3D

Extracts critical nets with Rapid3D

Command to invoke flow EXTRACTION: FSCOMPARE FS_EXTRACT_NETS

Default convergence

goal set by the

FSCOMPARE_OPTIONS

-perc_self command

0.5% 1.5%

Output files Generates the .fs_comptot and

.fs_compcoup output files, which

report the differences between the

pattern-based extraction results of

StarRC and the random-walk

extraction results of Rapid3D

Incorporates the extracted

capacitances into the resulting

netlist; does not generate

.fs_comptot and .fs_compcoup

report files

Chapter 7: Rapid3D Field Solver

Running Rapid3D 7-3

Chapter 7: Rapid3D Field Solver

Running Rapid3D 7-3

StarRC User Guide and Command Reference Version F-2011.06

In the .fs_comptot file, shown in Example 7-1, the values in the FS column represent the

capacitances calculated by Rapid3D; the percentages in parentheses represent the

corresponding statistical uncertainty in the Rapid3D results. The values in the xTract column

represent the capacitances calculated by StarRC using its default pattern-based extraction.

Example 7-1 .fs_comptot File

%@100fF %Diff AbsError(fF) FS(fF) xTract(fF) NetName

-0.17 -0.49% 0.0566781 11.5645 (0.5%) 11.5078 D7

0.12 0.55% 0.02676 4.89356 (1.2%) 4.92032 D23

0.08 0.24% 0.0278593 11.551 (0.5%) 11.5789 S7

-0.04 -0.18% 0.011445 6.49725 (1.0%) 6.4858 D22

You can customize Rapid3D extraction by specifying the options listed in Table 17-1 on

page 17-55 in the FSCOMPARE_OPTIONS statement of the star_cmd file.

Distributed Processing

During distributed processing, Rapid3D distributes the nets to be extracted among the

available cores. If the number of specified cores exceeds the number of nets to be extracted,

Rapid3D uses only the same number of cores as nets to be extracted to avoid using

unnecessary cores. Using distributed processing on small jobs that would only take a few

minutes is unlikely to be productive because of the startup time for the machines.

The distributed processing of Rapid3D can also tolerate machine failures. If a Rapid3D job

on one machine is lost during a run, Rapid3D continues to run on the remaining machines.

A Rapid3D process can be split across a combination of machines. For example, you can

split a single job across a mixture of Sun and Linux machines. You can also combine 64-bit

and 32-bit machines. However, if the job is too large for a 32-bit machine, you must use

64-bit machines.

To invoke distributed processing jobs on your compute farm, you must set the

FS_DP_STRING variable, which specifies the distributed processing method and job control

parameters. You can use the following methods to implement distributed processing:

•LSF System

•Gridware System

•General Network With a List of Machines

You must also specify the number of processors with the -np option to the

FSCOMPARE_OPTIONS statement. For example, to use four processors, use the following

statement in your star_cmd file:

FSCOMPARE_OPTIONS: -np 4

Chapter 7: Rapid3D Field Solver

Running Rapid3D 7-4

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

StarRC then invokes Rapid3D with the following command:

rapid3d -f rapid3d.tec -f rapid3d.des -f rapid3d.nets -np 4

LSF System

For an LSF system, you can specify the FS_DP_STRING variable as

• An environment variable before launching the tool. Be sure to enclose the LSF command

in single quotes because it might contain multiple arguments. For example,

% setenv FS_DP_STRING 'bsub -a amd64 -R "rusage[mem=5000]"'

• A statement in the star_cmd file. For example,

FS_DP_STRING: bsub -a amd64 -R "rusage[mem=5000]"

Gridware System

For a Gridware system, you can specify the FS_DP_STRING variable as

• An environment variable before launching the tool. Be sure to enclose the Gridware

command in single quotes because it might contain multiple arguments. For example,

% setenv FS_DP_STRING 'qsub -P bnormal -l "mem_free=1G mem_avail=1G"'

• A statement in the star_cmd file. For example,

FS_DP_STRING: qsub -P bnormal -l "mem_free=1G mem_avail=1G"

General Network With a List of Machines

For a general network with a list of machines, you can specify the FS_DP_STRING variable as

• An environment variable before launching the tool. Be sure to enclose the list in single

quotes because it might contain multiple arguments. For example,

% setenv FS_DP_STRING 'list mars jupiter uranus'

• A statement in the star_cmd file. For example,

FS_DP_STRING: list mars jupiter uranus

Note:

When using a general network with a list of host machines, each machine must be

available through a simple UNIX rsh command without a password.

Chapter 7: Rapid3D Field Solver

Input and Output Files 7-5

Chapter 7: Rapid3D Field Solver

Input and Output Files 7-5

StarRC User Guide and Command Reference Version F-2011.06

Notes on Distributed Processing

When using distributed processing, keep the following points in mind:

• The FS_DP_STRING variable does not specify the number of processors.

• If you specify the FS_DP_STRING variable as both an environment variable and a

star_cmd file statement, then the setting in the star_cmd takes precedence.

• The control parameters are site-specific; refer to your system administrator.

Licensing Requirement for Distributed Processing

You need one StarRC license to run up to four Rapid3D distributed processing jobs.

Input and Output Files

The Rapid3D input and output files are described in the following sections:

•Input Files

•Output File

Input Files

Rapid3D reads the following three input files that share a common syntax:

•Technology File (rapid3d.tec) – Contains the description of metal and dielectric layers,

including their z-coordinates.

•Design File (rapid3d.des) – Contains a description of the layout in the form of boxes, nets,

and net groups.

•Net File (rapid3d.nets) – Contains a list of nets to be extracted.

In the StarRC field solver extraction flow, these files are automatically created before running

Rapid3D. When running Rapid3D from the command line, these files must be specified in

the following order: rapid3d.tec, rapid3d.des, and rapid3d.nets.

Technology File

The technology file contains information about the metal and dielectric layers. You cannot

edit the technology file because it is encrypted in a binary format.

The technology file must be specified on the command line before the design file.

Chapter 7: Rapid3D Field Solver

Input and Output Files 7-6

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Design File

The design file contains the geometry of the nets in the netlist. It is written in an encrypted

binary format and is created during the StarRC field-solver flow. You cannot edit the design

file.

Net File

The net file contains a list of nets to be extracted. Each net is specified on a single line

preceded by the extract keyword and terminated with the XXend keyword, as shown in the

following syntax:

extract net_name XXend

If the net file does not contain any extract statements, then Rapid3D extracts all the nets.

To execute Rapid3D in distributed processing mode, include a dp_string statement in the

net file. Rapid3D submits the farm jobs using the command followed by the dp_string

keyword.

The following is an example of a net file:

extract net_A XXend

extract net_B XXend

dp_string bsub -q normal -o lsf.log -R "rusage[mem=1000]"

Output File

StarRC reports the following information about Rapid3D in the star_sum file:

• Rapid3D executable path, version, and build date

• Job completion status

•Runtime

• Memory usage

• Warning and error messages

• Distributed processing information

This information can help you to correct setup or design issues. Additional information such

the setting of job control parameters can be found in the rapid3d.log file.

Chapter 7: Rapid3D Field Solver

Trapezoidal Conductors 7-7

Chapter 7: Rapid3D Field Solver

Trapezoidal Conductors 7-7

StarRC User Guide and Command Reference Version F-2011.06

Trapezoidal Conductors

The metal layers with a trapezoidal cross section in the x-z and y-z planes are included in

the layer statements with side_tangent parameter in the technology file. The geometry for

the trapezoidal conductor is shown in Figure 7-1. The side_tangent parameter is a

dimensionless number that is the ratio of horizontal delta divided by one-half of the height of

the conductor. If the side_tangent parameter is positive, the trapezoid is smaller at the

bottom. If the side_tangent parameter is negative, the trapezoid is smaller at the top. The

side_tangent parameter is specified in the rapid3d.tec file.

Rapid3D calculates the capacitance and internally accounts for the trapezoidal shape of the

electrodes, as shown in Figure 7-1. Using trapezoidal electrodes increases the runtime of

Rapid3D.

Figure 7-1 Geometry for Trapezoidal Conductor

Conductor Types

Structures in Rapid3D are composed of conductors and dielectrics. Dielectrics are typically

read through the technology file. Conductors are composed of metal boxes or planar boxes

and are read from the design file. Boxes are specified using the x-, y-, and z-coordinates at

Chapter 7: Rapid3D Field Solver

Conductor Types 7-8

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

two opposite corners. Planar boxes are specified using the x- and y-coordinates at two

opposite corners, and the z-location and thickness come from the layer name specified in

the technology file.

Rapid3D uses the following conductor types:

•Nets

•Net Groups

•Ground Nets

•Fill Nets

Each type of conductor reports capacitance differently. Conductors are composed of

collections of metal boxes. All the metal boxes in a conductor are assumed to be connected

and at the same potential. The following sections describe the five types of conductors and

their reporting rules.

Nets

A net conductor is the most common general type of conductor. Random walks are started

only from nets and net groups. Rapid3D reports capacitances between nets and from nets

to all other types. Nets are created by placing metal boxes or planar boxes between a net

statement and an end statement. Net statements are specified in the encrypted design file

to describe and identify the nets.

Net Groups

A net group is a collection of nets assumed to be electrically connected and, therefore,

having the same potential. Rapid3D extracts the capacitance between nets in different net

groups but not between nets in the same net group. Net groups are specified in the

encrypted design file.

Ground Nets

If Dirichlet boundary conditions are used as the default, then the edges of the bounding box

are electrical ground planes that form a single net called ground. In addition, in the design

file, some nets may be identified as grounded. Rapid3D reports the capacitance from other

nets to ground, but because walks are not started from ground, the total capacitance of

ground is not reported.

Chapter 7: Rapid3D Field Solver

Capacitance Types 7-9

Chapter 7: Rapid3D Field Solver

Capacitance Types 7-9

StarRC User Guide and Command Reference Version F-2011.06

Fill Nets

Fill nets are used to model fill metal polygons in a chip. Fill metal consists of boxes inserted

into a metal layer to improve the planarity of the metal layer. A fill net is assumed to be

electrically floating—not connected to any circuit elements in the netlist.

The electronic potential at fill nets is effectively determined by setting the charge on the fill

net set to zero. Even though fill nets are not electrically connected, they can introduce

capacitive coupling effects between other nets.

The charge on a fill net is calculated as shown in Equation 7-1.

Equation 7-1 Calculation of Charge on a Fill Net

V1C1C0V1V2

–()C1C2

C0C1C2

-----------------------------------------------------------------

The effective capacitance at net 1 is calculated as shown in Equation 7-2.

Equation 7-2 Calculation of Effective Capacitance Between Fill Nets

Ceff

C1C0C1C2

C0C1C2

---------------------------------

The coupling capacitance between net 1 and net 2 is calculated as shown in Equation 7-3.

Equation 7-3 Calculation of Coupling Capacitance

CcC1C2

C0C1C2

--------------------------------

Capacitance Types

Rapid3D reports the following capacitances at a node:

• Total capacitance – The capacitance from the net to all other objects in the simulation.

• Coupling capacitance (xcap) – The capacitance between two nets that are not part of the

same net group.

Each capacitance type is reported in a separate section of the Rapid3D capacitance report.

Chapter 7: Rapid3D Field Solver

Boundary Conditions 7-10

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Boundary Conditions

Boundary conditions are applied at the six edges of the simulation domain. By default,

Rapid3D uses a Dirichlet boundary condition of 0 volts. This is equivalent to placing a

ground plane along each face of the simulation cube. These ground planes are connected

to the Rapid3D global ground net.

Note:

This is different from Raphael RC2 and RC3, which use a Neumann or reflecting

boundary condition at each external edge.

In general, the Dirichlet boundary condition used in Rapid3D causes the reported total

capacitance at a node that is higher than the Neumann boundary condition used in RC2 and

RC3. As the boundary is moved further from the simulated electrodes, the effect becomes

smaller.

You can select Neumann boundary conditions in Rapid3D by adding the -neuman_x and

-neuman_y options to the FSCOMPARE_OPTIONS statement in your star_cmd file.

The following example specifies the use of Neumann boundary conditions in both the x- and

y-directions:

FSCOMPARE_OPTIONS: -neuman_x -neuman_y

StarRC then invokes Rapid3D with the following command:

rapid3d -f rapid3d.tec -f rapid3d.des -f rapid3d.nets -neuman_x -neuman_y

You also can specify periodic boundary conditions on the x- or y-direction with the

-periodic_x and -periodic_y options to the FSCOMPARE_OPTIONS statement in your

star_cmd file. Periodic boundary conditions cause the random walks to wrap around to the

opposite side of the device. For example, a walk that exits the device at the positive x-side

reenters at the negative x-side of the device. Periodic boundary conditions are useful for

devices with repeated cells like RAM or CCD devices.

The following example specifies the use of periodic boundary conditions in both x- and

y-directions:

FSCOMPARE_OPTIONS: -periodic_x -periodic_y

StarRC then invokes Rapid3D with the following command:

rapid3d -f rapid3d.tec -f rapid3d.des -f rapid3d.nets

-periodic_x -periodic_y

You can specify a bounding box when using Neumann or periodic boundaries with the -bb

option to the rapid3d command. For more details, see Ta bl e 17-1 on page 17-55.

Chapter 7: Rapid3D Field Solver

Controlling Accuracy and Runtime 7-11

Chapter 7: Rapid3D Field Solver

Controlling Accuracy and Runtime 7-11

StarRC User Guide and Command Reference Version F-2011.06

Controlling Accuracy and Runtime

In Rapid3D, the runtime has an inverse quadratic dependency on the accuracy. For

example, reducing the accuracy tolerance by a factor of three (such as, from 3 percent to 1

percent) generally results in a ninefold increase in CPU time. The default accuracy tolerance

in Rapid3D is 1 sigma at 0.5 percent for total capacitance. This means that the error

incidence in total capacitance for 68 percent of the nets extracted is less than 0.5 percent.

You can change the default 0.5 percent for total capacitance convergence to a different value

using the -perc_self option in the FSCOMPARE_OPTIONS statement of your star_cmd file.

For example, to specify 1 percent as the requirement for total capacitance convergence, use

the following syntax in your star_cmd file:

FSCOMPARE_OPTIONS: -perc_self 1

In general, the runtime is proportional to the number of nets extracted. The runtime is also

dependent on the overall size of the layout (number of boxes or polygons). Increasing the

number of dielectric layers can also cause the runtime to increase because the number of

hops required for a walk to reach a conductor increases.

Specifying Convergence Goals

A net is considered to be convergent if it satisfies the following relations:

Ec < perc_self x C & for each Cij { Eij < abs_coup + Cij x perc_coup}

In this equation,

• Ec = estimated statistical error on the total net capacitance

• C = total net capacitance

• Cij = coupling capacitance from net i to a neighbor net j

• Eij = estimated statistical error on Cij

• Default of abs_coup = C x coup_cap_thresh

Small coupling capacitors can be very slow to converge. To determine the value of a

coupling capacitor between two electrodes A and B, a walk must start on electrode A and

end on electrode B. The smaller the coupling capacitor, the smaller the probability that this

happens, and a larger number of total walks is needed to obtain accurate statistics on the

coupling capacitor.

Chapter 7: Rapid3D Field Solver

Controlling Accuracy and Runtime 7-12

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

For example, if the total capacitance at a node is 1e-15 farads and a coupling capacitor to

the same node is 1e-18 farads, then 1000 more walks are needed to calculate the coupling

capacitance value. Therefore, extracting the coupling capacitor to the same accuracy as the

net total capacitance takes a 1000 times longer. Usually the largest capacitances are the

most important and converge the fastest in Rapid3D.

By default, Rapid3D does not check the percentage convergence of coupling capacitance.

However, you can force Rapid3D to check the percentage convergence of coupling

capacitance by using the -perc_coup option.

For example, to set the convergence of coupling capacitance to 10 percent, use the following

syntax in your star_cmd file:

FSCOMPARE_OPTIONS: -perc_coup 10

StarRC then invokes Rapid3D with the following command:

rapid3d -f rapid3d.tec -f rapid3d.des -f rapid3d.nets -perc_coup 10

By default, Rapid3D sets the threshold for convergence of coupling capacitance to 1 percent

of the total net capacitance. To change the default, use the -coup_cap_thresh option.

For example, to set the absolute convergence of coupling capacitance to 2 percent of the

total net capacitance, use the following syntax in your star_cmd file:

FSCOMPARE_OPTIONS: -coup_cap_thresh 2

Typically, it is not necessary to set coupling capacitance goals. If you do need to set them,

make sure you fully understand the convergence criteria because incorrectly setting

-perc_coup and -abs_coup can result in unnecessarily long runtimes.

Note:

There is no way to force Rapid3D to evaluate just one particular coupling capacitor of

interest. Coupling capacitors are evaluated in random order, based on where the random

walks start and end.

Specifying the Accuracy Goal

You can specify the accuracy of the extracted total capacitance without having to calculate

the convergence level in terms of the standard deviation. In this case, the tool automatically

chooses the appropriate convergence tolerance.

To specify convergence in this manner, you can set the -perc_accuracy and the

-perc_accuracy_confidence options. The default of the -perc_accuracy_confidence

option is 99.7%. For example, if you set -perc_accuracy to 5% and leave

-perc_accuracy_confidence at its default, the extracted total capacitance value is

Chapter 7: Rapid3D Field Solver

Controlling Accuracy and Runtime 7-13

Chapter 7: Rapid3D Field Solver

Controlling Accuracy and Runtime 7-13

StarRC User Guide and Command Reference Version F-2011.06

accurate to 5% with a confidence level of 99.7%. The 99.7% confidence interval about the

mean of a Gaussian distribution is 3σ. This is equivalent to setting -perc_self 1.67 (that

is, the standard deviation is 5% ÷ 3 = 1.67%).

Specifying the Consistency of Results

In a random walk solver such as Rapid3D, each net has a statistical error associated with

the result. If a design contains 1000 identical nets, then the extracted values vary somewhat

because of this error. The statistical error in Rapid3D follows a normal distribution. The

standard deviation of the distribution sigma (σ) is controlled by the -perc_self option.

For example, because the computed capacitance values follow the normal distribution, 68%

of the nets lie within one sigma of the correct value (μ); that is, they occur between μ–σ and

μ+σ, or within 2σ of each other. Thus, the number of nets consistent to within 2σ is 68%.

As an alternate way of setting the consistency, you can use the -perc_consistency and

-perc_of_nets_consistent options. Use these options to calculate a value for the

-perc_self option.

For example, to specify that 99.7% of the identical nets must have errors less than 1%, you

can use either of the following equivalent commands:

•rapid3d -perc_consistency 1 -perc_of_nets_consistent 99.7

•rapid3d -perc_self 0.167

Specifying the grids_per_meter Parameter

Rapid3D performs all geometric calculations using integers. Therefore, all geometries are

defined as integers in grid units. In the technology file, you can specify how many meters

each grid unit represents. It is important to specify a grid unit small enough to accurately

represent the geometry. Typically, you want to use about 100 grid units to represent the

smallest feature in your process, resulting in approximately one percent accuracy in the

geometry specification. Therefore, if you have a 90-nm process technology, you should

specify grids_per_meter 1e9 in the technology file so that each grid unit represents 1 nm.

The grids_per_meter parameter affects the runtime, with smaller grid units causing a

longer runtime. Therefore, while you could specify grids_per_meter 1e10 for the 90-nm

process for slightly better accuracy, the runtime would be typically twice as long as the

runtime with grids_per_meter 1e9.

Chapter 7: Rapid3D Field Solver

Controlling Accuracy and Runtime 7-14

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Specifying Pattern Matching for Symmetric Nets

Memory designs often contain thousands of identical or symmetric nets with the same

capacitance characteristics. Rapid3D uses a pattern matching process to identify these

nets, analyze only a single representative net, and copy the capacitance characteristics to

all matching nets. Using pattern matching can speed up the analysis of memory designs as

well as ensure the same capacitance values for identical or symmetric nets.

To enable pattern matching, specify the -match option in the FSCOMPARE_OPTIONS

statement.

8-1

Timing Analysis 8

This chapter includes the following sections:

•Timing Analysis Overview

•Net-Specific Modes

•Simulation Options in the StarRC Netlist

•Netlist Commands

Chapter 8: Timing Analysis

Timing Analysis Overview 8-2

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Timing Analysis Overview

The StarRC flow is a standard timing extraction intended to prepare raw parasitic output for

either post-layout timing analysis or for timing-driven design. This flow is shown in

Figure 8-1. The results of the extraction are exported into one of the parasitic formats. You

can execute the flow by writing a command file manually and providing it as an argument to

StarXtract or by invoking the GUI and filling in the Timing Wizard (choose Setup > Timing)

form. See Figure 8-2.

Figure 8-1 Timing Analysis

Milkyway

StarRC

LEF/DEF

[GDS]

SPF/SPEF

ANALYSIS: TIMING

GUI

SPICE_SUBCKT_FILE

star_cmd

NETS

SKIP_CELLS

STAR

Milkyway

CEL/FRAM XTR

Milkyway

PARA SBPF

Calibre

[GDS]

Chapter 8: Timing Analysis

Timing Analysis Overview 8-3

Chapter 8: Timing Analysis

Timing Analysis Overview 8-3

StarRC User Guide and Command Reference Version F-2011.06

Figure 8-2 Timing Wizard Form

database

type

The Timing Wizard shown in Figure 8-2 displays only the required and frequently used

options with the layout database type of choice. The full set of extraction options is available

through the SingleShot Extraction Wizard. Selecting OK or Apply in any of the Setup

notebook forms applies the command options to the extraction job. The current contents of

the Setup notebook can be exported to a file at any time by choosing File > Save. Once you

have specified all of the desired commands, you can execute the extraction by selecting OK

as shown in Figure 8-3.

Figure 8-3 Run Form

Clicking OK or Apply in this form starts the job. You can execute partial jobs by selecting only

the desired actions from the list. See “Selective Job Processing” on page 2-4 for more

information about the StarXtract execution flow.

Chapter 8: Timing Analysis

Net-Specific Modes 8-4

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Clean All removes all previous results in the STAR_DIRECTORY specified in the Setup

notebook. Selecting any of the options on this form instructs StarRC to clean and redo that

stage and any subsequent stages by deleting any previous results from the specified

STAR_DIRECTORY. Unless you click Clean All, StarRC attempts to use the previous results

for the Build HN stage.

Caution:

Using this clean feature in a directory where an extraction was already run causes all

previous results to be lost. Selecting Translate, xTractor, or Netlist has no effect if there

are no existing results.

When the Translate option is selected, the xTractor and Netlist options are automatically

selected, and every stage that follows the Translate DB stage are executed again. The clean

features have no effect on an empty STAR_DIRECTORY.

An example of commands you can use for a timing flow appears in “Timing Extraction/

Analysis” on page 13-2.

Net-Specific Modes

StarRC lets you specify a specific netlist mode for any net. This means that particular nets

can be generated in the netlist in different ways. Certain nets, such as signal or clock nets,

are required for netlist generation with full resistance and capacitance (RC) coupled

parasitics output for timing and crosstalk analysis during simulation. Other less important

nets might require a lesser degree of parasitic information in the netlist, such as lumped

capacitance only. To minimize netlist size and maximize simulation efficiency, you can

differentiate netlist modes for different types of nets.

Net-specific extraction modes allow for wildcard net selectivity so that you can specify a

group of nets without listing each net. To specify a netlist mode for a specific net, add the

following commands to the StarRC command file:

•NETLIST_SELECT_NETS

•NETLIST_TYPE

You can also specify that all unselected nets coupled to by selected nets be included in the

parasitic netlist, either with full parasitics or ideally. See the

NETLIST_COUPLE_UNSELECTED_NETS command. Unselected nets are all those nets that are

not specified in the NETLIST_SELECT_NETS command. To netlist unselected nets with a

specific mode, add the following command to the StarRC command file:

NETLIST_COUPLE_UNSELECTED_NETS

Chapter 8: Timing Analysis

Net-Specific Modes 8-5

Chapter 8: Timing Analysis

Net-Specific Modes 8-5

StarRC User Guide and Command Reference Version F-2011.06

Examples showing different ways to specify net-specific modes follow. See Chapter 17,

“StarRC Commands” for command details included in the following examples. In all cases,

the original extraction and netlist mode for the affected nets are retained.

Example 1

To netlist net1 as an R-only net and all other nets as RCc nets.

EXTRACTION:RC

NETS: *

COUPLE_TO_GROUND: NO

NETLIST_TYPE:R net1

Example 2

To output net1 and net2 as full RCc nets, and nets that couple to net1 and net2 nets as Cc

nets.

EXTRACTION:RC

NETS: *

COUPLE_TO_GROUND: NO

NETLIST_SELECT_NETS: net1 net2

NETLIST_COUPLE_UNSELECTED_NETS:COMPLETE

NETLIST_TYPE: Cc *

NETLIST_TYPE: RCc net1 net2

Example 3

Outputs to the netlist all nets whose names contain CLK* as RCc nets. Outputs to the netlist

all other nets in the NETLIST_SELECT_NETS command as Cc nets.

EXTRACTION:RC

NETS: *

COUPLE_TO_GROUND: NO

NETLIST_TYPE: Cc *

NETLIST_TYPE:RCc CLK*

Selective Netlist Creation

You can specify different netlist output (R, RCg, and so on) for specific nets in the same

extraction run. To do this, use the NETLIST_TYPE command because of its ability to accept

wildcards. The NETLIST_TYPE command is order-dependent so the last instance overrides

any previous instance.

Suppose the following commands are specified:

EXTRACTION: RC

NETLIST_TYPE: R NET*

NETLIST_TYPE: RCg NETA

Chapter 8: Timing Analysis

Simulation Options in the StarRC Netlist 8-6

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

With these settings, an RC extraction is performed on the entire design. However, net names

beginning with NET are generated in the netlist with R (resistance) only, except NETA, which

is generated in the netlist as RCg (resistance and capacitance lumped to ground).

Other netlist types include R, Cg, Cc, RCg, and RCc. For more details, see the

NETLIST_TYPE command.

Simulation Options in the StarRC Netlist

Circuit simulation options can be written directly in the StarRC generated netlist. This

eliminates the need for you to set simulation options explicitly depending on the parasitic

extraction tool settings used, and helps eliminate the possibility of double-counting or

omitting some parasitic capacitance and/or resistance. The required simulation options

based on parasitic extraction settings can be specified in a StarRC command file.

To write simulation options into the netlist, use the NETLIST_SIM_OPTIONS command. The

flow for this task is shown in Figure 8-4.

Figure 8-4 Flow Integration for Simulation Option Mapping

Hercules/Calibre

Layer

Mapping File

Process

File

StarRC

with Command File Option Mapping

Parasitic Netlist

SPICE Simulation

ready for simulation

Command file with

NETLIST_SIM_OPTIONS

specified.

Chapter 8: Timing Analysis

Netlist Commands 8-7

Chapter 8: Timing Analysis

Netlist Commands 8-7

StarRC User Guide and Command Reference Version F-2011.06

Netlist Commands

There are numerous netlist commands. They are found on the Netlist tab of the Tech Form

as shown in Figure 8-5. For a list of commands that affect netlisting, see Ta b l e B-1 on

page B-3.

Figure 8-5 Netlist Tech Form

Chapter 8: Timing Analysis

Netlist Commands 8-8

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

9-1

Noise Analysis 9

This chapter contains the following sections:

•Noise Analysis Overview

•Smart Decoupling of Coupling Capacitances

•Noise Analysis Commands

Chapter 9: Noise Analysis

Noise Analysis Overview 9-2

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Noise Analysis Overview

StarRC provides a fast, low-memory fully coupled chip extraction solution that serves as a

sound basis for detailed critical net noise analysis. This is shown in Figure 9-1. It offers

error-controlled on-the-fly reduction to limit processing resources, plus tools to filter net pairs

that are not susceptible to noise and netlisting features to keep the output manageable.

Figure 9-1 Noise Analysis Flow

Milkyway

StarRC

Milkyway

LEF/DEF

[GDS]

STAR SPEF

COUPLING

ANALYSIS: NOISE

XTR

CEL/FRAM

COUPLE_TO_GROUND: NO

REPORT SBPF

GUI

star_cmd

Calibre

[GDS]

SPF

From the cross-coupled parasitics database, StarRC can generate any of the netlist formats

or generate a coupling report file.

• A specific netlist format is specified using the NETLIST_FORMAT command.

• The COUPLING_REPORT_FILE command can be used to obtain a sorted list of the strongly

coupled nets for quick identification of nets most affected by the switching activity of their

neighbors.

You can change the value of COUPLE_TO_GROUND to YES following a cross-coupled extraction

and produce a decoupled netlist of any format directly from the existing internal parasitics

database. The value of this command can be changed from NO to YES to generate a

second netlist with all coupling capacitors grounded (decoupled). This second netlist is

generated only by executing the netlist stage with the clean option. To do this, you edit the

star_cmd file and run the following:

% StarXtract -cleanN star_cmd

You can alternatively use the GUI to run a noise analysis. See “Starting a Timing or Noise

Job” on page 10-3.

Chapter 9: Noise Analysis

Smart Decoupling of Coupling Capacitances 9-3

Chapter 9: Noise Analysis

Smart Decoupling of Coupling Capacitances 9-3

StarRC User Guide and Command Reference Version F-2011.06

Smart Decoupling of Coupling Capacitances

During extraction coupling capacitances exist on each net. For further work, you must know

which coupling capacitances need to be kept for netlist creation and those that are not

needed. The five conditions listed in Table 9-1 explain how the coupling capacitances are

filtered in subsequent extractions. When you do not use smart decoupling, all capacitances

are kept in the generated netlist.

Table 9-1 Five Conditions for Smart Decoupling

Condition1 Cc(net1_net2) < COUPLING_ABS_THRESHOLD

Condition2 Cc(net1_net2) < COUPLING_REL_THRESHOLD * TCAP_net1

Condition3 Cc(net1_net2) < COUPLING_REL_THRESHOLD * TCAP_net2

Condition4 Cc(net1_net2) < COUPLING_AVG_THRESHOLD * C_avg_net1

Condition5 Cc(net1_net2) < COUPLING_AVG_THRESHOLD * C_avg_net2

In the five conditions for smart decoupling,

• Cc(net1_net2) is the total coupling capacitance between net1 and net2

• TCAP_net1 is the total capacitance of net1

• TCAP_net2 is the total capacitance of net2

•C_avg_net1 is the average coupling capacitance on net1

•C_avg_net2 is the average coupling capacitance on net2

The COUPLING_THRESHOLD_OPERATION command specifies the use of AND filtering or OR

filtering of coupling capacitances.

• When AND filtering is specified by the COUPLING_THRESHOLD_OPERATION: AND

command, then a coupling capacitance is decoupled if the following operation is TRUE:

Condition1 AND (Condition2 AND Condition3) AND (Condition4 AND Condition5)

• When OR filtering is specified by the COUPLING_THRESHOLD_OPERATION: OR command,

then a coupling capacitance is decoupled if the following operation is TRUE:

Condition1 OR (Condition2 AND Condition3) OR (Condition4 AND Condition5)

For threshold checks, the total capacitance of a net includes all attached loading pin

capacitances but does not include intranet capacitance. Intranet capacitance is the

capacitance between one subnode of a net and another subnode of the same net.

Chapter 9: Noise Analysis

Noise Analysis Commands 9-4

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

For COUPLING_AVG_THRESHOLD checks, no defaults are assured. You need to set a percent

value for these additional checks to take place.

Noise Analysis Commands

There are several noise analysis commands shown in Figure 9-2. For a list of the noise

analysis commands, see the Noise column in Ta bl e B-1 on page B-3.

The Noise Report form lets you set commands specific to a noise analysis.

Figure 9-2 Noise Report Form

10-1

Graphical User Interface 10

This chapter covers running the StarRC tool in the following main sections:

•Graphical User Interface

•Files Needed to Run StarRC

•Starting StarRC Using the GUI

•Interface Reference

•Entering Information

•Creating a Mapping File in the GUI

Chapter 10: Graphical User Interface

Graphical User Interface 10-2

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Graphical User Interface

StarRC includes an easy-to-use, interactive graphical user interface (GUI) that provides an

environment for the extraction and analysis of physical designs.

Before starting the GUI, verify that all of the needed files are available. See “Files Needed to

Run StarRC” on page 10-2. To start the GUI, ensure that you are in the StarRC working

directory and enter the following:

% StarXtract -gui

Any StarRC extraction analysis can be configured and executed from the GUI. The GUI

interface also provides command selection for post-layout verification and analysis tools.

Additionally, every copy of StarRC includes a copy of the Milkyway layout viewer.

Files Needed to Run StarRC

Before starting, verify all the necessary files needed to run StarRC. These files are listed in

Table 10-1. Specify the file locations in your star_cmd file. These files must be available at

the specified location for StarXtract access.

Table 10-1 Files Needed to Run StarRC

File Definition

Design database Layout database in one of the following formats: Milkyway, LEF/DEF,

Milkyway XTR, *.AGF (Calibre).

star_cmd ASCII file containing StarRC commands that controls extraction functions.

See Example 10-1.

TCAD_GRD_FILE File containing the modeled layers of a circuit. See the TCAD_GRD_FILE

command.

MAPPING_FILE File containing physical layer mapping information between the input

database and the specified TCAD_GRD_FILE. The file matches every TCAD

process layer to a corresponding layout database layer. See also the

MAPPING_FILE command.

Chapter 10: Graphical User Interface

Starting StarRC Using the GUI 10-3

Chapter 10: Graphical User Interface

Starting StarRC Using the GUI 10-3

StarRC User Guide and Command Reference Version F-2011.06

Example 10-1 shows a star_cmd file. For detailed information about individual commands,

see Chapter 17, “StarRC Commands.”

Example 10-1 A star_cmd File

BLOCK : toprt

MILKYWAY_DATABASE : xtdesign

TCAD_GRD_FILE : example.nxtgrd

MAPPING_FILE : xt.mapping

************ Do NOT change the lines above **************

SKIP_CELLS : !*

NETLIST_FORMAT : SPEF

NETLIST_FILE : toprt.SPEF * default is toprt.spf

STAR_DIRECTORY : ./star * default is star

COUPLE_TO_GROUND: NO * default is YES

The Working Directory

The working directory contains the files needed to run StarRC. StarXtract is invoked at

working directory, the input files, intermediate files and resulting files can be at any location

including the working directory. The location of these files is specified in command file. You

specify the location in the GUI or on the command line. The files listed in the following table

are required.

Starting StarRC Using the GUI

This section explains how to start a timing, a noise, or a combined timing and noise analysis

(SingleShot) in StarRC.

Starting a Timing or Noise Job

Before starting timing or noise analysis, verify that all the necessary files are available. See

“Files Needed to Run StarRC” on page 10-2.

To start a StarRC timing or noise analysis, set up the files and save the collection in a unique

file with the following steps:

1. In your working directory, enter StarXtract -gui.

2. Select the type of analysis you want to run.

• For a timing analysis, choose Setup > Timing.

• For a noise analysis, choose Setup > Noise. The Timing or Noise Wizard appears.

Chapter 10: Graphical User Interface

Starting StarRC Using the GUI 10-4

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

3. Specify the type of input database you are supplying.

Select Milkyway, Lef/Def, Hercules, or Calibre. See Figure 10-1.

Figure 10-1 Select Input Database

Select the type of input database

4. Enter the command information as needed for the analysis.

The commands needed to run a timing or noise analysis are included in the wizard form

in their default setting. You can alter the defaults or accept them at their default. All

commands shown in red in the interface are required.

5. After adding the command information to the Wizard, click OK.

6. Specify the layer mapping file.

Each analysis that you run must contain a layer mapping file. The layer mapping file

should be present in your working directory.

Choose Setup > Layer Mapping.

If you do not have a layer mapping file, see “Creating a Mapping File in the GUI” on

page 10-20.

7. Format the StarRC output file a timing or noise run bu doing one of the following:

• For a timing analysis, choose Timing > Netlist. The Timing Netlist Form appears.

• For a noise analysis, choose Noise > Report. The Noise Report form appears.

8. To save the settings and run the StarRC analysis at a later time, choose File > Save.

The Save Tech File window appears. In the File name field, enter a unique name for the

analysis you have just prepared. Name the file using a unique name. This becomes the

star_cmd file for a subsequent analysis.

9. To run a analysis, choose File > Load.

Enter the unique run tile name in the File name field.

10. Choose File > Run. The Run Form appears.

The default behavior of StarRC is to start with the last unfinished module task. The

Translate, xTractor, and Netlist modules or stages are consecutive. When restarting a

analysis, select the module that follows the last finished module as shown in the log file.

Chapter 10: Graphical User Interface

Starting StarRC Using the GUI 10-5

Chapter 10: Graphical User Interface

Starting StarRC Using the GUI 10-5

StarRC User Guide and Command Reference Version F-2011.06

Figure 10-2 Run Form

11. Name the file using a unique name. This becomes your star_cmd file for your

subsequent analysis.

12. Click OK as shown in the run form in Figure 10-2.

Run Form Selection Description

OK Executes StarRC analysis and closes the Run Form.

Cancel Cancels and closes the Run Form.

Apply Starts the analysis while leaving the Run Form open.

Clean All Removes previously specified file settings and starts

StarRC analysis. (This is the same as specifying -clean

on the command line.)

Translate Starts the StarRC analysis in the Translate module.

xTractor Starts the StarRC analysis in the xTractor module.

Netlist Starts the StarRC analysis in the Netlist module.

When the StarRC analysis is complete, “done” is shown in the run log. To see the complete

contents of the run log, open it in your UNIX working directory.

Chapter 10: Graphical User Interface

Starting StarRC Using the GUI 10-6

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Starting a SingleShot Job

All StarRC command options are global throughout the GUI, so even though not all of the

options are visible on the Wizard forms, they still contain the values shown in the main

window (choose Setup > SingleShot). Command option settings that do not apply to the

currently selected flows are ignored.

• The GUI entry fields display the default upon startup, if applicable.

• Commands in red type are required.

• Command option settings that do not apply to the currently selected flows are ignored.

To start a SingleShot analysis, perform the following steps:

1. In your working directory, enter

$ StarXtract -gui.

2. Choose Setup > SingleShot.

The Tech Form appears.

3. Select the input database type from the Tech Form as shown in Figure 10-3.

Figure 10-3 Select Database Type on Tech Form

Select input database type

Chapter 10: Graphical User Interface

Starting StarRC Using the GUI 10-7

Chapter 10: Graphical User Interface

Starting StarRC Using the GUI 10-7

StarRC User Guide and Command Reference Version F-2011.06

Each tab on the Tech Form contains lists of options. See Figure 10-4.

Figure 10-4 Tech Fo r m Ta b s

Tech

Form

tabs

4. Select each tab, and specify the appropriate commands for your run. Commands that are

required are listed in Table 10-2.

Table 10-2 Required Commands

Tech Form Tabs Required Commands

Database MILKYWAY BLOCK, MILKYWAY_DATABASE

LEF/DEF LEF_FILE, TOP_DEF_FILE

Hercules BLOCK, MILKYWAY_DATABASE, MILKYWAY_EXTRACT_VIEW

Calibre BLOCK, CALIBRE_RUNSET, CALIBRE_QUERY_FILE,

CALIBRE_DEVTAB, CALIBRE_AGF, CALIBRE_AGF_LAYER_MAP,

CALIBRE_AGF_NETLIST, CALIBRE_AGF_CELL_EXTENTS,

CALIBRE_AGF_NAME_MAP, CALIBRE_CELLS_PORTS,

CALIBRE_IXF_FILE, CALIBRE_NXF_FILE

IC Validator ICV_RUNSET_REPORT_FILE

EXTRACTION TCAD_GRD_FILE, MAPPING_FILE

Xref (Hercules Only) EVACCESS_DIRECTORY, COMPARE_DIRECTORY

Note:

For SingleShot, Timing and Noise are automatically selected.

5. If you would like to save the command settings without running a StarRC analysis,

choose File > Save.

Name the file using a unique name. This becomes your star_cmd file for your subsequent

analysis.

Chapter 10: Graphical User Interface

Interface Reference 10-8

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

6. To start the SingleShot analysis, choose File > Run.

The Run Form appears.

The default behavior of StarRC is to start with the last unfinished module task. The

Translate, xTractor, and Netlist modules (or stages) are consecutive. When restarting an

analysis, select the module that follows the last finished module as shown in the log file.

7. When the StarRC analysis is complete, the run log prints the word “done.” To see the

complete contents of the run log, open it in your UNIX working directory.

Interface Reference

This section shows the various menus and dialog boxes available to you in StarRC.

Control Window

The control window opens when you invoke the GUI executable. It contains the menus you

use to configure and execute your StarRC analysis. The control window is shown in

Figure 10-5.

Figure 10-5 StarRC Control Window

Chapter 10: Graphical User Interface

Interface Reference 10-9

Chapter 10: Graphical User Interface

Interface Reference 10-9

StarRC User Guide and Command Reference Version F-2011.06

File Menu

The File menu shown in Figure 10-6 is on the Control Window. The File menu lists

commands that enable you to load the command file and start your StarRC analysis.

Figure 10-6 File Menu

Table 10-3 explains the file menu options.

Table 10-3 File Menu Options

File menu command Description

Run Runs StarRC analysis using the loaded file.

Cancel Cancels a analysis that is currently running. Intermediate files

remain in the working or “star” directory for your inspection. The

next run can be started after you have used the intermediate files

or specify a run “clean” to begin again with unprocessed files.

Load Opens the Load Tech File window so you can choose files to be

loaded into the StarRC information.

Clear Opens the Clear Technology Options window. This resets every

field to its default. It is helpful to use this command when you are

building a command file with user-specific commands.

Save Opens the Save Technology File window. Specify the technology

files to be saved in the file name field. All the commands you have

entered are contained and stored in the file name. The file is

saved in the working directory.

Quit Exits the StarRC GUI. Any process currently running in the

StarRC GUI is canceled

Chapter 10: Graphical User Interface

Interface Reference 10-10

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Setup Menu

The Setup menu shown in Figure 10-7 is on the Control Window. The Setup menu lists three

different types of StarRC runs (Timing, Noise, and SingleShot) that open forms which enable

you to enter the command options for your desired run. The options listed in the Setup menu

are explained in Table 10-4.

Figure 10-7 Setup Menu

Table 10-4 Setup Menu Options

Setup Menu Command Description

Timing Opens the Timing Wizard window enabling you to prepare to generate a

netlist specifically for a timing analysis. See Figure 10-8. This differs from the

Timing menu. The Timing Menu is shown on page 10-14.

Noise Opens the Noise Wizard window enabling you to generate a netlist for a

crosstalk or noise analysis.

SingleShot Opens the Tech Form window enabling you to generate a netlist specifically

for a combined timing and noise analyses.

Choose the type of database input from Milkyway, LEF/DEF, Hercules, and

Calibre.

Multiple tabs let you set commands and options specific to Database,

Extraction, Processing, Netlist, Noise, Field Solver, Simulation, and Xref

choices. All unused commands remain set to StarRC default settings. For

command details, see Chapter 17, “StarRC Commands.”

Layer Mapping Opens the specified mapping file so that you can alter its contents. A valid

mapping file must have been specified in Timing, Noise, or Single Shot form

before it can be opened with this interface. Alternatively, you can create a

mapping file by specifying a valid TCAD_GRD_FILE in one of the analysis

forms.

Chapter 10: Graphical User Interface

Interface Reference 10-11

Chapter 10: Graphical User Interface

Interface Reference 10-11

StarRC User Guide and Command Reference Version F-2011.06

Setup > Timing

The Setup > Timing command is on the Control Window. When you choose this menu

option, the Timing menu Wizard appears. As shown in Figure 10-8, the command lets you

specify StarRC commands and options for preparing parasitic netlist for timing analysis.

Figure 10-8 Setup > Timing Wizard (Top Portion)

Choose:

Milkyway

LEF/DEF

Hercules

Calibre

ICV

Chapter 10: Graphical User Interface

Interface Reference 10-12

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Setup > Noise

The following Noise menu is on the Control Window. Setup > Noise, as shown in

Figure 10-9, allows you to prepare a parasitic netlist for noise analysis.

Figure 10-9 Setup > Noise Wizard (Top Portion)

Chapter 10: Graphical User Interface

Interface Reference 10-13

Chapter 10: Graphical User Interface

Interface Reference 10-13

StarRC User Guide and Command Reference Version F-2011.06

Setup > Single Shot

When you choose Setup >Single Shot, a Tech Form appears as shown in Figure 10-10. The

Tech Form window lets you generate a netlist for both timing and noise analyses.

Figure 10-10 Setup > Single Shot Tech Form

Chapter 10: Graphical User Interface

Interface Reference 10-14

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Setup > Layer Mapping

The Setup > Layer Mapping menu, as shown in Figure 10-11, is on the Control Window. This

command opens the specified mapping file for modification. To create a mapping file, see

“Creating a Mapping File in the GUI” on page 10-20.

Figure 10-11 Setup > Layer Mapping

Timing Menu

The Timing menu is on the Control window. When you choose Timing > Netlist, the Timing

Netlist form appears.

Chapter 10: Graphical User Interface

Interface Reference 10-15

Chapter 10: Graphical User Interface

Interface Reference 10-15

StarRC User Guide and Command Reference Version F-2011.06

The Timing Netlist form is shown in Figure 10-12. This form enables you to generate an

output timing analysis. See “Setup > Timing” on page 10-11. For information about each

command and available options, see Chapter 17, “StarRC Commands.”

Figure 10-12 Top Portion of Timing Netlist Form

Noise Menu

When you choose Noise > Report, from the Noise menu as shown in Figure 10-13, the

Noise Report Form as shown in Figure 10-14 appears.

Figure 10-13 Noise Menu

The Noise report form enables you to enter options to generate output files from the noise

analysis.

Chapter 10: Graphical User Interface

Interface Reference 10-16

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Figure 10-14 Noise Report Form

Viewer Menu

The Viewer menu, as shown in Figure 10-15, features commands that let you access the

Milkyway Viewer with StarRC.

Figure 10-15 Viewer Menu

Table 10-5 Commands for Accessing the Milkyway Viewer with StarRC

Menu Command Description

Prepare Viewer Data StarXtract prepares the graphical layout data in the star directory from the

details of the loaded star command file.

Launch Viewer Runs an instance of Milkyway and opens the specified block of layout

design (read-only) from the loaded star_cmd file.

Close Viewer Closes Milkyway viewer.

Query Net Invokes a dialog box for querying nets. The filter provided accepts the

wildcard asterisk (*) and question mark (?).

For each net, the details are shown in the right pane. The top edit box

shows the net detail after the node information has been filtered out.The

net’s node names are listed in the bottom-left list box in the right pane.

The bottom-right list box provides the selected node detail. To show the

node detail, either double-click a node name or select a node name and

click the Show node details button. The viewer zooms to the bounding box

of the node. (You cannot do this from a Milkyway window. It must be done

from the viewer.)

Query Device Invokes a dialog box for querying devices. The filter provided accepts the

wildcard asterisk (*) and question mark (?).

For each device, the details are shown in the right pane. The top edit box

shows the device detail after the node information has been filtered out.

For each device, the details are displayed in the right pane. Among the

device details listed are any port instances (and their net names) to which

this device is connected.

Probe Text Opens Probe Text Window.

Chapter 10: Graphical User Interface

Entering Information 10-17

Chapter 10: Graphical User Interface

Entering Information 10-17

StarRC User Guide and Command Reference Version F-2011.06

Entering Information

This section covers the various types of entries and actions the StarRC GUI enables. See

“StarRC Command File Conventions” on page 2-14. For information about specific

command options found in the forms, see Chapter 17, “StarRC Commands.”

Entry Fields

You can set commands in the StarRC GUI by filling in the entry fields. The StarRC GUI has

several types of entries, as shown in Figure 10-16.

Chapter 10: Graphical User Interface

Entering Information 10-18

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Figure 10-16 Available Entry Field Types

Single file entry

Multiple entry

Single file entry (with Browse capability)

Multiple file entry

See Also

•MODE: 400

Chapter 17: StarRC Commands

AUTO_RUNSET 17-3

Chapter 17: StarRC Commands

AUTO_RUNSET 17-3

StarRC User Guide and Command Reference Version F-2011.06

AUTO_RUNSET

Automatically performs the necessary modifications internally for the separation of device

layers based on device definitions in the LVS rule file.

Syntax

AUTO_RUNSET: NO | YES

Arguments

Argument Description

NO Processes device layers directly from the LVS database without

any detection or modification of layer separation.

This is the default.

YES Enables automatic device layer separation for necessary devices

such as MOS devices and capacitors. Generates the

corresponding statements for such devices by separating layers

based on IGNORE_CAPACITANCE settings.

Description

Normally, StarRC utilizes device extraction data from various LVS flows such as IC Validator,

Hercules, and Calibre for device-level parasitic extraction. To ensure accurate extraction

results, a rule file for StarRC parasitic extraction flows as well as device extraction and LVS

flows must abide by the following conventions:

• MOS device and capacitor terminal layers must be distinct from the routing layers that

form those terminal layers, and no polygon overlap should occur between those layers.

This ensures that StarRC properly excludes all intradevice capacitances that are

represented by device models during simulation.

• All contacts must connect exactly two physical layers to ensure uniformity with the

physical processes as defined in the StarRC ITF file.

To satisfy these conventions required by the StarRC device-level extraction flow, the LVS

rule files must be updated. If you specify the AUTO_RUNSET command, StarRC internally

performs the necessary modifications to your LVS rule file automatically, based on device

definitions in the LVS rule file.

Chapter 17: StarRC Commands

AUTO_RUNSET 17-4

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Example

The following syntax shows a typical Calibre rule file that uses the polysilicon interconnect

layer directly as the MOS gate terminal layer:

gate = poly AND diff

gatenw = gate NOT nwell

ngate = gatenw AND nplus

DEVICE MN(n) ngate poly (G) ndiff (S) ndiff (D) psub (B)

In this example, the interconnect layer poly itself serves as the gate terminal layer, while

ngate serves as the unconnected recognition (seed) layer. Since the terminal layer

derivations violate StarRC's assumption that the gate terminal layer represents only the gate

area, StarRC erroneously ignores the capacitance for portions of poly that do not serve as

part of the gate, that is, all capacitance between the poly interconnect and the device

diffusions. StarRC then generates the following instructions for the extraction engine to

ignore intradevice capacitance:

IGNORE_CAPACITANCE poly ndiff

IGNORE_CAPACITANCE poly psub

You can solve this problem by using the AUTO_RUNSET command, which performs internal

layer separation operations to differentiate the poly serving as the gate terminal from the

poly remaining as the routing layer.

Note:

The AUTO_RUNSET command can be used only if the recognition layer, which is ngate in

this example, exists in the input physical database.

See Also

•IGNORE_CAPACITANCE

Chapter 17: StarRC Commands

BLOCK 17-5

Chapter 17: StarRC Commands

BLOCK 17-5

StarRC User Guide and Command Reference Version F-2011.06

BLOCK

Defines the layout block name that is to be extracted.

Syntax

BLOCK: block_name

Arguments

Argument Description

block_name The layout name of the block to be extracted.

Default: none

Description

For Milkyway gate-level place and route designs, this option is mandatory. Valid arguments

are top-level blocks or fully placed and routed macro blocks that exist in the

MILKYWAY_DATABASE library.

For LEF/DEF gate-level designs, this option is invalid. The block to be extracted is

determined by the DESIGN keyword in the TOP_DEF_FILE file argument.

For Hercules gate-level or device-level flows, this option is mandatory. Valid arguments for

this flow are dependent on the settings of XREF and CELL_TYPE. With CELL_TYPE:LAYOUT,

which is the default, valid arguments are any cell that exists in the WRITE_EXTRACT_VIEW

library from Hercules. With CELL_TYPE: SCHEMATIC and XREF:YES or XREF:COMPLETE, valid

arguments are any valid equivalence point from Hercules compare.

For Calibre gate-level or device-level flows, this option is mandatory. Valid arguments for this

flow are dependent on the settings of XREF and CELL_TYPE. With CELL_TYPE: LAYOUT,

which is the default, valid arguments are any cell that exists in the annotated GDSII file and

layout netlist file (.nl). With CELL_TYPE:SCHEMATIC and XREF: YES, valid arguments are any

valid HCELL from Calibre compare (.ixf).

Example

This example specifies INT4 as the block to be extracted:

BLOCK: INT4

To override the BLOCK statement for a particular run, you can specify the StarXtract

command line option -b.

% StarXtract -b SMALLARRAY

Chapter 17: StarRC Commands

BLOCK 17-6

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

As shown in the previous example, specifying the -b option causes StarRC to use

SMALLARRAY as the block to extract rather than the block that is defined in the command

file. The command file is not changed, and the override exists for that run only.

See Also

•CELL_TYPE

•MILKYWAY_DATABASE

•MILKYWAY_EXTRACT_VIEW

•TOP_DEF_FILE

•XREF

Chapter 17: StarRC Commands

BLOCK_BOUNDARY 17-7

Chapter 17: StarRC Commands

BLOCK_BOUNDARY 17-7

StarRC User Guide and Command Reference Version F-2011.06

BLOCK_BOUNDARY

Defines a boundary for the block specified by BLOCK.

Syntax

BLOCK_BOUNDARY: x1 y1 x2 y2 [... xn yn]

Arguments

Argument Description

x1 The first x-coordinate in database units

y1 The first y-coordinate in database units

x2 The second x-coordinate in database units

y2 The second y-coordinate in database units

Description

The BLOCK_BOUNDARY command defines a boundary for the block specified by BLOCK when

you use the RING_AROUND_THE_BLOCK command for in-context approximation.

BLOCK_BOUNDARY is required when RING_AROUND_THE_BLOCK is specified for a LEF/DEF

flow. BLOCK_BOUNDARY information is used by StarRC to build the in-context routing

approximation rings for preplacement block noise analysis.

Specify the coordinates in database units, not microns. You can specify an arbitrary number

of boundary points. Two points (x1, y1)(x2, y2) define a rectangular block boundary. If you

specify more than two points, this specifies a rectilinear, or nonrectangular, block boundary.

The points you specify must be in counterclockwise order around the boundary of the block.

You can specify a closing point, but it is not required. This command and coordinates can be

specified only once in the StarRC command file.

It is not necessary to use BLOCK_BOUNDARY when the database is Milkyway, because the

boundary information can be read directly. However, if specified in a Milkyway flow, the

BLOCK_BOUNDARY command overrides the internal database value.

Example

The following example shows how to specify a block boundary with four points:

BLOCK_BOUNDARY: 0 0 269.6 0 269.6 137.6 0 137.6

Chapter 17: StarRC Commands

BLOCK_BOUNDARY 17-8

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

If the following error message appears, you should provide at least four coordinates of the

block boundary irrespective of the shape in counterclockwise direction from the DEF file in

database units to the BLOCK_BOUNDARY command:

ERROR: BLOCK_BOUNDARY must have at least 4 points

See Also

•BLOCK

•RING_AROUND_THE_BLOCK

Chapter 17: StarRC Commands

BUS_BIT 17-9

Chapter 17: StarRC Commands

BUS_BIT 17-9

StarRC User Guide and Command Reference Version F-2011.06

BUS_BIT

Specifies the character or pair of characters that defines the bus bit delimiter during

extraction and netlist creation.

Syntax

BUS_BIT: {} | [] | () | <> | : | .

Arguments

Argument Description

string Specifies the character set that defines the bus bit delimiter

during extraction and netlisting; do not insert spaces between the

characters in the string

Default: Database BUSBIT value

Description

The BUS_BIT command specifies the character or pair of characters that defines the bus bit

delimiter during extraction and netlist creation.

The value of this option affects net selection and the Standard Parasitic Exchange Format

(SPEF) *BUS_DELIMITER header statement that is read by follow-on tools. Any literal

occurrence of these characters in a net or instance name should be escaped during net

selection; attempting to use an illegal delimiter results in an error.

For a LEF/DEF database, the BUS_BIT characters are defined by the LEF/DEF default

specification or database definition of the BUSBITCHARS keyword in the LEF/DEF

database.

This command does not do character substitution in the output netlist; it affects only

selection and escaping.

The BUS_BIT command does not define the bus bit character in the final netlist. To make this

change in the netlist, you must either change the input file or post process the netlist with a

script.

See Also

•NETS

Chapter 17: StarRC Commands

CALIBRE_LVS_DEVICE_TYPE_CAP 17-10

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

CALIBRE_LVS_DEVICE_TYPE_CAP

Identifies user-defined CAP devices.

Syntax

CALIBRE_LVS_DEVICE_TYPE_CAP: list_of_C_devices

Arguments

Argument Description

list_of_C_devices List of user-defined CAP devices

Description

This command identifies user-defined capacitors as CAP devices.

The list_of_C_devices argument follows the case-sensitivity set by the CASE_SENSITIVE

command and must use a layout name. Using schematic names might cause conflicts in

certain situations.

Example

CALIBRE_LVS_DEVICE_TYPE_CAP: cap_ss

See Also

•CALIBRE_LVS_DEVICE_TYPE_MOS

•CALIBRE_LVS_DEVICE_TYPE_RES

•CALIBRE_OPTIONAL_DEVICE_PIN_FILE

Chapter 17: StarRC Commands

CALIBRE_LVS_DEVICE_TYPE_MOS 17-11

Chapter 17: StarRC Commands

CALIBRE_LVS_DEVICE_TYPE_MOS 17-11

StarRC User Guide and Command Reference Version F-2011.06

CALIBRE_LVS_DEVICE_TYPE_MOS

Identifies user-defined MOS devices.

Syntax

CALIBRE_LVS_DEVICE_TYPE_MOS: list_of_M_devices

Arguments

Argument Description

list_of_M_devices List of user-defined MOS devices

Description

This command identifies user-defined MOS devices.

The list_of_M_devices argument follows the case-sensitivity set by the CASE_SENSITIVE

command and must use a layout name. Using schematic names might cause conflicts in

certain situations.

Example

CALIBRE_LVS_DEVICE_TYPE_MOS: nmos_ss

See Also

•CALIBRE_LVS_DEVICE_TYPE_CAP

•CALIBRE_LVS_DEVICE_TYPE_RES

•CALIBRE_OPTIONAL_DEVICE_PIN_FILE

Chapter 17: StarRC Commands

CALIBRE_LVS_DEVICE_TYPE_RES 17-12

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

CALIBRE_LVS_DEVICE_TYPE_RES

Identifies user-defined resistors as RES devices and marks the device terminal layers for

recognition by the WIDE_DEVICE_TERM_RESISTANCE command.

Syntax

CALIBRE_LVS_DEVICE_TYPE_RES: list_of_R_devices

Arguments

Argument Description

list_of_R_devices List of user-defined RES devices

Description

The CALIBRE_LVS_DEVICE_TYPE_RES statement identifies user-defined resistors as RES

devices and marks the device terminal layers for recognition by the

WIDE_DEVICE_TERM_RESISTANCE command.

Example

In the following example, the rp_sio and pwr_rm1 devices defined in the rule file are

identified as resistors:

CALIBRE_LVS_DEVICE_TYPE_RES: rp_sio pwr_rm1

See Also

•CALIBRE_OPTIONAL_DEVICE_PIN_FILE

•WIDE_DEVICE_TERM_RESISTANCE

Chapter 17: StarRC Commands

CALIBRE_OPTIONAL_DEVICE_PIN_FILE 17-13

Chapter 17: StarRC Commands

CALIBRE_OPTIONAL_DEVICE_PIN_FILE 17-13

StarRC User Guide and Command Reference Version F-2011.06

CALIBRE_OPTIONAL_DEVICE_PIN_FILE

Assigns non-standard device terminals by name.

Syntax

CALIBRE_OPTIONAL_DEVICE_PIN_FILE: file_name

Arguments

Argument Description

file_name Name of the device pin file

Description

By default, StarRC assigns non-standard device terminals by position. However, if you

specify the CALIBRE_OPTIONAL_DEVICE_PIN_FILE command, StarRC assigns the device

terminal by the name in the specified file.

Example

In the following example, devpin_file contains the list of device terminal names:

CALIBRE_OPTIONAL_DEVICE_PIN_FILE: devpin_file

The following lines show an example of a device pin file:

M MOS_DEV NDIFSI_D (D) POLY (G) NDIFSI_S (S) NWELL (B)

C CAP_DEV CAP_TOP (PLUS)CAP_BOT (MINUS)

See Also

•CALIBRE_LVS_DEVICE_TYPE_CAP

•CALIBRE_LVS_DEVICE_TYPE_MOS

•CALIBRE_LVS_DEVICE_TYPE_RES

Chapter 17: StarRC Commands

CALIBRE_PDBA_FILE 17-14

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

CALIBRE_PDBA_FILE

Specifies the use of data from a Calibre PDBA file.

Syntax

CALIBRE_PDBA_FILE: file_name

Arguments

Argument Description

file_name File containing devices and device properties

Default: none

Description

The CALIBRE_PDBA_FILE command reads a Calibre PDBA file. This file is generated by

Calibre and lists some devices and device properties. You can use the CALIBRE_PDBA_FILE

command in the StarRC Calibre Connectivity Interface flow to retrieve the separated

properties for a final parasitic netlist with complete device information.

To use the CALIBRE_PDBA_FILE command, you must also include the following commands

in your Calibre runset:

•LVS PUSH DEVICES YES

•LVS PUSH DEVICES SEPARATE PROPERTIES “pdba.data” AGF

Errors

If the file specified by CALIBRE_PDBA_FILE does not exist, StarRC stops and issues a

warning message.

Example

CALIBRE_PDBA_FILE: ./pdba.data

See Also

•SKIP_CELLS

•XREF_SWAP_MOS_SD_PROPERTY

Chapter 17: StarRC Commands

CALIBRE_QUERY_FILE 17-15

Chapter 17: StarRC Commands

CALIBRE_QUERY_FILE 17-15

StarRC User Guide and Command Reference Version F-2011.06

CALIBRE_QUERY_FILE

Specifies the location of all Calibre Connectivity Interface input files.

Syntax

CALIBRE_QUERY_FILE: query_script_file

Arguments

Argument Description

query_script_file The command file used with the Calibre Connectivity Interface

server.

Default: none

Description

To have the Calibre Connectivity Interface (CCI) generate all the files needed for a StarRC

extraction, all the necessary query commands must be in the query command file specified

by CALIBRE_QUERY_FILE.

For details about the Calibre Connectivity Interface, see “Calibre Connectivity Interface” on

page 4-7. For details about Calibre query commands, see “Running the Calibre Query

Server for Output to StarRC” on page 14-33.

Example

CALIBRE_QUERY_FILE: query.cmd

The following is a sample of a Calibre query command file for the Calibre > StarRC flow.

Chapter 17: StarRC Commands

CALIBRE_QUERY_FILE 17-16

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Example 17-0 Calibre Query Sample File

Sample Query Command File

=========================

# Define property numbers in annotated GDSII

GDS NETPROP NUMBER 5

GDS PLACEPROP NUMBER 6

GDS DEVPROP NUMBER 7

# Output seed polygon with net ID

GDS SEED PROPERTY ORIGINAL

# Output annotated GDSII mapping file for StarRC

RESPONSE FILE GDS_MAP

GDS MAP

RESPONSE DIRECT

# Output annotated GDSII file for StarRC

GDS WRITE agf

# Output device table file containing device layer

descriptions

# for StarRC

RESPONSE FILE devtab

DEVICE TABLE

RESPONSE DIRECT

# Output layout net name/net ID mapping table for StarRC

LAYOUT NETLIST TRIVIAL PINS YES

LAYOUT NETLIST EMPTY CELLS YES

LAYOUT NETLIST NAMES NONE

LAYOUT NAMETABLE WRITE lnn

# Output ideal layout netlist for StarRC

LAYOUT NETLIST PRIMITIVE DEVICE SUBCKTS YES

LAYOUT NETLIST PIN LOCATIONS YES

LAYOUT NETLIST HIERARCHY AGF

LAYOUT NETLIST WRITE nl

# Output net/device instance cross referencing tables for

StarRC

NET XREF WRITE nxf

INSTANCE XREF WRITE ixf

# Output ports file for StarRC

PORT TABLE CELLS WRITE ports_cells

# Output cell extents file for StarRC

CELL EXTENTS WRITE extents.txt

See Also

•CALIBRE_RUNSET

Chapter 17: StarRC Commands

CALIBRE_RUNSET 17-17

Chapter 17: StarRC Commands

CALIBRE_RUNSET 17-17

StarRC User Guide and Command Reference Version F-2011.06

CALIBRE_RUNSET

Specifies the LVS command file used for the Calibre run.

Syntax

CALIBRE_RUNSET: lvs_command_file

Arguments

Argument Description

lvs_command_file The LVS command file used for the Calibre run.

Default: none

Description

The CALIBRE_RUNSET command specifies the LVS command file used for the Calibre run. It

is required for the Calibre > StarRC flow.

An LVS rule deck contains data creation commands, device creation commands, device

property calculations, layer connect sequences, and LVS comparison options. StarRC

parses the layer connect sequence from the Calibre runset, including derived layer

connectivity, to understand the runset layer connectivity.

See Also

•BLOCK

•CALIBRE_QUERY_FILE

•MAPPING_FILE

•TCAD_GRD_FILE

Chapter 17: StarRC Commands

CASE_SENSITIVE 17-18

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

CASE_SENSITIVE

Specifies the case-sensitivity of net and cell names during selection.

Syntax

CASE_SENSITIVE: YES | NO

Arguments

Argument Description

YES Cell and net names are case-sensitive during selection.

This is the default.

NO Cell and net names are not case-sensitive during selection.

Description

The CASE_SENSITIVE command specifies whether net and cell names are case-sensitive

during selection. StarRC always retains the case sensitivity of the input database for netlist

creation. This command does not perform output case casting.

If IGNORE_CASE is set to TRUE in your Hercules runset, then you must specify

CASE_SENSITIVE: NO in your StarRC command file.

Example

The following syntax specifies that all net selection and cell selection are not case-sensitive.

CASE_SENSITIVE: NO

See Also

•CONLY_NETS

•INSTANCE_PORT

•NETLIST_SELECT_NETS

•NETLIST_TYPE

•NETS

•POWER_NETS

•SKIP_CELLS

Chapter 17: StarRC Commands

CELL_TYPE 17-19

Chapter 17: StarRC Commands

CELL_TYPE 17-19

StarRC User Guide and Command Reference Version F-2011.06

CELL_TYPE

Specifies whether layout or schematic cell names are used for data selection.

Syntax

CELL_TYPE: LAYOUT | SCHEMATIC

Arguments

Argument Description

LAYOUT Uses layout cell names from the Milkyway XTR or Calibre layout

databases.

This is the default.

SCHEMATIC Uses schematic cell names matched during LVS.

Description

The CELL_TYPE command specifies whether layout or schematic cell names are used for

BLOCK and SKIP_CELLS during data selection.

This command is ignored if XREF: NO is specified.

Note:

CELL_TYPE identifies only the source of cell names for SKIP_CELLS and BLOCK selection.

It does not affect the cell names reported by StarRC.

Example

CELL_TYPE: LAYOUT

See Also

•BLOCK

•MILKYWAY_EXTRACT_VIEW

•NET_TYPE

•SKIP_CELLS

•XREF

Chapter 17: StarRC Commands

COMPARE_DIRECTORY 17-20

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

COMPARE_DIRECTORY

Specifies the location of the Hercules LVS COMPARE output.

Syntax

COMPARE_DIRECTORY: path

Arguments

Argument Description

path The path to the location of the Hercules LVS COMPARE output

files.

Default: none

Description

The COMPARE_DIRECTORY command specifies the location of the Hercules LVS COMPARE

output. This path is specified in the Hercules runset HEADER section, with the

COMPARE_DIR option. The Hercules default for this option is ./run_details/compare.

This command is optional; however, if this path is not specified and XREF: YES or XREF:

COMPLETE is specified, the tool attempts to read the compare directory location from the XTR

(Milkyway Extract) view.

See Also

•XREF

Chapter 17: StarRC Commands

CONLY_NETS 17-21

Chapter 17: StarRC Commands

CONLY_NETS 17-21

StarRC User Guide and Command Reference Version F-2011.06

CONLY_NETS

Reports cross-capacitance to noncritical net neighbors.

Syntax

CONLY_NETS: list_of_nets

Arguments

Argument Description

list_of_nets List of nets; wildcards can be used.

Default: none

Description

The CONLY_NETS command reports cross-capacitance to noncritical net neighbors of the

NETS selected. The behavior of this command is dependent on the settings of the NETS and

COUPLE_TO_GROUND commands.

Example

In the following example, CONLY_NETS has no effect and all nets are netlisted:

COUPLE_TO_GROUND: NO

NETS: *

In the following example, net_a is extracted and netlisted with coupling to net_b:

COUPLE_TO_GROUND: NO

NETS: net_a

CONLY_NETS: net_b

The previous example results in the following sample output:

*|NET net_a

...

*CAP

1 net_a:23 net_b 1.32

2 net_a:3433 net_b 12.46

With the COUPLE_TO_GROUND: YES command, CONLY_NETS has no effect.

Chapter 17: StarRC Commands

CONLY_NETS 17-22

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

See Also

•COUPLE_TO_GROUND

•NETLIST_COUPLE_UNSELECTED_NETS

•NETS

Chapter 17: StarRC Commands

CONVERT_DIODE_TO_PARASITIC_CAP 17-23

Chapter 17: StarRC Commands

CONVERT_DIODE_TO_PARASITIC_CAP 17-23

StarRC User Guide and Command Reference Version F-2011.06

CONVERT_DIODE_TO_PARASITIC_CAP

Specifies the extraction of parasitic properties of antenna diode structures.

Syntax

CONVERT_DIODE_TO_PARASITIC_CAP: model_name area_coeff perimeter_coeff

Arguments

Argument Description

model_name Antenna diode model name

Default: none

area_coeff Area capacitance coefficient

Units: F/m2

Default: none

perimeter_coeff Perimeter capacitance coefficient

Units: F/m

Default: none

Description

Use the CONVERT_DIODE_TO_PARASITIC_CAP command to extract parasitic properties of

antenna diode structures. Antenna diode structures in layout designs are commonly used to

help accommodate high-frequency circuit operations. Their use has increased as devices

have become smaller and their parasitic properties have become included in the extracted

parasitic netlist.

Errors

Error messages are issued when

• The model name is not found

• The capacitance coefficients are not realistic values such as negative numbers

• Device properties are not found in the input data

Example

CONVERT_DIODE_TO_PARASITIC_CAP: NpParaDiode 1e-15 1e-16

Chapter 17: StarRC Commands

CONVERT_DIODE_TO_PARASITIC_CAP 17-24

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

See Also

•EXTRACTION

Chapter 17: StarRC Commands

COUPLE_NONCRITICAL_NETS 17-25

Chapter 17: StarRC Commands

COUPLE_NONCRITICAL_NETS 17-25

StarRC User Guide and Command Reference Version F-2011.06

COUPLE_NONCRITICAL_NETS

Reports the actual net names when coupling to material outside of the primary extraction

cell.

Syntax

COUPLE_NONCRITICAL_NETS: cell_list

Arguments

Argument Description

cell_list A cell or a list of cells for reporting coupling capacitance outside

the primary extraction cell

Default: !*

Description

Reports the actual net names when coupling to material outside of the primary extraction

cell. This command can affect the children of BLOCK and the parent, siblings, and children of

MACRO.

If you add a child cell to this list (that is, down from the primary cell), primary cell nets can

couple to the real hierarchical net names in the child. The child cells are not included in the

netlist and are floating nodes in the output SPEF. If you add a parent or a sibling cell to this

list, a special naming scheme is used to identify the coupling nodes. Instead of using full

hierarchical names from the MACRO perspective, the noncritical coupling nodes are named

cell_name/local_net_name.

This command overrides ZONE_COUPLE_TO_NET and SKIP_CELLS_COUPLE_TO_NET for the

selected cells.

The wildcards “*”, “?”, and “!” are acceptable. This command can be specified multiple times.

Note:

You should explicitly specify the cells on this list, rather than using the asterisk (*)

wildcard. Using a wildcard slows down runtime unnecessarily.

Chapter 17: StarRC Commands

COUPLE_NONCRITICAL_NETS 17-26

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Example

Assume that you want to extract an instance, XU0, of cell MacroA in the context of the

BLOCK TopBlock. MacroB is a sibling of MacroA, and SubMacroC is a child of MacroA. The

following example shows how to configure the related options to achieve the following result:

• Parent TopBlock and siblings MacroA and MacroB are coupled with special block/net

names.

• Other siblings of MacroA, such as standard cells, are coupled with the net name ZONE.

• Child SubMacroC is coupled with real hierarchical net names, from the perspective of

MacroA.

• Other children of MacroA are coupled with the net name LUMP.

BLOCK: TopBlock

MACRO: XU0

COUPLE_NONCRITICAL_NETS: TopBlock MacroA MacroB SubMacroC

SKIP_CELLS_COUPLE_TO_NET: LUMP

ZONE_COUPLE_TO_NET: ZONE

The resulting SPEF might have capacitors like this:

*CAP

...

11 net1 TopBlock/clk 1.2e-13

12 net2 MacroA/net1 1e-16 // can couple to

identical // sibling

13 net3 MacroB/net2 1.3e-18

14 net1 instA/net1 8.2e-17 // couple to SubMacroC

cell

...

*END

See Also

•BLOCK

•COUPLE_NONCRITICAL_NETS_PREFIX

•COUPLE_TO_GROUND

•MACRO

•NETLIST_FORMAT

•SKIP_CELLS_COUPLE_TO_NET

•ZONE_COUPLE_TO_NET

Chapter 17: StarRC Commands

COUPLE_NONCRITICAL_NETS_PREFIX 17-27

Chapter 17: StarRC Commands

COUPLE_NONCRITICAL_NETS_PREFIX 17-27

StarRC User Guide and Command Reference Version F-2011.06

COUPLE_NONCRITICAL_NETS_PREFIX

Specifies a prefix for the nets output by the COUPLE_NONCRITICAL_NETS command.

Syntax

COUPLE_NONCRITICAL_NETS_PREFIX: prefix

Arguments

Argument Description

prefix Prefix string

Default: SYNOPSYS_INCONTEXT_

Description

Changes the prefix used by the COUPLE_NONCRITICAL_NETS command flow for nets, which

must be made unique to preserve independent names.

From the specified BLOCK down the hierarchy, this command applies the prefix to

interconnect or port nets of selected COUPLE_NONCRITICAL_NETS and SKIP_CELLS. From a

specified MACRO up the hierarchy, the prefix is applied to all names in the external

environment.

For example, instance/prefixnetname is applied for all noncritical nets.

If you do not specify any value, the default is SYNOPSYS_INCONTEXT_. If you specify NONE

as the value (not case sensitive), an empty prefix is used such that the coupling netname is

instance/netname.

This command is ignored if you do not specify the COUPLE_NONCRITICAL_NETS command.

See Also

•COUPLE_NONCRITICAL_NETS

Chapter 17: StarRC Commands

COUPLE_NONCRITICAL_NETS_SUBNODE_SUFFIX 17-28

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

COUPLE_NONCRITICAL_NETS_SUBNODE_SUFFIX

Specifies a netlist delimiter between the netname and suffix.

Syntax

COUPLE_NONCRITICAL_NETS_SUBNODE_SUFFIX: string

Arguments

Argument Description

string Netlist delimiter to be inserted between the netname and suffix

Default: an empty string

Description

The COUPLE_NONCRITICAL_NETS_SUBNODE_SUFFIX command specifies a netlist delimiter

between the netname and suffix. For example,

instance/prefix netname netlist_delimiter suffix

This command only works for cell-level extraction.

Retaining coupling capacitances between the top-level parent routing and SKIP_CELLS child

net routing exists for the Milkyway flow using the SPEF netlist format.

Example

MY_SUB_GROUP_1/SYNOPSYS_INCONTEXT_n192:1

See Also

•COUPLE_NONCRITICAL_NETS

•NETLIST_FORMAT

•RING_AROUND_THE_BLOCK

•SKIP_CELLS_COUPLE_TO_NET

•ZONE_COUPLE_TO_NET

Chapter 17: StarRC Commands

COUPLE_TO_GROUND 17-29

Chapter 17: StarRC Commands

COUPLE_TO_GROUND 17-29

StarRC User Guide and Command Reference Version F-2011.06

COUPLE_TO_GROUND

Specifies whether or not coupling capacitances are lumped to ground during extraction and

netlist generation.

Syntax

COUPLE_TO_GROUND: YES | NO

Arguments

Argument Description

YES Grounds coupling capacitors to other signal nets.

This is the default.

NO Retains coupling capacitors neighboring signal nets.

Description

The COUPLE_TO_GROUND command specifies whether or not parasitic coupling capacitances

are lumped to ground during extraction and netlist generation. A related command,

COUPLING_MULTIPLIER, defines a scaling factor required to account for crosstalk effects

during decoupling.

Example

COUPLE_TO_GROUND: YES

See Also

•COUPLING_MULTIPLIER

•NETLIST_FORMAT

Chapter 17: StarRC Commands

COUPLE_TO_PCELL_PINS 17-30

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

COUPLE_TO_PCELL_PINS

Specifies the coupling of parameterized cell (PCELL) pins to overhead nets.

Syntax

COUPLE_TO_PCELL_PINS: NO | YES | YES KEEP_CG

Arguments

Argument Description

NO Ignores couplings between adjacent PCELL pins; ignores

couplings between PCELL pins and ground.

This is the default.

YES Extracts couplings between adjacent PCELL pins; ignores

couplings between PCELL pins and ground.

YES KEEP_CG Extracts couplings between adjacent PCELL pins; extracts

couplings between PCELL pins and ground.

Description

The COUPLE_TO_PCELL_PINS command controls whether StarRC extracts PCELL pin

couplings to adjacent PCELL pins and ground.

Example

In the following example, StarRC extracts couplings between adjacent PCELL pins and

couplings between PCELL pins and ground:

COUPLE_TO_PCELL_PINS: YES KEEP_CG

See Also

•SKIP_PCELLS

Chapter 17: StarRC Commands

COUPLING_ABS_THRESHOLD 17-31

Chapter 17: StarRC Commands

COUPLING_ABS_THRESHOLD 17-31

StarRC User Guide and Command Reference Version F-2011.06

COUPLING_ABS_THRESHOLD

Sets an absolute threshold for grounding coupling capacitors.

Syntax

COUPLING_ABS_THRESHOLD: threshold

Arguments

Argument Description

threshold Absolute threshold

Units: farads (F)

Default: 3e-15

Description

Sets an absolute threshold for grounding coupling capacitors. Any coupling capacitor less

than this value that also meets the specified relative threshold criteria is grounded. For more

details, see “Smart Decoupling of Coupling Capacitances” on page 9-3.

See Also

•COUPLING_AVG_THRESHOLD

•COUPLING_REL_THRESHOLD

•COUPLING_THRESHOLD_OPERATION

Chapter 17: StarRC Commands

COUPLING_AVG_THRESHOLD 17-32

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

COUPLING_AVG_THRESHOLD

Syntax

COUPLING_AVG_THRESHOLD: threshold

Arguments

Argument Description

threshold A nonnegative floating-point number

Default: none

Description

Sets the ratio of coupling to the average coupling of a net, which defines a coupling to be

grounded. Two nets are decoupled when the ratio of coupling between two nets to each

average coupling is less than this value (if coupling capacitance meets the specified

absolute threshold and relative threshold). For more details, see “Smart Decoupling of

Coupling Capacitances” on page 9-3.

Note:

The COUPLING_AVG_THRESHOLD command has no default.

Example

In the following example, StarRC retains all coupling capacitors, resulting in a large netlist

size.

COUPLING_AVG_THRESHOLD: 0

See Also

•COUPLING_ABS_THRESHOLD

•COUPLING_REL_THRESHOLD

•COUPLING_THRESHOLD_OPERATION

Chapter 17: StarRC Commands

COUPLING_MULTIPLIER 17-33

Chapter 17: StarRC Commands

COUPLING_MULTIPLIER 17-33

StarRC User Guide and Command Reference Version F-2011.06

COUPLING_MULTIPLIER

Specifies a design- and process-dependent factor to be applied for transferring coupling

capacitances to ground.

Syntax

COUPLING_MULTIPLIER: value

Arguments

Argument Description

value A floating-point number greater than zero

Default: 1.0

Description

Applies a design- and process-dependent factor when you are transferring coupling

capacitances to ground. This command has been implemented primarily to scale parasitic

capacitances for crosstalk effects.

Example

COUPLING_MULTIPLIER: 6

See Also

•COUPLE_TO_GROUND

Chapter 17: StarRC Commands

COUPLING_REL_THRESHOLD 17-34

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

COUPLING_REL_THRESHOLD

Sets the ratio of coupling to total capacitance.

Syntax

COUPLING_REL_THRESHOLD: threshold

Arguments

Argument Description

threshold Floating-point number between 0 and 1

Default: 0.03

Description

Sets the ratio of coupling to total capacitance, which defines nets to be grounded. Two nets

are decoupled when the ratio of coupling capacitance to each total net capacitance is less

than this value, as long as the coupling capacitance meets the specified absolute threshold.

For more details, see “Smart Decoupling of Coupling Capacitances” on page 9-3.

See Also

•COUPLING_ABS_THRESHOLD

•COUPLING_AVG_THRESHOLD

•COUPLING_THRESHOLD_OPERATION

Chapter 17: StarRC Commands

COUPLING_REPORT_FILE 17-35

Chapter 17: StarRC Commands

COUPLING_REPORT_FILE 17-35

StarRC User Guide and Command Reference Version F-2011.06

COUPLING_REPORT_FILE

Generates a report listing the coupling capacitance by net.

Syntax

COUPLING_REPORT_FILE: file

Arguments

Argument Description

file File name for the report containing coupling capacitances by net

Default: none

Description

Generates a report listing the coupling capacitance by net after smart decoupling. The

report is sorted by the percentage of coupling capacitance to total capacitance for the net.

The format is as follows:

< Cc/Ct *100 > < Cc > < victim_net > < aggressor_net

The report contains the number of entries indicated by the COUPLING_REPORT_NUMBER

command.

The total net capacitance used for the coupling percentage calculation is the same as that

used for smart decoupling. It includes loading pin capacitors but not intranet coupling

capacitors (same net coupling).

Example

* 1000 worst couplings in descending order

* ratio(%) coupling victim aggressor

30.00 3e-15 net1 net2

20.00 2e-15 net3 net2

10.00 3e-15 net2 net1

See Also

•COUPLING_REPORT_NUMBER

Chapter 17: StarRC Commands

COUPLING_REPORT_NUMBER 17-36

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

COUPLING_REPORT_NUMBER

Specifies the number of nets reported by COUPLING_REPORT_FILE.

Syntax

COUPLING_REPORT_NUMBER: value

Arguments

Argument Description

value The number of nets for which you want coupling capacitors

reported. This number must be an integer.

Default: 1000

Description

Controls the size of the COUPLING_REPORT_FILE. The top COUPLING_REPORT_NUMBER nets

are exported to the report file.

Example

COUPLING_REPORT_NUMBER: 5

See Also

•COUPLING_REPORT_FILE

Chapter 17: StarRC Commands

COUPLING_THRESHOLD_OPERATION 17-37

Chapter 17: StarRC Commands

COUPLING_THRESHOLD_OPERATION 17-37

StarRC User Guide and Command Reference Version F-2011.06

COUPLING_THRESHOLD_OPERATION

Specifies the use of AND filtering or OR filtering of coupling thresholds.

Syntax

COUPLING_THRESHOLD_OPERATION: AND | OR

Arguments

Argument Description

AND AND filtering

This is the default.

OR OR filtering

Description

The following five conditions are checked to determine whether a coupling capacitance,

Cc(net1-net2) should be decoupled:

Condition1: Cc(net1-net2) < COUPLING_ABS_THRESHOLD

Condition2: Cc(net1-net2) < COUPLING_REL_THRESHOLD * TCAP_net1

Condition3: Cc(net1-net2) < COUPLING_REL_THRESHOLD * TCAP_net2

Condition4: Cc(net1-net2) < COUPLING_AVG_THRESHOLD * C_avg_net1

Condition5: Cc(net1-net2) < COUPLING_AVG_THRESHOLD * C_avg_net2

The COUPLING_THRESHOLD_OPERATION command specifies the use of AND filtering or OR

filtering of coupling capacitances.

• When AND filtering is specified by COUPLING_THRESHOLD_OPERATION: AND, then a

coupling capacitance is decoupled if the following operation is TRUE:

Condition1 AND (Condition2 AND Condition3) AND (Condition4 AND Condition5)

• When OR filtering is specified by COUPLING_THRESHOLD_OPERATION: OR, then a

coupling capacitance is decoupled if the following operation is TRUE:

Condition1 OR (Condition2 AND Condition3) OR (Condition4 AND Condition5)

See Also

•COUPLING_ABS_THRESHOLD

•COUPLING_AVG_THRESHOLD

•COUPLING_REL_THRESHOLD

Chapter 17: StarRC Commands

DENSITY_BASED_THICKNESS 17-38

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

DENSITY_BASED_THICKNESS

Syntax

DENSITY_BASED_THICKNESS:YES | NO

Arguments

Argument Description

YES Considers density-based thickness variation options as specified

in the ITF.

This is the default.

NO Does not consider density-based thickness options.

Description

Enables the calculation of density and thickness variation during extraction. This command

is automatically set to YES if either the THICKNESS_VS_DENSITY or the POLYNOMIAL_BASED_

THICKNESS_VARIATION command is detected in your ITF, or process file.

Note:

No warning is issued when thickness variation commands are not specified in the ITF file.

Example

DENSITY_BASED_THICKNESS: YES

See Also

•NETS

•USE_SI_DENSITY

Chapter 17: StarRC Commands

DENSITY_OUTSIDE_BLOCK 17-39

Chapter 17: StarRC Commands

DENSITY_OUTSIDE_BLOCK 17-39

StarRC User Guide and Command Reference Version F-2011.06

DENSITY_OUTSIDE_BLOCK

Specifies the pattern density outside the block, which affects the thickness variation and

parasitic RC values.

Syntax

DENSITY_OUTSIDE_BLOCK: density_value

Arguments

Argument Description

density_value Pattern cell density, represented by a floating-point number from

0.0 to 1.0

Default: 0.0

Description

The DENSITY_OUTSIDE_BLOCK command defines the pattern density outside the block. The

specified density is applied to all layers on which StarRC performs density calculation. This

command is used by the StarXtract function in StarRC.

By default, StarRC sets the outside density to 0.0. When the tool calculates the density of a

particular polygon, it uses a 50 μm by 50 μm square window that contains the polygon of

interest at the center. If the polygon of interest is located near the edge of the block, a portion

of the 50 μm by 50 μm window might be outside the block. To avoid unexpectedly low density

values for polygons near the block edge, set a nonzero value for DENSITY_OUTSIDE_BLOCK.

Note:

This command is effective only when you specify density-based thickness variation in the

ITF file and specify DENSITY_BASED_THICKNESS: YES in the StarRC command file.

Errors

StarXtract issues an error if the value specified for DENSITY_OUTSIDE_BLOCK is less than 0.0

or greater than 1.0. When the specified value equals 0.0 or 1.0, the error is not issued.

Example

The following example specifies that the pattern density outside the block is 40 percent:

DENSITY_OUTSIDE_BLOCK: 0.40

See Also

•DENSITY_BASED_THICKNESS

Chapter 17: StarRC Commands

DETECT_FUSE 17-40

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

DETECT_FUSE

Reports the fuse contact width in the netlist.

Syntax

DETECT_FUSE: YES | NO

Arguments

Argument Description

YES Analyze wire contacts to locate fuses.

NO Do not analyze wire contacts to locate fuses.

This is the default.

Description

Fuse contacts can be small regions, for example, where misaligned wire contact as shown

in Figure 17-1, and where local current density might be significantly higher due to the

reduced cross section. As a result, such regions might be susceptible to electromigration

problems. While fuse contacts acting as conductor configurations have a relatively small

effect on the circuit resistance and therefore can be safely ignored in timing or noise

analysis, a more detailed analysis might be needed during reliability verification flow. With

this command, you are able to locate these fuse contacts. For this command to function

properly, the REDUCTION:NO command must be set in your command file.

Figure 17-1 DETECT_FUSE Misaligned Wire Contact

Reports fuse resistors:

- $I=0

- $w=fuse contact width

- Rval =0.01

fuse

Example

DETECT_FUSE: YES

Chapter 17: StarRC Commands

DETECT_FUSE 17-41

Chapter 17: StarRC Commands

DETECT_FUSE 17-41

StarRC User Guide and Command Reference Version F-2011.06

See Also

•NETLIST_TAIL_COMMENTS

•REDUCTION: NO

Chapter 17: StarRC Commands

EVACCESS_DIRECTORY 17-42

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

EVACCESS_DIRECTORY

Specifies the location of the Hercules LVS EvAccess database.

Syntax

EVACCESS_DIRECTORY: path

Arguments

Argument Description

path Path to the Hercules LVS EvAccess database

Default: none

Description

Specifies the location of the Hercules LVS EvAccess database. This path can also be

specified in the Hercules runset EVACCESS_OPTIONS section, with the PATH option. The

Hercules default for this option is ./evaccess.

If this path is not specified, and you have specified XREF: YES or XREF: COMPLETE, the tool

attempts to read the directory location from the XTR (Milkyway Extract) view.

The EVACCESS_DIRECTORY command is not used in the IC Validator flow.

See Also

•XREF

Chapter 17: StarRC Commands

EXTRA_GEOMETRY_INFO 17-43

Chapter 17: StarRC Commands

EXTRA_GEOMETRY_INFO 17-43

StarRC User Guide and Command Reference Version F-2011.06

EXTRA_GEOMETRY_INFO

Reports the internal node bounding box information from StarRC resistance extraction.

Syntax

EXTRA_GEOMETRY_INFO: NODE | NONE

Arguments

Argument Description

NODE Reports nodes with geometry information.

NONE Does not report extra geometry information.

This is the default.

Description

Reports the internal node bounding box information from StarRC resistance extraction,

either as a tail comment in the node section of the netlist or as a node property in the

Milkyway parasitic database. This command is supported only for the SPF,STAR,

NETNAME,SPEF,SBPF and MW netlist formats. The dimensions in the bounding box data are

always as drawn and are not affected by the NETLIST_UNSCALED_COORDINATES command.

Example

This example shows the EXTRA_GEOMETRY_INFO:NODE command result:

*D_NET I20|N9 0.0869015

*CONN

*I I20|I44.X O *C 151.19 11.75 *D NAN2 // \

$llx=150.35 $lly=11.75 $urx=151.19 $ury=12.73\

$lvl=1

*I I20|I45.A I *C 149.16 11.75 *L 2 *D NOR2 // \

$llx=149.16 $lly=11.75 $urx=149.16 $ury=12.73\

$lvl=1

*N I20|N9.220 *C 155.04 17.42 // $llx=154.83\

$lly=17.42 $urx=155.04 $ury=17.42 $lvl=1

*N I20|N9.235 *C 154.83 18.68 // $llx=154.83\

$lly=18.68 $urx=155.04 $ury=18.68 $lvl=1

*N I20|N9.234 *C 153.57 18.68 // $llx=153.57\

$lly=18.68 $urx=153.57 $ury=18.68 $lvl=1

*N I20|N9.219 *C 153.57 17.42 // $llx=153.43\

$lly=17.42 $urx=153.57 $ury=17.42 $lvl=

Chapter 17: StarRC Commands

EXTRA_GEOMETRY_INFO 17-44

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

When you run an extraction using EXTRA_GEOMETRY_INFO, the LAYER_MAP section of the

netlist can also contain generated layer names. Extra layers are formed in the case of

device-level extraction when there are database layers at the diffusion level or below that

share a contact. For instance, if the runset contains the line shown in the following example,

then the LAYER_MAP section contains an extra layer called nsd:psd or psd:nsd, which

becomes the lower terminal level of diffCont via resistors.

CONNECT metal1 nsd psd BY diffCon

See Also

•NETLIST_FORMAT

•NETLIST_UNSCALED_COORDINATES

Chapter 17: StarRC Commands

EXTRACTION 17-45

Chapter 17: StarRC Commands

EXTRACTION 17-45

StarRC User Guide and Command Reference Version F-2011.06

EXTRACTION

Specifies the type of extraction and the scope of the generated netlist.

Syntax

EXTRACTION: RC | C | R | FSCOMPARE

Arguments

Argument Description

RC Extracts both parasitic resistor and capacitor devices and merges them into the

original database network to produce a consolidated RC network description of

the layout in the specified format.

This is the default.

CExtracts only parasitic capacitor devices and produces a merged parasitic layout

network description as a SPICE file. The NETLIST_FORMAT command is ignored

for capacitance-only extractions.

RExtracts only parasitic resistor devices and produces a merged parasitic layout

network description in the specified format.

FSCOMPARE Provides a comparison report of a merged layout network description containing

only parasitic capacitors, executes a field solver analysis of the layout, and

produces report files that describe the accuracy in a comparison of the two

results.

When this option and the FS_EXTRACT_NETS command are specified, the

.fscomptot and .fs_compcoup output comparison files

always use the layout net names, regardless of the XREF command setting.

Description

The extraction of parasitic devices is performed only on that portion of the layout network

defined by the NETS command, terminating each net at the boundary of the specified

SKIP_CELLS.

See Also

•FSCOMPARE_OPTIONS

•FS_EXTRACT_NETS

•NETLIST_FORMAT

•REDUCTION

Chapter 17: StarRC Commands

EXTRACT_VIA_CAPS 17-46

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

EXTRACT_VIA_CAPS

Performs a detailed via capacitance extraction.

Syntax

EXTRACT_VIA_CAPS: NO | YES [IGNORE_GATE_CONTACT_COUPLING]

Arguments

Argument Description

NO Do not consider capacitive effect of vias/contacts. In general this

setting uses less runtime and reports fewer capacitances. This is

best used while developing designs and for technology nodes of

130 nm and above.

This is the default.

YES Consider the capacitive effect of vias/contacts. In general, this

setting uses more runtime and reports the accuracy of the total

net capacitance improvement. This is best used for signoff

designs and those with technology nodes of 90 nm and below.

IGNORE_GATE_CONTACT_COUP

LING

Ignore the gate contact coupling if SPICE models include

gate-to-contact capacitance. Use the following command:

EXTRACT_VIA_CAPS: YES

IGNORE_GATE_CONTACT_COUPLING

Description

This command is used in conjunction with the EXTRACTION: RC | C | FSCOMPARE

command.

If EXTRACT_VIA_CAPS is set to YES, StarRC considers the capacitive effects of all kinds of

via/contact layers when it extracts parasitics. You do not need to prepare a new nxtgrd file to

extract via capacitance in general; StarRC takes into account the via capacitance with a

normal nxtgrd file.

The ITF option GATE_TO_CONTACT_SMIN should be used in addition to SMIN inside the ITF

CONDUCTOR definition for polysilicon, for flows in which MOS gate-to-contact capacitance

accuracy is relevant. This allows StarRC to utilize the actual gate-to-contact spacing when

extracting contact capacitance because this spacing is typically smaller than the standard

polysilicon SMIN spacing.

Chapter 17: StarRC Commands

EXTRACT_VIA_CAPS 17-47

Chapter 17: StarRC Commands

EXTRACT_VIA_CAPS 17-47

StarRC User Guide and Command Reference Version F-2011.06

See Also

•EXTRACTION

Chapter 17: StarRC Commands

EXTRACT_RES_BODY_COUPLING 17-48

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

EXTRACT_RES_BODY_COUPLING

Specifies the extraction of coupling capacitances between metal interconnects to a resistor

body and resistor body to ground.

Syntax

EXTRACT_RES_BODY_COUPLING: YES | NO

Arguments

Argument Description

YES Enables resistor body capacitor extraction.

NO Disables resistor body capacitor extraction.

This is the default.

Description

Specifies the extraction of coupling capacitances between metal interconnects to a resistor

body and resistor body to ground. The coupling between resistor bodies and interconnect is

distributed between the two terminals of the resistor.

Example

EXTRACT_RES_BODY_COUPLING: YES

Chapter 17: StarRC Commands

FS_DP_STRING 17-49

Chapter 17: StarRC Commands

FS_DP_STRING 17-49

StarRC User Guide and Command Reference Version F-2011.06

FS_DP_STRING

Specifies the distributed processing method and job control parameters for Rapid3D

extraction runs.

Syntax

FS_DP_STRING:

bsub lsf_arguments

| qsub gridware_arguments

| list list_of_machines

Arguments

Argument Description

lsf_arguments Arguments for an LSF system

gridware_arguments Arguments for a Gridware system

list_of_machines List of machines on a general network

Description

For distributed processing, you must specify how to invoke jobs on your compute farm by

setting the FS_DP_STRING command.

There are three methods to implement distributed processing:

• LSF System

• Gridware System

• General Network With a List of Machines

When using distributed processing, keep the following points in mind:

• The FS_DP_STRING command does not specify the number of processors.

• If you specify the FS_DP_STRING variable as both an environment variable and a StarRC

command file statement, then StarRC command file uses the setting in the command file.

• The control parameters are site-specific; ask your system administrator for details.

Example

On an LSF system:

FS_DP_STRING: bsub -a amd64 -R "rusage[mem=5000]"

Chapter 17: StarRC Commands

FS_DP_STRING 17-50

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

On a Gridware system:

FS_DP_STRING: qsub -P bnormal -l "mem_free=1G mem_avail=1G"

On a general network with a list of machines:

FS_DP_STRING: list mars jupiter uranus

See Also

•rapid3d

Chapter 17: StarRC Commands

FS_EXTRACT_NETS 17-51

Chapter 17: StarRC Commands

FS_EXTRACT_NETS 17-51

StarRC User Guide and Command Reference Version F-2011.06

FS_EXTRACT_NETS

Specifies the nets to be extracted by the field solver.

Syntax

FS_EXTRACT_NETS: net_names

Arguments

Argument Description

net_names List of nets the require field solver extraction accuracy.

Wildcards can be used.

Description

The FS_EXTRACT_NETS command specifies a list of nets that need the highest level of

extraction accuracy. In addition to extracting these nets in the regular flow, StarRC also

creates a subset of the design based on these nets to also be extracted by the field solver.

The resulting netlist combines the nets extracted by StarRC and the field solver.

StarRC creates comparison tables for both total and coupling capacitances with the

FS_EXTRACT_NETS command. This enables you to generate an accurate parasitic netlist

along with a validation report. This is available for all flows.

In addition, StarRC supports NET_TYPE: SCHEMATIC when used with the FS_EXTRACT_NETS

command in the Calibre flow.

Example

In the following example, StarRC extracts all nets, but only the three nets specified by the

FS_EXTRACT_NETS command are extracted by the field solver:

NETS: *

FS_EXTRACT_NETS: net1 net2 net3

NET_TYPE: SCHEMATIC

Use the NET_TYPE command to specify whether the net names are layout or schematic net

names.

Chapter 17: StarRC Commands

FS_EXTRACT_NETS 17-52

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

See Also

•FSCOMPARE_COUPLING_RATIO

•FSCOMPARE_OPTIONS

•FSCOMPARE_THRESHOLD

•NET_TYPE

Chapter 17: StarRC Commands

FSCOMPARE_COUPLING_RATIO 17-53

Chapter 17: StarRC Commands

FSCOMPARE_COUPLING_RATIO 17-53

StarRC User Guide and Command Reference Version F-2011.06

FSCOMPARE_COUPLING_RATIO

Specifies the minimum ratio of the coupling capacitance to the total capacitance required on

a particular net to make it eligible for comparison in an FSCOMPARE extraction.

Syntax

FSCOMPARE_COUPLING_RATIO: value

Arguments

Argument Description

value A floating-point number between zero and one.

Default: 0.10

Description

FSCOMPARE_COUPLING_RATIO specifies the minimum ratio of the coupling capacitance to the

total capacitance required on a particular net to make it eligible for comparison in an

FSCOMPARE extraction. The results are filtered by the field solver results.

The specified value is applied to the capacitance values calculated by the 3-D field solver,

which is Rapid3D by default.

Example

FSCOMPARE_COUPLING_RATIO: 0.2

See Also

•EXTRACTION: FSCOMPARE

•FS_EXTRACT_NETS

•FSCOMPARE_OPTIONS

•FSCOMPARE_THRESHOLD

Chapter 17: StarRC Commands

FSCOMPARE_FILE_PREFIX 17-54

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

FSCOMPARE_FILE_PREFIX

Syntax

FSCOMPARE_FILE_PREFIX: prefix

Arguments

Argument Description

prefix A prefix to be attached to the beginning of file names.

Default: block name specified in the star_cmd file.

Description

Provides a prefix to be attached to files output by the EXTRACTION: FSCOMPARE command.

Example

FSCOMPARE_FILE_PREFIX: myprefix

myprefix.fs-compcoup

See Also

•EXTRACTION

Chapter 17: StarRC Commands

FSCOMPARE_OPTIONS 17-55

Chapter 17: StarRC Commands

FSCOMPARE_OPTIONS 17-55

StarRC User Guide and Command Reference Version F-2011.06

FSCOMPARE_OPTIONS

Specifies field solver options such as convergence goal and multiprocessing.

Syntax

FSCOMPARE_OPTIONS: option_1 [option_2 ...]

Arguments

Argument Description

option_1 [option_2 ...]Field solver options listed in Ta b l e 17-1.

Description

Table 17-1 lists the Rapid3D options that you can specify with FSCOMPARE_OPTIONS to be

passed to the field solver during FSCOMPARE extraction.

Table 17-1 List of Rapid3D Options Set by FSCOMPARE_OPTIONS

Argument Description

-f input_files Specifies the input files. Specify the technology file before the design

file.

-e list_of_nets Specifies a list of nets to extract.

Default: all nonground nets

-v Prints the program version.

-np number_processors During distributed processing, sets the number of processors to use.

Default: 1

-time_out wait_time During distributed processing, sets the maximum time that the

master process waits for the slave machines to start.

Units: minutes

Default: 1440

-mach_term retry_time During distributed processing, sets the time to keep trying to contact

a master or slave machine that has stopped responding. If the

machine does not respond within the specified time, the job

terminates.

Units: minutes

Default: 10

Chapter 17: StarRC Commands

FSCOMPARE_OPTIONS 17-56

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

-min_per_net

minutes_per_net

Sets the maximum extraction time per net.

Units: minutes

Default = 20

-l filename Specifies the name of a file containing a list of client machines. For

each client, specify a row with the following: machine_name arch

If -l is given, then LSF is not used for the clients.

-perc_self

self_cap_conv_goal

Sets the self-capacitance convergence goal at one standard

deviation as a percentage.

Units: percent

Default: 0.5

-perc_coup

coup_cap_conv_goal

Sets the coupling capacitance convergence goal at one standard

deviation as a percentage.

Default: not checking

-abs_coup

abs_cap_conv_goal

Sets the absolute coupling capacitance convergence goal.

The dynamic value of abs_cap_conv_goal is determined by

multiplying the total net capacitance by the percentage set by

-coup_cap_thresh.

Units: farads

Default: dynamic

-coup_cap_thresh number Sets the percentage of total capacitance at which to start checking

coupling.

Units: percent

Default: 1

-perc_consistency max_dev Sets the maximum deviation between identical nets, expressed as a

percentage of the total capacitance.

Units: percent

Default: none

-perc_of_nets_consistent

number

Sets the percentage of identical nets that deviate from each other by

the level specified by -perc_consistency.

Units: percent

Default: 97

Table 17-1 List of Rapid3D Options Set by FSCOMPARE_OPTIONS (Continued)

Argument Description

Chapter 17: StarRC Commands

FSCOMPARE_OPTIONS 17-57

Chapter 17: StarRC Commands

FSCOMPARE_OPTIONS 17-57

StarRC User Guide and Command Reference Version F-2011.06

-perc_accuracy number Sets the accuracy of the extracted capacitance value, expressed as

a percentage of the capacitance value.

Note: if this parameter is specified, -perc_self should not be

specified.

Units: percent

Default: 1.5

-perc_accuracy_confidence

number

Sets the confidence level for the estimated capacitance value,

extracted at the accuracy level set by -perc_accuracy, expressed

as a percentage.

Units: percent

Default: 99.7

-min_cap cap_value Sets the minimum capacitance value to report in the output file.

Units: farads

Default: 1.0e-20

-seed rand_num_seed Sets the random number seed.

Default: 12345

-bb xl yl xh yh Sets the bounding box.

Units: grid units

Default: 100 microns larger than design

-neuman_x Uses Neumann boundary conditions on X boundaries.

Default: false

-neuman_y Uses Neumann boundary conditions on Y boundaries.

Default: false

-periodic_x Uses periodic boundary conditions on X boundaries.

Default: false

-periodic_y Uses periodic boundary conditions on Y boundaries.

Default: false

-match Enables pattern matching and improves runtime and accuracy for

symmetric or identical net extraction in Rapid3D.

Table 17-1 List of Rapid3D Options Set by FSCOMPARE_OPTIONS (Continued)

Argument Description

Chapter 17: StarRC Commands

FSCOMPARE_OPTIONS 17-58

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

To obtain a complete list of Rapid3D options, enter rapid3d -help on the command line.

This assumes that the installation of Rapid3D has been correctly set up.

Example

To run two clients with a one percent self-capacitance goal, use the following command:

FSCOMPARE_OPTIONS: -np 2 -perc_self 1

To run three clients and pass an LSF option to specify a Red Hat Linux 3.0 operating system,

use the following command:

FSCOMPARE_OPTIONS: -np 3 -b "' -R rhel30'"

To run four clients using an AMD64 architecture with a 10 percent coupling capacitance and

one percent self-capacitance goal, use the following command:

FSCOMPARE_OPTIONS: -np 4 -a amd64 -perc_coup 10 -perc_self 1

See Also

•EXTRACTION: FSCOMPARE

•FS_EXTRACT_NETS

•FSCOMPARE_COUPLING_RATIO

•FSCOMPARE_THRESHOLD

Chapter 17: StarRC Commands

FSCOMPARE_THRESHOLD 17-59

Chapter 17: StarRC Commands

FSCOMPARE_THRESHOLD 17-59

StarRC User Guide and Command Reference Version F-2011.06

FSCOMPARE_THRESHOLD

Specifies the minimum total capacitance required on a particular net to make it eligible for

comparison in an FSCOMPARE extraction.

Syntax

FSCOMPARE_THRESHOLD: value

Arguments

Argument Description

value A floating-point number greater than or equal to zero.

Default: 1.0e-14

Description

FSCOMPARE_THRESHOLD specifies the minimum total capacitance required on a particular net

to make it eligible for comparison in an FSCOMPARE extraction. The results are filtered by the

field solver values.

The specified value is applied to the capacitance values calculated by the 3-D field solver,

which is Rapid3D by default.

Example

Setting FSCOMPARE_THRESHOLD to zero ensures that no nets are eliminated based on their

capacitance:

FSCOMPARE_THRESHOLD: 0

See Also

•EXTRACTION: FSCOMPARE

•FS_EXTRACT_NETS

•FSCOMPARE_COUPLING_RATIO

•FSCOMPARE_OPTIONS

Chapter 17: StarRC Commands

GDS_FILE 17-60

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

GDS_FILE

Specifies GDSII format files to represent part of the physical layout.

Syntax

GDS_FILE: file1 [file2] ...

Arguments

Argument Description

file1 [file2] ... Name of GDSII file

Default: none

Description

The GDS_FILE command specifies GDSII format files to represent part of the physical layout.

You can specify gzipped and compressed GDSII files for this command.

With LEF_FILE and TOP_DEF_FILE, this command merges GDSII data into LEF MACRO

definitions for SKIP_CELLS to provide a full physical layout representation. When this

command is specified, only the pin shapes from the LEF MACRO are used for the cells

which are defined both by the LEF MACRO and the GDS_FILE. Any material defined within

the OBS section of the LEF MACRO is overwritten and replaced by material defined within

any GDS_FILE cells of the same name. If no matching cell name is found within the

GDS_FILE for a particular DEF cell placement, then the OBS section of the corresponding

LEF MACRO continues to be used for that cell.

The GDS_FILE command

• Can be specified multiple times

• Must be used with the GDS_LAYER_MAP_FILE command

• Cannot be used with the OASIS_FILE command

See Also

•GDS_LAYER_MAP_FILE

•SKIP_CELLS

Chapter 17: StarRC Commands

GDS_LAYER_MAP_FILE 17-61

Chapter 17: StarRC Commands

GDS_LAYER_MAP_FILE 17-61

StarRC User Guide and Command Reference Version F-2011.06

GDS_LAYER_MAP_FILE

Specifies the mapping between the GDSII layer number and layer name in the design

database.

Syntax

GDS_LAYER_MAP_FILE: file_name

Arguments

Argument Description

file_name GDSII layer map file name

Default: none

Description

The GDS_LAYER_MAP_FILE command specifies the mapping between the GDSII layer

number and layer name in the design database whenever GDS_FILE or

METAL_FILL_GDS_FILE is used to import GDSII data into the design database.

Note:

The GDS_LAYER_MAP_FILE command cannot be used with the OASIS_LAYER_MAP_FILE

command.

Chapter 17: StarRC Commands

GDS_LAYER_MAP_FILE 17-62

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

GDS_LAYER_MAP_FILE Syntax

The GDS_LAYER_MAP_FILE uses the following syntax:

database_layer gdsii_layer_number gdsii_datatype

{FLOATING | GROUNDED | IGNORE}

Argument Description

database_layer Specifies the database layer name that is mapped in the MAPPING_FILE.

gdsii_layer_number Specifies the GDSII layer number.

gdsii_datatype Specifies the GDSII data type. If a gdsii_datatype is not specified, then

all data types on a given layer are read.

FLOATING Optional keyword that specifies whether the corresponding fill layer is to

be treated as floating. If METAL_FILL_POLYGON_HANDLING: AUTOMATIC

is specified in the command file, then the fill handling mode FLOATING is

used for the corresponding layer. If METAL_FILL_POLYGON_HANDLING:

AUTOMATIC is not specified, in the command file, this argument in the

GDS_LAYER_MAP_FILE is ignored.

GROUNDED Optional keyword that specifies whether the corresponding fill layer is to

be treated as grounded. If METAL_FILL_POLYGON_HANDLING:

AUTOMATIC is specified in the command file, then the fill handing mode

GROUNDED is used for the corresponding layer. If

METAL_FILL_POLYGON_HANDLING:AUTOMATIC is not specified in the

command file, this argument in the GDS_LAYER_MAP_FILE is ignored.

IGNORE Optional keyword that specifies whether the corresponding fill layer is to

be treated as ignored. If METAL_FILL_POLYGON_HANDLING:AUTOMATIC is

specified in the command file, then the fill handling mode IGNORE is used

for the corresponding layer. If METAL_FILL_POLYGON_HANDLING:

AUTOMATIC is not specified in the command file, this argument in the

GDS_LAYER_MAP_FILE is ignored.

All GDSII layers for translation must have an entry in this file and must have a definition in

the layout database. The GDS_LAYER_MAP_FILE can be used either to import GDS cell

material into a LEF/DEF database (GDS_FILE) or to import metal fill polygons into a

Milkyway, LEF/DEF, or Calibre Connectivity Interface database (METAL_FILL_GDS_FILE). If

both METAL_FILL_GDS_FILE and GDS_FILE are being used in a single run for a LEF/DEF

database, a single unified layer mapping file should be used for both the GDSII files.

An error occurs if any layer is specified in the file for which a corresponding layer does not

exist in the layout database.

Chapter 17: StarRC Commands

GDS_LAYER_MAP_FILE 17-63

Chapter 17: StarRC Commands

GDS_LAYER_MAP_FILE 17-63

StarRC User Guide and Command Reference Version F-2011.06

The additional specification of a layer-specific fill-handling keyword is available to allow

users to selectively decide how individual metal fill layers are handled during parasitic

extraction. This handling is considered only when METAL_FILL_POLYGON_HANDLING:

AUTOMATIC is set in the StarRC command file. If METAL_FILL_POLYGON_HANDLING:

AUTOMATIC is set in the StarRC command file, but a fill-handling mode is not specified for a

particular layer inside GDS_LAYER_MAP_FILE, StarRC assumes a default of FLOATING for

that layer. If another setting of METAL_FILL_POLYGON_HANDLING (other than AUTOMATIC) is

specified in the StarRC command file, that setting governs the handling of all layers, and any

layer-specific mode specifications inside GDS_LAYER_MAP_FILE are disregarded.

Note that in the given example, handling mode GROUNDED is specified for layer DIFF. If

METAL_FILL_POLYGON_HANDLING: AUTOMATIC is also specified in the StarRC command file,

DIFF is treated as GROUNDED while all other layers are treated as FLOATING. If

METAL_FILL_POLYGON_HANDLING:AUTOMATIC is not specified, the layer-specific mode

specification for DIFF is disregarded, and the global mode set by

METAL_FILL_POLYGON_HANDLING takes precedence.

Example

The following example shows how the DIFF layer is assigned to GDSII layer 2 and GDSII

datatype 0. Note that this example maps layers from a METAL_FILL_GDS_FILE and specifies

layer-specific fill handling for the DIFF layer.

Example 17-1 Layer-Specific Fill Handling

DIFF 2 0 GROUNDED

POLY 7 0

CONT 4 0

METAL1 10 0

METAL1 10 1

METAL1 76 0

VIA1 11 0

METAL2 12 0

In the following example, the METAL_FILL_POLYGON_HANDLING: AUTOMATIC command is

set in the command file.

Example 17-2 Automatic Fill Handling

*layer treated as grounded

DIFF 2 0 GROUNDED

*layer treated as floating

POLY 7 0 FLOATING

*layer governed by default floating mode since mode is unspecified.

METAL1 4 0

Chapter 17: StarRC Commands

GDS_LAYER_MAP_FILE 17-64

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

See Also

•GDS_FILE

•LEF_FILE

•METAL_FILL_GDS_FILE

Chapter 17: StarRC Commands

HIERARCHICAL_SEPARATOR 17-65

Chapter 17: StarRC Commands

HIERARCHICAL_SEPARATOR 17-65

StarRC User Guide and Command Reference Version F-2011.06

HIERARCHICAL_SEPARATOR

Specifies the character that defines design hierarchy levels during processing and netlist

creation.

Syntax

HIERARCHICAL_SEPARATOR: | | / | . | :

Arguments

Argument Description

|Pipe (|) character separates hierarchy

/Slash (/) character separates hierarchy

This is the default.

.Period (.) separates hierarchy

:Colon (:) character separates hierarchy

Description

Specifies the character that defines design hierarchy levels during processing and netlist

creation. If hierarchical nets are specified with the NETS command, this character must be

used to derive flattened names for selection. Any literal occurrence of this character in a net

or instance name should be avoided for net selection purposes; attempting to use an illegal

separator results in an error.

Changing the Hierarchical Delimiter in the Final Netlist

The StarRC commands HIERARCHICAL_SEPARATOR and BUS_BIT specify to the tool the

hierarchical delimiter and bus bit format used in the input netlist.

These commands are not used to change the hierarchical delimiter and/or bus bit character

in the final netlist. To make these changes in the netlist, you must either change the input file

or post process the netlist with a script.

Example

This example sets the hierarchical separator to the period (.).

HIERARCHICAL_SEPARATOR: .

Chapter 17: StarRC Commands

HIERARCHICAL_SEPARATOR 17-66

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

See Also

•BUS_BIT

•NETS

Chapter 17: StarRC Commands

HN_NETLIST_MODEL_NAME 17-67

Chapter 17: StarRC Commands

HN_NETLIST_MODEL_NAME 17-67

StarRC User Guide and Command Reference Version F-2011.06

HN_NETLIST_MODEL_NAME

Writes a simulation model name instead of the StarRC model name in the parasitic netlist.

Syntax

No wildcards are allowed in the arguments of this command.

HN_NETLIST_MODEL_NAME: ref_model_name SPICE_model_name

Arguments

Argument Description

ref_model_name The model name in the schematic or layout and is denoted by

MODEL_TYPE.

Default: none

SPICE_model_name The internal database is updated with this SPICE model name

Default: none

Description

Writes a simulation model name instead of the StarRC model name in the parasitic netlist.

When you specify this command, StarRC updates the internal database with the model

name provided in the command file. It also controls the model names in devices from an

ideal netlist output by StarRC with the NETLIST_IDEAL_SPICE_FILE command. The

MODEL_TYPE command determines whether StarRC looks for a reference model in the layout

or schematic netlist.

If the specified model is not present, StarRC issues a warning message.

If the same model name is specified more than once, the last one overrides all the other

settings.

You can map multiple reference models to a single simulation model.

If you specify an XREF_USE_LAYOUT_DEVICE_NAME and HN_NETLIST_MODEL_NAME

command in the same command file, then HN_NETLIST_MODEL_NAME overrides the

XREF_USE_LAYOUT_DEVICE_NAME setting.

Example

HN_NETLIST_MODEL_NAME: my_ref_model MY_SPICE_model

Chapter 17: StarRC Commands

HN_NETLIST_MODEL_NAME 17-68

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

If you have multiple device models, specify the command as follows:

HN_NETLIST_MODEL_NAME: p_dev pmos

HN_NETLIST_MODEL_NAME: pdev2 pmos-2

See Also

•MODEL_TYPE

•NETLIST_IDEAL_SPICE_FILE

Chapter 17: StarRC Commands

HN_NETLIST_SPICE_TYPE 17-69

Chapter 17: StarRC Commands

HN_NETLIST_SPICE_TYPE 17-69

StarRC User Guide and Command Reference Version F-2011.06

HN_NETLIST_SPICE_TYPE

Specifies StarRC netlist standard devices as SPICE .SUBCKT calls beginning with “X”.

Syntax

HN_NETLIST_SPICE_TYPE: device_model_name X

Arguments

Argument Description

device_model_name For a flow based on Hercules, any layout model name

specified in a device extraction command, or any

schematic model name specified in an EQUATE

statement.

For a flow based on Calibre, any model name or netlist

model name specified in a DEVICE command.

Default: none

Description

Specifies StarRC netlist standard devices as SPICE .SUBCKT calls beginning with “X”.

When you specify this command for a standard, non-user-defined ideal device, the SPICE

device card is replaced with an X card in the netlist.

For cases in which multiple device extraction commands match a single

device_model_name specified with HN_NETLIST_SPICE_TYPE, X device names are included

in the netlist for devices from all matching commands.

In Hercules flows, the desired SPICE device name can be set directly in the Hercules runset

using the DEVICE_PREFIX option. This setting is automatically propagated into the StarRC

output netlist without your specifying the HN_NETLIST_SPICE_TYPE command. The Hercules

DEVICE_PREFIX option is defined using a string argument. StarRC only includes the first

character of that string argument in the netlist. See the Hercules documentation for more

details about the option DEVICE_PREFIX.

In the Calibre flow, the device_model_name is automatically read from block.devtab for

model name and model card information:

DEVICE {element_name [(model_name)]} device_layer...

[NETLIST MODEL netlist_model_name] [NETLIST ELEMENT

netlist_element_name]

...

[[property_specification]]

Chapter 17: StarRC Commands

HN_NETLIST_SPICE_TYPE 17-70

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

StarRC treats an element or model name as a layout name and a netlist element name as a

schematic name.

Example

HN_NETLIST_SPICE_TYPE: p X

See Also

•MODEL_TYPE

Chapter 17: StarRC Commands

ICV_ANNOTATION_FILE 17-71

Chapter 17: StarRC Commands

ICV_ANNOTATION_FILE 17-71

StarRC User Guide and Command Reference Version F-2011.06

ICV_ANNOTATION_FILE

Specifies the IC Validator annotation file.

Syntax

ICV_ANNOTATION_FILE: file_name

Arguments

Argument Description

file_name Name of the gzip-format IC Validator annotation file

Default: adp.gz

Description

The ICV_ANNOTATION_FILE command specifies the IC Validator annotation file. This

annotation file is produced by IC Validator to extract advanced device properties efficiently

such as the well-proximity effect (WPE) and the length of diffusion (LOD). This command

also triggers the IC Validator Advanced Device Property (ADP) flow. You do not need the

ICV_ANNOTATION_FILE command in your star_cmd file if the annotation_file statement

exists in your IC Validator runset report file.

The IC Validator annotation file must be compressed into the gzip format.

In this annotation file, a line starting with the asterisk (*) character is considered a comment

and ignored. The annotation file contains ADP data in the SPICE format.

Example

ICV_ANNOTATION_FILE: ./my_icv_adp.gz

Example 17-3 Syntax of the IC Validator Annotation File

- Define File

property_annotation_file (

file = "string" //optional

);

- Initiate ADP Flow

init_device_matrix(dual_hierarchy_extraction=true)

- Write Annotation file

write_annotation_file (

device_db = device_database,

output_file = property_annotation_file_handle,

precision = integer //optional

);

Chapter 17: StarRC Commands

ICV_ANNOTATION_FILE 17-72

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Example 17-4 Example of an IC Validator Annotation File

.SUBCKT mc_co_stld_4x8

M0 sa =0.11u sa1=1.1e-07 sa2=1.1e-07 sa3=1.1e-07 sb=0.29u sb1=2.9e-07

sb2=2.9e-07 sb3=2.9e-07

M1 sa=0.11u sa1=1.1e-07 sa2=1.1e-07 sa3=1.1e-07 sb=0.11u sb1=1.1e-07

sb2=1.1e-07 sb3=1.1e-07

.ENDS

.SUBCKT blkcontrolc

M3 sa=0.29u sa1=2.9e-07 sa2=2.9e-07 sa3=2.9e-07 sb=1.19u sb1=1.19e-06

sb2=1.19e-06 sb3=1.19e-06

M4 sa=1.01u sa1=1.01e-06 sa2=1.01e-06 sa3=1.01e-06 sb=0.47u sb1=4.7e-07

sb2=4.7e-07 sb3=4.7e-07 sca=1.19602 scb=1.91168e-06 scc=2.37977e-12

spa=1.4e-07 spa1=1.4e-07 spa2=1.4e-07 spba=1e-06

X1/M2 sa=1.01u sa1=1.01e-06 sa2=1.01e-06 sa3=1.01e-06 sb=0.47u

sb1=4.7e-07 sb2=4.7e-07 sb3=4.7e-07 sca=1.19602 scb=1.91168e-06

scc=2.37977e-12 spa=1.4e-07 spa1=1.4e-07 spa2=1.4e-07 spba=1e-06

.ENDS

See Also

•ICV_RUNSET_REPORT_FILE

Chapter 17: StarRC Commands

ICV_RUNSET_REPORT_FILE 17-73

Chapter 17: StarRC Commands

ICV_RUNSET_REPORT_FILE 17-73

StarRC User Guide and Command Reference Version F-2011.06

ICV_RUNSET_REPORT_FILE

Specifies the IC Validator runset report file and activates the IC Validator flow.

Syntax

ICV_RUNSET_REPORT_FILE: file_name

Arguments

Argument Description

file_name IC Validator runset report file name

Default: pex_runset_report

Description

The IC Validator runset report file contains information that IC Validator provides to StarRC

for an RC extraction, such as the location of the LVS COMPARE output, the connection

information, the device pin and properties information, and the location of the extract view.

When the ICV_RUNSET_REPORT_FILE command is used, the MILKYWAY_EXTRACT_VIEW

command is set to YES. In addition, the MILKWAY_DATABASE, MAPPING_FILE,

COMPARE_DIRECTORY, and OA_LAYER_MAPPING_FILE commands become optional. If these

optional commands are specified in the StarRC command file, then the values in the StarRC

command file override the values in the IC Validator runset report file.

Example

ICV_RUNSET_REPORT_FILE: my_icv_rrf

See Also

•COMPARE_DIRECTORY

•MAPPING_FILE

•MILKYWAY_DATABASE

•MILKYWAY_EXTRACT_VIEW

•OA_LAYER_MAPPING_FILE

Chapter 17: StarRC Commands

IGNORE_CAPACITANCE 17-74

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

IGNORE_CAPACITANCE

Syntax

IGNORE_CAPACITANCE: ALL [RETAIN_GATE_DIFFUSION_COUPLING] | DIFF | NONE

Arguments

Argument Description

ALL Prohibits the xTractor program from calculating capacitance

between diffusion regions and the substrate, as well as between

the transistor gates and diffusion regions or substrate. Both

overlap and sidewall effects are ignored.

This is the default.

RETAIN_GATE_DIFFUSION_CO

UPLING

Retains gate-to-diffusion coupling capacitance.

DIFF Ignores only the junction capacitance. The gate capacitance is

included.

NONE Includes all parasitic capacitance.

Description

Prevents certain types of device-level capacitances from being extracted and netlisted.

Note:

IGNORE_CAPACITANCE is a device-level command and affects only parasitic output

related to transistor devices.

This command is typically used to identify and separate certain types of parasitic

capacitance from appearing in the transistor-level netlist because the primitive device

models already account for those types.

The IGNORE_CAPACITANCE command applies to capacitive effects internal to each individual

device in the runset. For the highest accuracy, IGNORE_CAPACITANCE: ALL | DIFF does

not exclude capacitive effects between a device and its neighbors because these interdevice

effects are not accounted for in the device model, as shown in Figure 17-2.

The following example contains two MOS devices:

NMOS N ngate nsd nsd SUBSTRATE { } TEMP=ndev_out

Chapter 17: StarRC Commands

IGNORE_CAPACITANCE 17-75

Chapter 17: StarRC Commands

IGNORE_CAPACITANCE 17-75

StarRC User Guide and Command Reference Version F-2011.06

PMOS P pgate psd psd NWELL { } TEMP=pdev_out

Table 17-2 lists the command interactions.

Table 17-2 Command Interactions if IGNORE_CAPACITANCE: ALL

StarRC ignores the following interactions if

IGNORE_CAPACITANCE: ALL

StarRC retains the following interactions if

IGNORE_CAPACITANCE: ALL

ngate-SUBSTRATE

nsd-nsd

ngate-nsd

nsd-SUBSTRATE

pgate-NWELL

psd-psd

pgate-psd

psd-NWELL

ngate-pgate

nsd-psd

ngate-psd

pgate-nsd

ngate-NWELL

nsd-NWELL

This means that interdevice capacitive effects that are not accounted for in the device model

are included in the parasitic netlist. For IGNORE_CAPACITANCE to be most effective and

accurate, it is very important that device layers in the runset be separated from other

connected layers, that is, in the CONNECT sequence of runset, that conflict with them.

For example, if nsd and psd are derived from input layer DIFF, PPLUS and NPLUS, and

DIFF is also a final CONNECT layer, the following Boolean sequence is required:

• BOOLEAN DIFF not nsd { } TEMP=DIFF

• BOOLEAN DIFF not psd { } TEMP=DIFF

This is critical because since the DIFF layer is not used in a device, it is not identifiable as a

diffusion layer. Therefore, its parasitic contribution to both N and P devices cannot be

ignored by StarRC. In other words, DIFF is not an N or P device layer, so it must be assumed

to be part of the unmodeled environment.

Chapter 17: StarRC Commands

IGNORE_CAPACITANCE 17-76

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Figure 17-2 IGNORE_CAPACITANCE Command

DIFF DIFF DIFF DIFF

Gate

Metal

Substrate

10 98

998

11 11

2222

1212212

DIODE

MOS MOS

Gate

IGNORE_CAPACITANCE:NONE (numbers 1-15 are extracted.)

IGNORE_CAPACITANCE:DIFF (numbers 4-15 are extracted.)

IGNORE_CAPACITANCE:ALL (numbers 4, 8-15 are extracted.)

When the calculation is done for netlist reduction to reduce the nodes with error control,

small coupling capacitors are moved around their individual nodes to attach to one of the

neighboring nodes. In such a situation, some device terminal nodes get coupling

capacitances even if the coupling capacitance is not associated with them irrespective of the

IGNORE_CAPACITANCE setting.

Retaining Gate-to-Diffusion Coupling Capacitance

To retain the gate-to-diffusion (Cf) coupling component when IGNORE_CAPACITANCE:ALL is

specified, use the RETAIN_GATE_DIFFUSION_COUPLING suffix:

IGNORE_CAPACITANCE: ALL RETAIN_GATE_DIFFUSION_COUPLING

When this suffix is specified, StarRC has two methods for extracting the gate-to-diffusion

component:

• Based on precharacterized models, similar to other capacitances extracted by StarRC

• Based on a 2-D capacitance table look-up dependent on layout parameters

Chapter 17: StarRC Commands

IGNORE_FIELDPOLY_DIFFUSION_COUPLING 17-77

Chapter 17: StarRC Commands

IGNORE_FIELDPOLY_DIFFUSION_COUPLING 17-77

StarRC User Guide and Command Reference Version F-2011.06

IGNORE_FIELDPOLY_DIFFUSION_COUPLING

Syntax

IGNORE_FIELDPOLY_DIFFUSION_COUPLING: YES | [NO]

Arguments

Argument Description

NO Retains field poly to diffusion capacitance.

This is the default.

YES Excludes field poly coupling capacitances during

extraction.

Description

Extracts the field poly to diffusion coupling. Although the capacitance effect may be small

from orthogonal coupling capacitance as shown in Figure 17-3, at lower technology nodes it

might have a capacitance impact. Given the large number of field poly connections in a

design, this can have a large impact on the circuit performance.

This command allows you the flexibility to ignore fieldpoly diffusion coupling when this

coupling effect is already included in the SPICE model.

This command supports all transistor-level flows that are Hercules or Calibre based.

Figure 17-3 Field Poly to Diffusion Ignored by Default

DiffDiff

Gate

Top and Bottom Top Only Bottom Only

DiffDiff

Gate

DiffDiff

Gate

Chapter 17: StarRC Commands

IGNORE_FIELDPOLY_DIFFUSION_COUPLING 17-78

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

See Also

•IGNORE_CAPACITANCE

Chapter 17: StarRC Commands

INCREMENTAL 17-79

Chapter 17: StarRC Commands

INCREMENTAL 17-79

StarRC User Guide and Command Reference Version F-2011.06

INCREMENTAL

Syntax

INCREMENTAL: YES | NO

Arguments

Argument Description

YES Enables incremental extraction. This is supported with SPEF and

SBPF formats only. If NETLIST_FORMAT is specified other than

SPEF or SBPF, then StarRC issues an error. A partial coupling

report is generated if the COUPLING_REPORT_FILE is specified.

NO Produces a full-chip parasitic netlist in all formats. This is the

default argument and also controls the content of the coupling

report. A partial coupling report is generated if the

COUPLING_REPORT_FILE command is specified.

This is the default.

Description

Enables use of the previous extraction results in the STAR directory by doing a comparison

with the new, post-ECO block and then producing a netlist that includes the changed

parasitics. To create an incremental netlist that only contains the changed parasitics, the

NETLIST_INCREMENTAL:YES option can be enabled.

Note:

You should perform a final full-chip extraction, using INCREMENTAL:NO and timing

analysis, for the final sign-off timing analysis. If StarRC detects no changes or too many

changes in the post-ECO block, StarRC produces an error message informing you to

perform extraction using INCREMENTAL: NO. If too many changes are applied to a block,

there is very little savings in runtime, and it is better to produce a fully accurate netlist.

For more information about incremental extraction flows and restricted commands, see

Chapter 5, “Incremental Extraction.”

Chapter 17: StarRC Commands

INCREMENTAL 17-80

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Example

BLOCK: TOP_Post-ECO

MILKYWAY_DATABASE: design

TCAD_GRD_FILE: nxtgrd_file

MAPPING_FILE: map

NETLIST_FORMAT: SPEF

INCREMENTAL: YES

NETLIST_INCREMENTAL: YES

See Also

•INCREMENTAL_FORCE_DP

•NETLIST_INCREMENTAL

Chapter 17: StarRC Commands

INCREMENTAL_FORCE_DP 17-81

Chapter 17: StarRC Commands

INCREMENTAL_FORCE_DP 17-81

StarRC User Guide and Command Reference Version F-2011.06

INCREMENTAL_FORCE_DP

Enables distributed processing with incremental extraction.

Syntax

INCREMENTAL_FORCE_DP: YES | NO

Arguments

Argument Description

YES Enables distributed processing with incremental extraction.

NO Does not enable distributed processing.

This is the default.

Description

Enables distributed processing with incremental extraction in the following ways:

• The pre-ECO full extraction and post-ECO incremental extraction can be run on the same

number of CPUs in parts.

• Pre-ECO full extraction can be run on multiple CPUs and post-ECO incremental can be

run on a single CPU.

If you are using distributed processing, the number of partitions between the pre-ECO and

post-ECO extraction should be the same.

Note:

StarRC supports a LEF file that has been gzipped and compressed.

Example

In the following example, one partition is used for incremental extraction. This is the default.

NUM_PARTS:N

INCREMENTAL:YES

INCREMENTAL_FORCE_DP:NO

See Also

•INCREMENTAL

•NUM_PARTS

Chapter 17: StarRC Commands

INSTANCE_PORT 17-82

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

INSTANCE_PORT

Applies different parasitic resistance extraction modes to different groups of instance ports

in a single extraction run.

Syntax

INSTANCE_PORT: [CONDUCTIVE [SUFFIXED [MULTIPLE] | CAPACITIVE]

| NOT_CONDUCTIVE | SUPERCONDUCTIVE | EXPLODE]

[[CELL wildcard] [INST wildcard]

[PORT wildcard]]

Arguments

Argument Description

CONDUCTIVE Enables resistance extraction for the ports of skip cell instances.

Therefore, feed through resistance of selected instance ports are

preserved.

This is the default.

The supplemental modes available are SUFFIXED or

CAPACITIVE. The SUFFIXED mode can be specified with or

without MULTIPLE.

NOT_CONDUCTIVE Similar to the CONDUCTIVE MULTIPLE SUFFIXED option, with

the exception of the port resistance not being netlisted. If the

top-level material overlaps with the instance port, the

conductance of the overlapping part of the top-level material is

not reported, either. See also “Long Ports” on page 15-15.

SUPERCONDUCTIVE When specified for a SKIP_CELLS port, the port is extracted as

an ideal node with zero resistivity.

EXPLODE Promotes all selected instance port material to the top level, and

marks it as part of the top-level net connecting it. No port nodes

are generated for instance ports selected for EXPLODE

extraction.

CELL Specifies a layout cell name.

INST Specifies a layout instance name.

PORT Specifies a layout port name.

Chapter 17: StarRC Commands

INSTANCE_PORT 17-83

Chapter 17: StarRC Commands

INSTANCE_PORT 17-83

StarRC User Guide and Command Reference Version F-2011.06

Description

Applies different parasitic resistance extraction modes to different groups of instance ports

in a single extraction run.

The INSTANCE_PORT command has four basic modes:

•CONDUCTIVE

•NOT_CONDUCTIVE

•SUPERCONDUCTIVE

•EXPLODE

For the CONDUCTIVE MULTIPLE and NOT_CONDUCTIVE modes, the number of port nodes is

determined by the top-level resistive interaction regions while the CONDUCTIVE mode only

one port node is created.

The INSTANCE_PORT option can be selectively applied to specific cells and/or instances,

and/or ports. Only layout CELL, PORT, and INST names may be specified in these arguments.

The default for all three selections is “*.”

No escape mechanism is provided for the keywords CELL, INST, and PORT in the wildcard

specification.

The INSTANCE_PORT command may be specified multiple times. Each use is cumulative,

and the last definition overrides the previous ones for the INSTANCE_PORT matching the

wildcard.

CONDUCTIVE

By default, one port (*|I) node per instance port is generated and no capacitance is reported

for the port. The location of the node is a point of contact between the port and the top-level

material. This default mode should be sufficient for most applications.

There are three supplemental modes, modifying the default behavior, that can be used

optionally in any combination with INSTANCE_PORT: CONDUCTIVE: SUFFIXED, MULTIPLE,

CAPACITIVE.

•SUFFIXED

If you choose the SUFFIXED option, you modify the port node’s name by having the name

of the instance port attached with a suffix according to the NETLIST_RENAME_PORT

command setting. If the MULTIPLE option is not set, exactly one connection point is

generated, despite the number of interactions between the port and the top-level

material. In the case of no interactions, the location of the node is random within the port.

In the case of the port having multiple connections to the top-level material, only one of

Chapter 17: StarRC Commands

INSTANCE_PORT 17-84

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

them is reported as a port node. If the MULTIPLE option is specified along with the

SUFFIXED option, then all of the connection points are reported as port nodes. In the

case of no interactions, no port nodes is generated. In the case of a large overlap with the

top-level material, multiple connection points are reported.

•MULTIPLE

The MULTIPLE option is meant to be used along with the SUFFIXED option. Use of the

MULTIPLE option without the SUFFIXED option leads to a complicated, indeterminate

behavior that is not supported. For a detailed explanation of MULTIPLE SUFFIXED, see the

SUFFIXED option, earlier.

•CAPACITIVE

The CAPACITIVE option netlists the capacitance of the selected instance ports.

NOT_CONDUCTIVE

If the port resistors are not included in the netlist, there may be disconnected networks.

However, no open warnings is issued, because the net is known to be connected by

feedthrough. Port nodes for a given instance port are generated at every top-level interaction

point. If there is more than one interaction point, multiple port nodes are netlisted. In the

case of no interaction with top-level material, no port nodes is generated.

SUPERCONDUCTIVE

This option instructs StarRC to assume ideal (zero) resistivity when extracting all port

shapes inside the SKIP_CELL. The port shapes effectively act as a short and no resistance

is extracted or netlisted for the port shapes.

EXPLODE

This option instructs StarRC to promote all selected instance port material to the top level

and to mark it as part of the top-level net connecting it. No port nodes are generated for

instance ports selected for EXPLODE extraction.

Note:

No *I or *|I statements are generated for instance ports marked as EXPLODE.

Example

• To select all instance ports as CONDUCTIVE:

INSTANCE_PORT: CONDUCTIVE

• To select all ports in cell ANTENNA for EXPLODE (to the top level) all other instance ports

are still CONDUCTIVE:

INSTANCE_PORT: EXPLODE CELL ANTENNA

Chapter 17: StarRC Commands

INSTANCE_PORT 17-85

Chapter 17: StarRC Commands

INSTANCE_PORT 17-85

StarRC User Guide and Command Reference Version F-2011.06

• To select ports VDD and VSS in all cells to be netlisted with suffixes and multiple times if

you have more than one connection point:

INSTANCE_PORT: CONDUCTIVE MULTIPLE SUFFIXED CELL

* PORT VDD VSS

This causes ports VSS and VDD in ANTENNA to be retained, but all other ports in

ANTENNA are exploded.

• To select all instance ports as CONDUCTIVE SUFFIXED, except for instance ports with

CELL names matching A*, which are NOT_CONDUCTIVE:

INSTANCE_PORT: CONDUCTIVE SUFFIXED

INSTANCE_PORT: NOT_CONDUCTIVE CELL A*

• To select all instance ports matching CELL B* (but not BUF1) PORT VDD* to be

CONDUCTIVE

INSTANCE_PORT: NOT_CONDUCTIVE

INSTANCE_PORT: CONDUCTIVE SUFFIXED CELL A* !AB*

PORT VDD*

Otherwise, instance ports matching CELL A* !AB* PORT VDD* are CONDUCTIVE SUFFIXED

and instance ports matching neither of these conditions is NOT_CONDUCTIVE.

See Also

•NETLIST_RENAME_PORTS

•SKIP_CELLS

Chapter 17: StarRC Commands

INSTANCE_PORT_OPEN_CONDUCTANCE 17-86

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

INSTANCE_PORT_OPEN_CONDUCTANCE

Syntax

INSTANCE_PORT_OPEN_CONDUCTANCE: float

Arguments

Argument Description

float A fixed conductance value for resistors used to connect

members of a port that are not electrically connected inside the

skip cell.

Units: mho

Default: 10

Description

Defines a fixed conductance value for the resistors used to connect members of a port that

are not resistively connected inside of the defined skip cell. This command affects only

CONDUCTIVE instance ports.

This case may happen frequently when the instance port material is not completely ported.

Often, small routing targets at the edges, instead of the entire port, are used as the port

definition. In this case, StarRC inserts resistors with user-defined conductance to prevent

opens in the output netlist. If you are also using the NETLIST_TAIL_COMMENTS command,

the resistor width’s is reported as nine microns to facilitate their identification.

Chapter 17: StarRC Commands

INTRANET_CAPS 17-87

Chapter 17: StarRC Commands

INTRANET_CAPS 17-87

StarRC User Guide and Command Reference Version F-2011.06

INTRANET_CAPS

Syntax

INTRANET_CAPS: YES | NO

Arguments

Argument Description

YES Retains the intranet capacitances during extraction.

NO Eliminates the intranet capacitances during extraction.

This is the default.

Description

Extracts intranet capacitances. These capacitances are defined as coupling capacitances

that have nodes that belong to the same net. Because this command affects extraction, you

must perform a -cleanX run when you change it.

Note:

INTRANET_CAPS is an Xtractor option that eliminates intranet capacitances when

processed. The default is NO, which means that intranet capacitances are eliminated by

default. To have intranet capacitances, you must specify INTRANET_CAPS: YES and do a

-cleanX run.

Chapter 17: StarRC Commands

KEEP_VIA_NODES 17-88

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

KEEP_VIA_NODES

Syntax

KEEP_VIA_NODES: YES | NO

Arguments

Argument Description

YES Preserves original nodes that a via resistor connects.

NO Does not necessarily preserve original nodes.

This is the default.

Description

Defines via nodes as the original nodes that a via resistor connects. The original nodes

might be reduced, or merged with other nodes, depending on the conductor configuration

and reduction used. Turning the mode on preserves such nodes.

See Also

•REDUCTION

Chapter 17: StarRC Commands

LEF_FILE 17-89

Chapter 17: StarRC Commands

LEF_FILE 17-89

StarRC User Guide and Command Reference Version F-2011.06

LEF_FILE

Creates a white-space-delimited list of LEF format files containing complete library cell

descriptions.

Syntax

LEF_FILE: technology_lef library_lef

LEF_FILE: library_lef macro_lef

LEF_FILE: macro_lef custom_lef

Arguments

Argument Description

technology_lef LEF file with the technology information

Default: none

library_lef LEF file with the cell library information

Default: none

macro_lef LEF file with the macro cell information

Default: none

custom_lef LEF file with the custom cell/block information

Default: none

Description

This command, which is mandatory for LEF/DEF flows, can be specified multiple times in a

single command file. The order in which the LEF files are specified is very important.

There are three types of LEF files that can be specified: the technology LEF, the standard

cell LEF, and macro LEF. The technology LEF must be listed first in the command file or in

the graphic user interface. Every layer defined in the technology LEF must be mapped to a

TCAD GRD layer by a MAPPING_FILE entry. Undefined layers that exist in the LEF file cause

StarRC to issue an error and exit. If any of the subsequently specified LEF files contain

additional technology information, it is ignored.

The standard cell LEF and the macro LEF can be listed in any order after the technology

LEF

. A macro LEF description is required for each block defined in a MACRO_DEF_FILE. A

LEF description is required for every member of the SKIP_CELLS list. Gzipped files can be

directly specified in the LEF_FILE command.

Chapter 17: StarRC Commands

LEF_FILE 17-90

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

See Also

•GDS_LAYER_MAP_FILE

•MACRO_DEF_FILE

•MAPPING_FILE

•SKIP_CELLS

Chapter 17: StarRC Commands

LEF_USE_OBS 17-91

Chapter 17: StarRC Commands

LEF_USE_OBS 17-91

StarRC User Guide and Command Reference Version F-2011.06

LEF_USE_OBS

Syntax

LEF_USE_OBS: YES | NO

Arguments

Argument Description

YES Includes the OBS shapes defined in the LEF MACRO and allows

StarRC to extract coupling to these shapes.

This is the default.

NO Uses only the PIN shapes translated from the LEF MACRO

Description

When NO is set, removes all MACRO blockage material from the extraction. LEF_USE_OBS

applies to all SKIP_CELLS commands in your design.

Most LEF MACRO definitions contain groups of shapes under the heading OBS. These are

blockage layers that restrict the top-level router and typically are a close approximation of the

actual cell layout.

This command has no effect on MACRO definitions for which supplemental GDS descriptions

have been provided. A GDS description for LEF MACRO is optional and can be imported

with the GDS_FILE command.

See Also

•GDS_FILE

•SKIP_CELLS

Chapter 17: StarRC Commands

LPE_DEVICES 17-92

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

LPE_DEVICES

Specifies the device model names that follow the LPE_PARAM rules.

Syntax

LPE_DEVICES: param_name device_model_1 [device_model_2 ...]

Arguments

Argument Description

param_name Specifies a user-defined LPE parameter name. The specified

parameter name should match the parameter names specified

by the LPE_PARAM command.

device_model Specifies device models to which the LPE parameter should be

applied.

Description

The LPE_DEVICES specifies the device model names that follow the LPE_PARAM rules. This

command must be used in conjunction with the LPE_PARAM command.

If the list of device models is very long, you can use multiple LPE_DEVICES statements for

the same parameter. The lists of device models are concatenated.

Example

LPE_DEVICES: pre_layout nfet pfet

LPE_DEVICES: nores ncap

See Also

•LPE_PARAM

Chapter 17: StarRC Commands

LPE_PARAM 17-93

Chapter 17: StarRC Commands

LPE_PARAM 17-93

StarRC User Guide and Command Reference Version F-2011.06

LPE_PARAM

Defines a netlist parameter for user-defined instances.

Syntax

LPE_PARAM: param_name mode1 value1 [mode2 value2...] [PINEXCEPT pinIds]

Arguments

Argument Description

param_name The LPE parameter name that you want to use.

mode The extraction mode used to netlist the device.

value Corresponds to flags in the device simulation SPICE model. The

value can be customized based on flows.

PINEXCEPT pinIds Specifies a list of pin indexes to be ignored while checking

extraction mode to compute the value.

Description

The LPE_PARAM command defines a netlist parameter for user-defined instances. The

post-layout parameter is set based on the extraction mode of the nets connected to the

instance of interest. Possible extraction modes include NORC, RC, R, and C.

The command can be used to control, based on a user-defined parameter and value, which

parasitics are taken from simulation SPICE models and which parasitics are extracted by

StarRC.

This command must be used in conjunction with the LPE_DEVICES command.

The PINEXCEPT option causes the list of pin indexes to be ignored while computing the

extraction mode for the device. For example, it could be used to ignore the bulk in a MOS

device (PINEXCEPT 4), so that only the net connected to drain, source and gate would be

taken into account for computing an LPE parameter value.

There can be only one LPE_PARAM definition for each parameter. If multiple LPE_PARAM

definitions exist for a single parameter, then the last definition overrides the previous

definitions.

All extraction modes should be specified in the LPE_PARAM command for completeness.

However, the tool tries to compute the value even if the extraction mode is not specified in

the LPE_PARAM command.

Chapter 17: StarRC Commands

LPE_PARAM 17-94

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

For example, if RC is not described for the nores parameter, then capacitance extraction

has no impact on its value. If capacitance extraction is performed, then tool must use the

NOR value, which is considered the default.

Example

LPE_PARAM: pre_layout_local NORC 1 C 3 R 2 RC 0 PINEXCEPT 4

LPE_PARAM: setres NORC -2 C -2 R 0 RC 0

LPE_PARAM: setcap NORC -1 C 0 R -1 RC 0

See Also

•LPE_DEVICES

Chapter 17: StarRC Commands

MACRO 17-95

Chapter 17: StarRC Commands

MACRO 17-95

StarRC User Guide and Command Reference Version F-2011.06

MACRO

Extracts the specified instance in the context of the specified BLOCK.

Syntax

MACRO: macro_block_instance_name

Arguments

Argument Description

macro_block_instance_name The instance name of the macro block

Description

This extraction mode provides parasitics for nets inside the instance, accounting for the

influence of routes in BLOCK that might run above or adjacent to MACRO nets. The resulting

netlist is a parasitic representation of the MACRO instance as it interacts with the rest of the

chip. All material outside the MACRO instance is grounded.

You must specify BLOCK to use this extraction mode. For the Milkyway and Hercules flows,

the MILKYWAY_DATABASE is the path to the main library that contains BLOCK, not the library

that contains the MACRO definition. In the LEF/DEF flow, the TOP_DEF_FILE and

MACRO_DEF_FILE should be specified just as though BLOCK were going to be extracted. In

general, to execute the MACRO in context extraction, the StarRC job should be configured for

a normal extraction of the BLOCK -then the MACRO instance name can be specified with no

changes to the star_cmd file.

The instance for extraction must have a connected cell description; this means DEF for the

LEF/DEF flow, place and route CEL view for Milkyway flow (not stream-in MACRO blocks), or

any XTR view cell for a Hercules flow.

Note:

Select nets extraction is not supported for MACRO extraction. MACRO instance must have a

connected cell definition.

See Also

•BLOCK

Chapter 17: StarRC Commands

MACRO_DEF_FILE 17-96

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

MACRO_DEF_FILE

Creates a white-space-delimited list of DEF files that define any macros referenced in the

TOP_DEF_FILE.

Syntax

MACRO_DEF_FILE: macro_def_file_name1 macro_def_file_name2 ...

Arguments

Argument Description

macro_def_file_name The file that contains any macro referenced in the

TOP_DEF_FILE

Description

This command can be specified multiple times in a single command file. The ordering of the

list of files is not important, but a LEF_FILE command must be provided for each macro on

this list.

The cells described within a specified MACRO_DEF_FILE may or may not be on the

SKIP_CELLS list. For example, you might go into these macro cells to produce a full-chip flat

netlist, or you might skip them if you are doing hierarchical extraction or analysis. StarRC

does not require any preprocessing to flatten a hierarchical DEF file; the hierarchical DEF is

flattened internally.

Gzipped or compressed DEF files can be directly specified in the MACRO_DEF_FILE

command.

StarRC supports gzipped or compressed DEF files.

See Also

•LEF_FILE

•SKIP_CELLS

•TOP_DEF_FILE

Chapter 17: StarRC Commands

MAGNIFICATION_FACTOR 17-97

Chapter 17: StarRC Commands

MAGNIFICATION_FACTOR 17-97

StarRC User Guide and Command Reference Version F-2011.06

MAGNIFICATION_FACTOR

Performs optical scaling of input data uniformly for all layers.

Syntax

MAGNIFICATION_FACTOR: value

Arguments

Argument Description

value A floating-point number greater than 0.

Default: 1.0

Description

MAGNIFICATION_FACTOR performs optical scaling of input data uniformly for all layers.

Scaling does not affect the connectivity of the layout network.

Specifying a number less than 1 initiates an optical shrink, whereas a number greater than

1 performs an enlargement.

The shrink is done on a database only while reading it.

Your nxtgrd file must contain rules for minimum width, spacing, and tables associated with

the shrunk/increased database.

You cannot use the MAGNIFICATION_FACTOR command together with the

HALF_NODE_SCALE_FACTOR ITF command.

See Also

•HALF_NODE_SCALE_FACTOR

•MAGNIFY_DEVICE_PARAMS

Chapter 17: StarRC Commands

MAGNIFY_DEVICE_PARAMS 17-98

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

MAGNIFY_DEVICE_PARAMS

Controls the behavior of the MAGNIFICATION_FACTOR command.

Syntax

MAGNIFY_DEVICE_PARAMS: YES | NO

Arguments

Argument Description

YES Applies the value specified in the MAGNIFICATION_FACTOR

command to SPICE device parameters.

This is the default.

NO Does not apply the value of the MAGNIFICATION_FACTOR to the

SPICE parameters.

Description

The MAGNIFY_DEVICE_PARAMS command controls the behavior of the

MAGNIFICATION_FACTOR command. When you specify MAGNIFY_DEVICE_PARAMS: YES, all

designed device parameters in the SPICE netlist are multiplied by the factor set by the

MAGNIFICATION_FACTOR command. Table 17-3 lists the designed device parameters that

are affected by the MAGNIFY_DEVICE_PARAMS command.

Table 17-3 Device Parameters Affected By MAGNIFY_DEVICE_PARAMS

Device Type Magnified Parameters

Diode area, pj

Resistor l, w

Capacitor l, w

MOS ad, as, pd, l, w

BJT area

See Also

•MAGNIFICATION_FACTOR

Chapter 17: StarRC Commands

MAPPING_FILE 17-99

Chapter 17: StarRC Commands

MAPPING_FILE 17-99

StarRC User Guide and Command Reference Version F-2011.06

MAPPING_FILE

Specifies the file containing physical layer mapping information between the input database

and the specified TCAD_GRD_FILE.

Syntax

MAPPING_FILE: file_name

Arguments

Argument Description

file_name The mapping file name.

Default: none

Description

This command is mandatory for all flows. Every connected layer must be mapped.

Advanced users can also elect to override sheet resistance values specified in the

TCAD_GRD_FILE by specifying new values in the MAPPING_FILE command.

For more information about mapping files, see Chapter 20, “Mapping File Commands.”

See Also

•TCAD_GRD_FILE

Chapter 17: StarRC Commands

MARKER_GENERATION 17-100

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

MARKER_GENERATION

Indicates how StarXtract should generate PIN shapes for a Hercules database.

Syntax

MARKER_GENERATION: AUTOMATIC | USER

Arguments

Argument Description

AUTOMATIC Specifies that StarRC automatically generates PIN shapes

based on connectivity.

This is the default.

USER Specifies that the user generates the PIN shapes.

Description

Databases generated by Hercules do not generally have a special object to represent a PIN

shape (also referred to as markers). However, StarXtract requires PIN shapes to define the

instance ports.

There are two ways to create PIN shapes in a Hercules database; the first is to identify a

special Hercules output layer that generates the PIN shapes, and the second is to have

StarRC automatically generate PIN shapes, based on connectivity.

For most purposes, using AUTOMATIC is preferable; it’s more robust. Specifying USER allows

more flexibility but requires great care when creating marker shapes and a rigorous

knowledge of the routing methodology to avoid creating opens and shorts in the extraction.

When you are specifying MARKER_GENERATION:USER, there are three techniques for

generating marker (PIN) shapes: text-based markers, ID-layer markers, and

connection-based markers.

Chapter 17: StarRC Commands

MERGE_INSTANCE_PORTS 17-101

Chapter 17: StarRC Commands

MERGE_INSTANCE_PORTS 17-101

StarRC User Guide and Command Reference Version F-2011.06

MERGE_INSTANCE_PORTS

Decreases the effective resistance connecting the schematic port to the rest of the net when

set to YES.

Syntax

MERGE_INSTANCE_PORTS: YES | NO

Arguments

Argument Description

YES Electrically merges together all N ports, which causes the N

branches to be treated as parallel-connected resistive paths

during extraction, netlist reduction, and netlist generation.

NO Matches one of the N layout ports to the single schematic port,

leaving the other N-1 branches as dangling in the parasitic

netlist.

This is the default.

Description

This command is only valid when XREF:COMPLETE is also used. This is shown in Figure 17-4.

For parallel MOS 1 : N (schematic : layout) merging in XREF:COMPLETE flows, this command

electrically merges together all of the N layout instance ports into a single port for netlist

generation on each of the source, drain, and gate nets.

For parallel M : N (schematic : layout) merging in XREF: COMPLETE where N > M,

MERGE_INSTANCE_PORTS electrically merges each of the extra unmatched (N-M) layout ports

with one of the matched M layout ports. The final parasitic netlist contains M ports for each

of the source, drain, and gate nets.

Chapter 17: StarRC Commands

MERGE_INSTANCE_PORTS 17-102

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Figure 17-4 XREF:COMPLETE Parasitic Netlist With MERGE_INSTANCE_PORTS

4W/L * S * S * S

Port locations for 4 MOS in layout

Rmesh1

Rmesh2Rmesh3Rmesh4

4W/L

Rmesh1

Rmesh2Rmesh3Rmesh4

MERGE_INSTANCE_PORTS:NO

(default)

MERGE_INSTANCE_PORTS:YES

* S

See Also

•XREF:COMPLETE

Chapter 17: StarRC Commands

MERGE_MULTI_CORNER 17-103

Chapter 17: StarRC Commands

MERGE_MULTI_CORNER 17-103

StarRC User Guide and Command Reference Version F-2011.06

MERGE_MULTI_CORNER

Syntax

MERGE_MULTI_CORNER: YES_SPLIT_NETLIST YES | NO

Arguments

Argument Description

YES_SPLIT_NETLIST Generates multiple netlist files similar to the NO option, but

maintains the same topology across corners, which is similar to

the YES option.

YES Produces a single parasitic netlist with multiple-corner data.

NO Produces one netlist for each nxtgrd file specified.

This is the default.

Description

Uses a single translation followed by multiple extraction and single or multiple netlist creation

with multiple corners or multiple netlists with different corners. To do a multiple corner

extraction and create a netlist, specify multiple nxtgrd files using the TCAD_GRD_FILE

command along with the MERGE_MULTI_CORNER command.

Reduction is done to maintain node consistency, but an alternative reduction is used when

you specify multiple nxtgrd files using the TCAD_GRD_FILE command. In this way, a

single-corner extraction result with REDUCTION:YES is not identical to a multiple-corner

extraction supplying multiple netlists for the same corner.

When you specify multiple nxtgrd files using the TCAD_GRD_FILE file command with the

MERGE_MULTI_CORNER:NO command, StarRC produces multiple parasitic netlists with

appended suffixes. An example is yourfile0, where 0 refers to the parasitic netlist file with

parasitics from the first nxtgrd file in the TCAD_GRD_FILE command.

When you specify multiple nxtgrd files using the TCAD_GRD_FILE file command with

MERGE_MULTI_CORNER: YES_SPLIT_NETLIST, StarRC generates multiple netlist files, but

maintains the same circuit topology across multiple corners. As with the YES option, you

must specify the REDUCTION:TOPOLOGY option. Be aware that commands affecting the

resistance and capacitance threshold, such as NETLIST_MINRES_THRESHOLD, cannot take

into account all corners. The output is based on the first corner extraction result.

Chapter 17: StarRC Commands

MERGE_MULTI_CORNER 17-104

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

You can specify corresponding temperatures for each corner by specifying the

OPERATING_TEMPERATURE command.

This command works with all netlist formats except SBPF and PARA View (Milkyway).

Errors

Warning Message for Multicorner Extraction

One of the goals of MERGE_MULTI_CORNER:YES is to ensure the nodes are consistent across

the corners. A dangling net has only one *P or a *I, and it is not possible for StarRC to know

where the net starts or ends. For this reason, the reduction is inconsistent across corners,

and the nodes cannot be guaranteed. Therefore, REMOVE_DANGLING_NETS is turned on

automatically with multiple nxtgrd files in TCAD_GRD_FILE and MERGE_MULTI_CORNER:YES.

The warning appears as follows:

WARNING: StarXtract

WARNING: REMOVE_DANGLING_NETS: NO is not valid when used with

TCAD_GRD_FILE:

WARNING: nx_min.nxtgrd

WARNING: nx_typ.nxtgrd

WARNING: nx_max.nxtgrd

WARNING: Setting REMOVE_DANGLING_NETS: YES...

Example

Example 17-5 shows how you specify three nxtgrd files to produce a single parasitic netlist

with multiple-corner data.

Example 17-5 Three nxtgrd Files Produce a Single Parasitic Netlist With Multiple-Corner Data

BLOCK: TOP_my

MILKYWAY_DATABASE: design

MERGE_MULTI_CORNER: YES

TCAD_GRD_FILE: nxtgrd_file1 nxtgrd_file2 nxtgrd_file3

MAPPING_FILE: map

NETLIST_FORMAT: SPEF

Example 17-6 shows how to specify three nxtgrd files to produce multiple parasitic netlists

while maintaining the same topology.

Example 17-6 Three nxtgrd Files Produce a Multiple Parasitic Netlists

BLOCK: TOP_my

MILKYWAY_DATABASE: design

MERGE_MULTI_CORNER: YES_SPLIT_NETLIST

TCAD_GRD_FILE: nxtgrd_file1 nxtgrd_file2 nxtgrd_file3

MAPPING_FILE: map

NETLIST_FORMAT: SBPF

Example 17-7 is an example of a three corner netlist with MERGE_MULTI_CORNER: YES

specified.

Chapter 17: StarRC Commands

MERGE_MULTI_CORNER 17-105

Chapter 17: StarRC Commands

MERGE_MULTI_CORNER 17-105

StarRC User Guide and Command Reference Version F-2011.06

Example 17-7 Three-Corner Netlist

*D_NET *169 8.18417:8.03749:8.51694

*CONN

*I *623:X O *C 37.0000 251.000 *D OR2

*CAP

1 *623:X 0.00945073:0.0116676:0.0126980

*RES

1 *623:X *169:116 0.0253828:0.0107081:0.038392

See Also

•OPERATING_TEMPERATURE

•TCAD_GRD_FILE

Chapter 17: StarRC Commands

MERGE_VIAS_IN_ARRAY 17-106

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

MERGE_VIAS_IN_ARRAY

Specifies whether or not vias in an array are not netlisted separately for parasitic resistance

output.

Syntax

MERGE_VIAS_IN_ARRAY: YES | NO

Arguments

Argument Description

YES Merges resistance value for a via array and reports one

resistance value for the array in the netlist.

This is the default.

NO Netlists each via in an array structure and reports parasitic

resistors between vias in the netlist output with separate

resistance values. You must also specify the KEEP_VIA_NODES

command.

Description

Resistance values between vias can be netlisted by specifying NO. By default, this command

is set to YES to merge vias into one reported resistance.

MERGE_VIAS_IN_ARRAY: YES

MERGE_VIAS_IN_ARRAY: NO

Report one resistance value for array Report each via resistance value

Example

Example 1

MERGE_VIAS_IN_ARRAY:YES

Chapter 17: StarRC Commands

MERGE_VIAS_IN_ARRAY 17-107

Chapter 17: StarRC Commands

MERGE_VIAS_IN_ARRAY 17-107

StarRC User Guide and Command Reference Version F-2011.06

The result of this example is the following output:

13 min_lsb_led[4]:45min_lsb_led[4]:46 0.72000// $a=2.00000 $lvl=5

Example 2

MERGE_VIAS_IN_ARRAY:NO

VIA_COVERAGE_OPTION_FILE: filename

Content of VIA_COVERAGE_OPTION_FILE:

VIA1 {Xrange=100,100;Yrange=100,100;

Landing=100,80,10,40,10;Coverage=100,80,10,40,10}

The result of this example is the following output:

14 min_lsb_led[4]:45 min_lsb_led[4]:46 1.44000 // $a=1.00000 $lvl=5

15 min_lsb_led[4]:54 min_lsb_led[4]:55 1.44000 // $a=1.00000 $lvl=5

See Also

•KEEP_VIA_NODES

•VIA_COVERAGE_OPTION_FILE

Chapter 17: StarRC Commands

METAL_FILL_GDS_FILE 17-108

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

METAL_FILL_GDS_FILE

Specifies the GDSII file containing metal fill data.

Syntax

METAL_FILL_GDS_FILE: file_name

Arguments

Argument Description

file_name Name of GDSII file containing metal fill data

Default: none

Description

The METAL_FILL_GDS_FILE command supports either hierarchical or flat GDSII files. All

shapes on layers mapped by GDS_LAYER_MAP_FILE within the master definition of BLOCK in

METAL_FILL_GDS_FILE and its children are treated as metal fill objects for extraction. All

other data not referenced by the master definition of BLOCK is ignored.

METAL_FILL_POLYGON_HANDLING applies to all shapes imported through the

METAL_FILL_GDS_FILE interface.

The METAL_FILL_GDS_FILE command

• Must be specified together with the GDS_LAYER_MAP_FILE command

• Cannot be used with the METAL_FILL_OASIS_FILE command

Note:

StarRC does not support a flow with metal fill polygons connected to more than one

power net when metal fill polygons are present in a separate GDSII file from the design

database.

When metal fill is embedded in a Milkyway or LEF/DEF database, StarRC reads the data

when you specify a METAL_FILL_GDS_FILE command.

You can specify gzipped and compressed GDS files for this command.

See Also

•GDS_FILE

•GDS_LAYER_MAP_FILE

•METAL_FILL_GDS_FILE_NET_NAME

Chapter 17: StarRC Commands

METAL_FILL_GDS_FILE_NET_NAME 17-109

Chapter 17: StarRC Commands

METAL_FILL_GDS_FILE_NET_NAME 17-109

StarRC User Guide and Command Reference Version F-2011.06

METAL_FILL_GDS_FILE_NET_NAME

Ties metal fill polygons to a power or ground net.

Syntax

METAL_FILL_GDS_FILE_NET_NAME: net_name

Arguments

Argument Description

net_name The layout net name

Default: none

Description

You can use the METAL_FILL_GDS_FILE_NET_NAME command to tie metal fill polygons to a

power or ground net.

The METAL_FILL_GDS_FILE_NET_NAME command

• Must be specified together with METAL_FILL_GDS_FILE and

METAL_FILL_POLYGON_HANDLING: GROUNDED

• Cannot be used with the METAL_FILL_OASIS_FILE_NET_NAME command

See Also

•GDS_LAYER_MAP_FILE

•METAL_FILL_GDS_FILE

•METAL_FILL_POLYGON_HANDLING

Chapter 17: StarRC Commands

METAL_FILL_GDS_MAG 17-110

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

METAL_FILL_GDS_MAG

Specifies the scaling factor that is applied to the GDSII metal fill data.

Syntax

METAL_FILL_GDS_MAG: float_number

Arguments

Argument Description

float_number Magnification factor

Default: 1.0

Description

The METAL_FILL_GDS_MAG command specifies the scaling factor that is applied to the GDSII

metal fill data.

The metal fill offset, specified by the METAL_FILL_GDS_OFFSET command, is not multiplied by

the scaling factor.

Note:

The METAL_FILL_GDS_MAG command cannot be used with the METAL_FILL_OASIS_MAG

command.

Example

In the following example, the length and width of the GDSII metal fill data are multiplied by a

factor of 0.8:

METAL_FILL_GDS_MAG: 0.8

The total entire area of the design would therefore be scaled by a factor of 0.64.

See Also

•METAL_FILL_GDS_FILE

•METAL_FILL_GDS_OFFSET

Chapter 17: StarRC Commands

METAL_FILL_GDS_OFFSET 17-111

Chapter 17: StarRC Commands

METAL_FILL_GDS_OFFSET 17-111

StarRC User Guide and Command Reference Version F-2011.06

METAL_FILL_GDS_OFFSET

Specifies the origin of the metal fill GDSII file.

Syntax

METAL_FILL_GDS_OFFSET: x_coordinate y_coordinate

Arguments

Argument Description

x_coordinate X-coordinate

Units: microns

Default: 0.0

y_coordinate Y-coordinate

Units: microns

Default: 0.0

Description

The METAL_FILL_GDS_OFFSET command specifies the coordinates of the origin of the metal

fill GDSII file. This command does not affect the magnification factor behavior.

Note:

The METAL_FILL_GDS_OFFSET command cannot be used with the

METAL_FILL_OASIS_OFFSET command.

Example

METAL_FILL_GDS_OFFSET: 10.8 5.3

See Also

•METAL_FILL_GDS_FILE

•METAL_FILL_GDS_FILE_NET_NAME

•METAL_FILL_POLYGON_HANDLING

Chapter 17: StarRC Commands

METAL_FILL_OASIS_FILE 17-112

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

METAL_FILL_OASIS_FILE

Specifies the OASIS file containing metal fill data.

Syntax

METAL_FILL_OASIS_FILE: file_name

Arguments

Argument Description

file_name Name of OASIS file containing metal fill data

Default: none

Description

The METAL_FILL_OASIS_FILE command supports either hierarchical or flat OASIS files. All

shapes on layers mapped by OASIS_LAYER_MAP_FILE within the master definition of BLOCK

in METAL_FILL_OASIS_FILE and its children are treated as metal fill objects for extraction.

All other data not referenced by the master definition of BLOCK is ignored.

METAL_FILL_POLYGON_HANDLING applies to all shapes imported through the

METAL_FILL_OASIS_FILE interface.

The METAL_FILL_OASIS_FILE command

• Must be specified together with the OASIS_LAYER_MAP_FILE command

• Cannot be used with the METAL_FILL_GDS_FILE command

Note:

StarRC does not support a flow with metal fill polygons connected to more than one

power net when metal fill polygons are present in a separate OASIS file from the design

database.

When metal fill is embedded in a Milkyway or LEF/DEF database, StarRC reads the data

when you specify a METAL_FILL_OASIS_FILE command.

You can specify gzipped and compressed OASIS files for this command.

See Also

•METAL_FILL_OASIS_FILE_NET_NAME

•OASIS_FILE

•OASIS_LAYER_MAP_FILE

Chapter 17: StarRC Commands

METAL_FILL_OASIS_FILE_NET_NAME 17-113

Chapter 17: StarRC Commands

METAL_FILL_OASIS_FILE_NET_NAME 17-113

StarRC User Guide and Command Reference Version F-2011.06

METAL_FILL_OASIS_FILE_NET_NAME

Ties metal fill polygons to a power or ground net.

Syntax

METAL_FILL_OASIS_FILE_NET_NAME: net_name

Arguments

Argument Description

net_name The layout net name

Default: none

Description

You can use the METAL_FILL_OASIS_FILE_NET_NAME command to tie metal fill polygons to

a power or ground net.

The METAL_FILL_OASIS_FILE_NET_NAME command

• Must be specified together with METAL_FILL_OASIS_FILE and

METAL_FILL_POLYGON_HANDLING: GROUNDED

• Cannot be used with the METAL_FILL_GDS_FILE_NET_NAME command

See Also

•METAL_FILL_OASIS_FILE

•METAL_FILL_POLYGON_HANDLING

•OASIS_LAYER_MAP_FILE

Chapter 17: StarRC Commands

METAL_FILL_OASIS_MAG 17-114

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

METAL_FILL_OASIS_MAG

Specifies the scaling factor that is applied to the OASIS metal fill data.

Syntax

METAL_FILL_OASIS_MAG: float_number

Arguments

Argument Description

float_number Magnification factor

Default: 1.0

Description

The METAL_FILL_OASIS_MAG command specifies the scaling factor that is applied to the

OASIS metal fill data.

The metal fill offset, specified by the METAL_FILL_GDS_OFFSET command, is not multiplied by

the scaling factor.

Note:

The METAL_FILL_OASIS_MAG command ca not be used with the METAL_FILL_GDS_MAG

command.

Example

In the following example, the length and width of the OASIS metal fill data are multiplied by

a factor of 0.8:

METAL_FILL_OASIS_MAG: 0.8

The total entire area of the design would therefore be scaled by a factor of 0.64.

See Also

•METAL_FILL_OASIS_FILE

•METAL_FILL_OASIS_OFFSET

Chapter 17: StarRC Commands

METAL_FILL_OASIS_OFFSET 17-115

Chapter 17: StarRC Commands

METAL_FILL_OASIS_OFFSET 17-115

StarRC User Guide and Command Reference Version F-2011.06

METAL_FILL_OASIS_OFFSET

Specifies the origin of the metal fill OASIS file.

Syntax

METAL_FILL_OASIS_OFFSET: x_coordinate y_coordinate

Arguments

Argument Description

x_coordinate X-coordinate

Units: microns

Default: 0.0

y_coordinate Y-coordinate

Units: microns

Default: 0.0

Description

The METAL_FILL_OASIS_OFFSET command specifies the coordinates of the origin of the

metal fill OASIS file. This command does not affect the magnification factor behavior.

The METAL_FILL_OASIS_OFFSET command cannot be used with the

METAL_FILL_GDS_OFFSET command.

Example

METAL_FILL_OASIS_OFFSET: 10.8 5.3

See Also

•METAL_FILL_OASIS_FILE

•METAL_FILL_OASIS_FILE_NET_NAME

•METAL_FILL_POLYGON_HANDLING

Chapter 17: StarRC Commands

METAL_FILL_POLYGON_HANDLING 17-116

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

METAL_FILL_POLYGON_HANDLING

Translates metal fill polygons into the internal format before performing extraction.

Syntax

METAL_FILL_POLYGON_HANDLING: IGNORE | GROUNDED | FLOATING | AUTOMATIC

Arguments

Argument Description

IGNORE Performs resistance and capacitance extraction without

considering the effect of metal fill polygons. In Milkyway, metal fill

polygons are ignored only if they have the correct ROUTE_TYPE.

This is the default.

GROUNDED Performs extraction by treating metal fill as grounded. By default,

StarRC treats metal fill polygons as connected to a ground net

(net 0) during extraction, unless the Milkyway or LEF/DEF design

database ties the metal fill polygons to a specific power/ground

net name or the METAL_FILL_GDS_FILE_NET_NAME command

is specified for the METAL_FILL_GDS_FILE.

FLOATING Performs extraction by treating the metal fill as floating. This

argument overrides the type of metal fill polygons provided in the

input database. This means that even though the input database

has grounded fill polygons, METAL_FILL_POLYGON_HANDLING

can extract the capacitance as if the fill polygons were floating. It

can also ignore the existence of fill objects in the database.

AUTOMATIC Performs in LEF/DEF, Milkyway place and route databases

automatic extraction by treating metal fill as floating or grounded.

In LEF/DEF, this argument parses the DEF file and translates fill

polygons based on the section in which they appear in the DEF

file.

Be sure to check LEF/DEF documentation for syntax that

requires fill polygon definitions in specific sections.

With Milkyway, this argument translates fills based on the

ROUTE_TYPE being attached to a net ID or not having a net ID

(floating). Both floating and grounded fills are allowed in the same

design as long as they are identified as such correctly.

To ensure that fills are treated properly using AUTOMATIC, you

should use the insert_metal_filler command in IC

Compiler.

Chapter 17: StarRC Commands

METAL_FILL_POLYGON_HANDLING 17-117

Chapter 17: StarRC Commands

METAL_FILL_POLYGON_HANDLING 17-117

StarRC User Guide and Command Reference Version F-2011.06

Description

The METAL_FILL_POLYGON_HANDLING command translates metal fill polygons into the

internal format before performing extraction. This process depends on the setting of this

command. If metal fill polygons are written into the FILL view in the Milkyway database, you

need to also set the MILKYWAY_ADDITIONAL_VIEWS command in StarRC.

Table 17-4 explains the usage of commands related to the METAL_FILL_POLYGON_HANDLING

command.

Table 17-4 Usage of Commands Related to the METAL_FILL_POLYGON_HANDLING

Command

Related Command Usage of Related Command

METAL_FILL_GDS_FILE_NET_NAME METAL_FILL_GDS_FILE_NET_NAME is required when you want to tie

metal fill polygons to a power or ground net. The net name should

match the layout net name. This command works only when the

METAL_FILL_POLYGON_HANDLING command is set to GROUNDED.

METAL_FILL_GDS_FILE METAL_FILL_GDS_FILE supports either hierarchical or flat GDSII

files. The cell name of the GDS file must be the same as the BLOCK

name, or top cell name of the design. The cell name requirement is

the same for the hierarchical METAL_FILL_GDS_FILE command.

GDS_LAYER_MAP_FILE GDS_LAYER_MAP_FILE is used to specify the mapping between the

GDSII layer number and the layer name in the design database.

GDS_FILE If the GDS_FILE command is specified for a LEF/DEF database, a

single unified layer mapping file should be used for both GDSII

files.

Example

This command treats the metal fill polygons as grounded:

METAL_FILL_POLYGON_HANDLING: GROUNDED

See Also

•GDS_FILE

•GDS_LAYER_MAP_FILE

•METAL_FILL_GDS_FILE

•METAL_FILL_GDS_FILE_NET_NAME

•MILKYWAY_ADDITIONAL_VIEWS

Chapter 17: StarRC Commands

METAL_SHEET_OVER_AREA 17-118

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

METAL_SHEET_OVER_AREA

Specifies an area for sheet metal coupling capacitance measurement.

Syntax

METAL_SHEET_OVER_AREA: layer_name X1 Y1 X2 Y2

Arguments

Argument Description

layer_name Metal layer name

Default: none

X1 Y1 Lower-left coordinates of the area

Default: none

X2 Y2 Upper-right coordinates of the area

Default: none

Description

One or more areas can be designated with repeated use of this command. You can

associate a single or multiple sheets of metal to a user-defined net name and output suffix.

This command is used together with the SHEET_COUPLE_TO_NET command for net naming

capability. You can optionally specify the SHEET_COUPLE_TO_NET_LEVEL command to

enable a net name suffix.

You must verify that the sheet metal areas do not cause metal shorts.

StarRC does not check for areas of metal that overlay each other.

StarRC checks that the layer name specified is a metal layer.

StarRC checks the correctness of the bounding box coordinate values.

Example

METAL_SHEET_OVER_AREA: METAL2 0 0 100 100

METAL_SHEET_OVER_AREA: METAL2 200 200 400 400

METAL_SHEET_OVER_AREA: METAL4 0 0 100 100

SHEET_COUPLE_TO_NET: zone_sheet

SHEET_COUPLE_TO_NET_LEVEL: YES

Chapter 17: StarRC Commands

METAL_SHEET_OVER_AREA 17-119

Chapter 17: StarRC Commands

METAL_SHEET_OVER_AREA 17-119

StarRC User Guide and Command Reference Version F-2011.06

See Also

•SHEET_COUPLE_TO_NET

•SHEET_COUPLE_TO_NET_LEVEL

Chapter 17: StarRC Commands

MILKYWAY_ADDITIONAL_VIEWS 17-120

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

MILKYWAY_ADDITIONAL_VIEWS

Specifies a Milkyway view.

Syntax

MILKYWAY_ADDITIONAL_VIEWS: view_name

Arguments

Argument Description

view_name Name of the additional view

Default: none

Description

Milkyway stores design data in different files called views inside a generated Milkyway

library. Use this command to read views other than CEL, FRAM, TIM, PWR, or LM views. The

previously listed views are automatically read by StarRC. This command causes StarRC to

read an additional view.

See the Milkyway documentation for a complete list of output views.

Example

MILKYWAY_ADDITIONAL_VIEWS: FILL

See Also

•METAL_FILL_POLYGON_HANDLING

Chapter 17: StarRC Commands

MILKYWAY_CELL_VIEW 17-121

Chapter 17: StarRC Commands

MILKYWAY_CELL_VIEW 17-121

StarRC User Guide and Command Reference Version F-2011.06

MILKYWAY_CELL_VIEW

Creates a white-space-delimited list specifying cells that StarRC uses as the layout cell view.

Syntax

MILKYWAY_CELL_VIEW: cell1 cell2 cell3 ... celln

MILKYWAY_CELL_VIEW: cellA !cellB cell? *C ...

MILKYWAY_CELL_VIEW: * !RAM*

Arguments

Argument Description

cell1 cell2 cell3 ... Specifies the cell name for which StarRC uses the layout cell

view during extraction, if available.

Default: none

Description

This command creates a white-space-delimited list specifying cells that StarRC uses as the

layout cell view (Milkyway CEL view) during extraction if it is available. You can specify this

command multiple times in a single command file. The asterisk (*), question mark (?), and

exclamation mark (!) wildcard characters are acceptable.

Note:

This command applies to SKIP_CELLS and their children only; CEL view is always used

for non-SKIP_CELL masters.

For SKIP_CELLS not on this list, the Milkyway FRAM view represents the cell contents during

extraction. The FRAM view typically contains all pin shapes and obstructions.

StarRC attempts to translate the Milkyway cell view for each SKIP_CELLS on this list. The

cell view contains the actual physical layout, including nonroute layers. Specifying a cell in

this list automatically includes all children of the cell. If a cell view cannot be found for a cell

contained in this list, StarRC issues a warning and reverts to the frame view for that cell and

all children of the cell.

See Also

•SKIP_CELLS

Chapter 17: StarRC Commands

MILKYWAY_DATABASE 17-122

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

MILKYWAY_DATABASE

Specifies the location of the input Milkyway layout database.

Syntax

MILKYWAY_DATABASE: layout_library

Arguments

Argument Description

layout_library The name of the layout library from the Milkyway database.

Default: none.

Description

The MILKYWAY_DATABASE command is mandatory for a Milkyway or Hercules extraction flow.

Note:

You must specify the BLOCK for extraction.

See Also

•BLOCK

Chapter 17: StarRC Commands

MILKYWAY_EXPAND_HIERARCHICAL_CELLS 17-123

Chapter 17: StarRC Commands

MILKYWAY_EXPAND_HIERARCHICAL_CELLS 17-123

StarRC User Guide and Command Reference Version F-2011.06

MILKYWAY_EXPAND_HIERARCHICAL_CELLS

Flattens any cell instance that has the cell type or property macro and is routed.

Syntax

MILKYWAY_EXPAND_HIERARCHICAL_CELLS: YES | NO

Arguments

Argument Description

YES StarRC flattens the cell types that are routed in the Milkyway

database and to run extraction.

NO StarRC does not flatten macro or routed cells.

This is the default.

Description

For this command, “routed” means any cell that contains one or more nets or more than one

instance placement. Any other cell type remains a SKIP_CELLS.

This command function is not related to the MACRO StarRC command.

MILKYWAY_EXPAND_HIERARCHICAL_CELLS automatically configures the SKIP_CELLS list and

takes precedence over the SKIP_CELLS command.

See Also

•SKIP_CELLS

Chapter 17: StarRC Commands

MILKYWAY_EXTRACT_VIEW 17-124

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

MILKYWAY_EXTRACT_VIEW

Syntax

MILKYWAY_EXTRACT_VIEW: YES | NO

Arguments

Argument Description

YES StarRC reads the Milkyway XTR view.

NO StarRC does not read the Milkyway XTR view.

This is the default.

Description

Selects the XTR (Milkyway extract view) layout description as the input for your StarRC

extraction. This command is mandatory for a Hercules flow.

Errors

For StarRC to read in data correctly from Hercules output, you must specify

MILKYWAY_EXTRACT_VIEW: YES. If MILKYWAY_EXTRACT_VIEW is not set, StarRC treats the

Milkyway library that was generated by Hercules as if it were a library generated by

Synopsys physical design tools and displays the following message:

WARNING: cannot open milkyway cell top:CEL!

See Also

•BLOCK

•MILKYWAY_DATABASE

•POWER_NETS

Chapter 17: StarRC Commands

MILKYWAY_REF_LIB_MODE 17-125

Chapter 17: StarRC Commands

MILKYWAY_REF_LIB_MODE 17-125

StarRC User Guide and Command Reference Version F-2011.06

MILKYWAY_REF_LIB_MODE

Specifies the order in which libraries are searched for a cell master.

Syntax

MILKYWAY_REF_LIB_MODE: NO | HIER | FILE

Arguments

Argument Description

NO The cell is first searched for in the reference library. The search

order for the reference library is the same as it is in the main

design library.

This is the default.

HIER The child cell is searched for in the same library as its parent

library. If the child cell is not found, the default mode is used.

FILE A reference control file in the main library specifies which

reference library is checked first. The specified order is followed

to find and open the cell.

Description

When extracting Milkyway databases, the MILKYWAY_REF_LIB_MODE command controls the

search preference among libraries and reference libraries for the cell master.

Note:

If you use IC Compiler for place and route, you should specify

MILKYWAY_REF_LIB_MODE: HIER to follow the same search sequence as IC Compiler.

Other tools use different commands or options to specify the library search order. See the

documentation for those tools for more details to ensure that you specify a consistent search

order throughout your entire design flow.

Example

Example 17-8

[ Top/top lib ] --[A1/(instantiated from cell A)]

| - Cell A

|----------[ lib1/ref lib] - cell A

In the library structure shown in Example 17-8, if you specify

MILKYWAY_REF_LIB_MODE: NO, StarRC uses Cell A in ref lib 1. If you specify

MILKYWAY_REF_LIB_MODE: HIER, StarRC uses Cell A in the main library.

Chapter 17: StarRC Commands

MILKYWAY_REF_LIB_MODE 17-126

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Example 17-9

[ Top/top lib ] --[A1/(instantiated from cell A)]

|----------[ lib1/ref lib] - cell A

|----------[ lib2/ref lib] - cell A

In the library structure shown in Example 17-9, StarRC uses ref lib/lib1 cell A for instance

A1.

Example 17-10

[ Top/top lib ] --[A1/(instantiated from cell A]

|----------[ lib1/ref lib] - cell A

|----------[ lib2/ref lib] - cell A

In the library structure shown in Example 17-10, StarRC uses ref lib/lib 1.

See Also

•MILKYWAY_DATABASE

Chapter 17: StarRC Commands

MODE 17-127

Chapter 17: StarRC Commands

MODE 17-127

StarRC User Guide and Command Reference Version F-2011.06

MODE

Sets the level of extraction accuracy versus speed.

Syntax

MODE: 200 | 400

Arguments

Argument Description

200 Provides the best balance between runtime performance and accuracy

compared to Rapid3D. Use this mode for faster extraction turnaround-time.

This is the default.

400 Provides the best accuracy compared to Rapid3D. Use this mode for higher

extraction accuracy.

Description

The MODE command specifies the level of accuracy versus speed.

Example

The following example sets the mode to 400:

MODE: 400

See Also

•EXTRACTION

Chapter 17: StarRC Commands

MODEL_TYPE 17-128

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

MODEL_TYPE

Syntax

MODEL_TYPE: LAYOUT | SCHEMATIC

Arguments

Argument Description

LAYOUT The reference model has been generated from a layout.

This is the default.

SCHEMATIC The reference model has been generated from a schematic. This

setting is not allowed with the XREF:NO command.

Description

Specifies whether the reference model comes from a layout or schematic in

HN_NETLIST_MODEL_NAME, RETAIN_CAPACITANCE_CAP_MODELS, or

HN_NETLIST_SPICE_TYPE.

If MODEL_TYPE is not specified in the command file, it is assumed to be LAYOUT.

StarRC reports the layout net names generated by Hercules/Calibre during ideal layout

extraction.

XREF Command Setting Behavior

XREF:YES|COMPLETE

(for schematic model name output)

Prints schematic model name in the parasitic netlist.

(default)

XREF:NO Prints the layout model name. (default)

XREF:YES

(for layout model name output)

Set XREF_USE_LAYOUT_DEVICE_NAME:YES in the

command file.

Example

MODEL_TYPE: SCHEMATIC

HN_NETLIST_MODEL_NAME:myrcxtmodel mysim_modelname

Chapter 17: StarRC Commands

MODEL_TYPE 17-129

Chapter 17: StarRC Commands

MODEL_TYPE 17-129

StarRC User Guide and Command Reference Version F-2011.06

See Also

•XREF

•HN_NETLIST_MODEL_NAME

•HN_NETLIST_SPICE_TYPE

•RETAIN_CAPACITANCE_CAP_MODELS

Chapter 17: StarRC Commands

MOS_GATE_CAPACITANCE 17-130

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

MOS_GATE_CAPACITANCE

Syntax

MOS_GATE_CAPACITANCE: float

Arguments

Argument Description

float MOS gate capacitance

Units: farads per square micron

Default: 1e-15, but defaults to zero for advanced device property

(ADP) extraction.

Description

Specifies a global loading capacitance per unit area (in square microns) for MOS gate

terminals in the Detailed Standard Parasitic Format (DSPF) and SPEF connectivity sections

(*|I and *I, respectively) of the output parasitic netlist. Only devices generated by the

Hercules commands NMOS and PMOS are assigned this capacitance. In addition, all MOS

gates are netlisted with direction “I”.

Chapter 17: StarRC Commands

MOS_GATE_DELTA_RESISTANCE 17-131

Chapter 17: StarRC Commands

MOS_GATE_DELTA_RESISTANCE 17-131

StarRC User Guide and Command Reference Version F-2011.06

MOS_GATE_DELTA_RESISTANCE

Syntax

MOS_GATE_DELTA_RESISTANCE: YES | NO

Arguments

Argument Description

YES The gate resistance is extracted as delta with one node at the

center of the gate and two nodes (one each) at the edge of the

gate. See Figure 17-5.

NO Does not extract delta resistance.

This is the default.

Description

Extracts the gate resistance of MOS devices as a delta to facilitate the modeling of gate

resistance using a 1/3 (instead of 1/2) scaling factor.

With MOS_GATE_DELTA_RESISTANCE:NO (default), an aggregate gate resistance of 1/2 Rg

appears in the parasitic netlist. An aggregate gate resistance value of 1/3 Rg is achieved by

modeling a delta circuit along the gate polygon length. The nodes of the delta circuit include

the two end nodes of the gate polygon, as well as the center node identified by the ideal

device extraction tool as the gate terminal's physical x, y position. Scaling factors are used

for each of the three legs of the delta circuit to achieve an aggregate resistance of the

following:

• 1/3 Rg for current entering the gate polygon from either end, and entering the MOS

device at the center node.

• 1 Rg for current flowing through the entire length of the gate polygon and not entering the

MOS device.

Note:

A negative resistor appears in the parasitic netlist to represent the delta circuit leg directly

adjoining the two end nodes of the gate polygon in Figure 17-5.

Chapter 17: StarRC Commands

MOS_GATE_DELTA_RESISTANCE 17-132

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Figure 17-5 Resistance Network Showing MOS_GATE_DELTA_RESISTANCE Command

N1 N1

-1/2 Rg

1/6 Rg1/6 Rg

Chapter 17: StarRC Commands

NET_SEGMENT_CUT_LENGTH 17-133

Chapter 17: StarRC Commands

NET_SEGMENT_CUT_LENGTH 17-133

StarRC User Guide and Command Reference Version F-2011.06

NET_SEGMENT_CUT_LENGTH

Specifies the length of a cut segment.

Syntax

NET_SEGMENT_CUT_LENGTH: cut_length

Arguments

Argument Description

cut_length Length of cut segment

Units: microns

Default: 20

Description

StarRC cuts polygons of straight paths along their lengths. You can use the

NET_SEGMENT_CUT_LENGTH command to specify the length of a cut segment. This feature

provides higher extraction accuracy for designs that run at high frequencies.

The length of each resulting segment must be at least twice the width of the path. A cut is

not made if it would result in a segment that is shorter than twice the width of the path.

If you enable netlist reduction with the REDUCTION command, then the additional nodes

created by NET_SEGMENT_CUT_LENGTH are merged based on error control.

Chapter 17: StarRC Commands

NET_SEGMENT_CUT_LENGTH 17-134

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Example

NET_SEGMENT_CUT_LENGTH: 20

Figure 17-6 shows one-micron wide paths cut into 20-micron segments, with the exception

of the last segments. In Case 1, the length of the last segment is nine microns, which is more

than twice the width of the path. Since the length of each segment must be at least twice the

width of the path, the second cut is not made in Case 2; therefore, the length of the last

segment is 20.5 microns.

Figure 17-6 Cut Segments for NET_SEGMENT_CUT_LENGTH: 20

See Also

•REDUCTION

Chapter 17: StarRC Commands

NET_TYPE 17-135

Chapter 17: StarRC Commands

NET_TYPE 17-135

StarRC User Guide and Command Reference Version F-2011.06

NET_TYPE

Syntax

NET_TYPE: LAYOUT | SCHEMATIC

Arguments

Argument Description

LAYOUT Specifies that the net names in a NETS: command are

referenced to the layout.

This is the default.

SCHEMATIC Specifies that the net names in a NETS: command are

referenced to the schematic.

Description

Milkyway XTR (extraction) databases contain both layout names and cross-referenced

schematic names. This command determines which set of names to use when looking up

NETS and POWER_NETS during data selection.

This command is ignored if MILKYWAY_EXTRACT_VIEW: NO (Hercules flow) or XREF: NO is

specified.

Note:

NET_TYPE identifies only the source of net names for NETS selection. It does not affect

StarRC reported net names.

See Also

•XREF

•CELL_TYPE

•MILKYWAY_EXTRACT_VIEW

•NETS

•POWER_NETS

Chapter 17: StarRC Commands

NETLIST_CAPACITANCE_UNIT 17-136

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

NETLIST_CAPACITANCE_UNIT

Syntax

NETLIST_CAPACITANCE_UNIT: float

Arguments

Argument Description

float Specifies the unit of capacitance for SPEF format.

Units: farads

Default: 1e-15

Description

Alters the units used for reporting capacitance values in both the header and the body of the

output netlist. Applicable when NETLIST_FORMAT:SPEF.

See Also

•NETLIST_FORMAT

Chapter 17: StarRC Commands

NETLIST_COMMENTED_PARAMS 17-137

Chapter 17: StarRC Commands

NETLIST_COMMENTED_PARAMS 17-137

StarRC User Guide and Command Reference Version F-2011.06

NETLIST_COMMENTED_PARAMS

Syntax

NETLIST_COMMENTED_PARAMS: YES | NO

Arguments

Argument Description

YES Lists instance parameters beginning with a ‘$’ SPICE comment

in the netlist.

NO Does not list instance parameters in the netlist.

This is the default.

Description

Specifies whether to generate instance parameters in the netlist beginning with a ‘$’ SPICE

comment. Extra terminals ($BULK) and $.model are always included in the netlist.

Chapter 17: StarRC Commands

NETLIST_COMMENTS_FILE 17-138

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

NETLIST_COMMENTS_FILE

Syntax

NETLIST_COMMENTS_FILE: file1 file2 ...

Arguments

Argument Description

file Specifies a file name. The content of the file is appended to the

output netlist file.

Default: none.

Description

Inserts the contents of specified files into the parasitic netlist (NETLIST_FILE) as comments.

This section begins after the netlist HEADER is printed. Each line from the file is inserted as

is, prefixed by a comment string (// in SPEF format, ** in all other formats). Empty lines are

not included.

See Also

•NETLIST_FILE

•NETLIST_FORMAT

Chapter 17: StarRC Commands

NETLIST_COMPRESS_COMMAND 17-139

Chapter 17: StarRC Commands

NETLIST_COMPRESS_COMMAND 17-139

StarRC User Guide and Command Reference Version F-2011.06

NETLIST_COMPRESS_COMMAND

Pipes the parasitic netlist through an executable or script for compression or

post-processing.

Syntax

NETLIST_COMPRESS_COMMAND: utility [options]

Arguments

Argument Description

utility The utility name.

Default: none.

options The command-line options for the utility.

Default: none.

Description

Makes the parasitic netlist a specified executable for fast file compression. No suffix is

appended to the output netlist file (in other words, the file name is not changed to *.gz or the

like). If the utility being specified is not in your $PATH, you need to specify the full path to the

executable. This command is relevant only for ASCII-format netlists.

The NETLIST_COMPRESS_COMMAND can also be used for postprocessing a parasitic netlist

through Perl, the UNIX command sed, and so on. When you use the

NETLIST_COMPRESS_COMMAND for postprocessing, StarRC pipes the parasitic netlist through

the script, then outputs the result to the file specified by NETLIST_FILE.

Example

To compress the netlist with gzip, use the following command:

NETLIST_COMPRESS_COMMAND: /usr/local/bin/gzip

The NETLIST_COMPRESS_COMMAND can also be used for postprocessing of the parasitic

netlist. For example, if your downstream tool, such as PrimeRail or NanoTime, does not run

because of backslash (\) characters in the bus bit notation, you can remove the backslash

characters by piping the parasitic netlist through the following sed command:

NETLIST_COMPRESS_COMMAND: sed 's/\\</</g' | sed 's/\\>/>/g'

Chapter 17: StarRC Commands

NETLIST_COMPRESS_COMMAND 17-140

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

See Also

•NETLIST_FILE

Chapter 17: StarRC Commands

NETLIST_CONNECT_OPENS 17-141

Chapter 17: StarRC Commands

NETLIST_CONNECT_OPENS 17-141

StarRC User Guide and Command Reference Version F-2011.06

NETLIST_CONNECT_OPENS

Syntax

NETLIST_CONNECT_OPENS: netnames

Arguments

Argument Description

netnames Specifies the net names connected by a small resistor to be

listed (if found open during extraction).

Default: all nets (*)

Description

Creates a white-space-delimited list of nets for StarRC to connect if found open in the input

database. This option may be specified multiple times in a single command file. The

wildcards “*”, “?”, and “!” are acceptable.

A small resistor is inserted wherever a physical open is found on any net belonging to this

list. This function makes it possible for most timing analyzers to calculate delay, even though

the net is not actually connected.

Example

NETLIST_CONNECT_OPENS: * !pwr* !gnd*

NETLIST_CONNECT_OPENS: net1 net2 net3 ... netn

*RES

742 6:425 6:970 0.0100000 // $l=174.000 $w=100.000 $lvl = 0

743 6:970 6:1445 0.0100000 // $l=1.37 $w=100.000 $lvl = 0

This example shows how you can explicitly state that a shorting resistor of a particular value

can be used to connect resistively connected groups (RCGs). In this example, the resistor is

denoted by R=0.01 ohms and width = 100.

Chapter 17: StarRC Commands

NETLIST_CONNECT_SECTION 17-142

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

NETLIST_CONNECT_SECTION

Syntax

NETLIST_CONNECT_SECTION: YES | NO

Arguments

Argument Description

YES Specifies the *I, *P, or *CONN sections to be present in the

output file.

This is the default.

NO Specifies the *I, *P, or *CONN sections to not be present in the

output file.

Description

Applicable for all non-capacitor-only formats, including NETNAME. Setting this command to

NO disables the generation of the information normally contained in the *|I and *|P or

*CONN sections. This can reduce the netlist size significantly, but most delay calculators

and static timing tools require this information.

See Also

•NETLIST_FORMAT

Chapter 17: StarRC Commands

NETLIST_CORNER_FILE 17-143

Chapter 17: StarRC Commands

NETLIST_CORNER_FILE 17-143

StarRC User Guide and Command Reference Version F-2011.06

NETLIST_CORNER_FILE

Specifies the file containing the user-defined corner definitions.

Syntax

NETLIST_CORNER_FILE: corner_file

Arguments

Argument Description

corner_file The relative or absolute path to the file.

Default: none.

Description

The command allows you to define a custom corner file and produce a netlist based on this

corner. You must perform sensitivity extraction to take advantage of user-defined corner

extraction and netlist generation.

Example

NETLIST_CORNER_FILE: /internal/project/mycorner

Chapter 17: StarRC Commands

NETLIST_CORNER_FILE 17-144

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

CORNER_NAME: CMAX

# PARAM VARIATION_POINT

M1_T 3.0

M1_W 3.0

M12_T -3.0

M2_T 3.0

M2_W 3.0

M23_T -3.0

NETLIST_CORNER_NAME: RCMAX

M1_T -3.0

M1_W -3.0

M12_T -3.0

M2_T -3.0

M2_W -3.0

M23_T -3.0

CORNER_NAME: M1_CMAX_M2_RCMAX

M1_T 3.0

M1_W 3.0

M12_T -3.0

M2_T -3.0

M2_W -3.0

M23_T -3.0

CORNER_NAME: RANDOM

M1_T -1.2

M1_W 0.6

M12_T 0.0

M2_T -3.0

M2_W 2.1

M23_T -2.4

See Also

•NETLIST_CORNER_NAMES

•SENSITIVITY

Chapter 17: StarRC Commands

NETLIST_CORNER_NAMES 17-145

Chapter 17: StarRC Commands

NETLIST_CORNER_NAMES 17-145

StarRC User Guide and Command Reference Version F-2011.06

NETLIST_CORNER_NAMES

Syntax

NETLIST_CORNER_NAMES: corner_names

Arguments

Argument Description

corner_names Space delimited list of corner names to extract from the

NETLIST_CORNER_FILE.

Default: none.

Description

This command specifies the user-defined corners to extract from file pointed to in the

NETLIST_CORNER_FILE command.

This command selects the names of the corners from the NETLIST_CORNER_FILE that you

are interested in extracting and netlist generation. The names specified in the command can

be a subset of the corners defined in NETLIST_CORNER_FILE. The corner names specified

are case sensitive.

Sensitivity extraction must be performed to take advantage of user-defined corner extraction

and netlist generation.

Example

NETLIST_CORNER_NAMES:RCMAX RANDOM

See Also

•NETLIST_CORNER_NAMES

•SENSITIVITY

Chapter 17: StarRC Commands

NETLIST_COUPLE_UNSELECTED_NETS 17-146

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

NETLIST_COUPLE_UNSELECTED_NETS

Syntax

NETLIST_COUPLE_UNSELECTED_NETS: IDEAL | COMPLETE | NO

Arguments

Argument Description

IDEAL Coupling capacitances are netlisted from nets specified in a

NETLIST_SELECT_NETS command to other nets, but no *|NET

lines appear for unselected nets (for example, nets not specified

with the NETLIST_SELECT_NETS command.

COMPLETE Coupling capacitances are netlisted from

NETLIST_SELECT_NETS to other nets, and those other nets

have *|NET parasitic sections.

The net type for this option is specified using wildcards with the

NETLIST_TYPE command. Coupling capacitances to

unselected nets are netlisted if the

NETLIST_TYPE:no_couple command is not set for the

unselected nets to which the couplings exist. The

NETLIST_TYPE:no_couple command option overrides the

NETLIST_COUPLE_UNSELECTED_NETS for any unselected

nets described in the NETLIST_TYPE command. If

NETLIST_TYPE: no_couple is set for certain unselected nets

that are coupled to selected nets, neither the unselected nets

nor their couplings to selected nets are netlisted.

NO Couplings to unselected nets are not netlisted.

This is the default.

Description

Specifies that StarRC creates a netlist from any unselected nets (nets not specified by

NETLIST_SELECT_NETS) or that are coupled to by selected nets (specified by

NETLIST_SELECT_NETS).

This is a netlist command. However, for coupled nets to be present in the output, the

extraction must be coupled. To do this, set EXTRACTION: RC, C, and COUPLE_TO_GROUND:

NO.

You can use -cleanN with this command.

Chapter 17: StarRC Commands

NETLIST_COUPLE_UNSELECTED_NETS 17-147

Chapter 17: StarRC Commands

NETLIST_COUPLE_UNSELECTED_NETS 17-147

StarRC User Guide and Command Reference Version F-2011.06

See Also

•NETLIST_SELECT_NETS

•NETLIST_TYPE

Chapter 17: StarRC Commands

NETLIST_DELIMITER 17-148

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

NETLIST_DELIMITER

Specifies the instance pin delimiter.

Syntax

NETLIST_DELIMITER: : | | | . | / | #

Arguments

Argument Description

:Colon (:) character is the instance delimiter.

This is the default.

|Pipe (|) character is the instance delimiter.

/Slash (/) character is the instance delimiter.

.Period (.) character is the instance delimiter.

#Pound sign or hash (#) character is the instance delimiter.

Description

Sets the instance pin delimiter to be printed in the output parasitic netlist.

Chapter 17: StarRC Commands

NETLIST_DEVICE_LOCATION_ORIENTATION 17-149

Chapter 17: StarRC Commands

NETLIST_DEVICE_LOCATION_ORIENTATION 17-149

StarRC User Guide and Command Reference Version F-2011.06

NETLIST_DEVICE_LOCATION_ORIENTATION

Queries each instance of the database for additional parameters including the xy angle.

Syntax

NETLIST_DEVICE_LOCATION_ORIENTATION: YES | NO

Arguments

Argument Description

YES The xy location and orientation angle appears in the instance section of the netlist

file.

NO The xy location and orientation angle does not appear in the instance section of the

netlist file.

This is the default.

COMMENT The dollar sign ($) appears in the instance section of the netlist file preceding the

xy location and orientation angle.

Description

For the output of a particular instance section, the retrieved information is printed in the

netlist.

Currently, this function is implemented for MOSFETS only.

Example

NETLIST_DEVICE_LOCATION_ORIENTATION: YES

The following example shows how the information is entered in the netlist when YES

specified.

MM1 10753:F40289 97802:F40290 10755:F40291 vgnd:F40288 MN ad=5.4p as=9.6p

pd=20.54u ps=40.96u l=0.18u w=20u x=-1873.77 y=1789.68 angle=0

The following example shows how the information is entered in the netlist when NO is

specified.

MM1 10753:F40289 97802:F40290 10755:F40291 vgnd:F40288 MN ad=5.4p as=9.6p

pd=20.54u ps=40.96u l=0.18u w=20u

Chapter 17: StarRC Commands

NETLIST_DEVICE_LOCATION_ORIENTATION 17-150

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

The following example shows how the information is entered in the netlist when COMMENT is

specified.

MM1 10753:F40289 97802:F40290 10755:F40291 vgnd:F40288 MN ad=5.4p as=9.6p

pd=20.54u ps=40.96u l=0.18u w=20u $x=-1873.77 $y=1789.68 $angle=0

See Also

•NETLIST_FORMAT

Chapter 17: StarRC Commands

NETLIST_FILE 17-151

Chapter 17: StarRC Commands

NETLIST_FILE 17-151

StarRC User Guide and Command Reference Version F-2011.06

NETLIST_FILE

Specifies the name of the file to which the output parasitic netlist is written.

Syntax

NETLIST_FILE: file_name

Arguments

Argument Description

file_name The generated output file.

Default: block_name.spf, where block_name is the block specified by the

BLOCK statement

Description

In the case of the SBPF format, you must also specify the .sbpf extension.

Example

NETLIST_FILE: top_block.sbpf

See Also

•NETLIST_FORMAT

Chapter 17: StarRC Commands

NETLIST_FORMAT 17-152

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

NETLIST_FORMAT

Defines the structure and format of the output parasitic netlist.

Syntax

Arguments

Argument Description

SPF DSPF 1.0; supports only EXTRACTION: RC with COUPLE_TO_GROUND: YES | NO.

Supports coupling capacitors from the 2003.03 release.

STAR Uses SPICE-like subnode naming conventions. Compact and allows netlist generation of

EXTRACTION:R and COUPLE_TO_GROUND:NO.

This is the default.

SPEF Flexible and compact. All names are mapped internally, reducing netlist size. Any StarRC

job configuration is supported by this format. SPEF prints the D_NET (detailed parasitics)

net type in the output NETLIST_FILE.

MW For this format, StarRC writes parasitic output into the PARA view of the extracted block in

the source MILKYWAY_DATABASE.

SBPF Specifies Synopsys binary parasitic format. This is an interface format to PrimeTime and

static timing analysis tools.

CAUTION: The following commands should not be specified in the StarRC command file

with the SBPF output format: NETLIST_SELECT_NETS,

NETLIST_COUPLE_UNSELECTED_NETS, CONLY_NETS, ZONE_COUPLE_TO_NET,

COUPLE_NONCRITICAL_NETS, SKIP_CELLS_COUPLE_TO_NET and EXTRACTION:C.

CONLY Outputs only capacitors. This format does not take the pin/port capacitances into account

when preparing the coupling report.

NETNAME Formats internal node names as netname:0, netname:1, and so on. This makes it

easier to determine which nets the parasitics are attached to and makes it easier to probe

an RC network.

NONE Skips the netlist stage.

OA Outputs the parasitic elements and ideal device in Open Access database format. This

allows tools able to read OA to access the parasitic database for analysis and viewing.

Chapter 17: StarRC Commands

NETLIST_FORMAT 17-153

Chapter 17: StarRC Commands

NETLIST_FORMAT 17-153

StarRC User Guide and Command Reference Version F-2011.06

Description

There are five supported formats for parasitics: SPF, STAR, SPEF, MW, SBPF, CONLY, NETNAME,

and NONE.

Example

See “Netlist Format Examples” on page 13-2.

See Also

•COUPLE_TO_GROUND

•EXTRACTION

•MILKYWAY_DATABASE

•NETLIST_FILE

Chapter 17: StarRC Commands

NETLIST_GROUND_NODE_NAME 17-154

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

NETLIST_GROUND_NODE_NAME

Defines the net name used when reporting the capacitance with respect either to noncritical

material or to an ITF defined SUBSTRATE.

Syntax

NETLIST_GROUND_NODE_NAME: string

Arguments

Argument Description

string The name of the net to which the capacitance is to be lumped.

Default: 0

Description

This command is not valid with SPEF format netlists, because the ground node is not output

in SPEF.

If you find a reference to node 0 in your output netlist, it is the location where all noncritical

extracted materials are lumped. This includes coupling to ideal ground, or SUBSTRATE in

StarRC. The entry for node 0 is the SPICE ground.

See Also

•NETLIST_FORMAT

Chapter 17: StarRC Commands

NETLIST_HIER_PROBE_NODES 17-155

Chapter 17: StarRC Commands

NETLIST_HIER_PROBE_NODES 17-155

StarRC User Guide and Command Reference Version F-2011.06

NETLIST_HIER_PROBE_NODES

Syntax

NETLIST_HIER_PROBE_NODES: YES | NO

Arguments

Argument Description

NO Does not report the hierarchy in the output.

This is the default.

YES Reports the hierarchy information cell_inst:text_label in the RC

netlist output.

Description

Specifies whether or not the net hierarchy must be reported in the RC netlist.

Example

**|OI (cell_inst : text_label cell_inst text_label

Z 0 x_coord y_coord

*| NET SUM0 0.0128485PF

**|OI ($1I1:ProbeA1 $1I1 ProbeA1 Z 0 459.5 34.5)

R16 $1I1:ProbeA1 SUM0 1.19335 $l = 38.495 $w = 2 $lvl = 1

The text, $1I1:ProbeA1 is inserted into the output when NETLIST_HIER_PROBE_NODES is

set to YES.

Chapter 17: StarRC Commands

NETLIST_IDEAL_SPICE_FILE 17-156

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

NETLIST_IDEAL_SPICE_FILE

Syntax

NETLIST_IDEAL_SPICE_FILE: file_name

Arguments

Argument Description

file_name The name of the file to be output.

Default: none.

Description

Creates an ideal SPICE-format netlist for use with simulation. Options

NETLIST_PASSIVE_PARAMS and NETLIST_MAX_LINE are in effect for this netlist.

NETLIST_IDEAL_SPICE_TYPE determines whether the ideal netlist should be layout or

schematic based. NETLIST_IDEAL_SPICE_HIER determines whether or not the ideal netlist

is flat or retains the hierarchy of the input data.

The NETLIST_IDEAL_SPICE_FILE stops at SKIP_CELLS boundaries. SKIP_CELLS and

device .SUBCKT statements are included in the netlist as comments to indicate port

ordering. For SKIP_CELLS extractions, the ideal device-level netlists can be provided with

SPICE_SUBCKT_FILE to order the .SUBCKT ports in the NETLIST_IDEAL_SPICE_FILE.

Then the SPICE_SUBCKT_FILE can be provided to a simulation tool in combination with the

NETLIST_IDEAL_SPICE_FILE for a complete device-level ideal SPICE netlist.

See Also

•NETLIST_IDEAL_SPICE_HIER

•NETLIST_IDEAL_SPICE_TYPE

•NETLIST_MAX_LINE

•NETLIST_PASSIVE_PARAMS

•SPICE_SUBCKT_FILE

Chapter 17: StarRC Commands

NETLIST_IDEAL_SPICE_HIER 17-157

Chapter 17: StarRC Commands

NETLIST_IDEAL_SPICE_HIER 17-157

StarRC User Guide and Command Reference Version F-2011.06

NETLIST_IDEAL_SPICE_HIER

Syntax

NETLIST_IDEAL_SPICE_HIER: YES | NO

Arguments

Argument Description

YES The original netlist or layout hierarchy is preserved.

NO The ideal netlist is flattened.

This is the default.

Description

Specifies whether or not to preserve the original hierarchy when you are generating the

NETLIST_IDEAL_SPICE_FILE.

See Also

•NETLIST_IDEAL_SPICE_FILE

•NETLIST_IDEAL_SPICE_TYPE

Chapter 17: StarRC Commands

NETLIST_IDEAL_SPICE_TYPE 17-158

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

NETLIST_IDEAL_SPICE_TYPE

Specifies whether to netlist a layout- or schematic-based NETLIST_IDEAL_SPICE_FILE

command.

Syntax

NETLIST_IDEAL_SPICE_TYPE: SCHEMATIC | LAYOUT

Arguments

Argument Description

SCHEMATIC Specifies the output file has schematic net names.

LAYOUT Specifies the output file has layout net names.

Description

The default for XREF:NO is LAYOUT. The default for all other XREF values is SCHEMATIC.

See Also

•NETLIST_IDEAL_SPICE_FILE

Chapter 17: StarRC Commands

NETLIST_INCREMENTAL 17-159

Chapter 17: StarRC Commands

NETLIST_INCREMENTAL 17-159

StarRC User Guide and Command Reference Version F-2011.06

NETLIST_INCREMENTAL

Specifies whether to output a partial or full netlist for an incremental extraction.

Syntax

NETLIST_INCREMENTAL: YES | NO

Arguments

Argument Description

YES Produces an incremental netlist. This is currently supported by SPEF or SBPF

formats only. If the NETLIST_FORMAT specified is other than SPEF or SBPF,

StarRC issues an error.

NO Produces a full chip parasitic netlist in all formats. This command also controls

the content of the coupling report. With NETLIST_INCREMENTAL: YES, a

partial coupling report is generated.

This is the default.

Description

Specifying NETLIST_INCREMENTAL:YES produces a partial netlist of the post-ECO nets and

the corresponding neighboring nets. Only SPEF and SBPF netlist formats are supported. A

downstream timing analysis tool must accept this partial netlist and properly restitch the

parasitics.

It is also important to note that the timing analysis must have Verilog netlist changes that

match the incremental parasitics. If you fail to match the incremental parasitics, there could

be back-annotation problems.

If you use timing analysis tools that do not support partial netlists, you may benefit by

running incremental extraction using the NETLIST_INCREMENTAL:NO command. A full netlist

is produced that includes parasitics of the post-ECO block.

Note:

The NETLIST_INCREMENTAL command works only when the INCREMENTAL: YES

command is also specified.

Chapter 17: StarRC Commands

NETLIST_INCREMENTAL 17-160

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Example

BLOCK: TOP_Post-eco

MILKYWAY_DATABASE: design

TCAD_GRD_FILE: nxtgrd_file

MAPPING_FILE: map

NETLIST_FORMAT: SPEF

INCREMENTAL: YES

NETLIST_INCREMENTAL: YES

See Also

•INCREMENTAL

Chapter 17: StarRC Commands

NETLIST_INPUT_DRIVERS 17-161

Chapter 17: StarRC Commands

NETLIST_INPUT_DRIVERS 17-161

StarRC User Guide and Command Reference Version F-2011.06

NETLIST_INPUT_DRIVERS

Identifies the driving cell models in the SPEF netlist format for each instance pin with the

optional *D statement.

Syntax

NETLIST_INPUT_DRIVERS: YES | NO

Arguments

Argument Description

YES Prints the driving cell model name in the netlist.

NO Does not enable the command function.

This is the default.

Description

Many static timing tools do not require this information for the inputs, because the loading

cap for the net is provided. StarRC does not print the *D statements for the inputs by default.

Use this option to print the models for the input instance pins.

This command is ignored unless you specify NETLIST_FORMAT: SPEF.

See Also

•NETLIST_FORMAT

Chapter 17: StarRC Commands

NETLIST_INSTANCE_SECTION 17-162

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

NETLIST_INSTANCE_SECTION

Sets whether or not the SPF instance section is printed in the output netlist.

Syntax

NETLIST_INSTANCE_SECTION: YES | NO | SELECTED

Arguments

Argument Description

YES Prints all instances.

NO Does not print the instance section.

SELECTED Print the instance section connected the nets group that is the

combination of NETS and NETLIST_SELECT_NETS.

This is the default.

Description

This command is valid only when the NETLIST_FORMAT:SPF|STAR|NETNAME command is

set.

Note:

Because .subckt must be consistent with the instance section, the .subckt statement is

printed accordingly.

Example

The following three examples show the expected behavior when combinations of these

commands are specified.

Example 1

NETS selected

XREF:NO|YES|NETS

NETLIST_SELECT_NETS:*

NETLIST_INSTANCE_SECTION:

NO: No instance section is printed.

YES|SELECTED:Only devices attached to extracted nets printed. YES and

SELECTED behave the same.

Chapter 17: StarRC Commands

NETLIST_INSTANCE_SECTION 17-163

Chapter 17: StarRC Commands

NETLIST_INSTANCE_SECTION 17-163

StarRC User Guide and Command Reference Version F-2011.06

Example 2

NETS selected

XREF:COMPLETE

NETLIST_SELECT_NETS:*

NETLIST_INSTANCE_SECTION:

NO: No instance section is printed.

YES|SELECTED: All devices in the schematic devices are printed. Nets not

extracted are ideal. YES and SELECTED behave the same.

Example 3

NETLIST_INSTANCE_SECTION:YES and SELECTED are influenced by the

NETLIST_SELECT_NETS command as explained in the following:

NETS*

XREF:NO|YES|NETS

NETLIST_SELECT_NETS:selected |subset_of_nets_in_NETS

NETLIST_INSTANCE_SECTION:

NO: No instance section is printed.

YES: All devices are generated in the netlist that are present in the IDX

file. .

SELECTED: Only devices attacted to NETLIST_SELECT_NETS are printed.

See Also

•NETLIST_FORMAT

•NETLIST_SELECT_NETS

•NETLIST_COUPLE_UNSELECTED_NETS

•NETS

•POWER_NETS

Chapter 17: StarRC Commands

NETLIST_LOGICAL_TYPE 17-164

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

NETLIST_LOGICAL_TYPE

Sets a value to be printed in the SPEF DESIGN_FLOW NETLIST_TYPE val header card.

Syntax

NETLIST_LOGICAL_TYPE: VERILOG | VHDL87 | VHDL93 | EDIF

Arguments

Argument Description

VERILOG Specifies Verilog as the naming convention used in the SPEF

netlist.

VHDL87 Specifies VHDL87 as the naming convention used in the SPEF

netlist.

VHDL93 Specifies VHDL93 as the naming convention used in the SPEF

netlist.

EDIF Specifies EDIF as the naming convention used in the SPEF

netlist.

Description

This command specifies which naming convention is used in the creation of the SPEF

netlist. It is not required by StarRC but might be necessary for some follow-on tools.

See Also

•NETLIST_FORMAT

Chapter 17: StarRC Commands

NETLIST_MAX_FILE_SIZE 17-165

Chapter 17: StarRC Commands

NETLIST_MAX_FILE_SIZE 17-165

StarRC User Guide and Command Reference Version F-2011.06

NETLIST_MAX_FILE_SIZE

Limits the size of the output netlist file produced by StarRC.

Syntax

NETLIST_MAX_FILE_SIZE: float

Arguments

Argument Description

float Floating-point number that is smaller than the default in defining a

single netlist size.

32-bit default: 1.6 GB

64-bit default: unlimited

Description

It is not necessary to issue this command to adhere to the 32-bit operating system file size

limit; the default for this option is 1.6e9, which is the 32-bit limit. NETLIST_MAX_FILE_SIZE

cannot be set higher than the default, only lower. For a 64-bit platform, this file size limitation

does not exist.

Whenever StarRC reaches a netlist size such that the next complete net exceeds the

specified limit, it begins a new netlist file. If it is impossible to print one complete net within

the specified limit, StarRC will exceed the limit. The minimum file size is not fixed but is

constrained by the requirement that nets may not be split between files.

The netlist header is printed only in the first file.

Note:

NETLIST_MAX_FILE_SIZE is specified in bytes.

Example

Each netlist file uses the root name provided by the NETLIST_FILE command. The first

netlist file does not have a suffix. Subsequent files receive an indexed suffix, as shown in the

following example:

block.spf

block.spf.1

block.spf.2

.....

block.spf.n

Chapter 17: StarRC Commands

NETLIST_MAX_FILE_SIZE 17-166

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

See Also

•NETLIST_FILE

•NETLIST_FORMAT

Chapter 17: StarRC Commands

NETLIST_MAX_LINE 17-167

Chapter 17: StarRC Commands

NETLIST_MAX_LINE 17-167

StarRC User Guide and Command Reference Version F-2011.06

NETLIST_MAX_LINE

Specifies the maximum number of characters allowed on each netlist line before the line is

discontinued with a carriage return and the text is wrapped with the “+” continuation tag.

Syntax

NETLIST_MAX_LINE: integer

Arguments

Argument Description

integer Maximum number of characters allowed on each netlist line.

Default: no limit.

Description

This command applies to the SPF and STAR netlist formats only. The default is not to limit

the number of characters.

See Also

•NETLIST_FORMAT

Chapter 17: StarRC Commands

NETLIST_MERGE_CORNERS 17-168

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

NETLIST_MERGE_CORNERS

Outputs a single netlist for multiple user-defined corners (UDC).

Syntax

NETLIST_MERGE_CORNERS: YES | NO

Arguments

Argument Description

YES Turns on function to output a single netlist for multiple user-defined

corners.

NO A single netlist for multiple user-defined corners is not generated.

This is the default.

Description

Specify this command with SENSITIVITY:YES to output a single netlist for multiple

user-defined corners (UDC). The resistance and capacitance values are separated by a

colon and are printed in the same order as the corner names specified in the

NETLIST_CORNER_NAMES command.

Note:

This command behaves similarly to MERGE_MULTI_CORNER used for traditional

nonsensitivity-based extraction flows. The command is a netlist generation function and

therefore can be modified for re-creating the netlist (-cleanN).

Example

NETLIST_MERGE_CORNERS:YES

See Also

•NETLIST_CORNER_FILE

•NETLIST_CORNER_NAMES

•SENSITIVITY

Chapter 17: StarRC Commands

NETLIST_MERGE_SHORTED_PORTS 17-169

Chapter 17: StarRC Commands

NETLIST_MERGE_SHORTED_PORTS 17-169

StarRC User Guide and Command Reference Version F-2011.06

NETLIST_MERGE_SHORTED_PORTS

Removes 0.001-ohm node-sharing resistors and merges node names in the netlist to

reduce the file size.

Syntax

NETLIST_MERGE_SHORTED_PORTS: YES | NO

Arguments

Argument Description

YES Instance ports connected by node sharing resistors are replaced by

one node in the group.

NO Instance nodes are unique and might be connected by node sharing

resistors (if there are no physical parasitic resistors).

This is the default.

Description

If NETLIST_MERGE_SHORTED_PORTS is set to YES, whenever multiple port nodes for a net are

connected together by node-sharing shorting resistors, StarRC chooses one node randomly

from the group to represent all nodes. StarRC uses this node to replace every node in the

group for every electrical element in the netlist including parasitic elements, elements in the

instance section, and *|I occurrences in DSPF.

Example

NETLIST_MERGE_SHORTED_PORTS: YES

Chapter 17: StarRC Commands

NETLIST_MINCAP_THRESHOLD 17-170

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

NETLIST_MINCAP_THRESHOLD

Sets the minimum capacitance allowed in the RC section of the netlist.

Syntax

NETLIST_MINCAP_THRESHOLD: capacitance_value

Arguments

Argument Description

capacitance_value The smallest capacitance to be allowed without merging with another

capacitance.

Units: farad (F)

Default: 0.0

Description

Any capacitance below this threshold is merged with another smaller capacitance or larger

capacitance in a given net. This is applicable for both coupling and grounded capacitance.

The capacitance value cannot be less than 0 (zero).

Note:

Capacitance that is below the threshold can remain in the netlist.

When NETLIST_MINCAP_THRESHOLD and COUPLING_ABS_THRESHOLD are both specified,

StarRC performs the function of COUPLING_ABS_THRESHOLD first.

This command is supported only for transistor-level extraction.

Example

This sets the threshold level at 1 fF.

NETLIST_MINCAP_THRESHOLD: 1e-15

See Also

•COUPLING_ABS_THRESHOLD

•NETLIST_TOTALCAP_THRESHOLD

Chapter 17: StarRC Commands

NETLIST_MINRES_HANDLING 17-171

Chapter 17: StarRC Commands

NETLIST_MINRES_HANDLING 17-171

StarRC User Guide and Command Reference Version F-2011.06

NETLIST_MINRES_HANDLING

Syntax

NETLIST_MINRES_HANDLING: SHORT | MERGE

Arguments

Argument Description

SHORT Does not preserve point-to-point resistance.

MERGE Merges the resistor with a neighboring resistor if it is in series and is

smaller than the threshold.

Description

Defines how a resistor is handled if it is less than or equal to the specified threshold in the

NETLIST_MINRES_THRESHOLD command. This command is supported only for

transistor-level extraction.

• If there is only one resistor in the net, it is not merged or shorted.

• If a resistor is attached to a PROBE node (or *P or *I), then that terminal is attached to

“keep nodes” and should not be affected.

•NETLIST_MINRES_HANDLING does not preserve point-to-point resistance.

•NETLIST_MINRES_HANDLING ensures that no resistors exist with their terminals shorted.

• You can specify either SHORT or MERGE in the NETLIST_MINRES_HANDLING command, but

not both. If you specify both, the second one overrides the first one.

•NETLIST_MINRES_HANDLING:MERGE does not work on resistor nodes with more than 3

branches. This means that it does only series merging. However,

NETLIST_MINRES_HANDLING:SHORT works on all resistor nodes and shorts the nodes

appropriately.

• When NETLIST_MINRES_HANDLING:MERGE is specified, the capacitance on the reduced

node is moved to the smaller resistor.

See Also

•NETLIST_MINRES_THRESHOLD

Chapter 17: StarRC Commands

NETLIST_MINRES_THRESHOLD 17-172

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

NETLIST_MINRES_THRESHOLD

Syntax

NETLIST_MINRES_THRESHOLD: threshold_value

Arguments

Argument Description

threshold_value Threshold value at which all resistances are merged or shorted if less

than or equal to this value.

Default: none.

Description

This command merges or shorts all resistances in the netlist less than or equal to the

threshold specified. This command is supported only for transistor-level extraction

• You cannot specify a value less than zero.

• This option is governed by the NETLIST_MINRES_HANDLING: SHORT | MERGE command.

Example

NETLIST_MINRES_THRESHOLD: 0.001

See Also

•NETLIST_MINRES_HANDLING

Chapter 17: StarRC Commands

NETLIST_MMC_FORMULA 17-173

Chapter 17: StarRC Commands

NETLIST_MMC_FORMULA 17-173

StarRC User Guide and Command Reference Version F-2011.06

NETLIST_MMC_FORMULA

Generates the value of resistors and capacitors as a formula in the final merged netlist.

Syntax

NETLIST_MMC_FORMULA: YES | NO

Arguments

Argument Description

YES Generates the value of resistors and capacitors as a formula in

the merged netlist.

NO Does not generate the resistors as a formula in the merged

netlist.

This is the default.

Description

This command activates only when the MERGE_MULTI_CORNER command is set to YES.

Example

The following example shows the command used with related commands.

TCAD_GRD_FILE: nxtgrd1 nxtgrd2 nxtgrd3

MERGE_MULTI_CORNER: YES

NETLIST_PARASITIC_RESISTOR_MODEL:Y ES

NETLIST_MMC_FORMULA: YES

See Also

•MERGE_MULTI_CORNER: YES

•NETLIST_MMC_FORMULA_NAMES

•NETLIST_PARASITIC_RESISTOR_MODEL

•TCAD_GRD_FILE

Chapter 17: StarRC Commands

NETLIST_MMC_FORMULA_NAMES 17-174

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

NETLIST_MMC_FORMULA_NAMES

Specifies the names of fixed corners.

Syntax

NETLIST_MMC_FORMULA_NAMES: corner_name1 corner_name2 ...

Arguments

Argument Description

corner_name Fixed corner name. The number of names specified must be the

same as the number of nxtgrd files.

Default: none

Description

If this command is not specified, the default corner names are used. Other command

requirements are the following:

• If the number of names specified is greater than or lesser than the number of nxtgrd files

specified, then StarRC errors out.

• The order of values in the netlist for a given element does not change. It is always in the

order of the nxtgrd file.

• With the NETLIST_MMC_FORMULA_NAMES command, you must also specify a

NETLIST_MMC_FORMULA:YES

MERGE_MULTI_CORNER:YES command.

• You must verify that the order of names corresponds to the named nxtgrd files specified

in the TCAD_GRD_FILE command.

Example

The following example identifies the corners rcworst, rcbest, and cbest in the file syntax:

TCAD_GRD_FILE:nxtgrd1 nxtgrd2 nxtgrd3

MERGE_MULTI_CORNER:YES

NETLIST_PARASITIC_RESISTOR_MODEL:NO

NETLIST_MMC_FORMULA:YES

NETLIST_MMC_FORMULA_NAMES:rcworst rcbest cbest

Chapter 17: StarRC Commands

NETLIST_MMC_FORMULA_NAMES 17-175

Chapter 17: StarRC Commands

NETLIST_MMC_FORMULA_NAMES 17-175

StarRC User Guide and Command Reference Version F-2011.06

See Also

•MERGE_MULTI_CORNER: YES

•NETLIST_MMC_FORMULA: YES

•NETLIST_PARASITIC_RESISTOR_MODEL

•TCAD_GRD_FILE

Chapter 17: StarRC Commands

NETLIST_NAME_MAP 17-176

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

NETLIST_NAME_MAP

Controls name mapping for a SPEF netlist.

Syntax

NETLIST_NAME_MAP: YES | NO

Arguments

Argument Description

YES Enables name mapping in an SPEF netlist only.

This is the default.

NO Disables name mapping in an SPEF netlist only.

Description

The NETLIST_NAME_MAP controls name mapping. This command is only applicable when

you use NETLIST_FORMAT: SPEF.

Note:

Disabling name mapping greatly increases the netlist size. You should not use this

command on a regular basis.

See Also

•NETLIST_FORMAT

Chapter 17: StarRC Commands

NETLIST_NODE_SECTION 17-177

Chapter 17: StarRC Commands

NETLIST_NODE_SECTION 17-177

StarRC User Guide and Command Reference Version F-2011.06

NETLIST_NODE_SECTION

Syntax

NETLIST_NODE_SECTION: YES | NO

Arguments

Argument Description

YES Generates *|S or *N statements in the output netlist.

NO Does not generate *|S or *N statements in the output netlist.

This is the default.

Description

Generates the *|S or *N statements in the output netlist.

Using the default setting, NETLIST_NODE_SECTION:NO greatly reduces the netlist size and is

useful for most post-extraction flows.

Specify this command with netlist formats STAR, SPF, or SPEF.

See Also

•NETLIST_FORMAT

Chapter 17: StarRC Commands

NETLIST_NODENAME_NETNAME 17-178

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

NETLIST_NODENAME_NETNAME

Retains a net name for one of the subnodes of a nonport net.

Syntax

NETLIST_NODENAME_NETNAME: YES | NO

Arguments

Argument Description

YES Retains net names for one of the subnodes of a nonport net. Names

the subnodes with the net name without the pin delimiter and positive

integer

NO Does not retain subnode names.

This is the default.

Description

NETLIST_NODENAME_NETNAME retains a net name for one of the subnodes of a nonport net.

StarRC chooses one subnode from a nonport (internal) net and converts it to a net name.

This command is valid for all settings of the NETLIST_FORMAT command and is particularly

useful for the SPF format. However, parasitic netlist reading tools that adhere strictly to the

SPEF standard might issue errors. To avoid SPEF netlist reading errors, set

NETLIST_NODENAME_NETNAME: NO.

Note:

Do not use a probe name specified in a probe text file that is the same as a net name. In

that case, the two nodes are electrically shorted.

If a net has a top-level port node, for example, *|P (DSPF) or *P (SPEF), then

NETLIST_NODENAME_NETNAME:YES does not rename or generate a node for that net.

When a net has at least one *|S node (DSPF) or *N node (SPEF), one of those *|S or *N is

renamed to match the *|NET or *D_NET net name.

Chapter 17: StarRC Commands

NETLIST_NODENAME_NETNAME 17-179

Chapter 17: StarRC Commands

NETLIST_NODENAME_NETNAME 17-179

StarRC User Guide and Command Reference Version F-2011.06

A node is never a candidate for renaming if it is from one of the following categories:

Node

instance port *|I (DSPF) or *I (SPEF)

top-level port *|P (DSPF) or *P (SPEF)

observation port **|O (DSPF) or **O (SPEF)

probe text **|OP (DSPF) or **OP (SPEF)

If a net contains no *|S or *N subnodes but has at least two *|P and/or *|I nodes, then a new

node is generated whose name matches the net name.

If a net is floating (no *|P or *|I nodes) or dangling (only one *|P or *|I node), then no resistor

is generated and no node is renamed.

Example

NETLIST_NODENAME_NETNAME: NO

*|NET x0.x38.n15 0.000900241PF

*|I (x0.x38.M2|DRN x0.x38.M2 DRN B 0 -492.5 11) //

$llx=-492.5 $lly=4.5 $urx=-489.5 $ury=17.5 $lvl=7

*|I (x0.x38.M1|DRN x0.x38.M1 DRN B 0 -489.5 11)//

$llx=-489.5 $lly=11 $urx=-489.5 $ury=11 $lvl=7

Cg1 x0.x38.M2|DRN 0 2.85306e-16

R1 x0.x38.M2|DRN x0.x38.M1|DRN 0.001 $l=3 $w=10 $lvl=7

Example continues ...

NETLIST_NODENAME_NETNAME: YES

*|NET x0.x38.n15 0.000900241PF

*|I (x0.x38.M2|DRN x0.x38.M2 DRN B 0 -492.5 11) //

$llx=-492.5 $lly=4.5 $urx=-489.5 $ury=17.5 $lvl=7

*|I (x0.x38.M1|DRN x0.x38.M1 DRN B 0 -489.5 11) //

$llx=-489.5 $lly=11 $urx=-489.5 $ury=11 $lvl=7

*|S (x0.x38.n15 -492.5 11//

$llx=-492.5 $lly=4.5 $urx=-489.5 $ury=17.5 $lvl=7)

Cg1 x0.x38.M2|DRN 0 2.85306e-16

R1 x0.x38.n15 x0.x38.M1|DRN 0.001 $l=3 $w=10 $lvl=7

R2 x0.x38.n15 x0.x38.M2|DRN 0.001 $l=3 $w=10 $lvl=7

See Also

•NETLIST_FORMAT

Chapter 17: StarRC Commands

NETLIST_PARA_VIEW 17-180

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

NETLIST_PARA_VIEW

Produces the PARA view output in a single pass.

Syntax

NETLIST_PARA_VIEW: milkyway_library

Arguments

Argument Description

milkyway_library Valid Milkyway library file name

Default: none

Description

The NETLIST_PARA_VIEW command produces the PARA view output in a single pass.

See Also

•NETLIST_FILE

•NETLIST_FORMAT

Chapter 17: StarRC Commands

NETLIST_PARASITIC_RESISTOR_MODEL 17-181

Chapter 17: StarRC Commands

NETLIST_PARASITIC_RESISTOR_MODEL 17-181

StarRC User Guide and Command Reference Version F-2011.06

NETLIST_PARASITIC_RESISTOR_MODEL

Outputs parasitic resistor models directly into the parasitic netlist.

Syntax

NETLIST_PARASITIC_RESISTOR_MODEL: YES |NO

Arguments

Argument Description

YES Prints model information to the parasitic netlist.

NO Does not print layer or model information to the parasitic netlist.

This is the default.

Description

This command outputs parasitic resistor models directly into the parasitic netlist so that

SPICE simulation can be done without additional postprocessing.

The model name printed in the parasitic netlist is based on the database layer from which

the model was extracted. If you need the same model layer for a given GRD layer, then map

the corresponding database layers to the same model in the mapping file.

If a nonphysical resistor is introduced into the netlist, it is not generated in the netlist.

If you have not specified a corresponding resistor MODEL in the database, no model is

printed to the parasitic netlist for that resistor and a warning is issued in the StarRC

summary file.

Example

The mapping file information uses the following syntax:

Conducting Layers

database_layer GRD_layer RPSQ = value MODEL = model_name

database_layer GRD_layer MODEL = model_name

database_layer GRD_layer MODEL = model_name RPSQ = value

Via_layers

database_layer GRD_layer RPV=value AREA=value MODEL=model_name

database_layer GRD_layer MODEL=model_name

database_layer GRD_layer MODEL=model_name RPV=value

AREA=value

Chapter 17: StarRC Commands

NETLIST_PARASITIC_RESISTOR_MODEL 17-182

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Example 1

TCAD_GRD_FILE: process.nxtgrd

NETLIST_PARASITIC_RESISTOR_MODEL: YES

NETLIST_TAIL_COMMENTS: YES

conducting_layers

metal2 m2 rpsq=0.02 model = M2R

metal1 m1 rpsq=0.02 model = M1R

poly PO1 rpsq=10 model = PR

pgate PO1 rpsq=10 model=PR

ngate PO1 psq=10 model=PR

Example 1 Final Netlist

*|NET IN2 0.0253958PF

*|I (xSD_11/M1:GATE xSD_11/M1 GATE I 2e-14 -5.1 29.8)

*|P (IN2 B 0 -30.8 7)

*|I (xSD_11/M6:GATE xSD_11/M6 GATE I 2e-14 -5.1 -7.2)

*|I (xSD_11/M2:GATE xSD_11/M2 GATE I 2e-14 -12.1 29.8)

*|I (xSD_11/M5:GATE xSD_11/M5 GATE I 2e-14 -12.1 -7.2)

Cg3 xSD_11/M1:GATE 0 1.0243e-15

C4 IN2:1 xSD_11/SN_22:1 6.78185e-17

Cg5 IN2:1 0 6.15523e-15

Cg6 IN2 0 3.06582e-15

C7 xSD_11/M6:GATE xSD_11/SN_22:1 2.54972e-16

Cg8 xSD_11/M6:GATE 0 3.78517e-16

Cg9 xSD_11/M2:GATE 0 8.35609e-16

C10 xSD_11/M5:GATE xSD_11/M6:DRN 2.46994e-16

Cg11 xSD_11/M5:GATE 0 6.85312e-16

Cg12 IN2:3 0 1.05002e-14

R3 xSD_11/M1:GATE IN2:1 PR r=130.419 $l=21.8 $w=1 $lvl=3

R4 IN2:1 IN2:2 M2R r=0.0701772 $l=7 $w=2.56 $lvl=1

R5 IN2:1 xSD_11/M6:GATE M1R r=121.333 $l=15.2 $w=1 $lvl=2

R6 IN2 IN2:2 M2R r=0.102702 $l=15.2 $w=3.6 $lvl=1

R7 IN2:2 IN2:3 VIAR r=0.0237957 $a=2.56 $lvl=10

R8 xSD_11/M2:GATE IN2:3 PR r=130.419 $l=21.8 $w=1 $lvl=3

R9 xSD_11/M5:GATE IN2:3 PR r=121.333 $l=15.2 $w=1 $lvl=3

Example 2

TCAD_GRD_FILE: process1.nxtgrd process2.nxtgrd

NETLIST_PARASITIC_RESISTOR_MODEL: YES

NETLIST_TAIL_COMMENTS: YES

MERGE_MULTI_CORNER: YES

Chapter 17: StarRC Commands

NETLIST_PARASITIC_RESISTOR_MODEL 17-183

Chapter 17: StarRC Commands

NETLIST_PARASITIC_RESISTOR_MODEL 17-183

StarRC User Guide and Command Reference Version F-2011.06

Example 2 Final Netlist

*|NET IN2 0.0253968:0.0253968PF

*|I (xSD_11/M1:GATE xSD_11/M1 GATE I 2e-14 -5.1 29.8)

*|P (IN2 B 0 -30.8 7)

*|I (xSD_11/M6:GATE xSD_11/M6 GATE I 2e-14 -5.1 -7.2)

*|I (xSD_11/M2:GATE xSD_11/M2 GATE I 2e-14 -12.1 29.8)

*|I (xSD_11/M5:GATE xSD_11/M5 GATE I 2e-14 -12.1 -7.2)

C2 IN2:1 xSD_11/SN_22:1 5.80324e-17:5.80324e-17

Cg3 IN2:1 0 1.57527e-15:1.57527e-15

Cg4 IN2:2 0 6.60687e-16:6.60687e-16

Cg5 xSD_11/M1:GATE 0 6.00431e-16:6.00431e-16

Cg6 IN2:3 0 2.08944e-15:2.08944e-15

C7 IN2:4 xSD_11/SN_22:1 9.78612e-18:9.78612e-18

Cg8 IN2:4 0 1.56523e-15:1.56523e-15

Cg9 IN2 0 3.06582e-15:3.06582e-15

Cg10 IN2:9 0 8.40713e-16:8.40713e-16

C11 xSD_11/M6:GATE xSD_11/SN_22:1 2.52126e-16:2.52126e-16

Cg12 xSD_11/M6:GATE 0 2.26279e-16:2.26279e-16

Cg13 IN2:10 0 7.49901e-16:7.49901e-16

Cg14 xSD_11/M2:GATE 0 5.99013e-16:5.99013e-16

Cg15 IN2:11 0 2.14233e-15:2.14233e-15

Cg16 IN2:12 0 3.98535e-15:3.98535e-15

Cg17 IN2:13 0 1.60862e-15:1.60862e-15

Cg18 IN2:14 0 1.56991e-15:1.56991e-15

Cg19 IN2:15 0 8.2874e-16:8.2874e-16

C20 xSD_11/M5:GATE xSD_11/SN_22:1 2.4984e-16:2.4984e-16

Cg21 xSD_11/M5:GATE 0 5.38315e-16:5.38315e-16

R7 IN2:1 IN2:4 poly-contR r=0.0645569:0.0645569 $a=4 $lvl=11

R8 IN2:1 IN2:5 M1R r=0.0210147:0.0210147 $l=3.2 $w=4 $lvl=2

R9 IN2:2 xSD_11/M1:GATE PR r=100:100 $l=10 $w=1 $lvl=4

R10 IN2:2 IN2:3 PR r=30.3125:30.3125 $l=5 $w=1 $lvl=3

R11 IN2:3 IN2:6 poly-contR r=0.0645569:0.0645569 $a=4 $lvl=11

R12 IN2:4 IN2:9 PR r=21.25:21.25 $l=3 $w=1 $lvl=3

R13 IN2:5 IN2:6 M1R r=0.0450315:0.0450315 $l=6.8 $w=4 $lvl=2

R14 IN2:5 IN2:8 VIAR r=0.0237957:0.0237957 $a=2.56 $lvl=10

See Also

•NETLIST_TAIL_COMMENTS

•REDUCTION

Chapter 17: StarRC Commands

NETLIST_PASSIVE_PARAMS 17-184

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

NETLIST_PASSIVE_PARAMS

Syntax

NETLIST_PASSIVE_PARAMS: YES | NO

Arguments

Argument Description

YES Generates the passive device parameters in the netlist.

NO Does not generate the passive device parameters in the netlist.

This is the default.

Description

Selects format to generate the designed R, L, or C devices in the parasitic netlist instance

section (NETLIST_FILE) and the ideal netlist (NETLIST_IDEAL_SPICE_FILE).

The following is an example of the default format for generating an RLC instance netlist. This

format does not require a SPICE model for these devices for simulation:

R11 R11:A R11:B 1000 $.model=Rdev $BULK=VDD

C12 C12:A C12:B 1e-12 $.model=Cdev

L13 L13:A L14:A 10 $.model=Ldev

If NETLIST_PASSIVE_PARAMS:YES is set, the format changes to include any properties you

calculated in the Hercules runset as well as the standard device extraction properties always

calculated by Hercules.

Nonstandard properties, such as capacitor length and width are always generated as

comments in the netlist, because they are not SPICE-model-compatible. For the same

reason, the BULK terminals on ideal RLC devices are always generated as comments in the

netlist.

Chapter 17: StarRC Commands

NETLIST_PASSIVE_PARAMS 17-185

Chapter 17: StarRC Commands

NETLIST_PASSIVE_PARAMS 17-185

StarRC User Guide and Command Reference Version F-2011.06

Example

The following is an example of the NETLIST_PASSIVE_PARAMS: YES format:

R11 R11:A R11:B Rdev r=1000 l=10u w=1000um

$BULK=VDD

C12 C12:A C12:B Cdev c=1e-12 area=100p pj=40u

$l=10u $w=10u

L13 L13:A L13:B Ldev l=10

See Also

•NETLIST_FILE

•NETLIST_INSTANCE_SECTION

•NETLIST_IDEAL_SPICE_FILE

Chapter 17: StarRC Commands

NETLIST_POSTPROCESS_COMMAND 17-186

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

NETLIST_POSTPROCESS_COMMAND

Updates the final netlist prior to simulation.

Syntax

NETLIST_POSTPROCESS_COMMAND: cmd

Arguments

Argument Description

cmd Command to which the StarRC netlist is piped

Description

The NETLIST_POSTPROCESS_COMMAND command gives you the flexibility to update the final

netlist prior to simulation. The StarRC netlist is piped into this command. This command also

works in conjunction with the NETLIST_COMPRESS_COMMAND command. The output of

NETLIST_POSTPROCESS_COMMAND is piped into NETLIST_COMPRESS_COMMAND prior to

writing.

See Also

•NETLIST_COMPRESS_COMMAND

Chapter 17: StarRC Commands

NETLIST_POWER_FILE 17-187

Chapter 17: StarRC Commands

NETLIST_POWER_FILE 17-187

StarRC User Guide and Command Reference Version F-2011.06

NETLIST_POWER_FILE

Controls the file name given to the file created by POWER_EXTRACT:RONLY, which contains

the power rail resistor values.

Syntax

NETLIST_POWER_FILE: file_name

Arguments

Argument Description

file_name The file name of a netlist (for power) with resistors only.

Default: none.

Description

This command should be used only with the POWER_EXTRACT:RONLY command.

See Also

•POWER_EXTRACT

Chapter 17: StarRC Commands

NETLIST_PRECISION 17-188

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

NETLIST_PRECISION

Specifies the default precision of node coordinates in a parasitic netlist.

Syntax

NETLIST_PRECISION: integer

Arguments

Argument Description

integer The precision of node coordinates.

Default: 6

Description

Changes the default precision of node coordinates in a parasitic netlist from 6 digits to the

positive integer specified.

Example

The following line from the netlist shows node coordinates with the default precision of 6

digits:

*|I (MP2:GATE MP2 GATE I 2.88e-16 14765.8 4.2)

The NETLIST_PRECISION: 7 command changes the precision to seven digits, resulting in

the following output:

*|I (MP2:GATE MP2 GATE I 2.88e-16 14765.81 4.2)

See Also

•NETLIST_FORMAT

Chapter 17: StarRC Commands

NETLIST_PRINT_CC_TWICE 17-189

Chapter 17: StarRC Commands

NETLIST_PRINT_CC_TWICE 17-189

StarRC User Guide and Command Reference Version F-2011.06

NETLIST_PRINT_CC_TWICE

Specifies whether or not to generate the reciprocal coupling capacitor twice in the netlist.

Syntax

NETLIST_PRINT_CC_TWICE: YES | NO

Arguments

Argument Description

YES Generates the reciprocal coupling capacitor twice in the netlist.

NO Does not generate the reciprocal coupling capacitor twice in the

netlist.

This is the default.

Description

The second capacitor is reported as a comment so that the netlist remains accurate for

standard simulation and timing analysis. This command is used when the NETLIST_FORMAT

is specified as STAR, or NETNAME.

Chapter 17: StarRC Commands

NETLIST_PRINT_CC_TWICE 17-190

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Example

NETLIST_PRINT_CC_TWICE: NO

*|NET NETA 0.0010000PF

*|I (NETA:F1 I0 A I 0 485.5 11)

*|I (NETA:F2 I1 Z O 0 483.5 11)

R1 NETA:F1 NETA:F2 12.43

C1 NETA:F1 0 6e-15

C2 NETA:F2 0 3.5e-15

C3 NETA:F1 NETB:F1 5e-16

*|NET NETB 0.007000PF

*|P (NETB B 0 32.5 8.3)

*|I (NETB:F1 I32 B I 0 554.3 12)

RNETB NETB:F1 1032

C4 NETB 0 5e-15

C5 NETB:F1 0 1.5e-15

NETLIST_PRINT_CC_TWICE: YES

*|NET NETA 0.0010000PF

*|I (NETA:F1 I0 A I 0 485.5 11)

*|I (NETA:F2 I1 Z O 0 483.5 11)

R1 NETA:F1 NETA:F2 12.43

C1 NETA:F1 0 6e-15

C2 NETA:F2 0 3.5e-15

C3 NETA:F1 NETB:F1 5e-16

*|NET NETB 0.007000PF

*|P (NETB B 0 32.5 8.3)

*|I (NETB:F1 I32 B I 0 554.3 12)

RNETB NETB:F1 1032

C4 NETB 0 5e-15

C5 NETB:F1 0 1.5e-15

*C6 NETB:F1 NETA:F1 5e-16

See Also

•COUPLE_TO_GROUND

•NETLIST_FORMAT

Chapter 17: StarRC Commands

NETLIST_REMOVE_DANGLING_BRANCHES 17-191

Chapter 17: StarRC Commands

NETLIST_REMOVE_DANGLING_BRANCHES 17-191

StarRC User Guide and Command Reference Version F-2011.06

NETLIST_REMOVE_DANGLING_BRANCHES

Removes dangling RC branches in the netlist.

Syntax

NETLIST_REMOVE_DANGLING_BRANCHES: YES | NO

Arguments

Argument Description

YES Removes dangling branches.

NO Does not remove dangling branches.

This is the default.

Description

This command removes dangling RC branches in the netlist. While doing so, it moves the

capacitors (both Cg and Cc) on dangling branches to an appropriate location in the RC

network.

Note the following:

• The possibility of having a dangling RC branch with REDUCTION: YES | HIGH |

NO_EXTRA_LOOPS is low, because REDUCTION would have eliminated it.

•NETLIST_REMOVE_DANGLING_BRANCHES does not affect point-to-point resistance

between *Ps or *Is, because the removed RC branch would be dangling.

•NETLIST_REMOVE_DANGLING_BRANCHES does not work on open nets that have multiple

RCgs.

See Also

•NETLIST_MINRES_HANDLING

•NETLIST_MINRES_THRESHOLD

Chapter 17: StarRC Commands

NETLIST_RENAME_PORTS 17-192

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

NETLIST_RENAME_PORTS

Syntax

NETLIST_RENAME_PORTS: XY | char

Arguments

Argument Description

XY Specifies the suffix based on the instance port cell location.

char Specifies the suffix for the instance port naming.

Default: none

Description

Globally defines the renaming scheme for ports, when any one of the following is used:

•SHORT_PINS: NO

•INSTANCE_PORT: NOT_CONDUCTIVE

•INSTANCE_PORT: CONDUCTIVE SUFFIXED [MULTIPLE] [CAPACITIVE]

The scheme can be either a single-character delimiter or XY. The XY mode forms a unique

suffix from the cell local coordinates of the instance port interaction point, in nanometers.

Example

NETLIST_RENAME_PORTS: XY

Output in the SPEF Nelist

....

*CONN

*P NET1_x42760y105240 B *C 42.76 105.24

*P NET1_x45000y115500 B *C 45.00 115.50 ...

See Also

•INSTANCE_PORT

•SHORT_PINS

Chapter 17: StarRC Commands

NETLIST_RESISTANCE_UNIT 17-193

Chapter 17: StarRC Commands

NETLIST_RESISTANCE_UNIT 17-193

StarRC User Guide and Command Reference Version F-2011.06

NETLIST_RESISTANCE_UNIT

Syntax

NETLIST_RESISTANCE_UNIT: float

Arguments

Argument Description

float Specifies the resistance unit (ohms) in an SPEF netlist.

Default: 1.0

Description

Alters the units used for reporting resistance values in both the header and the body of the

output netlist. Applicable when NETLIST_FORMAT: SPEF.

See Also

•NETLIST_FORMAT

Chapter 17: StarRC Commands

NETLIST_SELECT_NETS 17-194

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

NETLIST_SELECT_NETS

Syntax

NETLIST_SELECT_NETS: net_names

Arguments

Argument Description

net_names List of nets to be netlisted.

Default: all nets (*).

Description

Selects a subset of the extracted NETS to generate in the selected NETLIST_FORMAT or

NETLIST_TYPE. This command may be specified multiple times and may be used during the

first-pass StarRC execution or at any time following the completion of the xTract stage.

Wildcards “*”, “!”, and “?” are supported. The same selection rules detailed in the NETS

command description also apply to this command.

If a net marked for netlisting with NETLIST_SELECT_NETS was not extracted because it was

not on the original NETS list or because it did not exist, a warning is reported.

The value of this option can be modified following successful completion of the xTract stage,

and the -cleanN command-line option or the Timing > Netlist dialog box in the StarRC GUI

can be used to generate a new netlist containing only the selected nets.

See Also

•NETLIST_TYPE

•NETS

Chapter 17: StarRC Commands

NETLIST_SIM_OPTIONS 17-195

Chapter 17: StarRC Commands

NETLIST_SIM_OPTIONS 17-195

StarRC User Guide and Command Reference Version F-2011.06

NETLIST_SIM_OPTIONS

Enables you to specify simulation commands for downstream tools.

Syntax

NETLIST_SIM_OPTIONS: string

Arguments

Argument Description

string The value you specify is directly written into the StarRC parasitic

netlist for downstream tools to interpret.

Description

This command allows you to explicitly set simulation options dependent on the parasitic

extraction settings specified and to avoid double counting or to omit parasitic capacitance or

resistance.

Note:

For multiple options and/or parameters to be printed in the StarRC netlist, the command

must be specified multiple times.

Example

This example shows how the previous three options are specified for inclusion in the StarRC

generated netlist shown in the following output.

NETLIST_SIM_OPTIONS: .param cflag=0

NETLIST_SIM_OPTIONS: .param rflag=0

NETLIST_SIM_OPTIONS: .option scale=0.9

Chapter 17: StarRC Commands

NETLIST_SIM_OPTIONS 17-196

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

*|DSPF 1.3

*|DESIGN Test

*|DATE "Mon Feb 4 17:07:22 2008"

*|VENDOR "Synopsys"

*|PROGRAM "StarRC"

*|VERSION "A-2007.12

*|DIVIDER /

*|DELIMITER :

**FORMAT SPF

** COMMENTS

** TCAD_GRD_FILE process.nxtgrd

** TCAD_TIME_STAMP Tue Nov 27 15:29:49 2007

** TCADGRD_VERSION 62

.param cflag=0

.param rflag=0

.option scale=0.9

*|GROUND_NET 0

*|NET BOUNDBUF_N_838 0.0735652PF

*|I (cg/p0849A134:Z cg/p0849A134 Z O 0 -314.774 -248.309)

...

See Also

•NETLIST_FORMAT

Chapter 17: StarRC Commands

NETLIST_SUBCKT 17-197

Chapter 17: StarRC Commands

NETLIST_SUBCKT 17-197

StarRC User Guide and Command Reference Version F-2011.06

NETLIST_SUBCKT

Syntax

NETLIST_SUBCKT: YES | NO

Arguments

Argument Description

YES Specifies that StarRC outputs .SUBCKT and .ENDS statements.

This is the default.

NO Specifies that StarRC does not output .SUBCKT and .ENDS

statements.

Description

Specifies whether or not to print the .SUBCKT and .ENDS lines in the output STAR/SPF

netlist. It is not applicable to any other netlist format.

See Also

•NETLIST_FORMAT

Chapter 17: StarRC Commands

NETLIST_TAIL_COMMENTS 17-198

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

NETLIST_TAIL_COMMENTS

Provides geometric information about parasitic resistor devices as comments in

NETLIST_FILE for the netlist.

Syntax

NETLIST_TAIL_COMMENTS: YES | NO

Arguments

Argument Description

YES Reports resistor geometric information as comments in the netlist.

NO Does not report resistor geometric information.

This is the default.

Description

The NETLIST_TAIL_COMMENTS command outputs geometric information about parasitic

resistor devices as comments in the file specified by the NETLIST_FILE command.

Table 17-5 lists the allowed REDUCTION and POWER_REDUCTION settings for the

NETLIST_TAIL_COMMENTS command.

Table 17-5 Allowed REDUCTION and POWER_REDUCTION Settings for

NETLIST_TAIL_COMMENTS

Setting

Allowed REDUCTION

Settings

Allowed

POWER_REDUCTION

Settings

YES NO

LAYER

LAYER_NO_EXTRA_LOOPS

TOPOLOGICAL

LAYER

LAYER_NO_EXTRA_LOOPS

TOPOLOGICAL

NO HIGH

NO_EXTRA_LOOPS

YES

HIGH

NO_EXTRA_LOOPS

YES

Chapter 17: StarRC Commands

NETLIST_TAIL_COMMENTS 17-199

Chapter 17: StarRC Commands

NETLIST_TAIL_COMMENTS 17-199

StarRC User Guide and Command Reference Version F-2011.06

For device-level extractions with NETLIST_TAIL_COMMENTS, the LAYER_MAP section of the

netlist can also contain generated layer names. Extra layers are formed when there are

database layers at the diffusion level or below that share a contact. For example, if the runset

contains the line shown in the example, then the LAYER_MAP section contains an extra layer

called nsd:psd or psd:nsd, which becomes the lower terminal lvl of diffCont via resistors.

Example

CONNECT metal1 nsd psd BY diffCon

The SPF, NETNAME, and STAR formats geometric information for the netlist as follows:

R3 n1:3 n1:43 132.4 $l=12.3 $w=0.45 $lvl=3

R4 n1:3 n1:4 1.2 $a=0.6332 $lvl=14

The SPEF format generates geometric information for the netlist as follows:

3 n1:3 n1:43 132.4 // $l=12.3 $w=0.45 $lvl=3

4 n1:3 n1:4 1.2 // $a=0.6332 $lvl=14

R3 in the previous example is a CONDUCTOR resistor, whereas R4 is a VIA resistor. The lvl

information is a number that appears in the LAYER_MAP section of the netlist, just after the

HEADER. The number is associated with a retained MAPPING_FILE layer name.

See Also

•NETLIST_FILE

•NETLIST_FORMAT

•POWER_REDUCTION

•REDUCTION

Chapter 17: StarRC Commands

NETLIST_TIME_UNIT 17-200

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

NETLIST_TIME_UNIT

Syntax

NETLIST_TIME_UNIT: float

Arguments

Argument Description

float Specifies the unit for delay in the SPEF netlist.

Units: seconds

Default: 1e-09

Description

Alters the units used for reporting delay values in the header and the body of the netlist.

Applicable when the NETLIST_FORMAT is SPEF.

See Also

•NETLIST_FORMAT

Chapter 17: StarRC Commands

NETLIST_TOTALCAP_THRESHOLD 17-201

Chapter 17: StarRC Commands

NETLIST_TOTALCAP_THRESHOLD 17-201

StarRC User Guide and Command Reference Version F-2011.06

NETLIST_TOTALCAP_THRESHOLD

Syntax

NETLIST_TOTALCAP_THRESHOLD: capacitance_value

Arguments

Argument Description

capacitance_value Threshold at which the net is treated as ideal and there is not

any D_NET or *|NET in the parasitic netlist. The capacitance

value cannot be less than 0.

Units: farad (F)

Default: 0.0

Description

Determines whether a net is generated in the netlist or not. If the total capacitance is below

the specified threshold, then the net is treated as “ideal” and there is no D_NET or *|NET in

the parasitic netlist.

This command is supported only for transistor-level extraction.

Example

The following example sets the ideal threshold at 0.5 fF.

NETLIST_TOTALCAP_THRESHOLD: 0.5e-15

Chapter 17: StarRC Commands

NETLIST_TYPE 17-202

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

NETLIST_TYPE

Specifies the parasitic type to be generated for nets specified in the NETLIST_SELECT_NETS

command.

Syntax

NETLIST_TYPE: [no_couple] [R | Cg | Cc | RCg | RCc] wildcard_net_names

Arguments

Argument Description

no_couple No coupling capacitance is netlisted from other Cc/RCc nets to the listed

wildcard_net_names nets. When unspecified, any extracted coupling

capacitance is netlisted from other Cc/Rcc/RLc nets to the listed

wildcard_net_names nets. This argument is valid only when used

with NETLIST_TYPE: R, Cg, or RCg.

RResistance only.

Cg Lumped capacitance to ground only.

Cc Coupled capacitance.

RCg Resistance plus lumped capacitance to ground.

RCc Resistance plus coupled capacitance.

wildcard_net_names Name or a list of names to which the specified type of netlist is to be

applied. Wildcards are allowed in this list.

Description

This command is order dependent, meaning that the last NETLIST_TYPE specified for a

particular net or net group overrides previous NETLIST_TYPE specifications for the same net.

When NETLIST_TYPE is not specified, nets are generated according to the EXTRACTION and

COUPLE_TO_GROUND settings.

If a net is specified with NETLIST_TYPE Cc, or RCc, then couplings are included in the netlist

between that net and all other selected nets regardless the NETLIST_TYPE of those other

selected nets unless no_couple is specified for those other selected nets.

Chapter 17: StarRC Commands

NETLIST_TYPE 17-203

Chapter 17: StarRC Commands

NETLIST_TYPE 17-203

StarRC User Guide and Command Reference Version F-2011.06

See Also

•NETLIST_COUPLE_UNSELECTED_NETS

•NETLIST_SELECT_NETS

Chapter 17: StarRC Commands

NETLIST_UNSCALED_COORDINATES 17-204

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

NETLIST_UNSCALED_COORDINATES

Syntax

NETLIST_UNSCALED_COORDINATES: YES | NO

Arguments

Argument Description

YES Outputs unscaled values.

NO Outputs scaled values.

This is the default.

Description

Uses the value specified in the MAGNIFICATION_FACTOR command to de-magnify the layout

coordinates for *|I, *|P, *|S, and INSTANCE_PORT:NOT_CONDUCTIVE port names.

See Also

•INSTANCE_PORT

•MAGNIFICATION_FACTOR

Chapter 17: StarRC Commands

NETLIST_USE_M_FACTOR 17-205

Chapter 17: StarRC Commands

NETLIST_USE_M_FACTOR 17-205

StarRC User Guide and Command Reference Version F-2011.06

NETLIST_USE_M_FACTOR

Syntax

NETLIST_USE_M_FACTOR: YES | NO

Arguments

Argument Description

YES Specifies that device properties calculated with a magnification

factor are output.

This is the default.

NO Specifies that device properties calculated without a

magnification factor are output.

Description

Uses the magnification factor from the schematic netlist to calculate device properties.

Note:

NETLIST_USE_M_FACTOR is relevant only when XREF:COMPLETE is also specified. The

value is ignored for any other setting.

See Also

•XREF

Chapter 17: StarRC Commands

NETS 17-206

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

NETS

Creates a white-space-delimited list of nets for StarRC to extract and generate a netlist.

Syntax

NETS: string

Arguments

Argument Description

string Specifies a list of nets to be extracted.

Default: all nets (*)

Description

This command may be listed multiple times in a single command file. The wildcards “*”, “?”,

and “!” are acceptable.

If the names originate from a hierarchical netlist, they must be fully flattened with the

appropriate hierarchical separator, as defined by the HIERARCHICAL_SEPARATOR command.

Additionally, any reserved character escaping from the input database must be included in

this list to tag the literal use of special characters such as the BUS_BIT delimiter. Names

must be case-sensitive only in accordance with the value of the CASE_SENSITIVE command.

The input database case is always preserved in the output netlist, regardless of the case

used in this list.

StarRC does not alter the net information in the input database except to flatten names as

required. It is important to understand how the place and route tool handles names. If

possible, extract names directly from the input database.

StarRC has the capability to extract resistance and capacitance from 45-degree routed nets.

This is done by default and you need not specify additional commands.

The following example demonstrates the extraction of names from a hierarchical Verilog and

assumes that the place and route tool remembered to handle special characters in the

Verilog identifiers.

The example shows the correct way to specify a list of nets for extraction from a sample

Verilog netlist.

Chapter 17: StarRC Commands

NETS 17-207

Chapter 17: StarRC Commands

NETS 17-207

StarRC User Guide and Command Reference Version F-2011.06

Example

module low ( A , Y ) ;

input A ;

output Y ;

wire n1 ;

INVX1 X0 (.A(A ), .Y(n1 )) ;

INVX1 X1 (.A(n1 ), .Y(Y ));

endmodule

module mid ( IN , OUT ) ;

input IN ;

output OUT ;

wire \instA/din[1] , net2 ;

low U0/instA (.A(IN ), .Y(\instA/din[1] )) ;

INVX1 U1 (.A(\instA/din[1] ), .Y(net2 )) ;

INVX1 U2 (.A(net2 ), .Y(OUT )) ;

endmodule

module top ( SIG, SAME ) ;

input SIG ;

output SAME ;

wire route1 ;

mid U10 (.IN(SIG ), .OUT(route1 ));

mid U11 (.IN(route1 ), .OUT(SAME ));

endmodule

Suppose that HIERARCHICAL_SEPARATOR: / and BUS_BIT: []. To extract instA/din[1]

from instance U10 in block top, specify the following:

NETS: U10/instA\/din\[1\]

To extract n1 from U0/instA of U10 in block top, specify the following:

NETS: U10/U0\/instA/n1

See Also

•BUS_BIT

•CASE_SENSITIVE

•HIERARCHICAL_SEPARATOR

•NET_TYPE

•NETS_FILE

Chapter 17: StarRC Commands

NETS_FILE 17-208

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

NETS_FILE

Syntax

NETS_FILE: file1 [file2... fileN]

Arguments

Argument Description

file1 [file2...

fileN]

Specifies the files containing the NETS command lines.

Default: none

Description

Specifies one or more files containing a series of NETS commands.

Example

Suppose you have a filed named myNets, which contains the following lines:

NETS: neta1 neta2

NETS: netb1 netb2 netb3

NETS: clock1

The following command specifies that myNets file contains your series of NETS commands:

NETS_FILE: myNets

See Also

•BUS_BIT

•CASE_SENSITIVE

•HIERARCHICAL_SEPARATOR

•NETS

Chapter 17: StarRC Commands

NONCRITICAL_COUPLING_REPORT_FILE 17-209

Chapter 17: StarRC Commands

NONCRITICAL_COUPLING_REPORT_FILE 17-209

StarRC User Guide and Command Reference Version F-2011.06

NONCRITICAL_COUPLING_REPORT_FILE

Specifies the file name for the noncritical coupling report.

Syntax

NONCRITICAL_COUPLING_REPORT_FILE: output_file

Arguments

Argument Description

output_file Name StarRC assigns to the noncritical coupling report file.

Default: an empty string.

Description

Report file generation is supported in the Milkyway flow. The format of the file includes the

following:

• A comment at the top of the file refers to the corresponding SPEF filename, prefix

command, and suffix command.

• The report lists all coupling capacitances from noncritical nets to critical nodes, in reverse

order from the .spef output. For example, if the SPEF lists the first line shown in the

following, the report output lists what is shown on the second line.

SPEF:

14 A B/SYNOPSYS_INCONTEXT_b 1.0e-15

Report file:

14 B/SYNOPSYS_INCNTEXT_b A 1.0e-15

• The command works with NETLIST_NAME_MAP:YES | NO for net name mapping of

noncritical net names.

Do not specify the same name for the report file name with either the NETLIST_FILE or

COUPLING_REPORT_FILE commands. Otherwise, StarRC generates an error message and

stops.

Retaining coupling capacitances between the top-level parent routing and skip_cell child

net routing exists for the Milkyway flow using the SPEF netlist format.

Only SPEF format is supported. If the user-specified netlist is not SPEF, StarRC issues a

warning message.

Chapter 17: StarRC Commands

NONCRITICAL_COUPLING_REPORT_FILE 17-210

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

See Also

•NETLIST_FORMAT: SPEF

•COUPLE_NONCRITICAL_NETS

•COUPLE_NONCRITICAL_NETS_PREFIX

•RING_AROUND_THE_BLOCK

•SKIP_CELLS_COUPLE_TO_NET

•ZONE_COUPLE_TO_NET

Chapter 17: StarRC Commands

NUM_PARTS 17-211

Chapter 17: StarRC Commands

NUM_PARTS 17-211

StarRC User Guide and Command Reference Version F-2011.06

NUM_PARTS

Specifies the number of partitions for distributed processing.

Syntax

NUM_PARTS: number_of_partitions

Arguments

Argument Description

number_of_partitions Number of CPUs

Default: 1

Description

The NUM_PARTS command enables distributed processing for extraction (assuming that the

relevant licenses are acquired) and specifies the number of partitions. When set to a value

greater than 1, the design is physically partitioned into that number of parts and distributed

among the participating CPUs.

For additional information, see “Distributed Processing” on page 2-6.

Chapter 17: StarRC Commands

OA_DEVICE_MAPPING_FILE 17-212

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

OA_DEVICE_MAPPING_FILE

Specifies the mapping file to link database and OA device names.

Syntax

OA_DEVICE_MAPPING_FILE: file_path

Arguments

Argument Description

file_path OA device mapping file location.

Default: none

Description

For an example of the mapping file, see “Writing a Mapping File” on page 3-58.

Example

OA_DEVICE_MAPPING_FILE: /path/oa_device_map

See Also

•NETLIST_FORMAT: OA

•OA_LAYER_MAPPING_FILE

Chapter 17: StarRC Commands

OA_LAYER_MAPPING_FILE 17-213

Chapter 17: StarRC Commands

OA_LAYER_MAPPING_FILE 17-213

StarRC User Guide and Command Reference Version F-2011.06

OA_LAYER_MAPPING_FILE

Specifies the mapping file to link database and OA layer names.

Syntax

OA_LAYER_MAPPING_FILE: file_path

Arguments

Argument Description

file_path OA layer mapping file location

Default: none

Description

For an example of the mapping file, see “Writing a Mapping File” on page 3-58.

Example

OA_LAYER_MAPPING_FILE: /path/oa_layer_map

See Also

•NETLIST_FORMAT: OA

•OA_DEVICE_MAPPING_FILE

Chapter 17: StarRC Commands

OA_LIB_DEF 17-214

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

OA_LIB_DEF

Syntax

OA_LIB_DEF: file_path

Arguments

Argument Description

file_path Path to library definition file.

Default: lib.defs

Description

Specifies the path to a file which defines libraries referenced in OA_DEVICE_MAPPING_FILE

and OA_LAYER_MAPPING_FILE.

Example

OA_LIB_DEF: /path/lib.def

See Also

•NETLIST_FORMAT:OA

•OA_DEVICE_MAPPING_FILE

•OA_LAYER_MAPPING_FILE

•OA_LIB_DEF

•OA_READ_FILL_VIEW

•OA_READ_LIB_NAME

•OA_READ_VIEW_NAME

Chapter 17: StarRC Commands

OA_LIB_NAME 17-215

Chapter 17: StarRC Commands

OA_LIB_NAME 17-215

StarRC User Guide and Command Reference Version F-2011.06

OA_LIB_NAME

Specifies the name of the Open Access (OA) library written by StarRC.

Syntax

OA_LIB_NAME: library_name

Arguments

Argument Description

library_name Library name

Default: none

Description

The OA_LIB_NAME command specifies the name of the Open Access (OA) library written by

StarRC. The path to the library can be specified in the OA_LIB_DEF file.

Example

OA_LIB_NAME: PLL

See Also

•NETLIST_FORMAT:OA

•OA_DEVICE_MAPPING_FILE

•OA_LAYER_MAPPING_FILE

Chapter 17: StarRC Commands

OA_MARKER_SIZE 17-216

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

OA_MARKER_SIZE

Specifies the port or subnode marker size.

Syntax

OA_MARKER_SIZE: value

Arguments

Argument Description

value The port or subnode marker size.

Units: microns

Default: 0.1

Description

This command is optional.

Example

OA_MARKER_SIZE: 0.4

See Also

•NETLIST_FORMAT:OA

Chapter 17: StarRC Commands

OA_PORT_ANNOTATION_VIEW 17-217

Chapter 17: StarRC Commands

OA_PORT_ANNOTATION_VIEW 17-217

StarRC User Guide and Command Reference Version F-2011.06

OA_PORT_ANNOTATION_VIEW

Enables the simulation of a parasitic view generated by the Open Access writer.

Syntax

OA_PORT_ANNOTATION_VIEW: lib_name cell_name view_name

Arguments

Argument Description

lib_name Library name containing the top-level port information.

cell_name Cell name containing the top-level port information.

view_name View name containing the top-level port information.

Description

The function accepts a library name, cell name, or view name containing the pins or ports of

interest. The specified library, cell, or view name must correspond to the top-level block. If

the Open Access writer cannot find the named string, a warning is issued and the annotation

view is not generated.

The command functions in the following way:

• For each port in the OA_PORT_ANNOTATION_VIEW, there must be a port on the net in the

parasitic view with the same name. If the net does not have that same port, a port is

created on that net.

• If the port has been created after extraction, there is no annotation for that port.

Example

This example shows how the schematic view from the specified alib and acell arguments is

checked for schematic-only properties. The schematic-only properties are attached from the

Open Access parasitic view.

OA_PORT_ANNOTATION_VIEW: alib acell symbol

See Also

•NETLIST_FORMAT: OA

Chapter 17: StarRC Commands

OA_PROPERTY_ANNOTATION_VIEW 17-218

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

OA_PROPERTY_ANNOTATION_VIEW

Syntax

OA_PROPERTY_ANNOTATION_VIEW: [lib] [cell] view_name

Arguments

Argument Description

lib Checks ideal devices for schematic-only properties in this library.

cell Checks ideal devices for schematic-only properties in this cell.

view_name A view name in the current extraction library. It can be a library name, cell

name, or a view name. A warning is issued

- If the specified lib, cell, or view cannot be found (cannot be opened).

- If you specify more than the allowed names (an invalid value).

Description

Specifies which schematic library, cell, or view is used to check against ideal devices for

schematic-only properties and to attach them into the Open Access parasitic view.

If some ideal instances cannot be correctly cross-referenced, for example I0/I1/ld_M21,

the Open Access writer does not do a schematic annotation for it, while issuing an internal

warning for it as in the following text:“Warning: Instance I0|I1|ld_M21 can’t get

property from schematic view as not-XREF-ed”

Only XREF:YES and XREF:COMPLETE are supported in the schematic view annotation.

Example

This example shows the specified alib and acell arguments that are checked for

schematic-only properties. The Open Access parasitic view is schematic.

OA_PROPERTY_ANNOTATION_VIEW: alib acell schematic

See Also

•XREF: YES

•XREF: COMPLETE

•NETLIST_FORMAT: OA

Chapter 17: StarRC Commands

OA_READ_FILL_VIEW 17-219

Chapter 17: StarRC Commands

OA_READ_FILL_VIEW 17-219

StarRC User Guide and Command Reference Version F-2011.06

OA_READ_FILL_VIEW

Specifies the Open Access (OA) view that is treated as fill during extraction.

Syntax

OA_READ_FILL_VIEW: fill_view_name

Arguments

Argument Description

fill_view_name View name to be treated as fill during extraction

Default: layout

Description

The OA_READ_FILL_VIEW command specifies the OA view that is treated as fill during

extraction. This can accept lib/cell/view format. The current library or cell is the default.

Example

OA_READ_FILL_VIEW: fill

See Also

•OA_LIB_DEF

•OA_READ_LIB_NAME

•OA_READ_VIEW_NAME

Chapter 17: StarRC Commands

OA_READ_LIB_NAME 17-220

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

OA_READ_LIB_NAME

Specifies the name of the Open Access (OA) library read by StarRC.

Syntax

OA_READ_LIB_NAME: library_name

Arguments

Argument Description

library_name Library name

Default: none

Description

The OA_READ_LIB_NAME command specifies the name of the Open Access (OA) library read

by StarRC. The path to the library can be specified in the OA_LIB_DEF file.

Example

OA_READ_LIB_NAME: Top

See Also

•OA_LIB_DEF

•OA_READ_FILL_VIEW

•OA_READ_VIEW_NAME

Chapter 17: StarRC Commands

OA_READ_VIEW_NAME 17-221

Chapter 17: StarRC Commands

OA_READ_VIEW_NAME 17-221

StarRC User Guide and Command Reference Version F-2011.06

OA_READ_VIEW_NAME

Specifies the name of the Open Access (OA) view read by StarRC.

Syntax

OA_READ_VIEW_NAME: view_name

Arguments

Argument Description

view_name View name

Default: layout

Description

The OA_READ_VIEW_NAME command specifies the name of the Open Access (OA) view read

by StarRC.

Example

OA_READ_VIEW_NAME: layout

See Also

•OA_LIB_DEF

•OA_READ_FILL_VIEW

•OA_READ_LIB_NAME

Chapter 17: StarRC Commands

OA_SKIPCELL_MAPPING_FILE 17-222

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

OA_SKIPCELL_MAPPING_FILE

Specifies a file to define SKIP_CELL extraction in an Open Access flow.

Syntax

OA_SKIPCELL_MAPPING_FILE: oa_skip_file

Arguments

Argument Description

oa_skip_file Name of the cell to skip at a particular hierarchical level.

Default: none.

Description

For hierarchical designs, you might only want to extract the top-level design for a parasitic

view, without extracting the lower-level block. One of the benefits of doing this is to greatly

reduce the view generation time without noticeable accuracy degradation. A similar situation

is in normal ASCII DSPF flow, the SKIP_CELLS command is normally set for pre-extracted

blocks. In a DSPF flow, those skipped cells specified in a SKIP_CELLS command are listed

in the *Instance Section* for simulation purposes.

To do this skipping operation in an Open Access writer parasitic view, you must specify

which cell master to use for the SKIP_CELL instantiation in the parasitic view. Each

SKIP_CELL specified has corresponding mapping information for cell instantiation in the

parasitic view.

Example

SKIP_CELLS: INV1 INV2

OA_SKIPCELL_MAPPING_FILE: my_skip_file

The following is the OA_SKIPCELL_MAPPING_FILE, my_skip_file.

INV1 analogLib INV symbol

INV2 analogLib INV symbol

INV3 analogLib INV symbol

Even though there might be an INV3 in the top block, it is not treated as SKIP_CELL since it

is not listed in the SKIP_CELLS command.

See Also

•NETLIST_FORMAT: OA

•SKIP_CELLS

Chapter 17: StarRC Commands

OA_VIEW_NAME 17-223

Chapter 17: StarRC Commands

OA_VIEW_NAME 17-223

StarRC User Guide and Command Reference Version F-2011.06

OA_VIEW_NAME

Specifies the name of the OA parasitic view generated by StarRC.

Syntax

OA_VIEW_NAME: view_name

Arguments

Argument Description

view_name Name of OA parasitic view.

Default: starrc

Description

You can specify the name of the OA parasitic view generated by StarRC. By default, the OA

parasitic view name is starrc. This command is optional.

Example

OA_VIEW_NAME: extract_view

See Also

•NETLIST_FORMAT:OA

Chapter 17: StarRC Commands

OASIS_FILE 17-224

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

OASIS_FILE

Specifies OASIS format files to represent part of the physical layout.

Syntax

OASIS_FILE: file1 [file2] ...

Arguments

Argument Description

file1 [file2] ... Name of OASIS file

Default: none

Description

The OASIS_FILE command specifies OASIS format files to represent part of the physical

layout. You can specify gzipped and compressed OASIS files for this command.

With LEF_FILE and TOP_DEF_FILE, this command merges OASIS data into LEF MACRO

definitions for SKIP_CELLS to provide a full physical layout representation. When this

command is specified, only the pin shapes from the LEF MACRO are used for the cells

which are defined both by the LEF MACRO and the OASIS_FILE. Any material defined

within the OBS section of the LEF MACRO is overwritten and replaced by material defined

within any OASIS_FILE cells of the same name. If no matching cell name is found within the

OASIS_FILE for a particular DEF cell placement, then the OBS section of the corresponding

LEF MACRO continues to be used for that cell.

The OASIS_FILE command

• Can be specified multiple times

• Must be used with the OASIS_LAYER_MAP_FILE command

• Cannot be used with the GDS_FILE command

See Also

•OASIS_LAYER_MAP_FILE

•SKIP_CELLS

Chapter 17: StarRC Commands

OASIS_LAYER_MAP_FILE 17-225

Chapter 17: StarRC Commands

OASIS_LAYER_MAP_FILE 17-225

StarRC User Guide and Command Reference Version F-2011.06

OASIS_LAYER_MAP_FILE

Specifies the mapping between the OASIS layer number and layer name in the design

database.

Syntax

OASIS_LAYER_MAP_FILE: file_name

Arguments

Argument Description

file_name OASIS layer map file name

Default: none

Description

The OASIS_LAYER_MAP_FILE command specifies the mapping between the OASIS layer

number and layer name in the design database whenever OASIS_FILE or

METAL_FILL_OASIS_FILE is used to import OASIS data into the design database.

Note:

The OASIS_LAYER_MAP_FILE command cannot be used with the GDS_LAYER_MAP_FILE

command.

OASIS_LAYER_MAP_FILE Syntax

The OASIS_LAYER_MAP_FILE uses the following syntax:

database_layer oasis_layer_number oasis_datatype

{FLOATING | GROUNDED | IGNORE}

Table 17-6 OASIS File Syntax

Argument Description

database_layer Specifies the database layer name that is mapped in the

MAPPING_FILE.

oasis_layer_number Specifies the OASIS layer number.

oasis_datatype Specifies the OASIS data type. If a oasis_datatype is not specified,

then all data types on a given layer are read.

Chapter 17: StarRC Commands

OASIS_LAYER_MAP_FILE 17-226

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

All OASIS layers for translation must have an entry in this file and must have a definition in

the layout database. The OASIS_LAYER_MAP_FILE can be used either to import OASIS cell

material into a LEF/DEF database (OASIS_FILE) or to import metal fill polygons into a

Milkyway, LEF/DEF, or Calibre Connectivity Interface database (METAL_FILL_OASIS_FILE).

If both METAL_FILL_OASIS_FILE and OASIS_FILE are being used in a single run for a LEF/

DEF database, a single unified layer mapping file should be used for both the OASIS files.

An error occurs if any layer is specified in the file for which a corresponding layer does not

exist in the layout database.

The additional specification of a layer-specific fill-handling keyword is available to allow

users to selectively decide how individual metal fill layers are handled during parasitic

extraction. This handling is considered only when METAL_FILL_POLYGON_HANDLING:

AUTOMATIC is set in the StarRC command file. If METAL_FILL_POLYGON_HANDLING:

AUTOMATIC is set in the StarRC command file, but a fill-handling mode is not specified for a

particular layer inside OASIS_LAYER_MAP_FILE, StarRC assumes a default of FLOATING for

that layer. If another setting of METAL_FILL_POLYGON_HANDLING (other than AUTOMATIC) is

specified in the StarRC command file, that setting governs the handling of all layers, and any

layer-specific mode specifications inside OASIS_LAYER_MAP_FILE are disregarded.

FLOATING Optional keyword that specifies whether the corresponding fill layer is

to be treated as floating. If METAL_FILL_POLYGON_HANDLING:

AUTOMATIC is specified in the command file, then the fill handling

mode FLOATING is used for the corresponding layer. If

METAL_FILL_POLYGON_HANDLING: AUTOMATIC is not specified, in the

command file, this argument in the OASIS_LAYER_MAP_FILE is

ignored.

GROUNDED Optional keyword that specifies whether the corresponding fill layer is

to be treated as grounded. If METAL_FILL_POLYGON_HANDLING:

AUTOMATIC is specified in the command file, then the fill handing

mode GROUNDED is used for the corresponding layer. If

METAL_FILL_POLYGON_HANDLING:AUTOMATIC is not specified in the

command file, this argument in the OASIS_LAYER_MAP_FILE is

ignored.

IGNORE Optional keyword that specifies whether the corresponding fill layer is

to be treated as ignored. If

METAL_FILL_POLYGON_HANDLING:AUTOMATIC is specified in the

command file, then the fill handling mode IGNORE is used for the

corresponding layer. If METAL_FILL_POLYGON_HANDLING:

AUTOMATIC is not specified in the command file, this argument in the

OASIS_LAYER_MAP_FILE is ignored.

Table 17-6 OASIS File Syntax (Continued)

Argument Description

Chapter 17: StarRC Commands

OASIS_LAYER_MAP_FILE 17-227

Chapter 17: StarRC Commands

OASIS_LAYER_MAP_FILE 17-227

StarRC User Guide and Command Reference Version F-2011.06

Note that in the given example, handling mode GROUNDED is specified for layer DIFF. If

METAL_FILL_POLYGON_HANDLING: AUTOMATIC is also specified in the StarRC command file,

DIFF is treated as GROUNDED while all other layers are treated as FLOATING. If

METAL_FILL_POLYGON_HANDLING:AUTOMATIC is not specified, the layer-specific mode

specification for DIFF is disregarded, and the global mode set by

METAL_FILL_POLYGON_HANDLING takes precedence.

Example

The following example shows how the DIFF layer is assigned to OASIS layer 2 and OASIS

datatype 0. Note that this example maps layers from a METAL_FILL_OASIS_FILE and

specifies layer-specific fill handling for the DIFF layer.

Example 17-11 Layer-Specific Fill Handling

DIFF 2 0 GROUNDED

POLY 7 0

CONT 4 0

METAL1 10 0

METAL1 10 1

METAL1 76 0

VIA1 11 0

METAL2 12 0

In the following example, the METAL_FILL_POLYGON_HANDLING: AUTOMATIC command is

set in the command file.

Example 17-12 Automatic Fill Handling

*layer treated as grounded

DIFF 2 0 GROUNDED

*layer treated as floating

POLY 7 0 FLOATING

*layer governed by default floating mode since mode is unspecified.

METAL1 4 0

See Also

•OASIS_FILE

•LEF_FILE

•METAL_FILL_OASIS_FILE

Chapter 17: StarRC Commands

OBSERVATION_POINTS 17-228

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

OBSERVATION_POINTS

Specifies cells that are not skipped for reporting observation nodes in the output netlist.

Syntax

OBSERVATION_POINTS: wildcard_cell_list

Arguments

Argument Description

wildcard_cell_list List of (nonskipped) cell names.

Default: none.

Description

Observation nodes are netlisted as **O statements in the SPEF-format netlist and as **|O

statements in the DSPF-, NETNAME-, and STAR-format netlists. The observation point

statement has formatting identical to the *I and *|I statements.

Note:

This command is not supported for LEF/DEF input.

OBSERVATION_POINTS generates nodes at nonskipped hierarchical interactions.

Observation nodes also exist in the parasitics section of the netlist, allowing these locations

to be probed during simulation.

OBSERVATION_POINTS works with XREF:NO, YES, and COMPLETE. Only EQUIV points can be

selected cells with the OBSERVATION_POINTS command. Schematic names are used with

observation nodes netlisting when XREF is used. The CELL_TYPE option determines which

cell names are applied for selection.

Observation nodes are formed from marker layers. If there are no marker shapes in a

selected level of hierarchy, there are no **O statements.

With the default automatic marker generation, there must be a hierarchical interaction of the

routing layers to get a marker shape for **O at that level of the hierarchy. You can also control

OBSERVATION_POINTS by generating marker shapes with MARKER_GENERATION: USER.

Note:

Remember that the marker shape has nothing to do with either TEXT_POLYGON

commands in Hercules runset or marker_layers in the mapping file when

MARKER_GENERATION: is set to AUTOMATIC.

Chapter 17: StarRC Commands

OBSERVATION_POINTS 17-229

Chapter 17: StarRC Commands

OBSERVATION_POINTS 17-229

StarRC User Guide and Command Reference Version F-2011.06

See Also

•CELL_TYPE

•MARKER_GENERATION

•XREF

Chapter 17: StarRC Commands

OPERATING_TEMPERATURE 17-230

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

OPERATING_TEMPERATURE

Sets the temperature to calculate resistance when an R dependency is specified in the

nxtgrd.

Syntax

OPERATING_TEMPERATURE: float

Arguments

Argument Description

float The operating temperature

Units: degrees Celsius.

Default: none.

Description

Also sets the value to print in the SPEF DESIGN_FLOW TEMPERATURE header card.

Units are determined by the tool that reads the information.

OPERATING_TEMPERATURE must be defined in the star_cmd file in order to use the derating

information in the nxtgrd. If the resistance of a layer is changed by the mapping file, the

resistance value is taken for derating and the ITF value is ignored.

Example

OPERATING_TEMPERATURE: -40 25 125

TCAD_GRD_FILE: rcbest.nxtgrd rctyp.nxtgrd rcworst.nxtgrd

This example shows how rcbest.nxtgrd is extracted at -40, rctyp.nxtgrd at 25 degrees

Celsius, and rcworst.nxtgrd is extracted at 125 degrees Celsius.

The OPERATING_TEMPERATURE command accepts multiple values separated by spaces.

StarRC checks that the number of values is equal to the number of corners (or 1) and that

individual values are in the valid range. The new field temperatures can be found in the

netlist under the DESIGN field. This string can contain multiple integers separated by colons

(:).

Supporting Multiple OPERATING_TEMPERATURE for Multicorner Extraction

You can set different OPERATING_TEMPERATURE commands for different corners in a

multicorner extraction flow.

Chapter 17: StarRC Commands

OPERATING_TEMPERATURE 17-231

Chapter 17: StarRC Commands

OPERATING_TEMPERATURE 17-231

StarRC User Guide and Command Reference Version F-2011.06

Specify multiple commands as shown in the following example:

CORNER_NAME: CMAX

OPERATING_TEMPERATURE:-40

M1_T 3.0

M1_W 3.0

M12_T -3.0

M2_T 3.0

M2_W 3.0

M23_T -3.0

CORNER_NAME: RCMAX

OPERATING_TEMPERATURE:125

M1_T -3.0

M1_W -3.0

M12_T -3.0

M2_T -3.0

M2_W -3.0

M23_T -3.0

CORNER_NAME: M1_CMAX_M2_RCMAX

OPERATING_TEMPERATURE:25

M1_T 3.0

M1_W 3.0

M12_T -3.0

M2_T -3.0

M2_W -3.0

M23_T -3.0

See Also

•NETLIST_FORMAT

•TCAD_GRD_FILE

Chapter 17: StarRC Commands

PIN_CUT_THRESHOLD 17-232

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

PIN_CUT_THRESHOLD

Takes a long port and splits it into multiple *|P.

Syntax

PIN_CUT_THRESHOLD distance_in_nm

Arguments

Argument Description

distance_in_nm Distance at which you want the long port to be cut.

Units: nm

Default: none.

Description

This command takes a long port and splits it into multiple *|P. If a port has a continuous

Manhattan length less than the PIN_CUT_THRESHOLD, there is only one *|P for that segment.

In the case of a long port that is not evenly divisible by the PIN_CUT_THRESHOLD value, the

port is broken up symmetrically as shown in Figure 17-7.

Figure 17-7 Symmetric Division

10.2um

long port

With a PIN_CUT_THRESHOLD value of 2,000 nm, this 10.2m long port would be cut as follows:

1.7 u 1.7 u 1.7 u 1.7 u 1.7 u 1.7 u

XXXXXXX

*|P *|P *|P *|P *|P *|P *|P

Note:

LEF/DEF designs and non-Manhattan port shapes are not supported for this option. So,

using INSTANCE_PORT: NOT_CONDUCTIVE and PIN_CUT_THRESHOLD, the output in the

SPEF netlist would be as follows:

Example

PIN_CUT_THRESHOLD 500

Chapter 17: StarRC Commands

PIN_CUT_THRESHOLD 17-233

Chapter 17: StarRC Commands

PIN_CUT_THRESHOLD 17-233

StarRC User Guide and Command Reference Version F-2011.06

...

*CONN

*P NET1_x40000y105000 B *C 40.00 105.00

*P NET1_x45000y115500 B *C 45.00 115.50

*P NET1_x50000y115500 B *C 50.00 115.50

*P NET1_x55000y115500 B *C 55.00 115.50

....

*I Level_1/NET_A:PIN_A_x10000y10000 *C 10.00 10.00

*I Level_1/NET_A:PIN_A_x15000y20500 *C 15.00 20.50

*I Level_1/NET_A:PIN_A_x20000y20500 *C 20.00 20.50

*I Level_1/NET_A:PIN_A_x25000y20500 *C 25.00 20.50

See Also

•INSTANCE_PORT

Chapter 17: StarRC Commands

PIO_FILE 17-234

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

PIO_FILE

Syntax

PIO_FILE: file1 file2 ... fileN

Arguments

Argument Description

file Name of the file containing the pin descriptions.

Default: none.

Description

Specifies a file containing primary input/output pin direction and loading capacitance. Only

applicable for top-level ports. Information contained in PIO_FILE is applied to the output

netlist. Format is white-space-delimited with one entry per line:

pin_name IN | OUT | BIDIR [cap float]

Example

IN1 IN

CLK IN

OUT OUT cap 5pf

IN2 IN

OUT2 OUT cap 1e-12

See Also

•NETLIST_FORMAT

Chapter 17: StarRC Commands

PLACEMENT_INFO_FILE 17-235

Chapter 17: StarRC Commands

PLACEMENT_INFO_FILE 17-235

StarRC User Guide and Command Reference Version F-2011.06

PLACEMENT_INFO_FILE

Specifies the generation of output placement information.

Syntax

PLACEMENT_INFO_FILE: YES | NO

Arguments

Argument Description

YES Output placement information.

NO Do not output placement information.

Description

StarRC interfaces to HSIM through a Detailed Standard Parasitic Format (DSPF) file for both

hierarchical and flat post-layout simulation flows. The Synopsys product HSIM can receive

hierarchical DSPF and flat DSPF to perform hierarchical or flat timing and reliability analysis.

An important output of reliability analysis is a thermal map showing voltage (IR) drop and

electromigration violations provided by HSIM. Because the HSIM product is netlist based,

the reliability analysis thermal map is generated using node information (*|S, *|I, *|P)

provided by StarRC in the DSPF netlist. In a flat extraction, all nodes are shown with respect

to origin of the top cell, and a thermal map can be drawn without ambiguity. However, in a

hierarchical flow, each node in a hierarchical cell’s DSPF is shown with respect to its origin.

In order to map these nodes to the next level of hierarchy, you must know the placement of

the cell in the next level of hierarchy with rotation and flip attributes.

When PLACEMENT_INFO_FILE is set, StarRC outputs a file blockname.placement_info that

has the following information:

•Angle

• Reflection

• Location of the cell

• Cell name

• Cross-referenced instance name

Chapter 17: StarRC Commands

PLACEMENT_INFO_FILE 17-236

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Example

The following is an example of a transistor-level placement file.

* PLACEMENT FILE

* VENDOR: "Synopsys Inc."

* PROGRAM: "StarRC"

* VERSION: "Y-2006.06-SP1-1

* DATE: "Mon Oct 30 22:42:45 2006"

* UNIT: "MICRONS"

TOP_CELL = STBASE

inst_name cell_name X_Coord Y_Coord Angle reflection

xSD_8/M1 P 8.5 54 0 NO

xSD_8/M2 N 8.5 17 0 NO

xSD_9/M1 P 8.5 54 0 NO

xSD_9/M2 N 8.5 17 0 NO

xSD_10/M1 P 8.5 54 0 NO

xSD_10/M2 N 8.5 17 0 NO

xSD_11/M1 P 15.5 54 0 NO

xSD_11/M2 P 8.5 54 0 NO

xSD_11/M3 P 29.5 54 0 NO

xSD_11/M4 N 29.5 17 0 NO

xSD_11/M5 N 8.5 17 0 NO

xSD_11/M6 N 15.5 17 0 NO

* End of File

This is a sample output from a placement file. An example transistor-level placement file

follows the argument list.

* PLACEMENT FILE

* VENDOR "Synopsys, Inc."

* PROGRAM: "StarRC"

* DATE: "Mon Oct 30 22:39:56 2006"

* UNIT " MICRONS"

TOP_CELL = SMALLARRAY

inst_name cell_name X_Coord Y_Coord Angle reflection

xSD_0 STBASE -1925.8 -379 0 NO

xSD_1 STBASE -1797.2 -379 0 NO

xSD_2 STBASE -1668.6 -379 0 NO

xSD_3 STBASE -1540 -379 0 NO

xSD_4 STBASE -1411.4 -379 0 NO

xSD_5 STBASE -1282.8 -379 0 NO

xSD_6 STBASE -1154.2 -379 0 NO

xSD_7 STBASE -1025.6 -379 0 NO

Chapter 17: StarRC Commands

POWER_EXTRACT 17-237

Chapter 17: StarRC Commands

POWER_EXTRACT 17-237

StarRC User Guide and Command Reference Version F-2011.06

POWER_EXTRACT

Syntax

POWER_EXTRACT: YES | NO | RONLY | DEVICE_LAYERS

Arguments

Argument Description

YES Extracts the power nets.

NO Does not extract the power nets. The power nets are taken into

consideration when the signal nets are extracted. However, they

are not netlisted and the resulting effect on the signal nets is

reported as a grounded capacitance.

This is the default.

RONLY Extracts the power nets for R only and output separately.

Creates an additional resistor-only netlist when the

NETLIST_POWER_FILE and POWER_EXTRACT:YES

commands are used.

DEVICE_LAYERS Extracts the resistance and capacitance for the power nets

whose layers are specified in the mapping file with a device-layer

keyword along with all net extraction. (Hercules and Calibre

only)

Description

Selects the power nets to be extracted. The power nets are identified implicitly in a routed

Milkyway database or a LEF/DEF layout description. The command to specify the power

nets is POWER_NETS.

Using POWER_EXTRACT:RONLY creates an additional resistor-only netlist when the

NETLIST_POWER_FILE and POWER_EXTRACT: YES commands are used.

With the DEVICE_LAYERS command argument, you can extract the resistance from selected

power nets you define in your mapping file with a device_layer keyword.

Note:

The DEVICE_LAYERS command argument and device_layer keyword are very similar.

Use DEVICE_LAYERS in the command file; use device_layer in the mapping file. Verify

that you have specified them correctly or your results might not be accurate.

Chapter 17: StarRC Commands

POWER_EXTRACT 17-238

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

In the netlist, the signal nets have resistance and capacitance parasitics whereas the power

nets have only resistance parasitics included in the netlist. The coupling capacitances

between the signal and power nets are kept and grounded. The coupling capacitances for

power nets are not extracted, and the total capacitance reported for power nets is zero. The

order of the signal and power nets can be output in any order in the netlist. The

device_layer keyword can be specified in any order in the mapping file for the conducting

and via layers when RPSQ, RPV, device model, or via merging options are used. If the

power nets are not specified in the command file, StarRC reads them from the Hercules or

Calibre rule files.

For more information, see Chapter 20, “Mapping File Commands.”

DEVICE_LAYERS Argument Behavior

The following table describes the DEVICE_LAYERS behavior when specified as shown.

Table 17-7 DEVICE_LAYERS Behavior

Commands in File Expected Netlist and Instance Section

Behavior

NETS:*

POWER_NETS:VDD VSS

POWER_EXTRACT:DEVICE_LAYERS

Extracts contact, gate, and diffusion resistance

for VDD and VSS power nets based on the

device_layer keyword in the mapping file along

with all net extraction. The instance section

netlist lists all the devices connected to these

power nets along with the signal nets.

NETS:*

POWER_NETS:VDD VSS

POWER_EXTRACT:NO | YES | RONLY

No effect.

Errors

The following error conditions and restrictions exist when you are using the DEVICE_LAYERS

command argument:

• When NETS:XYZ is specified for a POWER_EXTRACT: DEVICE_LAYERS command. Note

that the NETS command default used with POWER_EXTRACT is all nets so you must specify

a wildcard, not net names.

• Issues an error message when no conducting layer or via layer is defined by a

device_layer keyword in the mapping file when POWER_EXTRACT:DEVICE_LAYERS is in

the command file.

• Issues an error message when the DEVICE_LAYERS argument is specified for a Milkyway

or LEF/DEF work flow.

Chapter 17: StarRC Commands

POWER_EXTRACT 17-239

Chapter 17: StarRC Commands

POWER_EXTRACT 17-239

StarRC User Guide and Command Reference Version F-2011.06

See Also

•AUTO_RUNSET

•NETLIST_MINRES_HANDLING

•NETLIST_MINRES_THRESHOLD

•NETLIST_PARASITIC_RESISTOR_MODEL

•NETLIST_SELECT_NETS

•NETLIST_POWER_FILE

•NETS

•POWER_NETS

•POWER_REDUCTION

•TRANSLATE_RETAIN_BULK_LAYERS

Chapter 17: StarRC Commands

POWER_NETS 17-240

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

POWER_NETS

Identifies power nets for special treatment during extraction.

Syntax

POWER_NETS: netnames

Arguments

Argument Description

netnames List of net names to identify power nets.

Default: none

Description

The power nets are implicitly defined in place and route Milkyway and LEF/DEF databases

and do not need to be specified in the StarRC command file. If this command is not specified

for a Hercules database, StarRC attempts to read the list of power nets from the Hercules

runset. An optional command for a Hercules flow extraction.

The wildcards “*”, “?”, and “!” are acceptable in this white-space- delimited list, and case

sensitivity is determined by the value of the CASE_SENSITIVE command.

See Also

•CASE_SENSITIVE

•POWER_EXTRACT

•NET_TYPE

•XREF

Chapter 17: StarRC Commands

POWER_PORTS 17-241

Chapter 17: StarRC Commands

POWER_PORTS 17-241

StarRC User Guide and Command Reference Version F-2011.06

POWER_PORTS

Defines a list of patterns for identifying POWER/GROUND-type ports for SKIP_CELLS if their

types are not explicitly defined in the database and their names are different from the top

level POWER_NETS.

Syntax

POWER_PORTS: wildcard_list

Arguments

Argument Description

wildcard_list Specifies the list of port names to identify to the power nets.

Default: List specified by the POWER_NETS statement.

Description

In LEF/DEF input, the USE POWER and USE GROUND keywords in LEF MACRO PIN definitions

identify the usage.

In Milkyway place and route input, the port-type tables defined at stream-in and/or during

BLOCKAGE_PIN_VIA_EXTRACTION determine the usage. Querying the PIN shapes in the

FRAM views indicates their usage type. For Hercules XTR view input, none of the ports are

marked.

By default, POWER_PORTS inherits the POWER_NETS list.

See Also

•NETLIST_POWER_FILE

•POWER_NETS

Chapter 17: StarRC Commands

POWER_REDUCTION 17-242

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

POWER_REDUCTION

Determines whether or not reduction of extracted power nets occurs during extraction.

Syntax

POWER_REDUCTION: NO | LAYER | LAYER_NO_EXTRA_LOOPS | YES

Arguments

Argument Description

NO This option is similar to REDUCTION: NO, except that the reduction is

applied to power nets rather than signal nets.

LAYER This option is similar to REDUCTION: LAYER, except that the

reduction is applied to the specified power nets rather than signal nets.

Reduction is not applied across different conductor layers.

LAYER_NO_EXTRA_LOOPS This option is similar to REDUCTION: LAYER_NO_EXTRA_LOOPS,

except that the reduction is applied to the specified power nets rather

than signal nets. Reduction is not applied across different conductor

layers.

YES This option is similar to REDUCTION: YES, except that the reduction is

applied to the specified power nets rather than signal nets.

Description

POWER_REDUCTION does not apply to POWER_EXTRACT:YES. POWER_REDUCTION is in effect

only when POWER_EXTRACT: is set to RONLY. When POWER_EXTRACT:YES is specified, the

power nets are extracted and netlisted, as though they were normal signals, into the

NETLIST_FILE with normal EXTRACTION and REDUCTION settings.

See Also

•REDUCTION

Chapter 17: StarRC Commands

PRINT_SILICON_INFO 17-243

Chapter 17: StarRC Commands

PRINT_SILICON_INFO 17-243

StarRC User Guide and Command Reference Version F-2011.06

PRINT_SILICON_INFO

Prints the silicon width in addition to the drawn width.

Syntax

PRINT_SILICON_INFO: YES | NO

Arguments

Argument Description

YES Specifies that StarRC prints silicon width $si_w for conductor

resistors and nonphysical resistors in addition to the existing

information ($l, $w and $lvl).

NO Specifies that silicon width is not printed to the netlist output.

This is the default.

Description

Technology processes sometimes require the silicon width which is different from the drawn

width for a more accurate analysis result. The silicon width is needed for the analysis, and

the drawn width is needed for display. This command prints the silicon width in addition to

the drawn width.

This command should be used with NETLIST_TAIL_COMMENTS: YES.

When YES is set, StarRC prints silicon width $si_w for conductor resistors and nonphysical

resistors in addition to the existing information ($l, $w and $lvl). For via resistors, silicon area

$si_a is appended after the existing information ($a and $lvl).

The silicon width is the width used in resistance calculation. The value can be smaller or

larger than the drawn width because etch can be positive or negative. The ITF commands

ETCH and ETCH_VS_WIDTH_AND_SPACING (excluding CAPACITIVE_ONLY) are included in the

silicon width computation.

The silicon area $si_a for a via is always the same as the area $a because via etch is not

supported in resistance calculation.

Errors

The silicon width might be inaccurate when ITF commands RPSQ_VS_WIDTH_AND_SPACING

or RHO_VS_WIDTH_AND_SPACING are specified. A warning is issued when

PRINT_SILICON_INFO is used with these two ITF commands. When this occurs, replace

RPSQ_VS_WIDTH_AND_SPACING and RHO_VS_WIDTH_AND_SPACING with RPSQ_VS_SI_WIDTH

Chapter 17: StarRC Commands

PRINT_SILICON_INFO 17-244

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

and ETCH_VS_WIDTH_AND_SPACING. RPSQ_VS_WIDTH_AND_SPACING should not be used to

model a scenario where a conductor has different spacing on the left side compared to the

right side.

Example

R41 M15:SRC Y:15 11.6946 $l=0.105 $w=0.153 $lvl=100 $si_w=0.149

R42 Y:12 Y:54 30 $a=0.0081 $lvl=134 $si_a=0.0081

See Also

•NETLIST_TAIL_COMMENTS:YES

Chapter 17: StarRC Commands

PROBE_TEXT_FILE 17-245

Chapter 17: StarRC Commands

PROBE_TEXT_FILE 17-245

StarRC User Guide and Command Reference Version F-2011.06

PROBE_TEXT_FILE

Specifies a file that contains simulation probe points to appear in the StarRC parasitic netlist.

This is how you can define net locations for particular simulation results.

Syntax

PROBE_TEXT_FILE: file_name

Arguments

Argument Description

file_name The file containing defined (x, y location) probe points

Default: none

Description

A probe point is a specific node point created as a node (in the parasitic node mesh) for a

particular net.

A PROBE_TEXT_FILE entry is translated and netlisted if the following is true:

• The specified cell master name is a valid extracted cell. If XREF is in the command file, the

cell name must correspond to a valid LVS equivalence point. The CELL_TYPE command

regulates whether the schematic or layout name is used.

• A polygon at the specified layer name exists at the specified coordinate location.

• The probe point falls on a net for which parasitics are included in the netlist.

• The probe point falls on a cross-referenced net within a cross-referenced instance in the

XREF: COMPLETE command.

Example

Example 17-13 shows the syntax of the probe text file.

Chapter 17: StarRC Commands

PROBE_TEXT_FILE 17-246

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Example 17-13 Probe Text File Syntax

CELL cell_name

textstring local_x local_y layername

...

CELL cell_name

...

Parameter Definition

textstring Identifying layout text label for the probe point by which the point is

identified in the parasitic netlist.

local_x X-coordinate for the probe point location. The specified coordinate is

interpreted local to the specified cell.

local_y Y-coordinate for the probe point location. The specified coordinate is

interpreted local to the specified cell.

layername Database layer name to which the probe point corresponds. The name

must correspond to a layer mapped in the conducting_layers section of

the StarRC mapping file.

cell_name Name of the cell master in which the probe point is specified. The

CELL_TYPE command regulates whether a layout cell or schematic cell is

used.

A prepared probe text file is specified as shown in the example. The probe file text syntax is

described following the argument list.

PROBE_TEXT_FILE: myprobetxtfile

Another example:

CELL ADD4_TOP

PROBE1 10 10 M3

CELL INVX$

GATE_1 16.3 14.5 FPOLY

GATE_2 15.3 1.1 FPOLY

See Also

•CELL_TYPE

Chapter 17: StarRC Commands

PROCESS_CORNER 17-247

Chapter 17: StarRC Commands

PROCESS_CORNER 17-247

StarRC User Guide and Command Reference Version F-2011.06

PROCESS_CORNER

Syntax

PROCESS_CORNER: MIN | TYP | MAX

Arguments

Argument Description

MIN Specifies that a minimum value of input loading capacitance is

taken from the input.

TYP Specifies that a typical value of input loading capacitance is

taken from the input.

MAX Specifies that a maximum value of input loading capacitance is

taken from the input.

This is the default.

Description

Milkyway databases can contain three pin capacitance values (or triplets) or input loading

capacitances for SKIP_CELLS. This command allows you to choose one of possibly three

capacitance values for use with (or generate a report) during your StarRC job.

Chapter 17: StarRC Commands

REDUCTION 17-248

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

REDUCTION

Specifies parasitic netlist reduction.

Syntax

Arguments

Argument Description

HIGH Performs maximum netlist reduction for device-level parasitic

extraction. This setting is intended to decrease excessive

runtimes of SPICE-level simulators, for which simulation runtime

is dominant relative to extraction runtime. Parasitic netlists

produced with REDUCTION:HIGH are of a size equal to or

smaller than netlists produced with REDUCTION:YES, with a

10-20% increase in extraction runtime relative to

REDUCTION:YES. Not enabled for use with LEF/DEF or

Milkyway cell-level extractions, and an error message is

generated when the source database is either LEF/DEF or

Milkyway.

YES Specifies that a reduced parasitic netlist during extraction.

This is the default.

NO Specifies that a unreduced parasitic netlist during extraction.

LAYER Similar to REDUCTION:YES, except that reduction does not

occur across different conductor layers.

NO_EXTRA_LOOPS Performs netlist reduction, but ensures that no resistive loops

are introduced into the parasitic netlist as a result of the

reduction algorithm. This setting enables a lesser degree of

netlist reduction for delay calculators that are unable to interpret

resistive loops. Limiting the algorithm to not produce resistive

loops produces a larger parasitic netlist (10-20 percent) than is

realized with REDUCTION:YES. This option does not prevent

loops in the parasitic netlist that occur as a result of the topology

of the layout being extracted. For example, overlapping metals

connected by two or more parallel vias can produce meshes in

the parasitic netlist even with REDUCTION: NO_EXTRA_LOOPS,

because such meshes directly reflect the physical topology of

the layout.

Chapter 17: StarRC Commands

REDUCTION 17-249

Chapter 17: StarRC Commands

REDUCTION 17-249

StarRC User Guide and Command Reference Version F-2011.06

Description

This command specifies the reduction of extracted parasitic devices during extraction. The

degree of compression is controlled by the REDUCTION_MAX_DELAY_ERROR command. The

reduction algorithm is designed to preserve point-to-point resistance and total net

capacitance.

Setting REDUCTION: YES is highly preferable because of the large amounts of data typically

involved in today’s designs and the level of detail the StarRC extraction engine achieves.

See Also

•REDUCTION_MAX_DELAY_ERROR

TOPOLOGICAL Similar to REDUCTION: LAYER without timing error control. This

option allows StarRC to create a similar topology of the RC

network for different process or temperature corners. Different

process or temperature corners have different R and C values,

and if the reduction error control is based on R and C values (for

example, timing), it’s not possible to maintain the same topology

for different corners.

This reduction mode does not support REDUCTION_MAX_

DELAY_ERROR which is used to specify timing error control

during reduction.

Argument Description

Chapter 17: StarRC Commands

REDUCTION_MAX_DELAY_ERROR 17-250

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

REDUCTION_MAX_DELAY_ERROR

Specifies the acceptable net delay error tolerance when StarRC performs reduction.

Syntax

REDUCTION_MAX_DELAY_ERROR: threshold

Arguments

Argument Description

threshold The absolute error threshold.

Units: seconds.

Default: 1.0 e-12

Description

The absolute error between the original and reduced netlists is not greater than this

threshold.

Note:

This option should not be combined with REDUCTION:TOPOLOGICAL because the

TOPOLOGICAL mode does not have timing error control.

See Also

•REDUCTION

Chapter 17: StarRC Commands

REMOVE_DANGLING_NETS 17-251

Chapter 17: StarRC Commands

REMOVE_DANGLING_NETS 17-251

StarRC User Guide and Command Reference Version F-2011.06

REMOVE_DANGLING_NETS

Directs StarRC to identify dangling nets and reassign them to ground (effectively removing

them).

Syntax

REMOVE_DANGLING_NETS: YES | NO

Arguments

Argument Description

YES Specifies that the netlist is output without dangling nets.

NO Specifies that the netlist is output with dangling nets.

This is the default.

Description

Dangling nets are defined as:

• Unrouted database nets (for Milkyway, LEF/DEF, and CCI)

• Nets that have only one connection (for Milkyway, LEF/DEF, CCI, and Hercules).

Nets that are connected to a pin port (*|P) are not eligible for removal. In Hercules flows,

such as *|P, ports must be generated during Hercules device/connectivity extraction using

the CREATE_PORTS runset command. Otherwise, StarRC does not consider the port

connection and the net is removed. REMOVE_DANGLING_NETS does not remove layout

material; the objects are assigned to ground.

You must run with -clean to change the value of this command.

See Also

•REMOVE_FLOATING_NETS

Chapter 17: StarRC Commands

REMOVE_FLOATING_NETS 17-252

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

REMOVE_FLOATING_NETS

Removes nets that have no connection, by reassigning them to ground (for Milkyway, LEF/

DEF, CCI, and Hercules designs).

Syntax

REMOVE_FLOATING_NETS: YES | NO

Arguments

Argument Description

YES Specifies that the output netlist does not contain floating nets.

NO Specifies that the output netlist does contain floating nets.

This is the default.

Description

No layout material is actually deleted; the objects are reassigned.

You must run with -clean to change the value of this command.

When using REMOVE_FLOATING_NETS, StarRC does not completely disregard polygons on

floating nets. The command’s goal is to eliminate floating nets from the parasitic netlist, but

to account for effects these nets might have on real signal nets in the design.

When REMOVE_FLOATING_NETS:YES is set in the command file, StarRC treats the floating

nets as noncritical material. This means that StarRC finds the coupling capacitance from

signal nets to the noncritical material and then decouples these capacitors. The decoupled

capacitance is then added to the ground capacitance of the signal net. The total capacitance

of the signal nets accounts for the effects of coupling to floating nets. The floating nets are

not shown in the parasitic netlist.

See Also

•REMOVE_DANGLING_NETS

Chapter 17: StarRC Commands

REMOVE_NET_PROPERTY 17-253

Chapter 17: StarRC Commands

REMOVE_NET_PROPERTY 17-253

StarRC User Guide and Command Reference Version F-2011.06

REMOVE_NET_PROPERTY

Specifies a single property name to indicate to the Milkyway layout database which objects

should not be extracted as signal nets (for Milkyway extraction flows).

Syntax

REMOVE_NET_PROPERTY: string

Arguments

Argument Description

string Specifies that nets with this property are not included in the

netlist

Default: none

Description

These objects are treated as ground during the extraction, and the influence of these objects

is considered when you are extracting the capacitance of neighboring signal nets. See the

Milkyway Environment Data Preparation User Guide for information about setting object

properties in the Milkyway database.

See Also

•MILKYWAY_DATABASE

Chapter 17: StarRC Commands

RETAIN_CAPACITANCE_CAP_MODELS 17-254

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

RETAIN_CAPACITANCE_CAP_MODELS

Specifies model-specific plate-to-plate capacitance retention for capacitor devices.

Syntax

RETAIN_CAPACITANCE_CAP_MODELS: model_list

Arguments

Argument Description

model_list List of capacitor devices for which plate-to-plate capacitance is to be retained.

Default is None. Accepted model names in model_list can include either the

schematic or layout names regardless of your XREF command setting.

If a specified model name matches the schematic model name of a capacitor device

in the design, RETAIN_CAPACITANCE_CAP_MODELS functionality is propagated to

all layout capacitor devices matching that schematic model name. If a specified

model name matches the layout model name of a capacitor device in the design,

RETAIN_CAPACITANCE_CAP_MODELS functionality is propagated only to layout

capacitor devices matching that layout model name. All of this occurs independent of

the XREF command in the command file.

Default: none.

Description

In certain applications, it is advantageous to retain parasitic capacitances within the parasitic

netlist for capacitor devices, particularly when you want to simulate devices using parasitic

capacitances instead of device simulation models.

To allow such a simulation flow, you can selectively retain plate-to-plate capacitance

(between plates) for designed capacitor devices. Devices whose capacitances are to be

retained are specified by model name.

You specify a list of model names of capacitor devices for which IGNORE_CAP statements

should not be generated between terminal layers and for which plate-to-plate capacitance

should not be ignored by the StarRC extraction engine.

Note:

If the MODEL_TYPE is not specified in the command file, it is assumed to be LAYOUT.

Errors

A warning is issued when a model name exists in the RETAIN_CAPACITANCE_CAP_MODELS

command for which no corresponding capacitor exists.

Chapter 17: StarRC Commands

RETAIN_CAPACITANCE_CAP_MODELS 17-255

Chapter 17: StarRC Commands

RETAIN_CAPACITANCE_CAP_MODELS 17-255

StarRC User Guide and Command Reference Version F-2011.06

Example

The following command retains capacitance for device cm1m2:

RETAIN_CAPACITANCE_CAP_MODELS: cm1m2

See Also

•MODEL_TYPE

Chapter 17: StarRC Commands

RETAIN_GATE_CONTACT_COUPLING 17-256

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

RETAIN_GATE_CONTACT_COUPLING

Retains gate-to-contact coupling capacitance.

Syntax

RETAIN_GATE_CONTACT_COUPLING: YES | NO

Arguments

Argument Description

YES Retain the gate-to-contact capacitance when COUPLE_TO_GROUND:YES is set

in the StarRC command file.

NO All couplings are retained if COUPLE_TO_GROUND:NO is set in the StarRC

command file.

This is the default.

Description

When this command is set in conjunction with EXTRACT_VIA_CAPS:YES, the gate-to-contact

capacitance is retained with COUPLE_TO_GROUND:YES, even if the coupling capacitances are

below the capacitance threshold value specified for COUPLING_ABS_THRESHOLD,

COUPLING_REL_THRESHOLD, or COUPLING_AVG_THRESHOLD.

When COUPLE_TO_GROUND:YES is set in the StarRC command file, coupling is retained to the

contact. Coupling thresholds are not used for the gate-to-contact coupling. When

COUPLE_TO_GROUND:NO is set in the StarRC command file, the coupling to contact is

retained only if the coupling is above the coupling thresholds specified. For more details, see

“Smart Decoupling of Coupling Capacitances” on page 9-3.

Note:

The RETAIN_GATE_CONTACT_COUPLING command is supported only in the Hercules and

Calibre flows.

Chapter 17: StarRC Commands

RETAIN_GATE_CONTACT_COUPLING 17-257

Chapter 17: StarRC Commands

RETAIN_GATE_CONTACT_COUPLING 17-257

StarRC User Guide and Command Reference Version F-2011.06

Table 17-8 describes the behavior of the RETAIN_GATE_CONTACT_COUPLING command

when specified with other commands.

Table 17-8 RETAIN_GATE_CONTACT_COUPLING Interaction With Commands

Command COUPLE_TO_GROUND:YES COUPLE_TO_GROUND:NO

NETS:*

EXTRACT_VIA_CAPS:YES

RETAIN_GATE_CONTACT_COUPLING:YES

POWER_EXTRACT:NO

Retain the gate-to-contact

capacitance for all signal nets

even if they are less than the

coupling threshold values.

All coupling capacitances for

signal nets including

gate-to-contact are retained and

netlisted. Coupling thresholds

apply to all coupling

capacitances, including gate-to-

contact.

NETS:*

EXTRACT_VIA_CAPS:YES

RETAIN_GATE_CONTACT_COUPLING:YES

POWER_EXTRACT:

DEVICE_LAYERS

Retain the gate-to-contact

capacitance for all signal and

power nets, only if the

appropriate device layers are

set (that is, contacted) for power

nets.

All coupling capacitances for

signal and power nets are

retained, only if the appropriate

device layers are set (that is,

contacted) for power nets.

NETS:*

EXTRACT_VIA_CAPS:YES

RETAIN_GATE_CONTACT_COUPLING:YES

POWER_EXTRACT: YES

Retain the gate-to-contact

capacitance for all signal nets

and power nets.

All coupling capacitances for

signal and power nets are

retained and netlisted.

Errors

The RETAIN_GATE_CONTACT_COUPLING command results in the following error message

when it is used in a LEF/DEF or Milkyway flow:

Error Message: RETAIN_GATE_CONTACT_CAPACITANCE is only supported in the

Hercules/Calibre flow.

See Also

•NETS

•NETS_FILE

Chapter 17: StarRC Commands

RING_AROUND_THE_BLOCK 17-258

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

RING_AROUND_THE_BLOCK

Generates a virtual ring on every routing layer around the block for extraction.

Syntax

RING_AROUND_THE_BLOCK: YES | NO

Arguments

Argument Description

YES Generates a ring around the block.

NO Does not generate a ring around the block.

This is the default.

Description

The RING_AROUND_THE_BLOCK command generates a virtual ring around the block for

extraction. The capacitance between the block material and the imaginary ring is calculated

as though the block is surrounded by solid metal.

Note:

Do not use the RING_AROUND_THE_BLOCK command with the MACRO command.

Specify the block for extraction with the BLOCK command.

Specify the block boundary with the BLOCK_BOUNDARY command and a list of points, which

can be read directly from the Milkyway database. It must be provided for LEF/DEF designs.

BLOCK material that lies outside the specified BLOCK_BOUNDARY does not create shorts with

or attach capacitance from the imaginary rings, even if they overlap. Overlaps should be

avoided, because shielding of nets occurs.

You can specify the spacing between the block boundary and the ring with the

RING_AROUND_THE_BLOCK_SMIN_MULTIPLIER command.

The rings are grounded by default but can be given a special name with the

ZONE_COUPLE_TO_NET command.

Chapter 17: StarRC Commands

RING_AROUND_THE_BLOCK 17-259

Chapter 17: StarRC Commands

RING_AROUND_THE_BLOCK 17-259

StarRC User Guide and Command Reference Version F-2011.06

See Also

•BLOCK

•BLOCK_BOUNDARY

•RING_AROUND_THE_BLOCK_SMIN_MULTIPLIER

•ZONE_COUPLE_TO_NET

Chapter 17: StarRC Commands

RING_AROUND_THE_BLOCK_SMIN_MULTIPLIER 17-260

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

RING_AROUND_THE_BLOCK_SMIN_MULTIPLIER

Specifies the spacing between the block boundary and the ring around the block in

hierarchical analysis.

Syntax

RING_AROUND_THE_BLOCK_SMIN_MULTIPLIER: multiplier

Arguments

Argument Description

multiplier Floating-point number that is greater than or equal to 0.5

Units: none

Default: 0.5

Description

The RING_AROUND_THE_BLOCK_SMIN_MULTIPLIER command specifies the spacing between

the block boundary and the ring around the block. The spacing is equal to the product of the

multiplier and the SMIN value of the GRD layer. The SMIN value might be different from layer

to layer, resulting in different ring spacing.

See Also

•BLOCK

•BLOCK_BOUNDARY

•RING_AROUND_THE_BLOCK

Chapter 17: StarRC Commands

SENSITIVITY 17-261

Chapter 17: StarRC Commands

SENSITIVITY 17-261

StarRC User Guide and Command Reference Version F-2011.06

SENSITIVITY

Enables sensitivity-based extraction for statistical or variation-aware analysis.

Syntax

SENSITIVITY: YES | NO

Arguments

Argument Description

YES Extracts sensitivities for resistance and capacitance.

NO Performs normal nominal extraction.

This is the default.

Description

If SENSITIVITY:YES is specified, the xTractor extracts capacitance and resistance

sensitivities along with the nominal values. The ITF and nxtgrd files supplied for the run must

have a VARIATION_PARAMETERS section, or temperature coefficients (CRT1/CRT2) if

TEMPERATURE_SENSITIVITY:YES is being used.

Sensitivity is supported by the following extraction modes: EXTRACTION: C|R|RC

When RKC extraction is specified, RKC nominal values are computed, whereas only RC

sensitivities are computed.

SENSITIVITY:YES is supported with existing commands used to model systematic

variations, such as THICKNESS_VS_DENSITY or ETCH_VS_WIDTH_AND_SPACING. Support for

this feature also exists with key flow features such as SKIP_CELLS for cell level and

IGNORE_CAPACITANCE for ignoring device capacitances.

Note:

The COUPLING_AVG_THRESHOLD, COUPLING_ABS_THRESHOLD, and

COUPLING_REL_THRESHOLD commands have functionality that can be altered as a result

of sensitivity extraction.

Example

*RES

1 *13:92 *13:90 0.271859 *SC 33:1.000 34:0.045

*END

Chapter 17: StarRC Commands

SENSITIVITY 17-262

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

See Also

•NETLIST_CORNER_NAMES

•NETLIST_CORNER_FILE

•NETLIST_FORMAT

Chapter 17: StarRC Commands

SHEET_COUPLE_TO_NET 17-263

Chapter 17: StarRC Commands

SHEET_COUPLE_TO_NET 17-263

StarRC User Guide and Command Reference Version F-2011.06

SHEET_COUPLE_TO_NET

Specifies a prefix net name for the sheet zone extraction capability. This user-defined name

appears in the generated output netlist.

Syntax

SHEET_COUPLE_TO_NET: prefix_name

Arguments

Argument Description

prefix_name Net prefix name reported in the output netlist.

Default: none.

Description

If this command is not specified, StarRC automatically sets the prefix name to ZONE_SHEET.

Example

METAL_SHEET_OVER_AREA: METAL2 0 0 100 100

METAL_SHEET_OVER_AREA: METAL2 200 200 400 400

METAL_SHEET_OVER_AREA: METAL4 0 0 100 100

SHEET_COUPLE_TO_NET: zone_sheet

SHEET_COUPLE_TO_NET_LEVEL: YES

See Also

•METAL_SHEET_OVER_AREA

•SHEET_COUPLE_TO_NET_LEVEL

Chapter 17: StarRC Commands

SHEET_COUPLE_TO_NET_LEVEL 17-264

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

SHEET_COUPLE_TO_NET_LEVEL

Enables or disables a net name suffix using the layer-level number for the sheet zone netlist

capability.

Syntax

SHEET_COUPLE_TO_NET_LEVEL: NO | YES

Arguments

Argument Description

NO Disables net name suffix reporting in sheet zone netlist output.

This is the default.

YES Enables net name suffix reporting in sheet zone netlist output.

Description

Enables or disables a net name suffix using the layer-level number for the sheet zone netlist

capability.

Example

METAL_SHEET_OVER_AREA: METAL2 0 0 100 100

METAL_SHEET_OVER_AREA: METAL2 200 200 400 400

METAL_SHEET_OVER_AREA: METAL4 0 0 100 100

SHEET_COUPLE_TO_NET: zone_sheet

SHEET_COUPLE_TO_NET_LEVEL: YES

See Also

•METAL_SHEET_OVER_AREA

•SHEET_COUPLE_TO_NET

Chapter 17: StarRC Commands

SHORT_PINS 17-265

Chapter 17: StarRC Commands

SHORT_PINS 17-265

StarRC User Guide and Command Reference Version F-2011.06

SHORT_PINS

Specifies whether or not to short top-level pin ports that have multiple placements.

Syntax

SHORT_PINS: YES | NO | MIXED

Arguments

Argument Description

YES If it is set to YES, all of the placements of the pin port are reported as

a single node (a single *|P).

This is the default.

NO If it is set to NO, each Hercules marker group, or Milkyway (LEF/DEF

flow) PIN, at the top level is uniquely netlisted with a suffix defined by

NETLIST_RENAME_PORTS.

MIXED Ensures correct back-annotation of a parasitic netlist. This option is

only available in the LEF/DEF flow. In Milkyway, SHORT_PINS:MIXED

behaves as SHORT_PINS:YES. In a Hercules > Calibre flow, the pin

names are the same as net names, so this option does not apply.

Description

A unique pin instance is defined as a physically connected group of objects marked as

interface material: PIN section in DEF, PIN type in Milkyway, MARKER_LAYER in Hercules.

Each separated group of connected objects is a pin instance. When you specify

SHORT_PINS:YES, the name of the *P connected to a net always inherits the name of the

*D_NET in case there are multiple names.

If the layout database has unique names for each pin instance associated with a single port,

that information is used to netlist the *P, instead of the NETLIST_RENAME_PORTS method

being used. The NETLIST_RENAME_PORTS delimiter is used only if no naming information

exists in the input layout database.

Chapter 17: StarRC Commands

SHORT_PINS 17-266

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Example

Input database contains unique pin names:

PINS 2 ;

- C.1 + NET C + LAYER METAL2 ( 0 0 ) ( 1000 1600 )

+ PLACED ( 263800 136000 ) N ;

- C.2 + NET C + LAYER METAL2 ( 0 0 ) ( 1000 1600 )

+ PLACED ( 264800 136000 ) N ;

END PINS

SHORT_PINS: NO

*|NET C 0.0295887PF

*|P (C.2 B 0 264.8 136)

*|P (C.1 B 0 263.8 136)

SHORT_PINS: YES

*|NET C 0.0295887PF

*|P (C B 0 264.8 136)

Input database does not contain unique pin names:

PINS 2 ;

- C + NET C + LAYER METAL2 ( 0 0 ) ( 1000 1600 )

+ PLACED ( 263800 136000 ) N ;

- C + NET C + LAYER METAL2 ( 0 0 ) ( 1000 1600 )

+ PLACED ( 264800 136000 ) N ;

END PINS

SHORT_PINS: NO, NETLIST_RENAME_PORTS: _

*|NET C 0.0295887PF

*|P (C_2 B 0 264.8 136)

*|P (C_1 B 0 263.8 136)

SHORT_PINS: YES

*|NET C 0.0295887PF

*|P (C B 0 264.8 136)

Chapter 17: StarRC Commands

SHORT_PINS 17-267

Chapter 17: StarRC Commands

SHORT_PINS 17-267

StarRC User Guide and Command Reference Version F-2011.06

Input database contains partial unique naming information:

PINS 3 ;

- C.1 + NET C + LAYER METAL2 ( 0 0 ) ( 1000 700 )

+ PLACED ( 263800 136000 ) N ;

- C.1 + NET C + LAYER METAL2 ( 0 0 ) ( 1000 700 )

+ PLACED ( 263800 137000 ) N ;

- C.2 + NET C + LAYER METAL2 ( 0 0 ) ( 1000 1600 )

+ PLACED ( 264800 136000 ) N ;

END PINS

SHORT_PINS: NO, NETLIST_RENAME_PORTS: _

*|NET C 0.0295974PF

*|P (C.1 B 0 263.8 136)

*|P (C.2 B 0 264.8 136)

*|P (C.1_1 B 0 263.8 137)

SHORT_PINS: YES

*|NET C 0.0295887PF

*|P (C B 0 264.8 136)

Input database contains the mixed pin names shown in the following table:

Net Name Logical Pins Physical Pins SHORT_PINS:MIXED

Net 1 Net 1 Net 1 Net 1

Net 1 net 1 Net 1 (Multiple) Net 1

Net 1 Pin 1 Pin 1 Pin 1

Net 1 Pin 1 Net 1 Pin 1 Net 1 Pin1 Net 1

Net 1 Pin 1 Net 1 Pin 1 Net 1 (Multiple) Pin1 Net 1

Net 1 Pin 1 Net 1 Pin 1 (Multiple)

Net 1 (Multiple)

Pin1 Net 1

Fixing Redundant Ports

Redundant ports that are unnecessary for an HSIM/NanoSim parasitic back-annotation flow

can be removed. The port name postfix “_1” in an extracted file is generated because the

input database contained partial unique naming information, such as:

SUBCKT v_ctl VCI_P0 VCI_P0_1 GND_P0 GND_P0_1 VDD_P0 VDD_P0_1

The redundant ports “VCI_P0_1”, “GND_P0_1” and “VDD_P0_1” can be removed by

changing the StarRC command SHORT_PINS:NO to SHORT_PINS:YES.

Chapter 17: StarRC Commands

SHORT_PINS 17-268

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

The result is as follows:

SUBCKT v_ctl VCI_P0 GND_P0 VDD_P0

The extracted SPF file can then be used for HSIM/NanoSim parasitic back-annotation.

See Also

•NETLIST_RENAME_PORTS

Chapter 17: StarRC Commands

SHORT_PINS_IN_CELLS 17-269

Chapter 17: StarRC Commands

SHORT_PINS_IN_CELLS 17-269

StarRC User Guide and Command Reference Version F-2011.06

SHORT_PINS_IN_CELLS

Syntax

SHORT_PINS_IN_CELLS: list

Arguments

Argument Description

list The list of skip cell names.

Default: *

Description

Place and route Milkyway databases sometimes contain ports of the class EEQ. These

ports are logically equivalent but can have a wide geographic distribution throughout the

design. StarRC merges all EEQ pins into a single port for every SKIP_CELLS on the

SHORT_PINS_IN_CELLS list.

Occasionally, designs with EEQ ports are instantiated as macros. If a macro with EEQ ports

were on the SKIP_CELLS list, StarRC default behavior reports a single connection for the

EEQ port in the netlist, using the first EEQ pin location. Because the EEQ pins can be so

widely distributed in the layout, it can be desirable to treat each of the EEQ pins as a unique

port for simulation. Negating a cell from the SHORT_PINS_IN_CELLS list means that StarRC

treats each EEQ pin as a unique port and uses the original database port suffix to report it.

Wildcards “*”, “?”, and “!” are acceptable. This command can be specified multiple times.

SHORT_PINS always overrides SHORT_PINS_IN_CELLS.

See Also

•CASE_SENSITIVE

•SHORT_PINS

•SKIP_CELLS

Chapter 17: StarRC Commands

SKIP_CELL_AGF_FILE 17-270

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

SKIP_CELL_AGF_FILE

Imports Hercules annotated GDSII (AGF) files as the detail view for SKIP_CELL.

Syntax

SKIP_CELL_AGF_FILE: cell agf_file herc_ideal_netlist

Arguments

Argument Description

cell AGF cell name

agf_file AGF file name

herc_ideal_netlist Hercules ideal netlist name

Description

Use this command in the star_cmd file to import Hercules annotated GDSII (AGF) files as

the detail view for SKIP_CELL. Specify the command once for each SKIP_CELL that has an

AGF description.

•A

SKIP_CELL_AGF_FILE command cannot be specified as a macro.

•All

SKIP_CELL_AGF_FILE commands specified must use the same layer mapping as

defined in the GDS_LAYER_MAP_FILE command.

• Layer mapping file must also be shared with the GDS_FILE (if it is used).

If the list of cells in a COUPLE_NONCRITICAL_NETS command contains a

SKIP_CELL_AGF_FILE cell (or descendant), the layout names are used to its contents. If the

list of cells in a COUPLE_NONCRITICAL_NETS command does not contain a

SKIP_CELL_AGF_FILE cell, its contents are annotated as noncritical (ground potential).

Note:

Child cells of a COUPLE_NONCRITICAL_NETS command are not automatically made into

COUPLE_NONCRITICAL_NETS themselves; they must be specified in the

COUPLE_NONCRITICAL_NETS command as well.

Example

SKIP_CELL_AGF_FILE:INV_BUF buf.agf buf.sp

Chapter 17: StarRC Commands

SKIP_CELL_AGF_FILE 17-271

Chapter 17: StarRC Commands

SKIP_CELL_AGF_FILE 17-271

StarRC User Guide and Command Reference Version F-2011.06

See Also

•COUPLE_NONCRITICAL_NETS

•GDS_LAYER_MAP_FILE

Chapter 17: StarRC Commands

SKIP_CELL_PORT_PROP_FILE 17-272

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

SKIP_CELL_PORT_PROP_FILE

Specifies files containing pin or port information for skip cell properties.

Syntax

SKIP_CELL_PORT_PROP_FILE: file1 [file2 ... fileN]

Arguments

Argument Description

fileN File name

Default: none

Description

You can also use this command to specify pin information (such as direction or capacitance)

for LEF/DEF and checkpoint databases (or to override values from a Milkyway database) for

netlist purposes.

The description of all port properties of a cell should be in one CELL block and should be

uniquely defined. For example, do not specify multiple descriptions of a cell in the same or

another (reference) library. Otherwise, the result is unpredictable. Ensure that reference

libraries you specify contain unique definitions of cells.

Chapter 17: StarRC Commands

SKIP_CELL_PORT_PROP_FILE 17-273

Chapter 17: StarRC Commands

SKIP_CELL_PORT_PROP_FILE 17-273

StarRC User Guide and Command Reference Version F-2011.06

Create a port property file by specifying the keyword CELL followed by the cell name. Follow

this by specifying the named cell’s pin name, pin direction, and pin capacitance. All three

parameters are required.

Argument Description

CELL Keyword specifying the beginning of the cell definition

cell_name Name of the cell whose pin characteristics are defined

pin_name String of the pin or port name

pin_io Pin/port direction. It could be I, O, or B representing input,

output, and bidirectional, respectively

pin_cap The capacitance value of the corresponding pin/port. It can

include a unit of the capacitance. The valid units are: FF, PF,

NF, uF and mF.

Errors

If the StarRC command file contains the command, SYNOPSYS_LIB_FILE, a warning

message is issued. The SYNOPSYS_LIB_FILE command will be phased out in a future

release.

Note:

If the SKIP_CELL_PORT_PROP_FILE is not specified, StarRC attempts to load the cell

models from the Milkyway LM (CLF) database. If both SYNOPSYS_LIB_FILE and

SKIP_CELL_PORT_PROP_FILE are specified, SKIP_CELL_PORT_PROP_FILE takes

precedence. A message indicating that StarRC is using the SKIP_CELL_

PORT_PROP_FILE command and ignoring the SYNOPSYS_LIB_FILE is issued.

Example

The following example shows the port property file format:

CELL cell1name

pin1name pin1io pin_cap

pin2name pin2io pin_cap

CELL cell2name

pin1name pin1io pin_cap

pin2name pin2io pin_cap

See Also

•SYNOPSYS_LIB_FILE

Chapter 17: StarRC Commands

SKIP_CELLS 17-274

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

SKIP_CELLS

Creates a white-space-delimited list of cells for StarRC to skip during extraction.

Syntax

SKIP_CELLS: cell1 cell2 ... cellN

Arguments

Argument Description

cell1 cell2 ... cellN A list of cells to be skipped during extraction. Wildcard characters

are acceptable.

Default: *

Description

The SKIP_CELLS command creates a white-space-delimited list of cells for StarRC to skip

during extraction. This command may be specified multiple times in a single command file.

The asterisk (*), exclamation mark (!), and question mark (?) wildcard characters are

acceptable. Case sensitivity for selection purposes is determined by the value of the

CASE_SENSITIVE command, but the netlist always retains the case of the original input

database.

Skipped cells are typically cells with their own timing models, which can later be applied,

along with the StarRC parasitic netlist, to perform a timing analysis. Skipped cells should

have labeled, or otherwise annotated, pin shapes for proper parasitic netlisting.

The default for all extraction flows is to skip everything in the input database, so any macro

blocks without timing models must be negated from the list.

Example

SKIP_CELLS: cellA !cellB cell? *C ...

SKIP_CELLS: * !macroA !macroB ...

Figure 17-8 Example Using SKIP_CELLS

AmacroB

macroA

Chapter 17: StarRC Commands

SKIP_CELLS 17-275

Chapter 17: StarRC Commands

SKIP_CELLS 17-275

StarRC User Guide and Command Reference Version F-2011.06

Using the hierarchy showing in Figure 17-8 only cell A is skipped in the following example:

SKIP_CELLS: A

Cell macroA is not skipped. The resulting netlist contains 4 instances of A.

If you use the following command, cells A and B is skipped:

SKIP_CELLS: A B

Cells macroA and macroB are not skipped. The resulting netlist contains 2 instances of A

and 2 instances of B.

In following example, all cells are skipped:

SKIP_CELLS: *

The following example specifies that all cells except macroA and macroB are skipped:

SKIP_CELLS: * !macro?

In following example, no cells are skipped:

SKIP_CELLS: !*

See Also

•CASE_SENSITIVE

•CELL_TYPE

Chapter 17: StarRC Commands

SKIP_CELLS_COUPLE_TO_NET 17-276

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

SKIP_CELLS_COUPLE_TO_NET

Specifies a lump net for all coupling capacitance between top-level routes and noncritical

SKIP_CELLS material.

Syntax

SKIP_CELLS_COUPLE_TO_NET: string

Arguments

Argument Description

string The net name to the noncritical SKIP_CELLS material.

Default: ground net.

Description

The default is to use ground as the noncritical SKIP_CELLS material potential.

You must set NETLIST_FORMAT: SPEF and COUPLE_TO_GROUND: NO to use this option.

Use this option in conjunction with SKIP_CELLS_COUPLE_TO_NET_LEVEL to append the

SKIP_CELLS_COUPLE_TO_NET name to the actual SKIP_CELLS object layer number.

Example

SKIP_CELLS_COUPLE_TO_NET: LUMP

See Also

•COUPLE_TO_GROUND

•NETLIST_FORMAT

•SKIP_CELLS_COUPLE_TO_NET_LEVEL

Chapter 17: StarRC Commands

SKIP_CELLS_COUPLE_TO_NET_LEVEL 17-277

Chapter 17: StarRC Commands

SKIP_CELLS_COUPLE_TO_NET_LEVEL 17-277

StarRC User Guide and Command Reference Version F-2011.06

SKIP_CELLS_COUPLE_TO_NET_LEVEL

Appends the SKIP_CELLS_COUPLE_TO_NET name to the real layer number for the

SKIP_CELLS material.

Syntax

SKIP_CELLS_COUPLE_TO_NET_LEVEL: YES | NO

Arguments

Argument Description

YES Specifies that the layer number of the SKIP_CELLS material is

appended to the assigned net name.

NO Specifies that the layer number of the SKIP_CELLS material is not

appended to the assigned net name.

This is the default.

Description

This command appends the SKIP_CELLS_COUPLE_TO_NET name to the real layer number for

the SKIP_CELLS material.

This command is ignored unless SKIP_CELLS_COUPLE_TO_NET is specified.

Example

If the net name is LUMP and this command is set to YES, the resulting coupling capacitor

between top-level net1 and a metal1 object inside a SKIP_CELLS might be as follows:

*CAP

...

12 net1 LUMP_1 1.2e-15

...

*END

See Also

•SKIP_CELLS_COUPLE_TO_NET

Chapter 17: StarRC Commands

SKIP_CELLS_FILE 17-278

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

SKIP_CELLS_FILE

Syntax

SKIP_CELLS_FILE: file1 file2 ...

Arguments

Argument Description

file Specifies the name of the file containing the defined

SKIP_CELLS.

Default: none

Description

Specifies a file containing SKIP_CELLS commands. See the SKIP_CELLS command for more

details.

Example

SKIP_CELLS: cellA cellB

SKIP_CELLS: cellC

See Also

•CASE_SENSITIVE

•SKIP_CELLS

Chapter 17: StarRC Commands

SKIP_INSTANCES 17-279

Chapter 17: StarRC Commands

SKIP_INSTANCES 17-279

StarRC User Guide and Command Reference Version F-2011.06

SKIP_INSTANCES

Creates a white space delimited list of cell instances that are not skipped in the SKIP_CELLS

command.

Syntax

SKIP_INSTANCES instance_list

Arguments

Argument Description

instance_list The list of instances to skip.

Default: none

Description

Wildcards “*”, “!”, and “?” are accepted, but cannot be used as global arguments (for

example: SKIP_INSTANCES:*).

Instances that you might want to skip are those that already have timing model or parasitic

netlists elsewhere in the library representing the cell master.

The default is not to skip any specific instances so all cell instances are skipped or flattened

depending on the SKIP_CELLS command setting.

Example

In this example, all macroA instances are flattened, except macroA_instance1. All macroB

instances are flattened, except macroB_instance1.

SKIP_CELLS: * !macroA !macroB

SKIP_INSTANCES: macroA_instance1 macroB_instance1

See Also

•SKIP_CELLS

Chapter 17: StarRC Commands

SKIP_PCELLS 17-280

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

SKIP_PCELLS

Extracts a parameterized cell (PCELL) as a fully characterized gray-box cell unit during

parasitic extraction and creates the entity in the DSPF netlist with all layout properties

extracted for the PCELL.

Syntax

SKIP_PCELLS: pcell_name

Arguments

Argument Description

pcell_name Name of parameterized cell. Only the exclamation mark (!) and

asterisk (*) wildcard characters can be used.

Default: none.

Description

The SKIP_PCELLS command extracts a parameterized cell (PCELL) as a fully characterized

gray-box cell unit during parasitic extraction and creates the entity in the DSPF netlist with

all layout properties extracted for the PCELL. StarRC defines a PCELL as a container cell,

within which one or more devices (including hierarchical cells) are extracted by the ideal

device extraction tool. With this command, StarRC treats the container cell as a gray-box for

parasitic extraction purposes but creates an entry in the DSPF Instance section listing all

geometric properties of the ideal device extracted inside the container cell.

In this flow, the PCELL placed in layout is assumed to be a fully characterized unit, for which

the layout’s PCELL container cell boundary defines the perimeter between the intradevice

effects inside the cell and the interconnect effects outside the cell. As such, runset terminal

layer manipulation is not required to isolate intradevice effects because the PCELL cell

boundary serves this role. Using the cell boundary eliminates the need to perform runset

terminal layer manipulation for PCELLs while retaining device properties in the netlist. This

is the functional benefit of this command.

When you specify the SKIP_PCELLS command, StarRC

• Creates the entity in the DSPF instance section as a device with all layout-extracted

device properties; the instantiation name must be consistent with the ideal devices inside

the container cell

• Treats the container cell as a gray-box (analogous to the SKIP_CELLS command

functionality), meaning that parasitic effects are extracted up to the cell boundary

Chapter 17: StarRC Commands

SKIP_PCELLS 17-281

Chapter 17: StarRC Commands

SKIP_PCELLS 17-281

StarRC User Guide and Command Reference Version F-2011.06

StarRC handles exploded shapes in PCELLS by supporting the following scenarios:

• PCELL shapes that are exploded to the upper level

• Flattened designs with some premodeled areas in which the PCELL is not preserved

Both scenarios require you to specify the PCELL or blocking layer, as well as the layers that

are exploded, in a file specified by the SKIP_PCELL_LAYERS_FILE command.

See Also

•SKIP_CELLS

•SKIP_PCELL_LAYERS_FILE

Chapter 17: StarRC Commands

SKIP_PCELL_LAYERS_FILE 17-282

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

SKIP_PCELL_LAYERS_FILE

Specifies a file that lists PCELL layers.

Syntax

SKIP_PCELL_LAYERS_FILE: file_name

Arguments

Argument Description

file_name File name

Default: none

Description

The SKIP_PCELL_LAYERS_FILE specifies a file that lists PCELL layers.

Example

The specified file uses the following syntax:

PCELL_LAYERS

pcell_name1 layer1 layer2 …

pcell_name2 layer3 layer4 …

pcell_* layer5 layer6 …

BLOCKING_LAYERS

blocking_layer1 [SIZE size_value | SCALE scale_factor] layer1 layer2 …

blocking_layer2 [SIZE size_value | SCALE scale_factor] layer3 layer4 …

The PCELL_LAYERS section has the following requirements:

• The first column specifies the PCELL name; the asterisk (*) wildcard is allowed. The

remaining columns specify the list of exploded layers. If the shapes on these layers are

located on the PCELL boundary, they are considered to be PCELL shapes.

• The PCELL hierarchy is preserved in CCI/XTR database, although some shapes are

exploded.

• The PCELLs must be specified in SKIP_PCELLS command.

• The layers must be specified in the StarRC mapping file.

Chapter 17: StarRC Commands

SKIP_PCELL_LAYERS_FILE 17-283

Chapter 17: StarRC Commands

SKIP_PCELL_LAYERS_FILE 17-283

StarRC User Guide and Command Reference Version F-2011.06

Table 17-9 shows an example of PCELL_LAYERS usage.

Table 17-9 Example of PCELL_LAYERS Usage

star_cmd file SKIP_PCELLS: Cell_1 Cell_2

SKIP_PCELL_LAYERS_FILE PCELL_LAYERS

Cell_1 m1 v1 m2

Cell_2 m3 v3 m4

Behavior Cell_1: normal PCELL + m1/v1/m2 shapes handling

Cell_2: normal PCELL

Cell_3: not considered for PCELL_LAYERS approach

The BLOCKING_LAYERS section has a syntax that is similar to the PCELL_LAYERS section.

• The first column specifies the blocking layer name.

• The size_value (in units of microns) expands or shrinks the blocking layer by the

specified amount. A positive value specifies expansion; a negative value indicates

shrinkage.

• The scale_factor expands or shrink the blocking layer by the specified scaling factor.

If you specify the BLOCKING_LAYERS section, you do not need PCELLS in the design; the

design can be completely flattened. When using this approach,

• The blocking layers must be specified in the CCI/XTR database

• Avoid using both blocking layers and PCELLs for the same area

See Also

•SKIP_PCELLS

Chapter 17: StarRC Commands

SLEEP_TIME_AFTER_FINISH 17-284

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

SLEEP_TIME_AFTER_FINISH

Specifies the CPU wait time before processing the next partition.

Syntax

SLEEP_TIME_AFTER_FINISH: number_of_seconds

Arguments

Argument Description

number_of_seconds Specifies the CPU wait time

Units: seconds

Default: 2

Description

When you use the NUM_PARTS command in your star_cmd file to specify a distributed

processing run, there is a chance that more than one CPU could start processing the same

partition. This can happen because of network glitches, thus causing StarRC to terminate

abnormally.

To prevent failures due to network glitches, use the SLEEP_TIME_AFTER_FINISH command

to increase the CPU wait time before processing the next partition:

By default, SLEEP_TIME_AFTER_FINISH is set to 2 seconds. To mask the effect of network

glitches, try increasing SLEEP_TIME_AFTER_FINISH to 100 or 200 seconds.

Note:

Setting a higher value for the SLEEP_TIME_AFTER_FINISH command can impact your

total runtime.

Example

The following command forces the CPUs to wait 100 seconds before starting a new job:

SLEEP_TIME_AFTER_FINISH: 100

See Also

•NUM_PARTS

Chapter 17: StarRC Commands

SPICE_SUBCKT_FILE 17-285

Chapter 17: StarRC Commands

SPICE_SUBCKT_FILE 17-285

StarRC User Guide and Command Reference Version F-2011.06

SPICE_SUBCKT_FILE

Specifies the SPICE file containing .subckt definitions for all of the SKIP_CELLS.

Syntax

SPICE_SUBCKT_FILE: file1 [... fileN]

Arguments

Argument Description

file1 [... fileN]Files containing the .subckt definitions for all SKIP_CELLS in the

design.

Default: none

Description

StarRC reads the SPICE_SUBCKT_FILE files to obtain port ordering information. The

SPICE_SUBCKT_FILE controls the port ordering of the top cell as well. The port order and the

port list members read from the .subckt for a SKIP_CELLS are preserved in the output netlist.

This command does not support the .include statement in the SPICE files.

See Also

•SKIP_CELLS

Chapter 17: StarRC Commands

STAR_DIRECTORY 17-286

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

STAR_DIRECTORY

Sets the working directory for StarRC.

Syntax

STAR_DIRECTORY: directory

Arguments

Argument Description

directory The working directory for StarRC.

Default: star

Description

The STAR_DIRECTORY command sets the working directory for StarRC with the following

restrictions:

• Absolute paths are not permitted. You must specify a relative path.

• A relative path to a directory can only be specified when the directory resides below the

working directory in the path.

% star_dir/working_dir/other_dir (incorrect)

% working_dir/other_dir/star_dir (correct)

Chapter 17: StarRC Commands

SUBSTRATE_EXTRACTION 17-287

Chapter 17: StarRC Commands

SUBSTRATE_EXTRACTION 17-287

StarRC User Guide and Command Reference Version F-2011.06

SUBSTRATE_EXTRACTION

Extracts resistance from layers mapped to substrate in the mapping file.

Syntax

SUBSTRATE_EXTRACTION: YES | NO

Arguments

Argument Description

YES Perform substrate extraction on layers specified in the mapping

file as “substrate” layers.

NO Substrate extraction is not done.

This is the default.

Description

You must specify each substrate layer in your mapping file and include RPSQ values for each

layer. The RPSQ values can be different for each layer as shown in line 2 and line 3 in the

previous example. The word substrate must also be specified in the mapping file (as

shown in the example) for those layers you want to extract. At least one substrate layer must

be specified in the mapping file. The command TRANSLATE_RETAIN_BULK_LAYERS:YES

must be specified in your command file when SUSTRATE_EXTRACTION is specified. You can

also specify substrate layers without RPSQ values. All substrate layers that do not have RPSQ

values are treated as ideal.

Since bulk layers are large and highly resistive, StarRC performs mesh extraction for these

layers, resulting in an increased parasitic netlist size.

It is appropriate to use the SUBSTRATE_EXTRACTION functionality for obtaining substrate

resistance information for three purposes:

• To prevent the shorting together of multiple electrical nodes that exist within a common

substrate well, to enable analyses of power nets having multiple electrical taps to a

common well.

• To prevent the shorting together of multiple electrical nodes that exist within a common

substrate well in parasitic viewing applications, to enable resistive probing between

nodes that share a common well.

• To allow the extraction of resistance between a MOS device's bulk terminal and source/

drain terminal, so that MOS back-biasing effects can be simulated.

Chapter 17: StarRC Commands

SUBSTRATE_EXTRACTION 17-288

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

This feature is generally not intended to facilitate substrate extraction for purposes of

substrate noise modeling.

Example

The following example shows a mapping file:

(with substrate extraction)

conducting_layers

nwell SUBSTRATE RPSQ=1000

psub SUBSTRATE RPSQ=2000

(with substrate extraction)

conducting layers

nwell SUBSTRATE

psub SUBSTRATE

See Also

•RPSQ

•TRANSLATE_RETAIN_BULK_LAYERS

Chapter 17: StarRC Commands

SUMMARY_FILE 17-289

Chapter 17: StarRC Commands

SUMMARY_FILE 17-289

StarRC User Guide and Command Reference Version F-2011.06

SUMMARY_FILE

Specifies the name of the summary file.

Syntax

SUMMARY_FILE: file_name

Arguments

Argument Description

file_name The name of the summary file

Default: block_name.star_sum

Description

The SUMMARY_FILE command specifies the name of the summary file generated by StarRC.

By default, the summary file is located in the run directory and has the name

block_name.star_sum, where block_name is the block specified by the BLOCK command.

You can use the SUMMARY_FILE command to change the name and location of the summary

file. This command accepts a path relative to the run directory. However, an absolute path is

not permitted because of the possibility of a change in the network file system (NFS).

Example

To create a summary file my_summary.log in the results subdirectory, use the following

syntax in your star_cmd file:

SUMMARY_FILE: ./results/my_summary.log

See Also

•BLOCK

Chapter 17: StarRC Commands

SYNOPSYS_LIB_FILE 17-290

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

SYNOPSYS_LIB_FILE

Specifies the path to a Synopsys .lib library timing database.

Syntax

SYNOPSYS_LIB_FILE: file1 [... fileN]

Arguments

Argument Description

file1 [... fileN] The name of the Synopsys binary file.

Default: none

Description

The information in these models can be used in any or all analysis flows. This command can

also be specified to provide pin information (such as capacitance or direction) for LEF/DEF

and Checkpoint databases (or to override the values from the Milkyway database) for

netlisting purposes. If this command is not specified, StarRC attempts to load the cell

models from the Milkyway (CLF) database.

This command affects all analysis flows.

Note:

This command will be phased out in a future release. See the

SKIP_CELL_PORT_PROP_FILE command.

See Also

•MILKYWAY_DATABASE

Chapter 17: StarRC Commands

TA R G E T _ P W R A 17-291

Chapter 17: StarRC Commands

TA R G E T _ P W R A 17-291

StarRC User Guide and Command Reference Version F-2011.06

TARGET_PWRA

Automatically generates all StarRC command file options that are needed in a power

reliability analysis flow.

Syntax

TARGET_PWRA: NO | YES

Arguments

Argument Description

NO Does not set an optimized set of commands for reliability

analysis.

This is the default.

YES Sets an optimized set of commands for a reliability analysis using

a StarRC/HSIM flow. Optimizes StarRC power extraction-related

commands.

Description

The TARGET_PWRA command automatically generates all StarRC command file options that

are needed for RC extraction in a power reliability analysis flow. With this command, you

also use the POWER_NETS command must specify a list of power nets.

The TARGET_PWRA: YES command sets the following options:

POWER_EXTRACT: RONLY

POWER_REDUCTION: LAYER_NO_EXTRA_LOOPS

NETLIST_CONNECT_SECTION: YES

NETLIST_NODE_SECTION: YES

NETLIST_TAIL_COMMENTS: YES

NETLIST_FORMAT: SPF

NETLIST_POWER_FILE: block_name.pwr.spf

SHORT_PINS: NO

Note:

StarRC automatically sets the POWER_EXTRACT option to the appropriate setting.

You do not need to set the EXTRA_GEOMETRY_INFO: NODE command because *|S is the

center of the bounding box node.

Only the reduction option KEEP_VIA_NODES as set by the TARGET_ANALYSIS: PWRA option

can be overridden by user settings. Other options are ignored and a warning is issued.

Chapter 17: StarRC Commands

TA R G E T _ P W R A 17-292

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Example

BLOCK:

MILKYWAY_DATABASE:

MILKYWAY_EXTRACT_VIEW

TARGET_PWRA:YES

POWER_NETS: list_of_power_nets

TCAD_GRD_FILE:

MAPPING_FILE:

MODE: 200

XREF: YES

SKIP_CELLS: list_of_cells

NETLIST_POWER_FILE: blockname_power_nets.spf

NETLIST_FILE: blockname_signal_nets.spf

See Also

•EXTRA_GEOMETRY_INFO: NODE

•KEEP_VIA_NODES: NO

•NETLIST_CONNECT_SECTION

•NETLIST_FORMAT

•NETLIST_POWER_FILE

•NETLIST_NODE_SECTION

•NETLIST_TAIL_COMMENTS

•POWER_EXTRACT

•POWER_NETS

•POWER_REDUCTION

•REDUCTION

•SHORT_PINS

Chapter 17: StarRC Commands

TCAD_GRD_FILE 17-293

Chapter 17: StarRC Commands

TCAD_GRD_FILE 17-293

StarRC User Guide and Command Reference Version F-2011.06

TCAD_GRD_FILE

Specifies the location of the TCAD GRD file.

Syntax

TCAD_GRD_FILE: file

TCAD_GRD_FILE: nxtgrd_file1 nxtgrd_file2 nxtgrd_file3

Arguments

Argument Description

file TCAD model file for StarRC

Default: none

Description

This command is mandatory for all extraction flows. It specifies the location of the TCAD

GRD file containing conductor sheet resistances and models for 3-D parasitic capacitance

calculation.

The MAPPING_FILE command specifies a file that maps every TCAD process layer to a

corresponding layout database layer. For more information about creating the mapping file,

see “Writing a Mapping File” on page 3-58. For information about creating the TCAD GRD

file, see “Process Characterization Basics” on page 3-3.

See Also

•MAPPING_FILE

•MERGE_MULTI_CORNER

Chapter 17: StarRC Commands

TEMPERATURE_SENSITIVITY 17-294

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

TEMPERATURE_SENSITIVITY

Syntax

TEMPERATURE_SENSITIVITY: YES | NO

Arguments

Argument Description

YES When TEMPERATURE_SENSITIVITY:YES is set in the StarRC

command file, any OPERATING_TEMPERATURE setting in the

command file is ignored. Temperature (CRT1/CRT2/

CRT_VS_SI_WIDTH) can be the only variation specified in the ITF file.

NO TEMPERATURE_SENSITIVITY function is not on.

This is the default.

Description

This command enables the temperature variation flow in StarRC. Temperature derating

parameters, CRT1 and CRT2, can be either printed in the sensitivity netlist or evaluated

during netlist creation based on a user-specified operating temperature.

When TEMPERATURE_SENSITIVITY:YES is set in the StarRC command file, the

OPERATING_TEMPERATURE setting in the command file is ignored. Temperature (CRT1/CRT2/

CRT_VS_SI_WIDTH) can be the only variation specified in the ITF file. You can input a nxtgrd

file without a VARIATION_PARAMETERS table and CRT1/CRT2 is treated as the only variation

parameter.

This command is supported for all reduction modes. For usage guidelines and expected

output, see Table 17-10.

Table 17-10 UDC and Statistical Flow

UDC Flow Statistical Flow

Temperature in UDC CRT1/CRT2 and sensitivities

Temperature from star_cmd

file

Nominal at star_cmd temperature with sensitivities

Chapter 17: StarRC Commands

TEMPERATURE_SENSITIVITY 17-295

Chapter 17: StarRC Commands

TEMPERATURE_SENSITIVITY 17-295

StarRC User Guide and Command Reference Version F-2011.06

Example

TEMPERATURE_SENSITIVITY: YES

SENSITIVITY: YES

See Also

•NETLIST_CORNER_FILE

•NETLIST_CORNER_NAMES

•NETLIST_MERGE_CORNERS

•OPERATING_TEMPERATURE

•SENSITIVITY

Chapter 17: StarRC Commands

THICKNESS_VARIATION_FILE 17-296

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

THICKNESS_VARIATION_FILE

Specifies the thickness variation map for each layer in the design generated by CMP

simulators.

Syntax

THICKNESS_VARIATION_FILE: file_name

Arguments

Argument Description

file_name The thickness variation file.

Default: none.

Description

StarRC reads the thickness variation map, calculates the thickness variation for each

interconnect polygon, and writes the value to the internal database.

Example

When the THICKNESS_VARIATION_FILE command exists in the StarRC command file, the

following commands are automatically disabled from the ITF:

POLYNOMIAL_BASED_THICKNESS_VARIATION

THICKNESS_VS_DENSITY

ILD_VS_WIDTH_AND_SPACING

For information about writing a thickness variation map file, see Chapter 3, “Interconnect

Parasitics Extraction Based on CMP Simulators.”

See Also

•DENSITY_BASED_THICKNESS

•TVF_ADJUSTMENT_TABLES

Chapter 17: StarRC Commands

TOP_DEF_FILE 17-297

Chapter 17: StarRC Commands

TOP_DEF_FILE 17-297

StarRC User Guide and Command Reference Version F-2011.06

TOP_DEF_FILE

Specifies the top-level block design file in DEF format.

Syntax

TOP_DEF_FILE: def_file

Arguments

Argument Description

def_file The top block design file in DEF format.

Default: none.

Description

This command is mandatory for LEF/DEF flows.

Define the top-level block for extraction. This DEF file can reference macros that can be

defined in separate files with the MACRO_DEF_FILE command. The standard cell and routing

layer definitions should be defined in the accompanying LEF_FILE. Macro blocks appearing

in the TOP_DEF_FILE are skipped by default.

Gzipped files can be directly specified in the TOP_DEF_FILE command.

See Also

•LEF_FILE

•MACRO_DEF_FILE

Chapter 17: StarRC Commands

TRANSLATE_DEF_BLOCKAGE 17-298

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

TRANSLATE_DEF_BLOCKAGE

Translates the routing DEF blockages from a TOP_DEF_FILE.

Syntax

TRANSLATE_DEF_BLOCKAGE: YES | NO

Arguments

Argument Description

YES Turns on function to translate the routing DEF BLOCKAGES from a designated

TOP_DEF_FILE.

NO Does not turn on translation of DEF BLOCKAGE.

This is the default.

Description

This command translates the routing DEF blockages from a TOP_DEF_FILE only. It ignores

DEF blockages from the MACRO_DEF_FILE. This is because the routing information

corresponding to these blockages is already present in the TOP_DEF_FILE. Moreover,

placement blockages in the TOP_DEF_FILE are ignored by this option.

Example

[BLOCKAGES numBlockages ;

[- LAYER layerName

[+ COMPONENT compName | + SLOTS | + FILLS | + PUSHDOWN]

[+ SPACING minSpacing | + DESIGNRULEWIDTH effectiveWidth]

{RECT pt pt | POLYGON pt pt pt ...} ...

;] ...

[- PLACEMENT

[+ COMPONENT compName | + PUSHDOWN]

{RECT pt pt} ...

;] ...

See Also

•MACRO_DEF_FILE

•TOP_DEF_FILE

Chapter 17: StarRC Commands

TRANSLATE_FLOATING_AS_FILL 17-299

Chapter 17: StarRC Commands

TRANSLATE_FLOATING_AS_FILL 17-299

StarRC User Guide and Command Reference Version F-2011.06

TRANSLATE_FLOATING_AS_FILL

Syntax

TRANSLATE_FLOATING_AS_FILL: YES | NO

Arguments

Argument Description

YES Treats disconnected floating polygons as fill polygons. Their capacitive

interaction is accounted as metal fill polygons.

NO Treats disconnected floating polygons as simple ideal ground. This is the

default.

Description

StarRC handles floating and grounded metal fill through a separate metal fill GDSII file

interface for transistor-level flows. For these flows, StarRC determines the name of a net

based on pin-marker definitions from physical verification tools such as Hercules or Calibre.

For nets that do not have pin-marker layers or text, verification tools generally assign a

random net ID to these layers. These polygons are considered disconnected or floating.

Since these are present in the input database, StarRC must take the polygons into account

for capacitive interaction. Resistance is not a concern since there are no pins present and

thus no current flowing through these polygons.

The TRANSLATE_FLOATING_AS_FILL command is independent of the

METAL_FILL_POLYGON_HANDLING command.

See Also

•METAL_FILL_GDS_FILE

Chapter 17: StarRC Commands

TRANSLATE_RETAIN_BULK_LAYERS 17-300

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

TRANSLATE_RETAIN_BULK_LAYERS

Syntax

TRANSLATE_RETAIN_BULK_LAYERS: YES | NO

Arguments

Argument Description

YES Specifies that all mapped bulk layers are passed to the StarRC

extraction engine for use during extraction.

When YES is specified, layer precedence should be set in your

mapping file; otherwise accuracy can be affected.

NO Specifies that no bulk layers are passed to the StarRC extraction

engine for use during extraction.

This is the default.

Description

Specifies that StarRC use (YES) or discard (NO) bulk layers during device-level parasitic

extraction, assuming such layers are mapped in a MAPPING_FILE.

A bulk layer is defined as any database layer that is used as the bulk terminal layer for any

of the following Hercules and Calibre device extraction commands: NMOS/PMOS, resistor,

diode, or bipolar junction transistor.

Note:

In Calibre flows, MOS bulk layer recognition is applicable to devices bearing a

device_type equal to MOS in the CALIBRE_DEVTAB file (including MN, MP, MD, and ME

element names) as well as to devices bearing the element name ’M’. This bulk layer

recognition is not applicable to lightly doped drain (LDD) devices. These LDD devices are

MOS transistors with source and drain pins that are not swappable. It is also not

applicable to most devices bearing the USER tag in the device_type field of the

CALIBRE_DEVTAB file, including inductor devices.

When you set the TRANSLATE_RETAIN_BULK_LAYERS:YES, command StarRC has the

capability to output coupling capacitance to well layers that serve as bulk layers. In this

mode, StarRC also outputs an instance port subnode for the bulk terminal of any of the

devices described previously. By contrast when you specify the TRANSLATE_RETAIN_BULK_

Chapter 17: StarRC Commands

TRANSLATE_RETAIN_BULK_LAYERS 17-301

Chapter 17: StarRC Commands

TRANSLATE_RETAIN_BULK_LAYERS 17-301

StarRC User Guide and Command Reference Version F-2011.06

LAYERS:NO command, StarRC includes the capacitance to well layers as a generic ground

capacitance in the netlist. In this way, StarRC also outputs bulk terminals using ideal net

names instead of instance port subnodes.

You should use TRANSLATE_RETAIN_BULK_LAYERS: YES command for the following types

of device-level extraction scenarios:

• Power net extractions where capacitance to well layers should be output as coupling

capacitance

• Extractions containing well devices (for example, well resistors, diodes, bipolar junction

transistors) whose database terminal layers consist solely of bulk layers

• Scenarios in which the bulk terminals of designed devices should be output as instance

port subnodes instead of ideal nodes

Errors

Two warning messages can be issued by StarRC when one of the following conditions

exists:

• When no precedence is set in a mapping file with the TRANSLATE_RETAIN_

BULK_LAYERS:YES command for layers mapped to substrate.

In this situation, accuracy can be affected. Check the order of substrate layer precedence

specified in your mapping file whenever the TRANSLATE_RETAIN_BULK_LAYERS:YES

command is specified.

• When the precedence is not set for all layers mapped to substrate in the mapping file.

For those layers not set with precedence, their precedence is set to zero automatically.

Example

To set precedence in a mapping file, use the following syntax:

conducting_layers

db_layer SUBSTRATE precedence=pos_integer

...

See Also

•COUPLE_TO_GROUND

•POWER_REDUCTION

Chapter 17: StarRC Commands

TVF_ADJUSTMENT_TABLES 17-302

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

TVF_ADJUSTMENT_TABLES

Specifies a file containing the thickness variation adjustment tables for local or density

effects.

Syntax

TVF_ADJUSTMENT_TABLES: file_name

Arguments

Argument Description

file_name File containing thickness variation adjustment tables

Description

The TVF_ADJUSTMENT_TABLES command specifies a file that contains the thickness

variation adjustment tables. These tables are an extension to the CMP flow interface, which

allows a thickness variation file to specify the bottom conductor thickness information. The

adjustment tables adjust the thickness variation based on the width and spacing of the local

conductor and based on the pattern density of neighboring tiles.

These adjustment tables are optional when THICKNESS_VARIATION_FILE is specified.

When adjustment tables are not provided with thickness variation file, the bottom thickness

variation is taken directly from the thickness variation file, and no adjustment is applied for

local or density effects.

See Also

•THICKNESS_VARIATION_FILE

Chapter 17: StarRC Commands

USER_DEFINED_DIFFUSION_RES 17-303

Chapter 17: StarRC Commands

USER_DEFINED_DIFFUSION_RES 17-303

StarRC User Guide and Command Reference Version F-2011.06

USER_DEFINED_DIFFUSION_RES

Controls the application of equation-based diffusion resistance methodology to contacts that

are below the thresholds specified in the ITF file.

Syntax

USER_DEFINED_DIFFUSION_RES: YES | NO

Arguments

Argument Description

YES Enables equation-based diffusion resistance methodology to

contacts that are below the thresholds specified in the ITF file.

NO Disables equation-based diffusion resistance methodology to

contacts that are below the thresholds specified in the ITF file.

This is the default.

Description

The USER_DEFINED_DIFFUSION_RES command controls the application of equation-based

diffusion resistance methodology to contacts that fall below the following thresholds

specified in the ITF file:

•DIFFUSION_RES_GATE_TO_CONT_THRESHOLD

•DIFFUSION_RES_BEND_THRESHOLD

For contacts with layout parameters that are above the thresholds specified in the ITF file,

StarRC performs the standard mesh-based diffusion resistance extraction.

Setting USER_DEFINED_DIFFUSION_RES: YES affects the capacitance values of nets within

the statistical convergence error limit because of layout polygon fragmentation and changing

nodes.

Example

To enable equation-based diffusion resistance methodology, use the following command:

USER_DEFINED_DIFFUSION_RES: YES

See Also

•NETLIST_POSTPROCESS_COMMAND

Chapter 17: StarRC Commands

VIA_COVERAGE 17-304

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

VIA_COVERAGE

Specifies the six values from the via edge to outer metal edge for coverage and landing

measurement.

Syntax

VIA_COVERAGE: via1 Lf Lq [Ls] Cf Cq [Cs]

Arguments

Argument Description

Lf Maximum number for a Landing full measurement.

Units: nanometers.

Lq Maximum number for a Landing quarter measurement.

Units: nanometers.

Ls Maximum number for a Landing semi- measurement.

Units: nanometers.

Cf Maximum number for a Coverage full measurement.

Units: nanometers.

Cq Maximum number for a Coverage quarter measurement.

Units: nanometers.

Cs Maximum number for a Coverage semi- measurement.

Units: nanometers.

Description

Each number corresponds to a coverage or landing measurement.

The VIA_COVERAGE command checks square vias; the VIA_COVERAGE_OPTION_FILE

command checks rectangular vias.

Note:

The NETLIST_TAIL_COMMENTS:YES command is required; the NETLIST_FORMAT:SPEF

command is no longer required. The VIA_COVERAGE command does not require a text

file.

All netlist formats are accepted by this command.

Chapter 17: StarRC Commands

VIA_COVERAGE 17-305

Chapter 17: StarRC Commands

VIA_COVERAGE 17-305

StarRC User Guide and Command Reference Version F-2011.06

Each VIA_COVERAGE command must have all six entries to include the semi-coverage

capability. (For backward compatibility, you can specify four numbers and get results without

the semi-coverage capability. Both are reported in the netlist under the heading

“VIA_COVERAGE_CODES.”

The full coverage/landing and quarter coverage/landing numbers are in nanometers and

represent “as drawn” dimensions. (These dimensions are before the application of a

MAGNIFICATION_ FACTOR command).

The full-coverage/landing numbers must be greater than the quarter-coverage/landing

numbers. All vias specified for this feature must also be defined in your ITF file.

Example

This example shows how to specify the measurement of via coverage including

“semi-coverage.”

NETLIST_FORMAT: SPF

NETLIST_TAIL_COMMENTS: YES

VIA_COVERAGE: via1 100 80 100 80

VIA_COVERAGE: via2 100 80 100 80

See Also

•MERGE_VIAS_IN_ARRAY

•NETLIST_FORMAT

•NETLIST_TAIL_COMMENTS

•VIA_COVERAGE_OPTION_FILE

Chapter 17: StarRC Commands

VIA_COVERAGE_OPTION_FILE 17-306

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

VIA_COVERAGE_OPTION_FILE

Checks rectangular vias.

Syntax

VIA_COVERAGE_OPTION_FILE: file_name

Arguments

Argument Description

file_name The via coverage option file

Description

This command uses the dimensions (for each side of a via) that you specify to check the

specified area. See Figure 17-9 on page 17-307. This function works as an area checking

rule. You specify a text file containing via check ranges that you name in this command

syntax.

The VIA_COVERAGE_OPTION_FILE command checks rectangular vias; the VIA_COVERAGE

command checks square vias.

The StarRC via coverage report in the netlist contains a table that shows the detail of the via

coverage results. These results are determined by rules inside of StarRC that read and

analyze your via coverage data. The via coverage results are shown as full coverage,

quarter coverage, semi-coverage, and partial coverage.

All netlist formats are accepted for this command.

A via satisfies the area check of a drawn box if the box area in the figure is filled with metal

polygons. This applies to both coverage and landing. For coverage, the metal layer refers to

the metal layer above the via layer (for example, metal2 for via12) and for the landing it refers

to the metal layer below the via layer (for example metal1 for via 12).

All dimensions are given in nanometers and integers.

The output netlist contains the following via classifications:

•FULL means all sides of the via are covered because all enclosures are greater than the

F parameter (as shown in Figure 17-9).

•QUARTER means one enclosure must be greater than or equal to Q1 and must have both

adjacent sides enclosed by greater than Q2.

Chapter 17: StarRC Commands

VIA_COVERAGE_OPTION_FILE 17-307

Chapter 17: StarRC Commands

VIA_COVERAGE_OPTION_FILE 17-307

StarRC User Guide and Command Reference Version F-2011.06

•SEMI means one enclosure must be greater than or equal to S1 and both adjacent sides

must be enclosed by more than S2.

•PARTIAL means no enclosures meet the full, quarter, or semi-coverage requirements.

Figure 17-9 Via Coverage

W = the width of the VIA in the horizontal (x direction)

L = the length of the VIA in the vertical (y direction)

F1, F2, Q2, Q1, S2, S1 are the parameters in the VIA_COVERAGE_OPTION_FILE command

Q2/S2

Q1/S1

Q2/S2

Q1/S1

Q2/S2

Q1/S1

F1 L

For each data set, you specify three numbers for coverage and three numbers for landing

when you are not checking semi-coverage and landing. For each data set, you specify five

numbers for coverage and five numbers for landing when you are checking semi-coverage

and landing.

The VIA_COVERAGE_OPTION_FILE command rules are as follows:

• Non-Manhattan shapes are not supported.

• For via arrays, all inside vias (those not on the perimeter) are considered fully covered.

• The horizontal direction is equal to the direction of the x-axis of coordinates used by the

StarRC extraction.

• The vertical direction is equal to the direction of the y-axis coordinates used by StarRC

extraction.

• Via coverage parameters must meet the following conditions, which apply to both

coverage and landing parameters and are checked in StarRC.

• F must be greater than or equal to Q2.

• F must be greater than or equal to S2.

• Q2 must be greater than S2.

• Q2 must be greater than Q1.

Chapter 17: StarRC Commands

VIA_COVERAGE_OPTION_FILE 17-308

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

• S2 must be greater than or equal to S1.

The following table explains text file syntax entries.

Keyword Description

Xrange Width of the via contact

Xmin Minimum width value of the via contact

Xmax Maximum width value of the via contact

Yrange Length of the via contact

Ymin Minimum length value of the via contact

Ymax Maximum length value of the via contact

FL1Full coverage “y” value for via landing

FL2Full coverage “x” value for via landing

FC1 Full coverage “y” value for via cover

FC2 Full coverage “x” value for via cover

QL1 Quarter coverage value for landing (small enclosure value)

QC1 Quarter coverage value for via cover (small enclosure value)

QL2 Quarter coverage value for via landing (large enclosure value)

QC2 Quarter coverage value for via cover (large enclosure value)

SL1 Semi-coverage value for via landing (small enclosure value)

SC1 Semi-coverage value for via cover (small enclosure value)

SL2 Semi-coverage value for via landing (large enclosure value)

SC2 Semi-coverage value for via cover (large enclosure value)

Example

Text File Syntax Single Parameter

via_layer_name

{Xrange=Xmin,Xmax;Yrange=Ymin,Ymax;Landing = FL,QL1,QL2,[SL1,SL2];

Coverage = FC,QC1,QC2,[SC1,SC2]}

Chapter 17: StarRC Commands

VIA_COVERAGE_OPTION_FILE 17-309

Chapter 17: StarRC Commands

VIA_COVERAGE_OPTION_FILE 17-309

StarRC User Guide and Command Reference Version F-2011.06

(Xrange=Xmin,Xmax;Yrange=Ymin,Ymax;

Landing = FL,QL1,QL2,[SL1,SL2];Coverage = FC,QC1,QC2,[SC1,SC2]}

Text File Syntax With Two Parameters

Without semi-coverage extraction

via_layer_name

{Xrange=Xmin,Xmax;Yrange=Ymin,Ymax;Landing = FL1,FL2,QL1,QL2;

Coverage = FC1,FC12,QC1,QC2}

With semi-coverage extraction

via_layer_name

{Xrange=Xmin,Xmax;Yrange=Ymin,Ymax;

Landing = FL1,FL2,QL1,QL2,[SL1,SL2];Coverage = FC1,FC2,QC1,QC2,[SC1,SC2]}

File Format Example 1 - With Semi-Coverage

VIA1 { Xrange= 100,100; Yrange = 100,100;

Landing = 100,80,10,40,10;Coverage = 100,80,10,40,10}

File Format Example 1 - Without Semi-Coverage

VIA1 { Xrange= 100,100; Yrange = 100,100;

Landing = 100,80,10;Coverage = 100,80,10}

In the example files, Xrange and Yrange represent the as-drawn length in X and Y

dimension of the via (before any scale factor has been applied). The ranges must not be

overlapping, and, each via size should be map-able to exactly one of the data sets in the list.

The range specification for a via landing and via coverage is the same. These requirements

are checked in the tool. No interpolation or extrapolation is needed. If -during a via coverage

mode extraction, a via is found that cannot be mapped to one of the specified ranges, then

StarRC issues a warning and the via has an “invalid” via coverage code, which is 0. There is

no limit to the number of data set ranges.

See Also

•NETLIST_FORMAT

•NETLIST_TAIL_COMMENTS

•REDUCTION

•VIA_COVERAGE

Chapter 17: StarRC Commands

WIDE_DEVICE_TERM_RESISTANCE 17-310

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

WIDE_DEVICE_TERM_RESISTANCE

Syntax

WIDE_DEVICE_TERM_RESISTANCE: RES

Arguments

Argument Description

RES Activates equipotential line node handling for RES devices.

Default: none.

Description

This command activates equipotential line node handling for RES devices -for example,

devices extracted with a RES command in Hercules or devices containing an element_name

= R in Calibre. Specifically, this command forces StarRC to always treat the A and B terminal

nodes as electrical line nodes (as opposed to electrical point nodes), which is the default

behavior. With this treatment, StarRC identifies the terminal or body boundary line and

extracts parasitic resistance orthogonal to that line.

For a resistor device, an electrical point node is a physical approximation that assumes all

current is concentrated at a single point instead of being distributed along the width of the

material. For a device whose width is small relative to its length, this approximation is

appropriate for default extraction flows. However, when the width of the device is large

relative to its length as shown in Figure 17-10, the impact of current distribution along the

entire terminal/body boundary must be considered during the parasitic resistance extraction.

If RES is specified, StarRC first identifies the A and B terminal layers for all the RES devices

extracted by LVS tools. Since LVS tools always put a RES device instance port on the butting

edge of the terminal shape and the RES device body shape, StarRC can determine the

current direction for the terminal shape to be perpendicular to the butting edge when

extracting the resistance of the terminal shapes. It is assumed that the RES terminal

contains one shape with its RES instance port lying on one edge. If the terminal contains

multiple shapes, only the shape touched by the instance port is treated. The other shapes

resume normal processing.

This command does not apply to bulk terminal layers of RES devices.

Chapter 17: StarRC Commands

WIDE_DEVICE_TERM_RESISTANCE 17-311

Chapter 17: StarRC Commands

WIDE_DEVICE_TERM_RESISTANCE 17-311

StarRC User Guide and Command Reference Version F-2011.06

Figure 17-10 Line Nodes for Resistor Terminals

terminal resistance to electrical line node

electrical line nodes

for resistor terminals

Chapter 17: StarRC Commands

XREF 17-312

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

XREF

Syntax

XREF: NO | YES | COMPLETE

Arguments

Argument Description

NO Reports the layout net names generated by Hercules or Calibre

during ideal layout extraction. These layout names are either

generated or derived from the application of text. The layout

instance names can either be the original GDSII instance name

(if the ASSIGN_PROPERTY command in Hercules is used), or

names generated by Hercules.

This is the default.

YES Reports all layout nets and devices occurring in the ideal layout

netlist using schematic, net, and instance names wherever

possible. When nets or devices exist that were not successfully

matched during LVS, layout names are used. When a successful

match did occur during LVS, StarRC uses schematic names.

StarRC handles composite device merging by using schematic

instance names with modifiers attached whenever layout devices

outnumber schematic devices within a particular composite

device pairing.

Chapter 17: StarRC Commands

XREF 17-313

Chapter 17: StarRC Commands

XREF 17-313

StarRC User Guide and Command Reference Version F-2011.06

Description

A GDS-based device-level extraction database contains both layout names and

cross-referenced schematic names if a logic versus schematic verification was performed.

The XREF command determines which set of names to provide to StarRC for netlist creation

and analysis flows. It also determines which devices and nets to retain.

This command is only valid when MILKYWAY_EXTRACT_VIEW: YES is specified for Hercules

input databases, or when a CALIBRE_IXF_FILE and CALIBRE_NXF_FILE are specified for

Calibre input databases.

See Also

•MILKYWAY_EXTRACT_VIEW

COMPLETE Reports every SKIP_CELLS/device in the schematic.

XREF:COMPLETE is only valid in the Hercules flow. The netlist

includes all instances. If you do not want this, make sure that any

net selected with the NETS command is also included in

NETLIST_SELECT_NETS.

Parasitics are netlisted only for nets that were successfully

cross-referenced to schematic nets. Nets that do not

cross-reference to a schematic net are treated as ideal

connections by StarRC. Schematic model names are reported for

SKIP_CELLS and primitive devices.

Internal nets of the SERIES/PATHS merged devices do not have

*|NET sections in XREF:COMPLETE; they are netlisted ideally in

the instance section. For an example of XREF:COMPLETE, see

Appendix A, “XREF:COMPLETE (SPF).

XREF:COMPLETE reports device properties in the following way.

The syntax used is x:y, where the left side is the number of

schematic devices and the right side is the number of layout

devices. A1 indicates one device, with m and n being differing

values of more than one. For example, m:m is “same number of

schematic and layout devices, but more than one,” m:n would

refer to different numbers of layout and schematic devices, and so

on.

Layout property merging for XREF:COMPLETE applies only to

standard SPICE properties. Nonstandard properties cannot be

merged for smashed devices in XREF:COMPLETE.

Argument Description

Chapter 17: StarRC Commands

XREF_FEEDTHRU_NETS 17-314

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

XREF_FEEDTHRU_NETS

Syntax

XREF_FEEDTHRU_NETS: YES | NO

Arguments

Argument Description

YES Generates pure layout feed-through nets and ports in the

XREF:COMPLETE netlist.

NO Does not generate feed-through nets and ports.

This is the default.

Description

Specifies whether or not to output pure layout feed-through nets and ports in the XREF:

COMPLETE netlist. These are routes that cross a hierarchical boundary but whose ports were

excluded from LVS, because they have no correspondence in the schematic netlist.

This command has no effect on XREF arguments other than COMPLETE. Pure layout

feed-through nets are always netlisted in the other XREF modes, because the other modes

are layout-based.

Note:

The CREATE_PORTS option must be enabled in the Hercules runset for

XREF_FEEDTHRU_NETS: YES.

See Also

•XREF

Chapter 17: StarRC Commands

XREF_LAYOUT_INST_PREFIX 17-315

Chapter 17: StarRC Commands

XREF_LAYOUT_INST_PREFIX 17-315

StarRC User Guide and Command Reference Version F-2011.06

XREF_LAYOUT_INST_PREFIX

Syntax

XREF_LAYOUT_INST_PREFIX: prefix

Arguments

Argument Description

prefix A prefix to be used in netlist generation

Default: Id_

Description

Sets a prefix for layout device instance names that were not cross-referenced to a schematic

device by the LVS tool. This prefix is applicable only for layout-based XREF mode YES, which

generates a netlist for every layout element whether or not it was cross-referenced. Device

instances that have no LVS comparison information, such as filtered layout instances, are

netlisted with this prefix followed by the layout instance name.

See Also

•XREF_LAYOUT_NET_PREFIX

Chapter 17: StarRC Commands

XREF_LAYOUT_NET_PREFIX 17-316

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

XREF_LAYOUT_NET_PREFIX

Sets a prefix for layout net names that were not cross-referenced to a schematic net by the

LVS tool.

Syntax

XREF_LAYOUT_NET_PREFIX: prefix

Arguments

Argument Description

prefix A prefix to be assigned to net names in netlist generation.

Default: ln_

Description

This prefix is applicable only for the layout based XREF mode YES, which generates a netlist

for every layout element whether or not it was cross-referenced. Nets that have no LVS

comparison information such as dangling and floating nets are output with this prefix

followed by the layout net name.

See Also

•XREF_LAYOUT_INST_PREFIX

Chapter 17: StarRC Commands

XREF_SWAP_MOS_SD_PROPERTY 17-317

Chapter 17: StarRC Commands

XREF_SWAP_MOS_SD_PROPERTY 17-317

StarRC User Guide and Command Reference Version F-2011.06

XREF_SWAP_MOS_SD_PROPERTY

Syntax

XREF_SWAP_MOS_SD_PROPERTY: prop1 prop2 [model_name]

Arguments

Argument Description

prop1 prop2 A pair of properties to be swapped

model_name Specifies that prop1 and prop2 are swapped only for

model_name device models

Description

Specifies a pair of MOS properties to be swapped. The pair of properties has the same

swapping behavior as generic MOS source and drain properties such as, ad, ps, and pd.

The XREF_SWAP_MOS_SD_PROPERTY statement affects SPICE, SPF, and any other netlist

format that has instances with properties. It does not affect SPEF files, which do not include

device parameters.

Example

To swap multiple pairs of properties, use a separate XREF_SWAP_MOS_SD_PROPERTY

statement for each pair of properties. For example,

XREF_SWAP_MOS_SD_PROPERTY: as2 ad2

XREF_SWAP_MOS_SD_PROPERTY: as3 ad3

To restrict the property swapping to a specific device model, specify the model name in the

XREF_SWAP_MOS_SD_PROPERTY statement as shown in the following example:

XREF_SWAP_MOS_SD_PROPERTY: as5 ad5 nch_mac5

See Also

•MODEL_TYPE

•XREF: YES | COMPLETE

Chapter 17: StarRC Commands

XREF_USE_LAYOUT_DEVICE_NAME 17-318

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

XREF_USE_LAYOUT_DEVICE_NAME

Syntax

XREF_USE_LAYOUT_DEVICE_NAME: YES | NO

Arguments

Argument Description

YES Netlist layout model names for all devices with XREF:

YES. A layout model name is a primary device model

name used in a device extraction command in a

Hercules or Calibre rule-file.

NO Netlist schematic model names for all devices with

XREF: YES; continue to use layout model names for

XREF: NO. A schematic model name is a device model

name that occurs in a schematic netlist used for an LVS

(Hercules flow) or that occurs in NETLIST MODEL or

TEXT MODEL commands (Calibre flow). This is default.

This is the default.

Description

Device model names recognized by StarRC can originate from one of two places:

• Schematic model name from a Hercules flow or NETLIST MODEL rule-file command

from a Calibre flow.

• Layout model name specified in device extraction command

See Also

•COUPLE_TO_GROUND

•NETLIST_FORMAT

•XREF

•ZONE_COUPLE_TO_NET_LEVEL

Chapter 17: StarRC Commands

ZONE_COUPLE_TO_NET 17-319

Chapter 17: StarRC Commands

ZONE_COUPLE_TO_NET 17-319

StarRC User Guide and Command Reference Version F-2011.06

ZONE_COUPLE_TO_NET

Syntax

ZONE_COUPLE_TO_NET: net_name

Arguments

Argument Description

net_name The net name to the noncritical material outside the

defined MACRO.

Default: none.

Description

This command is analogous to the SKIP_CELLS_COUPLE_TO_NET command, except that it

applies to overhead or adjacent material when you are doing the in-context extraction of a

MACRO or using the RING_AROUND_THE_BLOCK in-context approximation.

You must specify NETLIST_FORMAT: SPEF and COUPLE_TO_GROUND: NO to use this

command.

Example

ZONE_COUPLE_TO_NET: ZONE

See Also

•ZONE_COUPLE_TO_NET_LEVEL

Chapter 17: StarRC Commands

ZONE_COUPLE_TO_NET_LEVEL 17-320

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

ZONE_COUPLE_TO_NET_LEVEL

Syntax

ZONE_COUPLE_TO_NET_LEVEL: YES | NO

Arguments

Argument Description

YES Appends the layer number of the material outside the

MACRO.

NO Does not append the layer number of the material

outside the MACRO.

This is the default.

Description

Analogous to the SKIP_CELLS_COUPLE_TO_NET_LEVEL command option, except that it

applies to the ZONE_COUPLE_TO_NET.

See Also

•ZONE_COUPLE_TO_NET

18-1

ITF Statements and Options 18

The Interconnect Technology Format (ITF) defines a cross-section profile of the process.

The ITF file consists of an ordered list of conductor and dielectric layer definition statements.

The layers are defined from the topmost dielectric layer to the bottommost dielectric layer,

excluding the substrate, in a way that is consistent with the physical manufacturing process.

This chapter describes the ITF statements and their options. Use the ITF statements to

create an ITF file with the following structure:

TECHNOLOGY = process_name

[GLOBAL_TEMPERATURE = temp_value]

[BACKGROUND_ER = value]

[HALF_NODE_SCALE_FACTOR = scale_factor]

[USE_SI_DENSITY = YES | NO ]

[DROP_FACTOR_LATERAL_SPACING = value]

DIELECTRIC top_dielectric_name {...}

CONDUCTOR top_conductor_name {...}

[...]

[DIELECTRIC bottom_dielectric_name{...}]

VIA top_via_name {...}

[...]

VIA bottom_via_name {...}

[VARIATION_PARAMETERS {...}]

Comments in an ITF File

In an ITF file, a dollar sign ($) at the beginning of a line indicates a comment that is not

interpreted by the extraction tool.

Chapter 18: ITF Statements and Options

18-2

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Restrictions for Layer Names

In the CONDUCTOR, DIELECTRIC, and VIA statements, the case-sensitive layer names

• Must contain only alphanumeric characters and underscores (_) unless otherwise noted

• Must begin with an alphabetic character

• Must not begin with a number or an underscore (_)

• Must not contain periods

Chapter 18: ITF Statements and Options

AIR_GAP_VS_SPACING 18-3

Chapter 18: ITF Statements and Options

AIR_GAP_VS_SPACING 18-3

StarRC User Guide and Command Reference Version F-2011.06

AIR_GAP_VS_SPACING

Defines the parameters of the air gap in your process.

Syntax

AIR_GAP_VS_SPACING {

SPACINGS { s1 s2 .. sn }

AIR_GAP_WIDTHS { w(s1) s(s2) ... s(sn) }

AIR_GAP_THICKNESSES { t(s1) t(s2) ... t(sn) }

AIR_GAP_BOTTOM_HEIGHTS { h(s1) h(s2) h(sn) }

}

Arguments

Argument Description

s1 s2 ... sn Spacings between the two conductors.

Units: microns

w(s1) s(s2) ... s(sn) The widths of the air gap formed at the corresponding spacing

values.

Units: microns

t(s1) t(s2) ... t(sn) The thicknesses of the air gap formed at the corresponding

spacing values.

Units: microns

h(s1) h(s2) ... h(sn) The heights of the bottom of the air gap from the bottom of the

conductor at the corresponding spacing values.

Units: microns

Description

Use AIR_GAP_VS_SPACING within a CONDUCTOR statement to define the parameters of the air

gap in your process. The number of arguments in each row of the table must be equal.

Spacing value s1 must be equal to SMIN in the CONDUCTOR statement.

If the spacing between the polygons is greater than sn, an air gap does not form.

Chapter 18: ITF Statements and Options

AIR_GAP_VS_SPACING 18-4

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Errors

If StarRC finds an air gap definition from an earlier release format, the following warning

message is issued:

WARNING:(1005) ITF**

WARNING: AIR_GAP_WMAX, AIR_GAP_SMAX, AIR_GAP_HEIGHT are obsolete from

2003.03 release;

WARNING: grdgenxo translates them into the following new syntax for layer

M2:

WARNING: AIR_GAP_VS_SPACING {

WARNING: SPACINGS { 0.28 1 2 }

WARNING: AIR_GAP_WIDTHS { 0.28 1 1 }

WARNING: AIR_GAP_THICKNESSES { 0.4 0.4 0.4 }

WARNING: AIR_GAP_BOTTOM_HEIGHTS { 0.1 0.1 0.1 }

WARNING: }

If you change any values in the air gap definition, you need to regenerate the nxtgrd file. The

previous grdgenxo run directory cannot be used.

Example

AIR_GAP_VS_SPACING {

SPACINGS { 0.3 0.5 0.7 1.0 3.0 }

AIR_GAP_WIDTHS { 0.1 0.09 0.09 0.15 0.20 }

AIR_GAP_THICKNESSES { 0.2 0.23 0.25 0.26 0.28 }

AIR_GAP_BOTTOM_HEIGHTS { 0.1 0.14 0.18 0.20 0.22 }

}

See Also

•CONDUCTOR

Chapter 18: ITF Statements and Options

AREA 18-5

Chapter 18: ITF Statements and Options

AREA 18-5

StarRC User Guide and Command Reference Version F-2011.06

AREA

Specifies the default area of a via.

Syntax

AREA = via_area

Arguments

Argument Description

via_area Area of default via.

Units: square microns

Default: 1.0e -6 / RPV

Description

The resistive properties of the via layer must be specified. The via layers can be specified in

two ways: RHO, or RPV and AREA. However, only one specification method is required.

If RPV is specified, then AREA is required.

You must specify this option within a VIA statement.

Example

VIA via1 { FROM=m1 TO=m2 AREA=4 RPV=0.25 }

See Also

•RPV

•VIA

Chapter 18: ITF Statements and Options

ASSOCIATED_CONDUCTOR 18-6

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

ASSOCIATED_CONDUCTOR

Allows conformal layers to be associated with a specified conductor layer.

Syntax

ASSOCIATED_CONDUCTOR = layer_name

Arguments

Argument Description

layer_name Layer to which the associated conductor is assigned

Description

The ASSOCIATED_CONDUCTOR statement allows conformal layers to be associated with a

specified conductor layer.

• Only one CONDUCTOR is allowed for an ASSOCIATED_CONDUCTOR.

• When an ASSOCIATED_CONDUCTOR material drops with a DROP_FACTOR defined for a

CONDUCTOR below it, IS_CONFORMAL layers also drop.

• If a CONDUCTOR above overlaps with the TW_T of an IS_CONFORMAL layer, the CONDUCTOR

cuts into the IS_CONFORMAL layer.

•An

IS_CONFORMAL layer can be specified without an ASSOCIATED_CONDUCTOR. See also

IS_CONDUCTOR

An ASSOCIATED_CONDUCTOR statement can only be defined for an IS_CONFORMAL layer; it

cannot be used with other conformal layers. When no ASSOCIATED_CONDUCTOR is specified

for an IS_CONFORMAL layer, the default is to measure from the top layer.

Errors

The following error and warning messages can be issued in the noted conditions:

• It the layer defined by ASSOCIATED_CONDUCTOR is not a valid layer, the following error

message appears:

ERROR: ASSOCIATED_CONDUCTOR layer xxx for layer xxx is not a valid

• If the layer defined by ASSOCIATED_CONDUCTOR is not a conductor layer, the following

error message appears:

ERROR: ASSOCIATED_CONDUCTOR must be a conductor for layer xxx.

Chapter 18: ITF Statements and Options

ASSOCIATED_CONDUCTOR 18-7

Chapter 18: ITF Statements and Options

ASSOCIATED_CONDUCTOR 18-7

StarRC User Guide and Command Reference Version F-2011.06

• If ASSOCIATED_CONDUCTOR is defined for a non-IS_CONFORMAL layer, the following

error message appears:

ERROR: Layer xx must be set to be IS_CONFORMAL if it has

ASSOCIATED_CONDUCTOR.

• If the conductor defined for ASSOCIATED_CONDUCTOR is higher than the IS_CONFORMAL

layer, the following message appears:

ERROR: ASSOCIATED_CONFORMAL layer xxx for layer xxx cannot be higher

than the layer itself.

Example

DIELECTRIC D1 {

IS_CONFORMAL

ASSOCIATED_CONDUCTOR=met1

SW_T=0.1 TW_T=0.1 ER=2.5

}

Chapter 18: ITF Statements and Options

BACKGROUND_ER 18-8

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

BACKGROUND_ER

Specifies the relative permittivity, or dielectric constant, of the background dielectric.

Syntax

BACKGROUND_ER = relative_permittivity

Arguments

Argument Description

relative_permittivity Relative permittivity

Default: 1.0

Description

The BACKGROUND_ER statement is an optional statement. If the BACKGROUND_ER statement is

not specified, then the relative permittivity of the background dielectric defaults to 1.0, the

relative permittivity of air.

The background dielectric globally fills the cross section to an infinite height, effectively

replacing air as the operating medium for the chip.

The DIELECTRIC statements specified in the ITF locally override the global background

dielectric.

Example

TECHNOLOGY = Sample_tech

GLOBAL_TEMPERATURE = 31.0

BACKGROUND_ER = 4.1

Chapter 18: ITF Statements and Options

BOTTOM_DIELECTRIC_ER 18-9

Chapter 18: ITF Statements and Options

BOTTOM_DIELECTRIC_ER 18-9

StarRC User Guide and Command Reference Version F-2011.06

BOTTOM_DIELECTRIC_ER

Specifies the relative permittivity of the dielectric region below the conductor.

Syntax

BOTTOM_DIELECTRIC_ER = permittivity

Arguments

Argument Description

permittivity Relative permittivity of the dielectric

Description

Specify the BOTTOM_DIELECTRIC_ER option together with the

BOTTOM_DIELECTRIC_THICKNESS option within a CONDUCTOR statement.

For more information about the BOTTOM_DIELECTRIC_ER option, see the description of the

BOTTOM_DIELECTRIC_THICKNESS option.

Example

BOTTOM_DIELECTRIC_ER = 4.0

See Also

•BOTTOM_DIELECTRIC_THICKNESS

•CONDUCTOR

Chapter 18: ITF Statements and Options

BOTTOM_DIELECTRIC_THICKNESS 18-10

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

BOTTOM_DIELECTRIC_THICKNESS

Specifies the thickness of the dielectric region below the conductor.

Syntax

BOTTOM_DIELECTRIC_THICKNESS = thickness

Arguments

Argument Description

thickness Thickness of the dielectric

Units: microns

Description

Specify the BOTTOM_DIELECTRIC_THICKNESS option together with the

BOTTOM_DIELECTRIC_ER option within a CONDUCTOR statement. If the specified conductor

layer does not appear in a certain model, the bottom dielectric layer does not appear in the

model either.

If a conductor with a bottom dielectric also has conformal dielectrics on the sides of the

conductor, the side conformal dielectric layers extend to the bottom of the bottom conformal

dielectric, as shown in Figure 18-1. When placing a conductor with bottom dielectric in the

dielectric stack, the bottom of the bottom dielectric layer is assumed to be sitting on top of

the planar dielectric layer defined below the conductor. To specify the thickness of the

conductor with the bottom dielectric layer, use the THICKNESS option in the CONDUCTOR

statement. Therefore, the top of the conductor with the bottom dielectric is at a distance

equal to the conductor thickness and the bottom dielectric thickness above the planar

dielectric.

Chapter 18: ITF Statements and Options

BOTTOM_DIELECTRIC_THICKNESS 18-11

Chapter 18: ITF Statements and Options

BOTTOM_DIELECTRIC_THICKNESS 18-11

StarRC User Guide and Command Reference Version F-2011.06

Figure 18-1 Bottom Dielectric Layer with Covertical Layers

Example

High-Permittivity Gate Oxide

The high-permittivity dielectric under the gate shown in Figure 18-2 can be modeled with the

following syntax:

CONDUCTOR gpoly {

THICKNESS = 0.06

WMIN = 0.03

SMIN = 0.03

BOTTOM_DIELECTRIC_THICKNESS = 0.002

BOTTOM_DIELECTRIC_ER = 10.0

}

Figure 18-2 Modeling the High-Permittivity Dielectric Under the Gate

Chapter 18: ITF Statements and Options

BOTTOM_DIELECTRIC_THICKNESS 18-12

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Independent Bottom Dielectric Regions in Covertical Conducting Layers

You can define independent bottom dielectric regions in covertical conducting layers. For

example, pgpoly and ngpoly conductors with different bottom dielectric regions, as shown in

Figure 18-1 on page 18-11, can be specified in the following manner:

CONDUCTOR pgpoly {

THICKNESS = 0.06 WMIN = 0.03 SMIN = 0.03

BOTTOM_DIELECTRIC_THICKNESS = 0.002

BOTTOM_DIELECTRIC_ER = 10.0

}

CONDUCTOR ngpoly {

THICKNESS = 0.06 WMIN = 0.03 SMIN = 0.03

BOTTOM_DIELECTRIC_THICKNESS = 0.004

BOTTOM_DIELECTRIC_ER = 12.0

}

See Also

•BOTTOM_DIELECTRIC_ER

•CONDUCTOR

Chapter 18: ITF Statements and Options

BOTTOM_THICKNESS_VS_SI_WIDTH 18-13

Chapter 18: ITF Statements and Options

BOTTOM_THICKNESS_VS_SI_WIDTH 18-13

StarRC User Guide and Command Reference Version F-2011.06

BOTTOM_THICKNESS_VS_SI_WIDTH

Specifies the bottom thickness of a conductor layer at different widths.

Syntax

BOTTOM_THICKNESS_VS_SI_WIDTH [RESISTIVE_ONLY | CAPACITIVE_ONLY]

{ (s1, r1) (s2, r2) . . . (sn, rn) }

Arguments

Argument Description

RESISTIVE_ONLY Applies thickness adjustment to resistance only.

CAPACITIVE_ONLY Applies thickness adjustment to capacitance only.

s1 ... sn Silicon widths in ascending order. The first entry should be the

smallest possible silicon width of the layer coming from the drawn

WMIN, but there is no error checking in the grdgenxo process. There

is no extrapolation beyond the range of s1 ... sn.

r1 ... rn Relative changes in bottom thickness. This is the absolute thickness

change from the bottom divided by the nominal thickness of the layer.

A bottom thickness or BTi is positive if the thickness becomes larger in

the nominal value. A bottom thickness BTi is negative if the thickness

becomes smaller than the nominal value.

Description

The BOTTOM_THICKNESS_VS_SI_WIDTH statement models bottom thickness within a

CONDUCTOR statement.

Various foundries note that in a low-k dielectric damascene process, one challenge is to etch

accurate depth for metal trenches. Analysis of data indicates that etching accurate depth in

a low-k dielectric process is not only dependent on the materials used, but it is also

dependent on the interconnect dimension and the proximity to the neighboring interconnect.

The variation in the etch depth for the metal deposition not only affects the thickness of the

interconnect but also affects the vertical distance between metal interconnects. Both

parasitic resistance and capacitance are affected.

Chapter 18: ITF Statements and Options

BOTTOM_THICKNESS_VS_SI_WIDTH 18-14

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

BOTTOM_THICKNESS_VS_SI_WIDTH performs linear interpolation of thickness variation for

wires whose widths fall between entries in the table. StarRC does not extrapolate beyond

the table.

• This feature is available only for conducting layers, because no variations exist for vias or

contacts in standard foundry processes.

•grdgenxo automatically processes trapezoidal conductor cross-sections. This means

that at a given thickness coming from a change at the bottom (and/or top), the specified

ETCH_VS_WIDTH_AND_SPACING, ETCH_FROM_TOP, or SIDE_TANGENT is automatically

applied for the whole cross-section when calculating the sensitivity,

• An error message is issued from grdgenxo if a BOTTOM_THICKNESS_VS_SI_WIDTH table

changes the relative thickness larger than 0.5 or smaller than -0.5. It does not guarantee

the accuracy of the modeling if the thickness changes too much. The same warning

condition is used for the following thickness variation flows in StarRC:

THICKNESS_VS_DENSITY, THICKNESS_VS_WIDTH_AND_SPACING,

POLYNOMIAL_BASED_THICKNESS_VARIATION, THICKNESS_VARIATION_FILE

• You can specify the BOTTOM_THICKNESS_VS_SI_WIDTH option along with the thickness

variation from the top of the conductor by using the following options:

THICKNESS_VS_DENSITY, THICKNESS_VS_WIDTH_AND_SPACING,

POLYNOMIAL_BASED_THICKNESS_VARIATION.

• When the BOTTOM_THICKNESS_VS_SI_WIDTH option is used along with

THICKNESS_VARIATION_FILE, which can already take thickness from the bottom of the

conductor, the resulting bottom thickness variation value is the sum of the two values.

• The BOTTOM_THICKNESS_VS_SI_WIDTH option cannot be used in conjunction with

multiple ETCH_VS_WIDTH_AND_SPACING tables.

• The BOTTOM_THICKNESS_VS_SI_WIDTH option cannot be specified in the same

CONDUCTOR statement as the MEASURED_FROM option.

Effective Thickness Calculation

The effective thickness is calculated with the following equation:

T Tnom 1 RTf Deff()RTf W S,()RTf SiW()++ +()×=

where

• Tnom is the nominal thickness specified in the ITF.

• RTf(Deff) is the relative thickness change due to density.

Chapter 18: ITF Statements and Options

BOTTOM_THICKNESS_VS_SI_WIDTH 18-15

Chapter 18: ITF Statements and Options

BOTTOM_THICKNESS_VS_SI_WIDTH 18-15

StarRC User Guide and Command Reference Version F-2011.06

• RTf(W,S) is the relative change in thickness due to width and spacing.

• RTf(SiW) is the relative change in thickness due to silicon width.

The resistance and capacitance is computed after the effective thickness is computed.

Note:

The grdgenxo process errors out and issues the following message when either a

RESISTIVE_ONLY or CAPACITIVE_ONLY argument is used with another

BOTTOM_THICKNESS_VS_SI_WIDTH table without any qualifiers:

Either a common BOTTOM_THICKNESS_VS_SI_WIDTH table or two separate

BOTTOM_THICKNESS_VS_SI_WIDTH tables with RESISTIVE_ONLY and

CAPACITIVE_ONLY can be used in the ITF.

See Also

•CONDUCTOR

Chapter 18: ITF Statements and Options

CAPACITIVE_ONLY_ETCH 18-16

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

CAPACITIVE_ONLY_ETCH

Specifies the etch value on one edge.

Syntax

CAPACITIVE_ONLY_ETCH = etch_value

Arguments

Argument Description

etch_value Etch value on one edge. A positive value reduces width.

Units: microns

Default: 0.0

Description

This option is specified in the ITF only within a CONDUCTOR statement.

It is identical to the ETCH option, except that only capacitance is affected by etching;

resistance is unaffected. This option is not the same as ETCH_VS_WIDTH_AND_SPACING

CAPACITIVE_ONLY.

Example

CONDUCTOR metal1 {

CAPACITIVE_ONLY_ETCH = 0.05

THICKNESS=0.66 WMIN=0.15 SMIN=0.15 RPSQ=0.078

}

Chapter 18: ITF Statements and Options

CONDUCTOR 18-17

Chapter 18: ITF Statements and Options

CONDUCTOR 18-17

StarRC User Guide and Command Reference Version F-2011.06

CONDUCTOR

Describes the properties of a conductor layer.

Syntax

CONDUCTOR conductor_name {

WMIN = min_width

SMIN = min_spacing

THICKNESS = thick_value

[AIR_GAP_VS_SPACING { ... }]

[BOTTOM_DIELECTRIC_THICKNESS = thickness

BOTTOM_DIELECTRIC_ER = permittivity]

[BOTTOM_THICKNESS_VS_SI_WIDTH ... { ... }]

[T0 = nominal_temp]

[CRT1 = lin_coeff

| CRT2 = quad_coeff

| CRT1 = lin_coeff CRT2 = quad_coeff

| CRT_VS_SI_WIDTH { ... }]

[DENSITY_BOX_WEIGHTING_FACTOR { ... }]

[DROP_FACTOR = value]

[ETCH = value

| CAPACITIVE_ONLY_ETCH = value

| RESISTIVE_ONLY_ETCH = value]

[ETCH_VS_WIDTH_AND_SPACING ... { ... }]

[FILL_RATIO = fill_ratio_value

FILL_WIDTH = fill_width_value

FILL_SPACING = fill_spacing_value

FILL_TYPE = GROUNDED | FLOATING ]

[GATE_TO_CONTACT_SMIN = value]

[GATE_TO_DIFFUSION_CAP { ... }]

[ILD_VS_WIDTH_AND_SPACING { ... }]

[IS_PLANAR]

[LAYER_TYPE = GATE | FIELD_POLY | DIFFUSION | TRENCH_CONTACT]

[MEASURED_FROM = dielectric_name | TOP_OF_CHIP]

[POLYNOMIAL_BASED_THICKNESS_VARIATION { ... }]

[RPSQ = rpsq_value

| RHO = rho_value

| RPSQ_VS_SI_WIDTH { ... }

| RPSQ_VS_WIDTH_AND_SPACING { ... }

| RHO_VS_SI_WIDTH_AND_THICKNESS { ... }

| RHO_VS_WIDTH_AND_SPACING { ... }]

[SIDE_TANGENT = value]

[THICKNESS_VS_DENSITY ... { ... }]

[THICKNESS_VS_WIDTH_AND_SPACING ... { ... }]

[TVF_ADJUSTMENT_TABLES { ... }]

}

Arguments

Argument Description

conductor_name Name of the conductor layer

Chapter 18: ITF Statements and Options

CONDUCTOR 18-18

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

WMIN = min_width Minimum width of a geometry on this layer

Units: microns

SMIN = min_spacing Minimum spacing between two geometries on this layer

Units: microns

THICKNESS = thick_value Thickness of this layer; cannot be less than 0.001 micron

Units: microns

BOTTOM_DIELECTRIC_THICKN

ESS = thickness

Thickness of the dielectric

Units: microns

BOTTOM_DIELECTRIC_ER =

permittivity

Relative permittivity of the dielectric

T0 = nominal_temp Nominal temperature for the layer

Units: degrees Celsius

Default: temperature specified by GLOBAL_TEMPERATURE

CRT1 = lin_coeff Layer-specific linear temperature coefficient

Default: 0

CRT2 = quad_coeff Layer-specific quadratic temperature coefficient

Default: 0

FILL_RATIO =

fill_ratio_value

Ratio of metal fill coverage

FILL_WIDTH =

fill_width_value

Average width of metal fill objects

Units: microns

FILL_SPACING =

fill_spacing_value

Average lateral spacing between signal nets and metal fill objects

Units: microns

ISPLANAR From this conductor and above, the layers do not drop because

DROP_FACTOR is specified for the lower layers

RPSQ = rpsq_value Resistance per square of the conducting layer

Units: ohms/square

Default: 0

Argument Description

Chapter 18: ITF Statements and Options

CONDUCTOR 18-19

Chapter 18: ITF Statements and Options

CONDUCTOR 18-19

StarRC User Guide and Command Reference Version F-2011.06

Description

The CONDUCTOR statement describes the properties of a conductor layer such as minimum

width, minimum spacing, thickness, resistivity, and process variation.

StarRC allows a maximum of 50 CONDUCTOR statements in the ITF file.

User-Defined Diffusion Resistance

To apply a user-defined, equation-based model for diffusion resistance extraction, set

USER_DEFINED_DIFFUSION_RES: YES in your star_cmd file and specify the

DIFFUSION_RES_GATE_TO_CONT_THRESHOLD and DIFFUSION_RES_BEND_THRESHOLD

arguments within a CONDUCTOR statement for a polysilicon gate layer. Figure 18-3 illustrates

the gate_cont_distance and gate_diff_bend_distance parameters.

Figure 18-3 Parameters for User-Defined Diffusion Resistance Thresholds

When you specify DIFFUSION_RES_GATE_TO_CONT_THRESHOLD, equation-based diffusion

resistance extraction is applied to any contact with a distance from the gate less than

gate_cont_distance. Standard mesh-based extraction is applied to any contact with a

distance from the gate greater than gate_cont_distance.

RHO = rho_value Bulk resistivity of the via or conductor layer.

Units: ohms-micron

Default: RPV x AREA

Argument Description

Chapter 18: ITF Statements and Options

CONDUCTOR 18-20

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Similarly, when you specify DIFFUSION_RES_BEND_THRESHOLD, equation-based diffusion

resistance extraction is applied to any contact with a distance from a diffusion bend less than

gate_diff_bend_distance. Standard mesh-based extraction is applied to any contact with

a distance from a diffusion bend greater than gate_cont_distance.

Example

The following example shows a simple CONDUCTOR statement for a metal layer.

Example 18-1 CONDUCTOR Statement for a Metal Layer

CONDUCTOR M1 { THICKNESS=0.8 WMIN=0.5 SMIN=0.45 RPSQ=0.041 }

The following example shows a CONDUCTOR statement with thresholds for equation-based

diffusion resistance.

Example 18-2 CONDUCTOR Statement With Thresholds for Equation-Based Diffusion

Resistance

CONDUCTOR POLY_GATE {

CRT1=0.0030 CRT2=0.0000 THICKNESS=0.10

GATE_TO_CONTACT_SMIN=0.04 WMIN=0.03 SMIN=0.04

RPSQ=13.00

DIFFUSION_RES_GATE_TO_CONT_THRESHOLD = 0.6

DIFFUSION_RES_BEND_THRESHOLD = 0.6

}

Chapter 18: ITF Statements and Options

CRT_VS_AREA 18-21

Chapter 18: ITF Statements and Options

CRT_VS_AREA 18-21

StarRC User Guide and Command Reference Version F-2011.06

CRT_VS_AREA

Specifies the temperature coefficients of resistance as a function of via area.

Syntax

CRT_VS_AREA {

(area_1, crt1_1, crt2_2)

(area_2, crt1_1, crt2_2)

...

(area_n, crt1_n, crt2_n)

}

Arguments

Argument Description

area_1 ... area_n Via areas specified in increasing order

Units: square microns

crt1_1 ... crt1_n Linear temperature coefficients for corresponding via sizes

crt2_1 ... crt2_n Quadratic temperature coefficients for corresponding via sizes

Description

Use a CRT_VS_AREA table within a VIA statement to specify the temperature coefficients of

resistance as function of via area. There is no limit to the number of entries you can specify.

You cannot specify CRT_VS_AREA together with CRT1 or CRT2 in the same VIA statement.

When the actual via size does not exactly equal any of the area entries in the CRT_VS_AREA

table, CRT1 and CRT2 are determined by the following methods:

• If the actual via size is less than the smallest area entry in the CRT_VS_AREA table, the

CRT values are set to the corresponding crt1 and crt2 entries of the smallest area

entry; no extrapolation is performed.

• If the actual via size falls between two area entries in the CRT_VS_AREA table, CRT1 and

CRT2 are calculated by linear interpolation.

• If the actual area is greater than the largest area entry in the CRT_VS_AREA table, the CRT

values are set to the corresponding crt1 and crt2 entries of the largest area entry; no

extrapolation is performed.

Note:

CRT and AREA values specified in a mapping file take precedence over the CRT_VS_AREA

values specified in an ITF file.

Chapter 18: ITF Statements and Options

CRT_VS_AREA 18-22

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Errors

The grdgenxo executable issues a warning message if

•AREA values in the table are not specified in increasing order. The grdgenxo executable

internally re-orders the table entries with increasing AREA values.

• The absolute value of CRT1 specified in the table is greater than 0.02.

• The value of CRT2 specified in the table is less than -0.002.

The grdgenxo executable errors out if

• You specify both the CRT_VS_AREA statement and the CRT statement in the same VIA

definition.

• You specify neither the nominal temperature for the via layer nor the global temperature.

• The CRT_VS_AREA table contains fewer than two rows. This same requirement applies to

the RPV_VS_AREA statement.

• The AREA values in the table are zero or negative.

• The CRT_VS_AREA table contains duplicate AREA values.

• You specify the -res_update option while adding or removing a CRT_VS_AREA table.

Example

CRT_VS_AREA {

(0.002025, 9.04E-04, 4.74E-07)

(0.005265, 1.18E-03, 8.02E-07)

}

See Also

•CRT1, CRT2, and T0

•VIA

Chapter 18: ITF Statements and Options

CRT_VS_SI_WIDTH 18-23

Chapter 18: ITF Statements and Options

CRT_VS_SI_WIDTH 18-23

StarRC User Guide and Command Reference Version F-2011.06

CRT_VS_SI_WIDTH

Specifies the CRT-based temperature derating for different conductor widths.

Syntax

CRT_VS_SI_WIDTH {

(siw_1, crt1_1, crt2_1)

(siw_2, crt1_2, crt2_2)

...

(siw_n, crt1_n, crt2_n)

}

Arguments

Argument Description

siw_1 ... siw_n Post-etch conductor widths

Units: microns

crt1_1 ... crt1_n Linear temperature coefficients for corresponding conductor

widths

crt2_1 ... crt2_n Quadratic temperature coefficients for corresponding conductor

widths

Description

You can use a CRT_VS_SI_WIDTH table within a CONDUCTOR statement to specify the CRT-

based temperature derating for different conductor widths. There is no limit to the number of

entries you can specify.

When the actual conductor width does not exactly equal any of the siw entries in the

CRT_VS_SI_WIDTH table, then CRT1 and CRT2 are determined by the following methods:

• If the actual conductor width is less than the smallest siw entry in the CRT_VS_SI_WIDTH

table, the CRT values are set to the corresponding crt1 and crt2 entries of the smallest

siw entry; no extrapolation is performed.

• If the actual conductor width falls between two siw entries in the CRT_VS_SI_WIDTH table,

CRT1 and CRT2 are calculated by linear interpolation.

• If the actual conductor width is greater than the largest siw entry in the

CRT_VS_SI_WIDTH table, the CRT values are set to the corresponding crt1 and crt2

entries of the largest siw entry; no extrapolation is performed.

Chapter 18: ITF Statements and Options

CRT_VS_SI_WIDTH 18-24

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

You can specify CRT_VS_SI_WIDTH only within CONDUCTOR statements, not VIA or CONTACT

statements.

If CRT_VS_SI_WIDTH is used with RPSQ_VS_SI_WIDTH, then the width index of

CRT_VS_SI_WIDTH should match that of RPSQ_VS_SI_WIDTH.

Example

CONDUCTOR MET1 {

THICKNESS=0.6 WMIN=0.34 SMIN=0.40

CRT_VS_SI_WIDTH {

(0.34, 0.001, 0.000)

(0.40, 0.001, 0.001)

(0.823, 0.002, 0.001)

(2.0, 0.003, 0.001)

}

See Also

•CONDUCTOR

•CRT1, CRT2, and T0

•RPSQ_VS_SI_WIDTH

Chapter 18: ITF Statements and Options

CRT1, CRT2, and T0 18-25

Chapter 18: ITF Statements and Options

CRT1, CRT2, and T0 18-25

StarRC User Guide and Command Reference Version F-2011.06

CRT1, CRT2, and T0

Defines parameters for temperature-dependent resistance models for CONDUCTOR and VIA

layers.

Syntax

CRT1 = lin_coeff

CRT2 = quad_coeff

T0 = nominal_temp

Arguments

Argument Description

CRT1 = lin_coeff Linear temperature coefficient for the layer. Specified on a per-

layer basis.

Default: 0

CRT2 = quad_coeff Quadratic temperature coefficient for the layer. Specified on a

per-layer basis.

Default: 0

T0 = nominal_temp Nominal temperature for the layer

Units: degrees Celsius

Default: temperature specified by GLOBAL_TEMPERATURE

Description

CRT1, CRT2, and T0 define temperature-dependent resistance models for conducting layers

and vias. The resistances are modeled similar to the way they are modeled in SPICE, by

using the following equation:

RR0CRT1TT0–()×CRT2 T T0–()

×1++[]×=

In this equation,

• R is the modeled resistance at the operating temperature T.

• R0 is the resistance value at the nominal temperature T0.

• CRT1 and CRT2 are the linear and quadratic temperature coefficients.

Chapter 18: ITF Statements and Options

CRT1, CRT2, and T0 18-26

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Note:

The modeled resistance R exactly equals the nominal resistance (R0) if T=T0, or if both

CRT1=0 and CRT2=0.

If either CRT1 or CRT2 is nonzero for a layer (VIAs included), then a nominal temperature

specification is required for that layer. A value for nominal temperature can be set globally

with the command GLOBAL_TEMPERATURE at the top of the ITF. If the temperature is set by

individual layer and globally, the layer nominal temperature overrides the global setting.

Note:

OPERATING_TEMPERATURE must also be set in the command file to use the derating

information in the nxtgrd. If the resistance of a layer is changed by the mapping file, and

if that layer has temperature derating in the ITF, specifying the OPERATING_TEMPERATURE

command uses the temperature derating coefficients for that layer from the ITF.

OPERATING_TEMPERATURE is an extraction option. You must use the -cleanX option to the

StarXtract command if it is changed. OPERATING_TEMPERATURE replaces the

NETLIST_TEMPERATURE command.

Example

TECHNOLOGY = Sample_tech

GLOBAL_TEMPERATURE = 31.0

DIELECTRIC IMD2 { THICKNESS=2.0 ER=3.9 }

CONDUCTOR metal2 {

CRT1=3.00e-3 CRT2=2.0e-7

THICKNESS = 0.6 SMIN=0.5 WMIN=0.5 RPSQ = 0.06

}

DIELECTRIC IMD1 { THICKNESS=1.9 ER=4.9 }

CONDUCTOR metal1 {

CRT1=3.50e-3 CRT2=2.5e-7

THICKNESS = 0.5 SMIN = 0.4 WMIN=0.4 RPSQ = 0.08

}

DIELECTRIC FOX { THICKNESS=1.0 ER=3.9 }

VIA via1 {

FROM=metal1 TO=metal2 AREA=1 RPV=1

CRT1=2.5e-3 CRT2=1e-6 T0=29

}

Chapter 18: ITF Statements and Options

DAMAGE_ER 18-27

Chapter 18: ITF Statements and Options

DAMAGE_ER 18-27

StarRC User Guide and Command Reference Version F-2011.06

DAMAGE_ER

Defines the equivalent permittivity of a damage layer.

Syntax

DAMAGE_ER = equivalent_permittivity

Arguments

Argument Description

equivalent_permittivity Equivalent permittivity

Description

Use the DAMAGE_ER statement to specify the equivalent permittivity of a damage layer.

Chapter 18: ITF Statements and Options

DAMAGE_THICKNESS 18-28

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

DAMAGE_THICKNESS

Defines the thickness of the damage on the surface of the conductor.

Syntax

DAMAGE_THICKNESS = thickness

Arguments

Argument Description

thickness Thickness of the damage on the surface of the conductor

Units: microns

Description

The DAMAGE_THICKNESS statement defines the thickness of the damage on the surface of

the conductor.

Chapter 18: ITF Statements and Options

DENSITY_BOX_WEIGHTING_FACTOR 18-29

Chapter 18: ITF Statements and Options

DENSITY_BOX_WEIGHTING_FACTOR 18-29

StarRC User Guide and Command Reference Version F-2011.06

DENSITY_BOX_WEIGHTING_FACTOR

Specifies a density box weighting factor.

Syntax

DENSITY_BOX_WEIGHTING_FACTOR {(S1 W1) (S2 W2) (S3 W3) (S4 W4) (S5 W5)}

Arguments

Argument Description

Sn The size of the density box. Up to five entries are allowed.

S1, S2, S3, S4 and S5 are integers that are within (0<S<500) S1

< S2 < S3 < S4 < S5. Density box is SxS.

Units: microns

Wn The weighting factor specified in a floating-point number. Must be

within the range (-10 < W < 10). If W is set to 0, then that pair (Sn

Wn) is ignored.

Description

This option is to be used with the THICKNESS_VS_DENSITY option when specifying a single

or multiple box method for effective density calculation.

If you do not specify a DENSITY_BOX_WEIGHTING_FACTOR option, then the default density

box size of 50 µm is used with the weighting factor of unity. The weighting factor is multiplied

with the density to arrive at the effective density. The default is

DENSITY_BOX_WEIGHTING_FACTOR {(50 1)}.

Example

CONDUCTOR metal3 {

SMIN= 0.35 WMIN=0.42 THICKNESS=0.53 RPSQ=0.061

THICKNESS_VS_DENSITY {(0.1 -0.1)(0.2 0.1)(0.3 0.15)(0.5 0.3)}

DENSITY_BOX_WEIGHTING_FACTOR

{ (10 1)(20 0.23)(30 0.29)(40 0.08)(50 0.12) }

}

See Also

•THICKNESS_VS_DENSITY

•DENSITY_BASED_THICKNESS

Chapter 18: ITF Statements and Options

DIELECTRIC 18-30

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

DIELECTRIC

Describes the properties of a dielectric layer.

Syntax

DIELECTRIC dielectric_name {

ER = value

THICKNESS = value

[MEASURED_FROM = layer_name | TOP_OF_CHIP

[SW_T = value] [TW_T = value]]

[ASSOCIATED_CONDUCTOR = conductor_name [IS_CONFORMAL]]

[DAMAGE_THICKNESS = value DAMAGE_ER = value]

}

Arguments

Argument Description

dielectric_name Name of the dielectric layer

Description

The DIELECTRIC statement describes a dielectric layer above or below a conductor layer.

Errors

The following error messages are issued when limitations for THICKNESS, TW_T, and SW_T

are not observed:

ERROR:(908) ITF**

ERROR: Too thin SW_T value of 0.001 is specified for layer local1;

0 < SW_T < 0.005 is not allowed

ERROR:(910) ITF**

ERROR: Too thin TW_T value of 0.001 is specified for layer local1;

0 < TW_T < 0.005 is not allowed

ERROR:(906) ITF**

Too thin THICKNESS value of 0.0007 is specified for layer thin;

0<THICKNESS<0.001 is not allowed (THICKNESS=0 is allowed for conformal

dielectrics)

Example

The following example describes a dielectric layer with a thickness of 0.3 µm and a relative

permittivity of 3.9.

DIELECTRIC FOX { THICKNESS=0.3 ER=3.9 }

Chapter 18: ITF Statements and Options

DROP_FACTOR 18-31

Chapter 18: ITF Statements and Options

DROP_FACTOR 18-31

StarRC User Guide and Command Reference Version F-2011.06

DROP_FACTOR

Syntax

DROP_FACTOR = value

Arguments

Argument Description

value Absolute height which describes the nonplanarity of conductor

layers by specifying the amount that upper conductors fall in base

height whenever polygons of the specified conductor are not

present in a given layout area.

Units: microns

Default: 0

Description

This ITF CONDUCTOR option represents the decrease in base height of all conductors above,

when the bottom conductor is not present in the given layout area.

When a part of a polygon drops by the DROP_FACTOR specified for the conductor below, there

is a lateral gap between the dropped polygon and the polygon as shown in Figure 18-4. This

lateral gap is fixed at 0.5 micron.

You can specify up to four conductors with a DROP_FACTOR command.

Figure 18-4 DROP_FACTOR

0.5 µm

0.2 µm

SUBSTRATE

Chapter 18: ITF Statements and Options

DROP_FACTOR 18-32

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Example

DROP_FACTOR = 0.2

See Also

•CONDUCTOR

Chapter 18: ITF Statements and Options

DROP_FACTOR_LATERAL_SPACING 18-33

Chapter 18: ITF Statements and Options

DROP_FACTOR_LATERAL_SPACING 18-33

StarRC User Guide and Command Reference Version F-2011.06

DROP_FACTOR_LATERAL_SPACING

Specifies a constant lateral spacing value.

Syntax

DROP_FACTOR_LATERAL_SPACING = value

Arguments

Argument Description

value Constant value between 0.5 and 4.0

Units: microns

Default: 0.5

Description

The DROP_FACTOR_LATERAL_SPACING statement specifies a constant lateral spacing value

for all conductors.

It is preferred that you specify the DROP_FACTOR_LATERAL_SPACING statement after the

TECHNOLOGY statement.

Example

This example specifies a lateral spacing of 0.6 µm for all conductors when dropped.

TECHNOLOGY = sample_tech

DROP_FACTOR_LATERAL_SPACING = 0.6

Chapter 18: ITF Statements and Options

ER 18-34

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Specifies the relative permittivity of a dielectric.

Syntax

ER = permittivity

Arguments

Argument Description

permittivity Relative permittivity of a dielectric layer

Description

The ER statement specifies the relative permittivity, or dielectric constant, of a dielectric

layer.

The ER statement must be specified within the DIELECTRIC statement.

Example

DIELECTRIC D2 {THICKNESS = 1.2 ER = 3.9}

See Also

•DIELECTRIC

Chapter 18: ITF Statements and Options

ETCH 18-35

Chapter 18: ITF Statements and Options

ETCH 18-35

StarRC User Guide and Command Reference Version F-2011.06

ETCH

Specifies the absolute width adjustment for layer etch effects.

Syntax

ETCH = width_adjustment

Arguments

Argument Description

width_adjustment Absolute width adjustment for layer etch effects

Units: microns

Description

ETCH is calculated before resistance is calculated (for example, RPSQ). A positive value

denotes conductor shrink; a negative value denotes conductor growth. The adjusted width

is equal to the drawn width minus twice the etch value.

Specify the ETCH statement within a CONDUCTOR statement. The ETCH value is applied to

each edge of the conductor.

Example

CONDUCTOR M1 {

THICKNESS=0.6 WMIN=0.3 SMIN=0.3 RPSQ=0.05 ETCH=0.05

}

See Also

•CAPACITIVE_ONLY_ETCH

•RESISTIVE_ONLY_ETCH

Chapter 18: ITF Statements and Options

ETCH_VS_CONTACT_AND_GATE_SPACINGS 18-36

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

ETCH_VS_CONTACT_AND_GATE_SPACINGS

Specifies a contact bias as a function of contact width and spacing between the gate and

contact.

Syntax

ETCH_VS_CONTACT_AND_GATE_SPACINGS CAPACITIVE_ONLY {

CONTACT_TO_CONTACT_SPACING { c1 c2 c3 ... }

GATE_TO_CONTACT_SPACING { s1 s2 s3 ... }

VALUES { v(c1,s1) v(c2,s1) ...

v(c1,s2) v(c2,s2) ...

...

}

ETCH_VS_CONTACT_AND_GATE_SPACINGS CAPACITIVE_ONLY {

NUMBER_OF_TABLES = num_of_tables

name_of_table1 {

CONTACT_TO_CONTACT_SPACING { c1 c2 c3 ... }

GATE_TO_CONTACT_SPACING { s1 s2 s3 ... }

VALUES { v(c1,s1) v(c2,s1) ...

v(c1,s2) v(c2,s2) ...

...

}

name_of_table2 {

CONTACT_TO_CONTACT_SPACING { c1 c2 c3 ... }

GATE_TO_CONTACT_SPACING { s1 s2 s3 ... }

VALUES { v(c1,s1) v(c2,s1) ...

v(c1,s2) v(c2,s2) ...

...

}

...

}

Description

The actual size of contacts in silicon may be different than the sizes drawn in layout. To

account for this difference during parasitic extraction, the VIA statement allows a contact

bias to be specified as a function of contact width and gate-to-contact spacing.

A positive etch value models a shrinking contact, and a negative etch value indicates that

the contact size is growing.

The resistance is assumed to be measured and therefore post-etch as specified in the RPV

statement for a via definition. Hence, the contact etch only affects the estimated

capacitance.

Chapter 18: ITF Statements and Options

ETCH_VS_CONTACT_AND_GATE_SPACINGS 18-37

Chapter 18: ITF Statements and Options

ETCH_VS_CONTACT_AND_GATE_SPACINGS 18-37

StarRC User Guide and Command Reference Version F-2011.06

All values for CONTACT_TO_CONTACT_SPACING, GATE_TO_CONTACT_SPACING, and VALUES

must be specified in microns.

Errors

The following error and warning messages can occur if the noted condition exists.

•grdgenxo errors and warnings

• If NUMBER_OF_TABLES is not given, only the old format is accepted in grdgenxo. If

there are multiple tables or a table with a table_name, an error occurs.

• If the number of tables are different from the specified NUMBER_OF_TABLES, grdgenxo

stops and issues an error message.

• If the old ITF format (no NUMBER_OF_TABLES, no table name) and a new format exists

at the same time in ITF with each format used for each of contact-etch and Cf tables

grdgenxo process stops and issues an error message.

• StarXtract Layers errors and warnings:

• If the table_name option in a mapping file does not match with any <name_of_table>

option in the ITF, StarXtract issues the following warning:

“Warning: TABLE_NAME table_name is provided for layer_name layer in Mapping file,

but is not found in ITF. TABLE_NAME for this layer will be ignored.”

• If a table_name is given for a non gate level layer in mapping file, StarXtract issues the

following warning:

“Warning: TABLE_NAME table_name is specified for non-gate-level layer layer_name

in the mapping file. TABLE_NAME for this layer will be ignored.”

• If contact-etch and/or gate-diffusion cap tables with the table name in the new format

present in ITF but a gate-level layer in mapping file does not have the TABLE_NAME

option, StarXtract issues the following warning:

“Warning: No TABLE_NAME is given for layer_name layer in the mapping file, while

there exist contact etch and/or gate-diffusion cap tables in ITF.”

Example

The following VIA definition does not have a contact bias:

VIA DiffCont {

FROM=diff TO=metal1 AREA=0.003 RPV=15

CRT1=6.56e-04 CRT2=-5.643e-0

}

Chapter 18: ITF Statements and Options

ETCH_VS_CONTACT_AND_GATE_SPACINGS 18-38

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

The previous VIA definition can be extended to include a contact bias 2-D table, or etch

table, as a function of contact-to-contact and gate-to-contact spacings. For example,

VIA DiffCont {

FROM=diff TO=metal1 AREA=0.003 RPV=15

CRT1=6.56e-04 CRT2=-5.643e-0

ETCH_VS_CONTACT_AND_GATE_SPACINGS CAPACITIVE_ONLY {

CONTACT_TO_CONTACT_SPACINGS {0.1 0.2 0.3}

GATE_TO_CONTACT_SPACINGS {0.05 0.1 0.15}

VALUES {0.005 0.006 0.007

0.004 0.005 0.006

0.003 0.004 0.005}

}

You can specify multiple table definitions in the ETCH_VS_CONTACT_AND_GATE_SPACINGS

option. Each table should have a name_of_table, which associates with a gate database

layer through a mapping file. You must use the same name for a contact etch table and a

gate diffusion table for one kind of device. A keyword can, however, associate with only one

contact-etch table or gate-diffusion capacitance table.

The following is an example of an ITF with multiple contact etch tables defined:

VIA diffCont {

FROM=diff TO=metal1 AREA=0.0036 RPV=55

CRT1=9.56e-04 CRT2=-3.68e-07

ETCH_VS_CONTACT_AND_GATE_SPACINGS CAPACITIVE_ONLY {

NUMBER_OF_TABLES=2

NMOS {

CONTACT_TO_CONTACT_SPACINGS {0.08 0.12}

GATE_TO_CONTACT_SPACINGS {0.04 0.08}

VALUES {0.008 0.009 0.003 0.005}

}

PMOS {

CONTACT_TO_CONTACT_SPACINGS {0.08 0.12}

GATE_TO_CONTACT_SPACINGS {0.04}

VALUES {0.004 0.002}

}

Mapping File Syntax

Use the following syntax for the mapping file:

conducting_layers gate_database_layer gate_grd_layer [table_name=keyword]

If the table_name keyword is defined for a gate, StarRC finds and uses the contact etch

table and gate-diffusion capacitance table of the same name in the ITF.

Chapter 18: ITF Statements and Options

ETCH_VS_CONTACT_AND_GATE_SPACINGS 18-39

Chapter 18: ITF Statements and Options

ETCH_VS_CONTACT_AND_GATE_SPACINGS 18-39

StarRC User Guide and Command Reference Version F-2011.06

By default, if a table_name is not defined for a gate database layer, no contact etch or gate-

diffusion capacitance calculation is applied to the device with the gate of that data layer. For

those devices, the contact etch is zero, and the gate-diffusion capacitance is the extracted

value if the IGNORE_CAP is set to extract gate-diffusion coupling.

Mapping File for Multiple Contact Etch Table Support

When multiple contact etch tables are defined in the ITF, the device gate layer that maps to

the corresponding table name must be specified in the StarRC mapping file. Use the

following mapping file syntax to look up the appropriate gate-to-diffusion table:

conducting_layers

gate_database_layer1 gate_grd_layer1 [table_name=name1]

gate_database_layer2 gate_grd_layer2 [table_name=name2]

...

If table_name is defined for a gate, StarRC finds and uses the corresponding gate-diffusion

capacitance table with same NAME in ITF.

If table_name is not defined for a gate database layer, no gate-diffusion capacitance

calculation is done for the device with the gate of that database layer.

The following example shows a mapping file to lookup the corresponding gate-to-diffusion

capacitance tables based on the tables specified in the previous example:

conducting_layers

ngate gpoly table_name=NMOS

pgate gpoly table_name=PMOS

tngate gpoly

tpgate gpoly

With this mapping file definition, devices with ngate as the gate polysilicon use the NMOS

contact etch table, and devices with pgate as the gate polysilicon use the PMOS table in the

ITF. No gate-to-contact etch is applied to the devices with tngate or tpgate gates.

Backward Compatibility

If an nxtgrd file from a previous version of StarRC is given as an input, StarRC behaves as

it did in the previous version. The older format supports a single table for each contact-etch

and Cf specification and does not have the table_name attribute in the ITF.

StarRC treats the given table as a default table for all gate layers as it did in older versions.

Even when the mapping file has table_name attributes for gate layers,

• StarRC ignores the table_name given in mapping file because there is no match in the

nxtgrd file.

• StarRC uses the table with no name in the nxtgrd file for all cases.

Chapter 18: ITF Statements and Options

ETCH_VS_CONTACT_AND_GATE_SPACINGS 18-40

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

See Also

•CAPACITIVE_ONLY_ETCH

•GATE_TO_DIFFUSION_CAP

Chapter 18: ITF Statements and Options

ETCH_VS_WIDTH_AND_LENGTH 18-41

Chapter 18: ITF Statements and Options

ETCH_VS_WIDTH_AND_LENGTH 18-41

StarRC User Guide and Command Reference Version F-2011.06

ETCH_VS_WIDTH_AND_LENGTH

Specifies different via etch values for the length and width sides of nonsquare vias.

Syntax

ETCH_VS_WIDTH_AND_LENGTH CAPACITIVE_ONLY {

LENGTHS { l1 l2 ... lm }

WIDTHS { w1 w2 ... wn }

VALUES { (v_l1, v_w1) (v_l2, v_w1) ... (v_lm, v_w1)

(v_l1, v_w2) (v_l2, v_w2) ... (v_lm, v_w2)

...

(v_l1, v_wn) (v_l2, v_wn) ... (v_lm, v_wn)

}

Arguments

Argument Description

CAPACITIVE_ONLY Applies etch effect to capacitance only

l1 l2 ... lm Via lengths specified in ascending order

Units: microns

w1 w2 ... wn Via widths specified in ascending order

Units: microns

(v_l1, v_wn)

... (v_lm, v_wn)

Etch values of corresponding via lengths and widths

Units: microns

Description

Specify the ETCH_VS_WIDTH_AND_LENGTH option within a VIA statement to apply different

via etch values to the length and width sides of nonsquare vias.

The specified length and width values are used as indexes for the two-dimensional table of

etch values. Each combination of length lm and width wn has a corresponding pair of etch

values (v_lm, v_wn), where v_lm represents the etch value for the length, and v_wn

represents the etch value for the width.

Note the following restrictions when using an ETCH_VS_WIDTH_AND_LENGTH table:

• When the width is greater than the length, the corresponding etch values are n.

• Do not use the ETCH_VS_WIDTH_AND_LENGTH option to describe nonsquare diffusion

contacts.

Chapter 18: ITF Statements and Options

ETCH_VS_WIDTH_AND_LENGTH 18-42

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

• Do not specify the ETCH_VS_WIDTH_AND_LENGTH option together with the

ETCH_VS_CONTACT_AND_GATE_SPACINGS option in the same VIA statement.

• You can use ETCH_VS_WIDTH_AND_LENGTH together with the contstant etch

CAPACITIVE_ONLY_ETCH option.

Errors

If the ETCH_VS_WIDTH_AND_LENGTH option is specified along with the constant etch

CAPACITIVE_ONLY_ETCH option in a VIA definition, the two etch values are added together

in xTractor to apply the via etch.

The grdgenxo executable issues a warning message if

• A width and length combination results in an aspect ratio greater than one. The grdgenxo

executable then forces their corresponding etch values to be zero.

• A width and length combination results in an aspect ratio equal to one, but their

corresponding etch values are not the same.

The grdgenxo executable errors out if

• The CAPACITIVE_ONLY keyword is not specified.

• The ETCH_VS_WIDTH_AND_LENGTH statement and the

ETCH_VS_CONTACT_AND_GATE_SPACINGS statement both exist in the same VIA definition.

•VL ≥ 0.5 x LENGTH or VW ≥ 0.5 x WIDTH.

Note:

If you specify both ETCH_VS_WIDTH_AND_LENGTH and CAPACITIVE_ONLY_ETCH within

the same VIA definition, then the combined value of the two etches is subject to the

preceding restriction.

Example

In the following example, the etch entry for length=0.045 and width=0.115 is set to

(VL,VW)=(0.000, 0.000) because the parameter combination is invalid when the length is

less than the width.

VIA via1{ FROM=M8 TO=M9 AREA=0.005 RPV=5

ETCH_VS_WIDTH_AND_LENGTH CAPACITIVE_ONLY {

LENGTHS { 0.045 0.115 0.200 }

WIDTHS { 0.045 0.115 }

VALUES { (0.015, 0.015) (0.002, 0.002) (0.003 0.001)

(0.000, 0.000) (0.015, 0.015) (0.005 0.002)

}

Chapter 18: ITF Statements and Options

ETCH_VS_WIDTH_AND_LENGTH 18-43

Chapter 18: ITF Statements and Options

ETCH_VS_WIDTH_AND_LENGTH 18-43

StarRC User Guide and Command Reference Version F-2011.06

See Also

•ETCH_VS_CONTACT_AND_GATE_SPACINGS

•VIA

Chapter 18: ITF Statements and Options

ETCH_VS_WIDTH_AND_SPACING 18-44

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

ETCH_VS_WIDTH_AND_SPACING

Specifies different via etch values for different via sizes and spacings.

Syntax

ETCH_VS_WIDTH_AND_SPACING

[RESISTIVE_ONLY | CAPACITIVE_ONLY | ETCH_FROM_TOP] {

SPACINGS { s1 s2 ... sm }

WIDTHS { w1 w1 ... wn }

VALUES { v_s1_w1 v_s2_w1 ... v_sm_w1

v_s1_w2 v_s2_w2 ... v_sm_w2

...

v_s1_wn v_s2_wn ... v_sm_wn

}

Arguments

Argument Description

RESISTIVE_ONLY Applies etch effect to resistance only

CAPACITIVE_ONLY Applies etch effect to capacitance only

ETCH_FROM_TOP Specifies a trapezoidal cross section using the spacing and

width-dependent top etch feature of CONDUCTOR

SPACINGS {...} Spacing values specified in ascending order

Units: microns

WIDTHS {...} Width values

Units: microns

VALUES {...} Etch values

Units: microns

Description

This option helps you to consider the actual fabricated patterns in the extraction of parasitic

components. This is important because OPC (Optical Proximity Correction) cannot fix all

proximity effects and the actual patterns might be different from the drawn mask patterns.

You specify this option within a CONDUCTOR statement.

Chapter 18: ITF Statements and Options

ETCH_VS_WIDTH_AND_SPACING 18-45

Chapter 18: ITF Statements and Options

ETCH_VS_WIDTH_AND_SPACING 18-45

StarRC User Guide and Command Reference Version F-2011.06

To more accurately model technologies with multiple etch processes, multiple

ETCH_VS_WIDTH_AND_SPACING tables can be specified in the same order as the

corresponding etch processes. When multiple ETCH_VS_WIDTH_AND_SPACING tables are

present, the RPSQ_VS_WIDTH_AND_SPACING option, RHO_VS_WIDTH_AND_SPACING option,

and BOTTOM_THICKNESS_VS_SI_WIDTH option are not allowed for that layer.

You must specify all three tables in the syntax definition: SPACINGS, WIDTHS, and VALUES.

You can list the tables in any order. All values (sn, wn) must be specified in microns; positive

etch values represent shrink and negative etch values represent an increase in width.

You can apply the ETCH_VS_WIDTH_AND_SPACING statement to both capacitance and

resistance. You can use the RESISTIVE_ONLY and CAPACITIVE_ONLY keywords within the

same conductor syntax, but you cannot use them when using

ETCH_VS_WIDTH_AND_SPACING independently. RESISTIVE_ONLY and CAPACITIVE_ONLY

can each be specified only once within any given CONDUCTOR statement.

The ETCH_FROM_TOP keyword specifies a trapezoidal cross section using the spacing and

width-dependent top etch feature of CONDUCTOR. The amount of etch is edge-based so the

sides of the trapezoidal cross section can have different angles. For example, in Figure 18-5,

the left side of the conductor could have an angular shift of 23 degrees and the right side

could have a shift of 14 degrees. As with the SIDE_TANGENT option, the center width is

unaffected by these adjustments.

Chapter 18: ITF Statements and Options

ETCH_VS_WIDTH_AND_SPACING 18-46

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Figure 18-5 Effect of the ETCH_FROM_TOP Keyword

W_center W_center

Before After

ETCH_FROM_TOP = -0.2

W_center

Negative value of ETCH_FROM_TOP

W_center

Positive value of ETCH_FROM_TOP

If you specify both the SIDE_TANGENT statement and the ETCH_FROM_TOP keyword for these

techniques, the top etch value takes precedence.

Example

Example 18-3 Example of a single ETCH_VS_WIDTH_AND_SPACING table

CONDUCTOR metal2 {

THICKNESS=0.65 WMIN=0.65 SMIN=0.50 RPSQ=0.62 ETCH=0.05

ETCH_VS_WIDTH_AND_SPACING RESISTIVE_ONLY {

SPACINGS { 0.5 0.67 0.8 }

WIDTHS { 0.65 0.9 }

VALUES { 0.1 0.05 -0.05

0.15 0.10 -0.10 }

}

Chapter 18: ITF Statements and Options

ETCH_VS_WIDTH_AND_SPACING 18-47

Chapter 18: ITF Statements and Options

ETCH_VS_WIDTH_AND_SPACING 18-47

StarRC User Guide and Command Reference Version F-2011.06

Example 18-4 Example using ETCH_FROM_TOP

CONDUCTOR metal5 {

THICKNESS=1.2 WMIN=0.3 SMIN=0.3 RPSQ = 0.62

ETCH_VS_WIDTH_AND_SPACING ETCH_FROM_TOP {

SPACINGS { 0.3 0.85 1.4 }

WIDTHS { 0.3 0.75 1.4 }

VALUES {-0.1 0.0 0.1

-0.1 0.0 0.1

-0.1 0.0 0.1 }

}

Example 18-5 Example of multiple ETCH_VS_WIDTH_AND_SPACING tables

CONDUCTOR M2 {

THICKNESS=0.132 WMIN=0.050 SMIN=0.050 SIDE_TANGENT=0.06992

ETCH_VS_WIDTH_AND_SPACING {

*the first EVWS table (round 1, pre-ADI table)

SPACINGS { 0.050 0.100 }

WIDTHS { 0.050 1.0 }

VALUES {-0.0027 0.0034

0.0003 0.0052 }

}

ETCH_VS_WIDTH_AND_SPACING {

*the second EVWS table (round2, API table)

SPACINGS { 0.045 0.150 }

WIDTHS { 0.045 2.0 }

VALUES {-0.002 0.0014

0.004 -0.003 }

}

See Also

•CAPACITIVE_ONLY_ETCH

•ETCH

•RESISTIVE_ONLY_ETCH

•RPSQ_VS_SI_WIDTH

•RPSQ_VS_WIDTH_AND_SPACING

•SIDE_TANGENT

Chapter 18: ITF Statements and Options

FILL_RATIO 18-48

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

FILL_RATIO

Specifies the ratio of metal fill coverage for a specified conductor.

Syntax

FILL_RATIO = ratio

Arguments

Argument Description

ratio Ratio of metal fill for a given layer

Description

The FILL_RATIO statement specifies the ratio of metal fill coverage for a specified

conductor. For example, if the density of the fill is 50 percent, specify FILL_RATIO = 0.5.

You must specify FILL_RATIO when you specify the FILL_SPACING and FILL_WIDTH

options.

Example

CONDUCTOR m1 {

THICKNESS=0.6 WMIN=0.3 SMIN=0.3

FILL_RATIO = 0.4 FILL_SPACING = 1.0 FILL_WIDTH = 2.0

}

See Also

•FILL_SPACING

•FILL_TYPE

•FILL_WIDTH

Chapter 18: ITF Statements and Options

FILL_SPACING 18-49

Chapter 18: ITF Statements and Options

FILL_SPACING 18-49

StarRC User Guide and Command Reference Version F-2011.06

FILL_SPACING

Specifies the average lateral space separating signal nets and metal fill objects in microns.

Syntax

FILL_SPACING = float

Arguments

Argument Description

float The average lateral spacing

Units: microns

Description

The FILL_SPACING statement specifies the average lateral space separating signal nets

and metal fill objects in microns. It is required if FILL_RATIO is specified.

Example

CONDUCTOR m1 {

THICKNESS=0.6 WMIN=0.3 SMIN=0.3

FILL_RATIO = 0.4 FILL_SPACING = 1.0 FILL_WIDTH = 2.0

}

See Also

•FILL_RATIO

•FILL_TYPE

•FILL_WIDTH

Chapter 18: ITF Statements and Options

FILL_TYPE 18-50

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

FILL_TYPE

Specifies grounded or floating processing of lateral metal fill emulation.

Syntax

FILL_TYPE = GROUNDED | FLOATING

Arguments

Argument Description

GROUNDED (default) Treats lateral metal fill patterns defined by FILL_WIDTH and

FILL_SPACING as if they are tied to ground net. This is the same

as the existing metal fill emulation in grdgenxo.

FLOATING Treats lateral metal fill patterns defined by FILL_WIDTH and

FILL_SPACING as if they are floating.

Description

FILL_TYPE provides for floating as well as grounded processing of lateral metal fill emulation

as defined by FILL_WIDTH and FILL_SPACING.

In the StarRC tool, real metal fill handling, both floating and grounded metal fill patterns, can

be extracted. However, the grdgenxo metal fill emulation has supported only grounded

handling for the lateral metal fills. The floating and grounded metal fill patterns is required

(especially during the design cycle) because there are no metal fill patterns in the layout until

the place and route has been fully completed. With this ITF command enhancement, you

can specify whether each layer’s metal fill emulation is treated as floating or grounded.

Example

CONDUCTOR m1 {

THICKNESS=0.6 WMIN=0.3 SMIN=0.3 FILL_RATIO = 0.4

FILL_SPACING = 1.0 FILL_WIDTH = 2.0 FILL_TYPE=FLOATING

}

See Also

•FILL_WIDTH

Chapter 18: ITF Statements and Options

FILL_WIDTH 18-51

Chapter 18: ITF Statements and Options

FILL_WIDTH 18-51

StarRC User Guide and Command Reference Version F-2011.06

FILL_WIDTH

Specifies the average size of metal fill objects.

Syntax

FILL_WIDTH = value

Arguments

Argument Description

value Average width of metal fill objects

Units: microns

Description

The FILL_WIDTH statement specifies the average size of metal fill objects, in microns.

FILL_WIDTH is required if FILL_SPACING or FILL_RATIO is specified.

Example

CONDUCTOR m1 {

THICKNESS=0.6 WMIN=0.3 SMIN=0.3

FILL_RATIO = 0.4 FILL_SPACING = 1.0 FILL_WIDTH = 2.0

}

See Also

•FILL_TYPE

Chapter 18: ITF Statements and Options

FROM 18-52

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

FROM

Specifies a conductor layer connected by a via.

Syntax

FROM = layer

Arguments

Argument Description

layer Conductor layer connected by the via

Description

The FROM statement specifies the upper or lower layer (which must be a defined CONDUCTOR

layer) connected by the via. Specify this option within a VIA statement.

Example

VIA sub_tie {

FROM = SUBSTRATE

TO = M1

AREA = 0.25

RPV = 5

}

See Also

•TO

•VIA

Chapter 18: ITF Statements and Options

GATE_TO_CONTACT_SMIN 18-53

Chapter 18: ITF Statements and Options

GATE_TO_CONTACT_SMIN 18-53

StarRC User Guide and Command Reference Version F-2011.06

GATE_TO_CONTACT_SMIN

Specifies the minimum spacing value between the polysilicon gate and the METAL1-

diffusion contact layer.

Syntax

GATE_TO_CONTACT_SMIN = float

Arguments

Argument Description

float Minimum spacing value between the polysilicon gate layer and

the METAL1 diffusion contact layer. The default is specified by the

SMIN statement.

Description

The GATE_TO_CONTACT_SMIN statement specifies the minimum spacing value between the

polysilicon gate and the METAL1-diffusion contact layer as shown in Figure 18-6. This

parameter is intended for use with ITF used with the StarRC EXTRACT_VIA_CAPS command,

and is specified in addition to SMIN for the polysilicon conductor. Because gate-to-contact

spacing is typically less than the SMIN value for polysilicon, specifying

GATE_TO_CONTACT_SMIN along with SMIN enables grdgenxo to account for both spacings to

maximize accuracy for EXTRACT_VIA_CAPS flows.

GATE_TO_CONTACT_SMIN is specified within a CONDUCTOR statement.

Figure 18-6 Derivation of SMIN and GATE_TO_CONTACT_SMIN

NSD

GATE

NSD

POLY

SMIN

GATE_TO_CONTACT_SMIN

Chapter 18: ITF Statements and Options

GATE_TO_CONTACT_SMIN 18-54

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Example

CONDUCTOR poly {

THICKNESS=1.00 WMIN=0.13 SMIN=0.15

RPSQ=0.015 GATE_TO_CONTACT_SMIN=0.08

}

Chapter 18: ITF Statements and Options

GATE_TO_DIFFUSION_CAP 18-55

Chapter 18: ITF Statements and Options

GATE_TO_DIFFUSION_CAP 18-55

StarRC User Guide and Command Reference Version F-2011.06

GATE_TO_DIFFUSION_CAP

Models the gate-to-diffusion capacitance within a CONDUCTOR statement.

Syntax

GATE_TO_DIFFUSION_CAP {

NUMBER_OF_TABLES = num_of_tables

model_name1{

CONTACT_TO_CONTACT_SPACINGS {c1 c2 c3 ...}

GATE_TO_CONTACT_SPACINGS {s1 s2 s3 ...}

CAPS_PER_MICRON { v(c1,s1) v(c2,s1)...

v(c1,s2) v(c2,s2)... }

}

model_name2{

CONTACT_TO_CONTACT_SPACINGS {c1 c2 c3 ...}

GATE_TO_CONTACT_SPACINGS {s1 s2 s3 ...}

CAPS_PER_MICRON { v(c1,s1) v(c2,s1)...

v(c1,s2) v(c2,s2)... }

}

...

}

Arguments

Argument Description

num_of_tables Number of tables

model_name Model name

c1 c2 c3 ... Nearest contact-to-contact spacing

Units: microns

s1 s2 s3 ... Gate-to-contact spacings

Units: microns

v(c1,s1) v(c2,s1)... Capacitance per micron

Units: femtofarads per micron

Description

StarRC can extract the gate-to-diffusion capacitance component when the

IGNORE_CAPACITANCE: ALL setting is specified. The gate-to-diffusion intra-device

capacitance is of interest for parasitic extraction tools because of the strong layout

dependency of this capacitance component. The gate-to-contact capacitance is extracted

using the EXTRACT_VIA_CAPS: YES command in the StarRC command file.

Chapter 18: ITF Statements and Options

GATE_TO_DIFFUSION_CAP 18-56

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

To retain the gate-to-diffusion (Cf) coupling component when IGNORE_CAPACITANCE: ALL is

specified during a StarRC parasitic extraction, a command must be specified to include this

capacitance in the netlist.

Foundries responsible for creating a tight link between simulation SPICE models and the

parasitic netlist have requested the ability to provide a direct capacitance table plug-in to

extract gate to diffusion capacitance. Foundries choose to use a direct capacitance table

input rather than having StarRC extract the gate-to-diffusion capacitance based on pre-

characterized models (nxtgrd) to preserve proprietary information regarding complex

process effects around the device gate polysilicon. Another advantage of using the table is

you can use field solvers to characterize this very critical and small capacitance component.

The capacitance table is included as part of the gate polysilicon definition in the ITF file. The

two layout dependent parameters used for the Cf value in the table are:

•CONTACT_TO_CONTACT_SPACINGS

•GATE_TO_CONTACT_SPACINGS

Note:

A contact etch table and gate-diffusion cap table cannot be individually selected for a gate

layer or for a device. They are always selected as a set. If you need another combination

of two tables for a specific type of device, they can be defined in a table set with a new

keyword in ITF and a new database layer for the corresponding gate in the mapping file.

Example

The following example shows a gate-to-diffusion capacitance table specified within the gate-

polysilicon definition:

GATE_TO_DIFFUSION_CAP {

CONTACT_TO_CONTACT_SPACINGS { c1 c2 c3 ... c_m }

GATE_TO_CONTACT_SPACINGS { s1 s2 s3 ... s_n }

CAPS_PER_MICRON {

v(c1,s1) v(c2,s1) ... v(c_m,s1)

v(c1,s2) v(c2,s2) ... v(c_m,s2)

...

v(c1,s_n) v(c2,s_n) ... v(c_m,s_n)

}

In the case where contacts do not exist, as for shared source and drain regions, the largest

spacing value is taken from the Cf table that you specified.

Chapter 18: ITF Statements and Options

GATE_TO_DIFFUSION_CAP 18-57

Chapter 18: ITF Statements and Options

GATE_TO_DIFFUSION_CAP 18-57

StarRC User Guide and Command Reference Version F-2011.06

Device Dependent Gate-to-Diffusion Capacitance Table

You can specify a Cf table based on device type. Example 18-6 shows multiple gate-to-

diffusion capacitance tables defined in the ITF, one for an n-type and another for a p-type

device. Note that the number of tables and the table name must be specified when multiple

gate-to-diffusion tables are specified in the ITF.

A contact etch table and a gate-diffusion capacitance table for the same type of device

should have the same table name.

Example 18-6 Device-Dependent Gate-to-Diffusion Capacitance Table

CONDUCTOR gpoly {

THICKNESS= 0.080000 WMIN= 0.040 SMIN= 0.100 RPSQ=12.000

GATE_TO_CONTACT_SMIN=0.040 CRT1=1.924e-03 CRT2=-8.751e-07

GATE_TO_DIFFUSION_CAP {

NUMBER_OF_TABLES=2

NMOS{

CONTACT_TO_CONTACT_SPACINGS {0.08 0.12}

GATE_TO_CONTACT_SPACINGS {0.04 0.08}

CAPS_PER_MICRON {0.062 0.088 0.080 0.096}

}

PMOS {

CONTACT_TO_CONTACT_SPACINGS {0.08 0.12}

GATE_TO_CONTACT_SPACINGS {0.04 0.08}

GAPS_PER_MICRON {0.088 0.1200.108 0.128}

}

See Also

•CAPACITIVE_ONLY_ETCH

•ETCH_VS_CONTACT_AND_GATE_SPACINGS

•IGNORE_CAP: ALL RETAIN_GATE_TO_DIFFUSION_COUPLING

Chapter 18: ITF Statements and Options

GLOBAL_TEMPERATURE 18-58

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

GLOBAL_TEMPERATURE

Specifies the default nominal global temperature for the layers.

Syntax

GLOBAL_TEMPERATURE = temp_value

Arguments

Argument Description

temp_value Global temperature

Units: degrees Celsius

Default: 25

Description

The GLOBAL_TEMPERATURE statement is optional. If the GLOBAL_TEMPERATURE statement is

not specified, then the nominal global temperature defaults to 25 degrees Celsius.

The nominal layer temperature overrides the global temperature when both are specified.

Example

TECHNOLOGY = Sample_tech

GLOBAL_TEMPERATURE = 31.0

...

Chapter 18: ITF Statements and Options

HALF_NODE_SCALE_FACTOR 18-59

Chapter 18: ITF Statements and Options

HALF_NODE_SCALE_FACTOR 18-59

StarRC User Guide and Command Reference Version F-2011.06

HALF_NODE_SCALE_FACTOR

Shrinks the design database before extraction begins.

Syntax

HALF_NODE_SCALE_FACTOR = scale_factor

Arguments

Argument Description

scale_factor Scale factor

Default:1.0

Description

The HALF_NODE_SCALE_FACTOR statement directs the extraction tool to shrink the design

database by the specified value before extraction begins. This optional statement is useful if

you are using a half-node process technology.

This statement embeds or remove the specified magnification factor from the nxtgrd file

without a grdgenxo models directory.

When the HALF_NODE_SCALE_FACTOR value is detected in the nxtgrd file, StarRC

automatically internally sets the MAGNIFY_DEVICE_PARAMS:NO and

NETLIST_UNSCALED_COORDINATES:YES commands to ensure that the final netlist contains

the full node coordinates.

• The MAGNIFY_DEVICE_PARAMS option ensures that the standard device properties

($w,$l,$area and so on) are generated in the netlist at full node.

• The NETLIST_UNSCALED_COORDINATES option ensures that all of the coordinate

information in the netlist is printed at the full node.

The following list explains possible scenarios and the corresponding StarRC behavior:

• Scenario 1

If the value is set for the MAGNIFICATION_FACTOR in the StarRC command file and a

value is specified for HALF_NODE_SCALE_FACTOR in the nxtgrd file, an error message is

issued.

"ERROR: Both MAGNIFICATION_FACTOR cannot be used in half node flow

where

the scaling factor is specified in the nxtgrd file."

Chapter 18: ITF Statements and Options

HALF_NODE_SCALE_FACTOR 18-60

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

• Scenario 2

If MAGNIFY_DEVICE_PARAMS:YES and/or NETLIST_UNSCALED_COORDINATES:NO is set in

the star_cmd file for a run that uses a nxtgrd file containing the

HALF_NODE_SCALE_FACTOR option, a warning is issued stating the new value for the

options.

"WARNING: HALF_NODE_SCALE_FACTOR detected in nxtgrd file, setting

MAGNIFY_DEVICE_PARAMS:NO for unshrunk device properties.

• Scenario 3

If you generated the StarRC nxtgrd file without setting the HALF_NODE_SCALE_FACTOR, or

you set an incorrect value (not between 0 and 1), and you would like to embed a value of

0.9 into the nxtgrd file, you can run grdgenxo and generate an updated nxtgrd file by

using the following syntax:

grdgenxo -add_sf 0.9 -i noshrink.nxtgrd -o shrink.nxtgrd

If you generated a StarRC nxtgrd file with a HALF_NODE_SCALE_FACTOR value and you would

like to run StarRC without magnification, you can remove the magnification factor from the

nxtgrd file by using the following command syntax:

grdgenxo -add_sf 1 -i noshrink.nxtgrd -o shrink.nxtgrd

Note:

You can set the magnification factor command in the StarRC command file after removing

the value from nxtgrd file as shown in the previous example. You cannot, however, simply

delete the MAGNIFICATION_FACTOR line from the nxtgrd file, because this causes the

nxtgrd file to be corrupt.

Example

This is an example of an ITF header using the HALF_NODE_SCALE_FACTOR statement:

TECHNOLOGY = 65nm_sample

GLOBAL_TEMPERATURE = 25

HALF_NODE_SCALE_FACTOR = 0.9

DIELECTRIC PASS2 {THICKNESS=0.800000 ER=6.9}

DIELECTRIC PASS1 {THICKNESS=0.700000 ER=4.0}

The following is an example of coordinates in a SPICE-like netlist:

*|I (ZN:F12 M1 SRC B 0 0.48 0.64)

*|P (ZN B 0 0.695 1.115)

*|S (ZN:16 0.53 1.545)

Chapter 18: ITF Statements and Options

HALF_NODE_SCALE_FACTOR 18-61

Chapter 18: ITF Statements and Options

HALF_NODE_SCALE_FACTOR 18-61

StarRC User Guide and Command Reference Version F-2011.06

The physical properties of parasitic resistors, used for reliability analysis flows, as a result of

NETLIST_TAIL_COMMENTS:YES option must also be at the full node:

R1 F9 F8 0.588229 $l=9.9 $w=2 $lvl=1

Note:

The HALF_NODE_SCALE_FACTOR command does not change the function of the

MAGNIFICATION_FACTOR option. However, you cannot use the MAGNIFICATION_FACTOR

option with the HALF_NODE_SCALE_FACTOR command. It is not allowed.

If you want to update the magnification factor value during nxtgrd file generation, use the

following command:

grdgenxo -add_sf factor -i input_nxtgrd_file -o output_nxtgrd_file

Chapter 18: ITF Statements and Options

ILD_VS_WIDTH_AND_SPACING 18-62

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

ILD_VS_WIDTH_AND_SPACING

Enables you to measure the micro-loading effect or bottom conductor thickness variation.

Syntax

ILD_VS_WIDTH_AND_SPACING {

DIELECTRIC = ILD_Layer_Name

WIDTHS {w1 w2 w3 ...}

SPACINGS {s1 s2 s3 ...}

THICKNESS_CHANGES {

v(s1,w1) v(s2,w1) ...

v(s1,w2) v(s2,w2) ...

...

}

Arguments

Argument Description

ILD_Layer_Name The name of the dielectric layer below the conductor

corresponding to the thickness variation

WIDTHS {...} Width in drawn dimensions

SPACINGS {...} Spacing in drawn dimensions

THICKNESS_CHANGES {...} Absolute thickness variation of the ILD layer specified. A positive

variation indicates an increase of thickness, and a decrease of

thickness is represented by a negative variation. The maximum

value is 0.2. The minimum value is -0.2.

Description

The ILD_VS_WIDTH_AND_SPACING statement in the ITF enables you to measure the micro-

loading effect or bottom conductor thickness variation.

WIDTH and SPACING are both in drawn dimensions and DIELECTRIC is the dielectric layer

below the conductor corresponding to the thickness variation. Each entry of the VALUES

specifies the absolute thickness variation of the ILD layer specified. A positive variation

indicates an increase of thickness, and a decrease of thickness is represented by a negative

variation. The SPACING command can be specified before the WIDTH command; however,

the mapping of the values remains the same regardless of the order of specification of the

two subcommands.

Maximum values specified in the table must not be greater than 0.2 and must not be less

than -0.2.

Chapter 18: ITF Statements and Options

ILD_VS_WIDTH_AND_SPACING 18-63

Chapter 18: ITF Statements and Options

ILD_VS_WIDTH_AND_SPACING 18-63

StarRC User Guide and Command Reference Version F-2011.06

The ILD_VS_WIDTH_AND_SPACING option cannot be used in the same CONDUCTOR statement

as the BOTTOM_THICKNESS_VS_SI _WIDTH option or the MEASURED_FROM option.

Handling ILD Variation in Flows

StarRC today allows multiple definitions of bottom thickness variation:

•BOTTOM_THICKNESS_VS_SI_WIDTH command

•THICKNESS_VARIATION_FILE (TVF) in CMP simulator flow

StarRC does not combine multiple bottom thickness variation sources. As previously

mentioned, you cannot specify BOTTOM_THICKNESS_VS_SI_WIDTH with

ILD_VS_WIDTH_AND_SPACING for a given conductor.

For TVF input to StarRC, the ILD variation from the nxtgrd file is disabled because it is

assumed that the CMP simulation thickness output accounts for the loading effect. The

following thickness variation effects are automatically disabled when TVF input is provided

from a CMP simulation flow:

•POLYNOMIAL_BASED_THICKNESS_VARIATION (PBTV)

•THICKNESS_VS_DENSITY (TVD)

•THICKNESS_VS_WIDTH_AND_SPACING (TVWS)

•ILD_VS_WIDTH_AND_SPACING

Note:

The BOTTOM_THICKNESS_VS_SI_WIDTH is not disabled for TVF input flows because the

CMP simulation in this case is assumed to not model the loading effect.

Restrictions

The following conditions are implemented pertaining to the ILD_VS_WIDTH_AND_SPACING

ITF command:

• If ILD variation is specified for a dielectric layer that does not exist directly below a

conductor, the following error occurs:

“ERROR: ILD_VS_WIDTH_AND_SPACING can only be specified for dielectric layers

directly below the conductor (due to micro-loading)”

• If ILD variation is specified for a conductor layer that does not have

POLYNOMIAL_BASED_THICKNESS_VARIATION, the following error occurs:

“ERROR: ILD_VS_WIDTH_AND_SPACING requires

POLYNOMIAL_BASED_THICKNESS_VARIATION table be specified

ERROR: within the same conductor layer: metal8”

Chapter 18: ITF Statements and Options

ILD_VS_WIDTH_AND_SPACING 18-64

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

• If the ILD variation specified is greater than 0.2 or less than -0.2, the following error

occurs:

“ERROR: Maximum variation of 20% allowed for intra-layer dielectric (ILD) thickness (due

to micro-loading)"

• If ILD variation table is specified within the same CONDUCTOR statement with a

BOTTOM_THICKNESS_VS_SI_WIDTH table, the following error occurs:

“ERROR: ILD_VS_WIDTH_AND_SPACING cannot be specified together with

BOTTOM_THICKNESS_VS_SI_WIDTH within the same CONDUCTOR command"

Example

ILD_VS_WIDTH_AND_SPACING {

DIELECTRIC = ILD3

WIDTHS {0.1 0.2 0.3 0.4}

SPACINGS {0.11 0.22 0.33 0.44}

THICKNESS_CHANGES {0.130 0.134 0.138 0.140

0.135 0.138 0.139 0.142

0.138 0.139 0.139 0.143

0.140 0.142 0.144 0.146

}

The DIELECTRIC statement specifies the dielectric layer below which the ILD variation is to

be accounted for. The VALUES specified are absolute ILD variation values.

See Also

•BOTTOM_THICKNESS_VS_SI_WIDTH

•THICKNESS_VARIATION_FILE (CMP simulator)

Chapter 18: ITF Statements and Options

IS_CONFORMAL 18-65

Chapter 18: ITF Statements and Options

IS_CONFORMAL 18-65

StarRC User Guide and Command Reference Version F-2011.06

IS_CONFORMAL

Defines the material the conductor layer is deposited around and allows conformal layers to

be associated with a specified conductor layer.

Syntax

IS_CONFORMAL

Arguments

The IS_CONFORMAL keyword does not have any arguments.

Description

The IS_CONFORMAL keyword is specified with an ASSOCIATED_CONDUCTOR statement. It

defines the material the conductor layer is deposited around and allows conformal layers to

be associated with a specified conductor layer.

•A DIELECTRIC layer specified with an IS_CONFORMAL layer tag is a conformal layer.

•An IS_CONFORMAL layer can have SW_T and/or TW_T around the CONDUCTOR. If TW_T or

SW_T is not specified, 0.0 is assumed.

• When an ASSOCIATED_CONDUCTOR material drops with a DROP_FACTOR defined for a

CONDUCTOR below it, IS_CONFORMAL layers also drop.

• If a CONDUCTOR above overlaps with the TW_T of an IS_CONFORMAL layer, the CONDUCTOR

cuts into the IS_CONFORMAL layer.

•An IS_CONFORMAL layer can be specified without an ASSOCIATED_CONDUCTOR. See also

ASSOCIATED_CONDUCTOR

Errors

The following error and warning messages can be issued in the noted conditions:

• If thickness is defined for an IS_CONFORMAL layer, an error message is issued:

ERROR:LAYER xxx is set to be IS_CONFORMAL; it must have a thickness of

• If ASSOCIATED_CONDUCTOR is defined for a non-IS_CONFORMAL layer:

ERROR: LAYER xxx must be set to IS_CONFORMAL if it has an

ASSOCIATED_CONDUCTOR.

• If the conductor defined for ASSOCIATED_CONDUCTOR is higher than the IS_CONFORMAL

layer, the following message appears:

ERROR: ASSOCIATED_CONFORMAL layer xxx for layer xxx cannot be higher

than

the layer itself.

Chapter 18: ITF Statements and Options

IS_CONFORMAL 18-66

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Example

DIELECTRIC D1 {

IS_CONFORMAL ASSOCIATED_CONDUCTOR=met1

SW_T=0.1 TW_T=0.1 ER=2.5

}

See Also

•ASSOCIATED_CONDUCTOR

•DROP_FACTOR

Chapter 18: ITF Statements and Options

IS_PLANAR 18-67

Chapter 18: ITF Statements and Options

IS_PLANAR 18-67

StarRC User Guide and Command Reference Version F-2011.06

IS_PLANAR

Specifies planar layers.

Syntax

IS_PLANAR

Arguments

The IS_PLANAR keyword does not have any arguments.

Description

Specifies that from this conductor and above, the layers do not drop because the

DROP_FACTOR command is specified for the lower layers.

Example

CONDUCTOR ELEC1 {

THICKNESS = 0.010

WMIN = 0.180

SMIN = 0.100

RPSQ = 0.00001

CAPACITIVE_ONLY_ETCH = 0

IS_PLANAR

}

See Also

•DROP_FACTOR

Chapter 18: ITF Statements and Options

LAYER_TYPE 18-68

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

LAYER_TYPE

Specifies the layer type within a CONDUCTOR statement.

Syntax

LAYER_TYPE = GATE | FIELD_POLY | DIFFUSION | TRENCH_CONTACT

Arguments

Argument Description

GATE Identifies conducting layers that represent the gate of a device. If

separate ITF conducting layers are not specified for gate and field

polysilicon, specify the combined gate-field polysilicon layer as

LAYER_TYPE = GATE.

FIELD_POLY Identifies conducting layers that represent field polysilicon

outside of the device region.

DIFFUSION Identifies conducting layers that represent source or drain

diffusion regions for devices.

TRENCH_CONTACT Identifies conducting layers that represent trench contacts. This

includes both M1-to-diffusion trench contacts and M1-to-

polysilicon trench contacts that can be used both inside and

outside of the device region.

Description

In advanced processes technologies at 28 nm and below, including those with trench

contacts, information in the ITF file about the function of the conducting layers improves

capacitance extraction accuracy in the device region. To identify certain conductor layers,

use the LAYER_TYPE option within the appropriate CONDUCTOR statements.

If a conducting layer does not have a specified layer type, then the layer type is assumed to

be a standard routing layer.

When specifying the layer type, note the following constraints on the relative vertical position

of the conductors in the interconnect stack:

• Conductors with LAYER_TYPE = GATE and LAYER_TYPE = FIELD_POLY must be

covertical.

• Conductors with LAYER_TYPE = TRENCH_CONTACT must be covertical with or above

conductors with LAYER_TYPE = GATE or LAYER_TYPE = FIELD_POLY.

Chapter 18: ITF Statements and Options

LAYER_TYPE 18-69

Chapter 18: ITF Statements and Options

LAYER_TYPE 18-69

StarRC User Guide and Command Reference Version F-2011.06

• Conductors with LAYER_TYPE = DIFFUSION must be below the conductors with

LAYER_TYPE = GATE.

Errors

If the constraints on the layer type are not satisfied, the grdgenxo executable issues an error

message.

Example

The following example uses the LAYER_TYPE option to identify gate and diffusion layers:

CONDUCTOR PS {

THICKNESS = 0.04

WMIN = 0.04

SMIN = 0.04

GATE_TO_CONTACT_SMIN = 0.02

LAYER_TYPE = GATE

...

}

DIELECTRIC DP1 {

THICKNESS = 0.001

...

}

DIELECTRIC D_DIFF {

THICKNESS = 0.04

...

}

CONDUCTOR DIFF {

THICKNESS = 0.04

WMIN=0.04

SMIN=0.04

LAYER_TYPE = DIFFUSION

...

}

See Also

•CONDUCTOR

Chapter 18: ITF Statements and Options

MEASURED_FROM 18-70

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

MEASURED_FROM

Modifies the reference location where thickness is measured.

Syntax

MEASURED_FROM = dielectric_layer | TOP_OF_CHIP

Arguments

Argument Description

dielectric_layer The name of the dielectric layer from which the measurement is

made. This layer name must be defined in the ITF.

The default is the dielectric layer immediately below.

TOP_OF_CHIP Facilitates the creation of conformal dielectrics. It creates the

bottom plane from the layers already present below the new layer

and mimics the topology of the existing base (copies any existing

nonplanarities to the new layer, which has a conformal thickness).

See Example 2 on the previous page.

Description

Modifies the reference location where thickness is measured. The default is the dielectric

layer immediately below it; be careful when using this feature for a conducting layer, as it is

possible to create a conductor that cuts a dielectric, which may not be the desired effect.

The MEASURED_FROM statement provides the ability to customize the model to account for

such process characteristics as conformal dielectrics, mixed conformal and planar

dielectrics, and covertical conductors. When used with a DIELECTRIC layer definition, the

MEASURED_FROM keyword can refer to a lower dielectric or can have the value TOP_OF_CHIP.

When used with a CONDUCTOR layer definition, the MEASURED_FROM keyword can refer only to

a lower PLANAR dielectric.

The heights of the conductors and dielectrics are determined exclusively by the order in

which they are specified and by the thicknesses of the lower layers. When you are specifying

a new conductor or dielectric layer, the bottom plane of that layer is exactly the top plane of

the dielectric layer immediately below it unless a MEASURED_FROM statement is included (to

explicitly specify the location of the bottom plane).

Specify the MEASURED_FROM option within a CONDUCTOR or DIELECTRIC statement.

Chapter 18: ITF Statements and Options

MEASURED_FROM 18-71

Chapter 18: ITF Statements and Options

MEASURED_FROM 18-71

StarRC User Guide and Command Reference Version F-2011.06

Example

In the following example, TOP is planarized by measuring from D2:

DIELECTRIC TOP {

THICKNESS = 3.6

MEASURED_FROM = D2

ER = 3.9

}

In the following example, D3 is a conformal dielectric:

DIELECTRIC D3 {

THICKNESS=0.2

MEASURED_FROM = TOP_OF_CHIP

ER=3.9

}

See Also

•CONDUCTOR

•DIELECTRIC

•SW_T

•TW_T

Chapter 18: ITF Statements and Options

POLYNOMIAL_BASED_THICKNESS_VARIATION 18-72

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

POLYNOMIAL_BASED_THICKNESS_VARIATION

Syntax

POLYNOMIAL_BASED_THICKNESS_VARIATION {

DENSITY_POLYNOMIAL_ORDERS = { o(n), o(n-1), ..., o(0) }

WIDTH_POLYNOMIAL_ORDERS = { o(m), o(m-1), ..., o(0) }

WIDTH_RANGES = { w0, w1 }

POLYNOMIAL_COEFFICIENTS = {

c(n,m), c(n,m-1), ..., c(n ,0)

c(n-1,m), c(n-1,m-1), ..., c(n-1,0)

...

c(0,m), c(0,m-1), ..., c(0,0)

}

POLYNOMIAL_COEFFICIENTS = {

c(n,m), c(n,m-1), ..., c(n ,0)

c(n-1,m), c(n-1,m-1), ..., c(n-1,0)

...

c(0,m), c(0,m-1), ..., c(0,0)

}

POLYNOMIAL_COEFFICIENTS = {

c(n,m), c(n,m-1), ..., c(n ,0)

c(n-1,m), c(n-1,m-1), ..., c(n-1,0)

...

c(0,m), c(0,m-1), ..., c(0,0)

}

Arguments

Argument Description

DENSITY_POLYNOMIAL_ORDERS Powers of density used in the polynomial

WIDTH_POLYNOMIAL_ORDERS Powers of width used in the polynomial

WIDTH_RANGES Range of widths for which polynomial coefficients tables are

used

POLYNOMIAL_COEFFICIENTS Coefficient of the yth power of width of the polynomials for xth

power of density coefficient c(x,y)

Description

Use this option to model the effects of thickness variation as a function of density and width

in a polynomial format. This option is to be specified within a CONDUCTOR statement.

Chapter 18: ITF Statements and Options

POLYNOMIAL_BASED_THICKNESS_VARIATION 18-73

Chapter 18: ITF Statements and Options

POLYNOMIAL_BASED_THICKNESS_VARIATION 18-73

StarRC User Guide and Command Reference Version F-2011.06

Only integers are allowed for DENSITY_POLYNOMIAL_ORDERS and

WIDTH_POLYNOMIAL_ORDERS.

The thickness variation is calculated as follows based on the polynomial coefficients along

with width and density:

deltaT/T = fn(w) x Densityn + fn-1(w) x Densityn-1 + ... + f1(w) x Density + f0(w)

In this equation,

fn(w) = c(n,m) x Widthm + c(n,m-1) x Widthm-1 + ... + c(n,1) x Width + c(n,0)

fn-1(w) = c(n-1,m)x Widthm + c(n-1,m-1) x Widthm-1 + ... + c(n-1,1)x Width + c(n-1,0)

...

f1(w) = c(1,m) x Widthm + c(1,m-1) x Widthm-1 + ... + c(1,1) x Width + c(1,0)

f0(w) = c(0,m) x Widthm + c(0,m-1) x Widthm-1 + ... + c(0,1) x Width + c(0,0)

StarRC assumes that the PBTV model is not valid for all density ranges 0-1. To calculate the

range of the density for thickness variation modeling with PBTV, StarRC uses the

ETCH_VS_WIDTH_AND_SPACING (evws) table to obtain the range of widths and spacings. The

minimum and maximum density bounds are calculated as follows:

•Maximum density bound = maximum_width_from_evws/

(maximum_width_from_evws+minimum_sapcing_from_evws)

•Minimum density bound = minimum_width_from_evws/

(minimum_width_from_evws+maximum_sapcing_from_evws)

If the computed polygon density is less than the minimum density bound, the minimum

density is used in the PBTV computation. Similarly, if the density of the polygon is larger than

the maximum density bound, the maximum density is used in the computation.

The following commands or keywords cannot be specified with the

POLYNOMIAL_BASED_THICKNESS_VARIATION command:

• RESISTIVE_ONLY

• CAPACITIVE_ONLY

• THICKNESS_VS_DENSITY

• DENSITY_BOX_WEIGHTING_FACTOR

The following describes how StarRC selects the polynomial coefficients tables.

• The first POLYNOMIAL_COEFFICIENTS table is used for width <= w0.

• The second POLYNOMIAL_COEFFICIENTS table is used for w0 < width <= w1.

• The third POLYNOMIAL_COEFFICIENTS table is used for width > w1.

Chapter 18: ITF Statements and Options

POLYNOMIAL_BASED_THICKNESS_VARIATION 18-74

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

• There can be more than two width values for WIDTH_RANGES, and the number of

POLYNOMIAL_COEFFICIENTS tables should increase accordingly.

• If there is one width value in WIDTH_RANGE, there are two POLYNOMIAL_COEFFICIENTS

tables. The first one is for width <= w0. The second one is for width > w0.

• If the WIDTH_RANGE is not specified, there is only one POLYNOMIAL_COEFFICIENTS table

used for all width values.

Errors

Error and warning messages appear when the following situations exist:

• The thickness variation scaling factor is causing the thickness to vary by more than 50

percent (or less than -50 percent).

•RESISTIVE_ONLY, CAPACITIVE_ONLY, THICKNESS_VS_DENSITY, or

DENSITY_BOX_WEIGHTING_FACTOR is used.

Example

CONDUCTOR M1 { THICKNESS=0.18 SIDE_TANGENT = 0.0556

POLYNOMIAL_BASED_THICKNESS_VARIATION {

DENSITY_POLYNOMIAL_ORDERS = { 3, 2, 1, 0 }

WIDTH_POLYNOMIAL_ORDERS = { 4, 3, 2, 1, 0 }

WIDTH_RANGES = { 0.27 }

$ Coefficients for width <= 0.27

POLYNOMIAL_COEFFICIENTS = {

0, 1.656E+03, -9.488E+02, 1.731E+02, -1.041E+01,

0, -1.212E+03, 6.935E+02, -1.262E+02, 7.666E+00,

0, 2.314E+02, -1.320E+02, 2.400E+01, -1.580E+00,

0, -5.211E+00, 3.417E+00, -6.853E-01, 1.131E-01

}

$ Coefficients for width > 0.27

POLYNOMIAL_COEFFICIENTS = {

1.027E-03, -2.006E-02, 8.996E-02, -5.189E-02, -1.814E-01,

-2.805E-03, 5.795E-02, -3.084E-01, 4.211E-01, 1.152E-01,

2.097E-03, -4.375E-02, 2.394E-01, -3.662E-01, -2.697E-02,

-4.866E-04, 1.001E-02, -5.416E-02, 1.012E-01, 4.308E-02

}

See Also

•DENSITY_BOX_WEIGHTING_FACTOR

•ETCH_VS_WIDTH_AND_SPACING

•THICKNESS_VS_DENSITY

•DENSITY_BASED_THICKNESS

•PBTV_DENSITY_BOUND

Chapter 18: ITF Statements and Options

RESISTIVE_ONLY_ETCH 18-75

Chapter 18: ITF Statements and Options

RESISTIVE_ONLY_ETCH 18-75

StarRC User Guide and Command Reference Version F-2011.06

RESISTIVE_ONLY_ETCH

Specifies the width adjustment for layer etch effects.

Syntax

RESISTIVE_ONLY_ETCH = etch_value

Arguments

Argument Description

etch_value Etch value

Units: microns

Description

Specify this option within a CONDUCTOR definition. It is identical to the ETCH option, except that

only resistance is affected by etching; capacitance is unaffected. This option is not the same

as ETCH_VS_WIDTH_AND_SPACING RESISTIVE_ONLY.

Note:

This option works only with EXTRACTION:RC. Otherwise resistance extraction does not

have etching effects.

Example

CONDUCTOR metal1 {

RESISTIVE_ONLY_ETCH = 0.05

THICKNESS=0.66

WMIN=0.15 SMIN=0.15 RPSQ=0.078

}

See Also

•CAPACITIVE_ONLY_ETCH

•ETCH

•RPSQ_VS_SI_WIDTH

Chapter 18: ITF Statements and Options

RHO 18-76

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

RHO

Defines the bulk resistivity of a VIA or CONDUCTOR layer.

Syntax

RHO = float

Arguments

Argument Description

float Bulk resistivity of the via or conductor layer

Units: ohms-micron

Default: 0.0 for conductors or RPV x AREA of 1.0e-6 for VIAs.

If not specified for VIA in the ITF, StarRC calculates

RPV x AREA = 1.0e-6.

Description

The resistive properties of the via and conductor layers must be specified.

The via layers can be specified in two ways: RHO, or RPV and AREA, however, only one

specification method is required.

The conductor layer’s resistive properties can be specified in two ways: RHO or RPSQ.

You specify this option within a CONDUCTOR or VIA statement. You cannot specify an

RPV_VS_AREA statement option with an RPV or RHO statement option.

Example

VIA via1 {FROM = M1 TO = M2 RHO = 0.263}

CONDUCTOR M1 {THICKNESS = 0.4 SMIN=0.15 WMIN=0.18 RHO=0.8}

See Also

•RPV

Chapter 18: ITF Statements and Options

RHO_VS_SI_WIDTH_AND_THICKNESS 18-77

Chapter 18: ITF Statements and Options

RHO_VS_SI_WIDTH_AND_THICKNESS 18-77

StarRC User Guide and Command Reference Version F-2011.06

RHO_VS_SI_WIDTH_AND_THICKNESS

Models resistivity as a function of silicon thickness and width.

Syntax

RHO_VS_SI_WIDTH_AND_THICKNESS {

WIDTH {w1 w2 w3 ...}

THICKNESS {t1 t2 t3 ...}

VALUES { v(w1,t1) v(w2,t1) ...

v(w1,t2) v(w2,t2) ...

}

Arguments

Argument Description

WIDTH {...} A list of silicon widths of the CONDUCTOR

Units: microns

THICKNESS {...} A list of silicon thickness of the CONDUCTOR

Units: microns

VALUES {...} A list of the RHO values for the corresponding silicon widths and

thicknesses

Description

The RHO_VS_SI_WIDTH_AND_THICKNESS statement models resistivity as a function of silicon

thickness and width.

WIDTH and THICKNESS are both in silicon dimensions. The THICKNESS subcommand can be

specified before the WIDTH subcommand, however the mapping of the values remain the

same regardless of the order of specification of the two subcommands.

Errors

The following restrictions take effect when you are using

RHO_VS_SI_WIDTH_AND_THICKNESS.

• If RHO_VS_SI_WIDTH_AND_THICKNESS is specified but not one of the following commands

are specified in the ITF for the conductor,

•POLYNOMIAL_BASED_THICKNESS_VARIATION

•THICKNESS_VS_DENSITY

Chapter 18: ITF Statements and Options

RHO_VS_SI_WIDTH_AND_THICKNESS 18-78

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

•THICKNESS_VS_WIDTH_AND_SPACING

• If the THICKNESS_VARIATION_FILE is not specified in the StarRC command file, StarRC

issues a warning as follows:

“WARNING: RHO_VS_SI_WIDTH_AND_THICKNESS specified, but

silicon thickness is same as drawn thickness for conductor X”

• If RHO_VS_SI_WIDTH_AND_THICKNESS is specified, but not one of the following

commands are specified in the ITF for the conductor,

•ETCH

•ETCH_VS_WIDTH_AND_SPACING (RESISTIVE_ONLY)

StarRC issues the following warning:

"WARNING: RHO_VS_SI_WIDTH_AND_THICKNESS is specified for

layer X without any ETCH modeling in the ITF. Drawn

width will be used in resistance extraction for this layer."

• If RHO_VS_SI_WIDTH_AND_THICKNESS is specified with the following ITF commands for

the same conductor statement,

•RHO

•RHO_VS_WIDTH_AND_SPACING

•RPSQ

•RPSQ_VS_SI_WIDTH

•RPSQ_VS_WIDTH_AND_SPACING

StarRC issues the following warning:

ERROR: RHO_VS_SI_WIDTH_AND_THICKNESS cannot be specified

for a conductor in conjunction with RHO/

RHO_VS_WIDTH_AND_SPACING, RPSQ/RPSQ_VS_WIDTH_AND_SPACING/

RPSQ_VS_SI_WIDTH.

Example

RHO_VS_SI_WIDTH_AND_THICKNESS {

WIDTH {0.1 0.2 0.3 0.4}

THICKNESS {0.11 0.22 0.33 0.44}

VALUES { 0.304 0.410 0.518 0.640

0.210 0.340 0.438 0.560

0.504 0.530 0.618 0.720

0.604 0.710 0.818 0.940

}

Chapter 18: ITF Statements and Options

RHO_VS_SI_WIDTH_AND_THICKNESS 18-79

Chapter 18: ITF Statements and Options

RHO_VS_SI_WIDTH_AND_THICKNESS 18-79

StarRC User Guide and Command Reference Version F-2011.06

See Also

•ETCH

•ETCH_VS_WIDTH_AND_SPACING

•POLYNOMIAL_BASED_THICKNESS_VARIATION

•RESISTIVE_ONLY_ETCH

•RPSQ_VS_SI_WIDTH

•RPSQ_VS_WIDTH_AND_SPACING

•THICKNESS_VS_DENSITY

•THICKNESS_VS_WIDTH_AND_SPACING

•THICKNESS_VARIATION_FILE

Chapter 18: ITF Statements and Options

RHO_VS_WIDTH_AND_SPACING 18-80

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

RHO_VS_WIDTH_AND_SPACING

Models the RHO variation with respect to width and spacing.

Syntax

RHO_VS_WIDTH_AND_SPACING

SPACINGS {s1 s2}

WIDTHS {w1 w2 w3}

VALUES {v(s1 w1) v(s2 w1)

v(s1 w2) v(s2 w2)

v(s1 w3) v(s2 w3)

}

Arguments

Argument Description

SPACINGS {...} A list of spacings to the nearest CONDUCTOR

Units: microns

WIDTHS {...} A list of widths of the nearest CONDUCTOR

Units: microns

VALUES {...} A list of the RHO values for the corresponding width and spacing

Description

Specify this option within a CONDUCTOR statement to model the RHO variation with respect to

width and spacing.

The RHO_VS_WIDTH_AND_SPACING option cannot be used in conjunction with RHO, RPSQ,

RPSQ_VS_WIDTH_AND_SPACING, or multiple ETCH_VS_WIDTH_AND_SPACING tables.

See Also

•ETCH_VS_WIDTH_AND_SPACING

•RHO

•RPSQ_VS_WIDTH_AND_SPACING

Chapter 18: ITF Statements and Options

RPSQ 18-81

Chapter 18: ITF Statements and Options

RPSQ 18-81

StarRC User Guide and Command Reference Version F-2011.06

RPSQ

Specifies the resistance per square of a conductor layer.

Syntax

RPSQ = float

Arguments

Argument Description

float Resistance per square of the conducting layer

Default: 0

Units: ohms/square

Description

RPSQ is the resistance per square of a conductor. You can specify the resistive properties

of CONDUCTOR layers using either the RPSQ or the RHO values, but only one is required.

Example

CONDUCTOR metal1 {

RESISTIVE_ONLY_ETCH=0.05 THICKNESS=0.66

WMIN=0.15 SMIN=0.15 RPSQ=0.078

}

See Also

•RHO

•RPSQ_VS_SI_WIDTH

•RPSQ_VS_WIDTH_AND_SPACING

Chapter 18: ITF Statements and Options

RPSQ_VS_SI_WIDTH 18-82

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

RPSQ_VS_SI_WIDTH

Syntax

RPSQ_VS_SI_WIDTH {(SIW1, R1) (SIW2, R2)... (SIWn, Rn)}

Arguments

Argument Description

SIWn The nth measured width of the conductor

Units: microns

Rn RPSQ of the conductor at silicon width SIWn

Units: ohms/square

Description

Defines the nonlinear relation of resistance per square (RPSQ) of the measured silicon

width. This option replaces the EFFECTIVE_RPSQ_TABLE option. You cannot specify RPSQ for

this conductor in your layer mapping file. This option models the effects of changing RPSQs

because of different widths and includes in its model the different process effects such as

cladding and dishing. The first entry of SIW does not have to be the same as WMIN.

Errors

• This option cannot be used with RPSQ, RHO, or RPSQ_VS_WIDTH_AND_SPACING

• The resistance value of the conductor having RPSQ_VS_SI_WIDTH or

RPSQ_VS_WIDTH_AND_SPACING should not be specified in a mapping file.

Chapter 18: ITF Statements and Options

RPSQ_VS_SI_WIDTH 18-83

Chapter 18: ITF Statements and Options

RPSQ_VS_SI_WIDTH 18-83

StarRC User Guide and Command Reference Version F-2011.06

If this is done, StarXtract issues this error message:

ERROR: StarXtract

ERROR: Invalid to set both RPSQ_VS_SI_WIDTH in the nxtgrd

ERROR: file and RPSQ in the mapping file for

ERROR: layer M2; please remove one of them and run again.

ERROR: StarXtract

ERROR: Invalid to set both RPSQ_VS_WIDTH_AND_SPACING in the

ERROR: nxtgrd file and RPSQ in the mapping file for layer M2;

ERROR: please remove one of them and run again.

ERROR: StarXtract

ERROR: Invalid to set both RPV_VS_AREA in the nxtgrd file

ERROR: and RPV/AREA in the mapping file for layer M2;

ERROR: please remove one of them and run again.

Example

This example specifies a varying RPSQ value with respect to the measured width.

CONDUCTOR MET1 {

THICKNESS=0.6 WMIN=0.34 SMIN=0.40

RPSQ_VS_SI_WIDTH {

(0.34, 0.075) (0.40, 0.062)

(0.823, 0.0817)(2.0, 0.0321)

(6.0,0.0173)

}

See Also

•ETCH_VS_WIDTH_AND_SPACING

Chapter 18: ITF Statements and Options

RPSQ_VS_WIDTH_AND_SPACING 18-84

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

RPSQ_VS_WIDTH_AND_SPACING

Syntax

RPSQ_VS_WIDTH_AND_SPACING {

SPACINGS {s1 s2 s3 ... }

WIDTHS {w1 w2 w3 ... }

VALUES {v(s1,w1) v(s2,w1) ...

v(s1,w2) v(s2,w2) ...

}

Arguments

Argument Description

SPACINGS {...} A list of spacings to the nearest CONDUCTOR.

Units: microns

WIDTHS {...} A list of widths of the nearest CONDUCTOR

Units: microns

VALUES {...} A list of the RPSQ values for the corresponding width and spacing

Description

Use this option to model the effects of changing RPSQ because of different widths and

spacings. You can use this option to model different process effects such as conductor

cladding or dishing. RPSQ is the resistance per square in ohms per square. The grdgenxo

executable accounts for the RPSQ values for the various widths and spaces and stores them

in the nxtgrd file. If RPSQ has only a dependency on width, SPACINGS can be skipped and

vice versa. This command replaces EFFECTIVE_RPSQ_TABLE. The first entry of SPACINGS

and WIDTHS should be the same as SMIN and WMIN, respectively.

Specify this option within a CONDUCTOR statement. Do not use this option in conjunction with

multiple ETCH_VS_WIDTH_AND_SPACING tables.

Chapter 18: ITF Statements and Options

RPSQ_VS_WIDTH_AND_SPACING 18-85

Chapter 18: ITF Statements and Options

RPSQ_VS_WIDTH_AND_SPACING 18-85

StarRC User Guide and Command Reference Version F-2011.06

Example

CONDUCTOR m1 {

THICKNESS = 0.6 WMIN = 0.25 SMIN = 0.25

RPSQ_VS_WIDTH_AND_SPACING {

SPACINGS {0.25 0.3}

WIDTHS {0.25 0.3}

VALUES {0.1 0.05 0.05 0.01} }

}

See Also

•ETCH_VS_WIDTH_AND_SPACING

Chapter 18: ITF Statements and Options

RPV 18-86

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

RPV

Specifies the resistive properties of a via layer.

Syntax

RPV = float

Arguments

Argument Description

float Resistance per default via

Units: ohms

Description

The resistive properties of the via layer must be specified. The via layers can be specified in

three ways: RHO, RPV and AREA, or RPV_VS_AREA. However, only one specification method is

required.

If RPV is specified, then AREA is required.

The default of RPV is such that RPV x AREA = 1-0e-6.

You specify this option within a VIA statement. You cannot specify RPV_VS_AREA together

with RPV or RHO in the same VIA statement.

Example

VIA via1 {

FROM=m1 TO=m2 AREA=0.5 RPV=4

}

See Also

•RHO

•RPV_VS_AREA

Chapter 18: ITF Statements and Options

RPV_VS_AREA 18-87

Chapter 18: ITF Statements and Options

RPV_VS_AREA 18-87

StarRC User Guide and Command Reference Version F-2011.06

RPV_VS_AREA

Specifies the resistance per via (RPV) for different via areas.

Syntax

RPV_VS_AREA {

(area1, rpv1)

(area2, rpv2)

(area3, rpv3)

...

}

Arguments

Argument Description

area Via or contact area

Units: square microns

rpv Resistance per via or contact specified

Units: ohms

Description

You can use a RPV_VS_AREA table in a VIA statement to specify the via resistance for

different via sizes. There is no limit to the number of entries you can specify. You cannot

specify RPV_VS_AREA together with RPV or RHO in the same VIA statement.

• If the actual via area falls between two area entries in the RPV_VS_AREA table, StarRC

performs linear interpolation to calculate the RPV value.

• If the actual via area is less than the smallest area entry in the RPV_VS_AREA table, the

RPV value is set to the corresponding rpv entry of the smallest area entry; no

extrapolation is performed.

• If the actual area is greater than the largest area entry in the RPV_VS_AREA table, the

RPV value is set to the corresponding rpv entry of the largest area entry; no

extrapolation is performed.

Note:

RPV and AREA values specified in a mapping file take precedence over the

RPV_VS_AREA values specified in an ITF.

Chapter 18: ITF Statements and Options

RPV_VS_AREA 18-88

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Example

VIA via1 {

FROM=m1 TO=m2

RPV_VS_AREA { (200, 0.5) (350, 0.5) (600, 0.25) }

}

See Also

•VIA

Chapter 18: ITF Statements and Options

SIDE_TANGENT 18-89

Chapter 18: ITF Statements and Options

SIDE_TANGENT 18-89

StarRC User Guide and Command Reference Version F-2011.06

SIDE_TANGENT

Specifies the tangent of an angular shift from vertical of the conductor sides.

Syntax

SIDE_TANGENT = float

Arguments

Argument Description

float Tangent value

Default: 0

Description

The SIDE_TANGENT option specifies the tangent of an angular shift from vertical of the

conductor sides, as shown in Figure 18-7.

Figure 18-7 Effect of the SIDE_TANGENT Option

W_center W_center

Before After

20o

-20o

Figure 18-8 Positive Versus Negative SIDE_TANGENT Values

W_center

Positive SIDE_TANGENT

W_center

Negative SIDE_TANGENT

-20o

+20o

Chapter 18: ITF Statements and Options

SIDE_TANGENT 18-90

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

If you specify a positive value for SIDE_TANGENT, a trapezoid is produced with a top width

larger than the center width. If W denotes the width of the conductor without any trapezoidal

enhancement, and t is the vertical thickness of the conducting layer, then:

W_top = W + (SIDE_TANGENT * t)

W_bottom = W - (SIDE_TANGENT * t)

W_center = W

t = conductor thickness

The center width (W_center) is not affected by the trapezoidal adjustment. Also note that the

trapezoidal cross section is effectively a capacitive effect because the cross sectional area

does not change as long as top and bottom widths are greater than or equal to zero.

Example

This example shows how you can specify that the conductor has a 20 degree angular shift

(tan 20°=0.364).

CONDUCTOR met4 {

SIDE_TANGENT=0.364 THICKNESS=0.66 WMIN=0.15

SMIN=0.15 RPSQ=0.078

}

See Also

•ETCH_VS_WIDTH_AND_SPACING

Chapter 18: ITF Statements and Options

SMIN 18-91

Chapter 18: ITF Statements and Options

SMIN 18-91

StarRC User Guide and Command Reference Version F-2011.06

SMIN

Minimum spacing between two geometries of this conductor layer.

Syntax

SMIN = float

Arguments

Argument Description

float Minimum spacing value

Units: microns

Description

Minimum spacing between two geometries of this conductor layer.

You must specify this option within a CONDUCTOR statement.

Example

CONDUCTOR m1 {

THICKNESS=1.00 WMIN=0.13 SMIN=0.15 RPSQ=0.015

}

See Also

•WMIN

Chapter 18: ITF Statements and Options

SW_T 18-92

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

SW_T

Defines the sidewall thickness of a conformal layer.

Syntax

SW_T = float

Arguments

Argument Description

float The sidewall thickness

Units: microns

Default: dielectric THICKNESS value

Description

SW_T=0 is allowed for conformal dielectrics. An error message is issued if SW_T is less than

zero or is between zero and 0.005. If not specified, THICKNESS of the dielectric is used as

SW_T.

Example

DIELECTRIC D3 {

THICKNESS = 0.2

MEASURED_FROM = TOP_OF_CHIP

SW_T = 0.15

TW_T = 0.18

ER = 5.9

}

See Also

•MEASURED_FROM

•THICKNESS

•TW_T

Chapter 18: ITF Statements and Options

TECHNOLOGY 18-93

Chapter 18: ITF Statements and Options

TECHNOLOGY 18-93

StarRC User Guide and Command Reference Version F-2011.06

TECHNOLOGY

Specifies the name of the process technology for tracking and identification purposes.

Syntax

TECHNOLOGY = process_name

Arguments

Argument Description

process_name The process name represented by a single word that can contain

alphanumeric characters and underscores

Description

The TECHNOLOGY statement is mandatory and should precede all other statements, but it

does not need to be the first line of the ITF.

The output of the grdgenxo executable is stored in the process_name.nxtgrd file.

Example

In the following example, the process name is sample_tech, and the grdgenxo output is

stored in the sample_tech nxtgrd file:

TECHNOLOGY = sample_tech

Chapter 18: ITF Statements and Options

THICKNESS 18-94

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

THICKNESS

Specifies the thickness of a dielectric or conductor layer.

Syntax

THICKNESS = float

Arguments

Argument Description

float The thickness of the dielectric or conductor

Units: microns

Description

The dielectric or conductor thickness measured from the top of the dielectric layer below it.

The reference point can be changed by setting MEASURED_FROM. Specifying THICKNESS=0 is

allowed for a conformal dielectric layer; for planar layers THICKNESS should not be specified

as 0.

You specify this option within a CONDUCTOR or DIELECTRIC statement.

Errors

An error message is issued if THICKNESS is less than 0.001 micron for a conductor layer or

planar dielectric layer.

Example

CONDUCTOR M2 { THICKNESS=0.60 WMIN=0.55 SMIN=0.50 RPSQ=0.062 }

DIELECTRIC D2 { THICKNESS=1.20 ER=3.9 }

See Also

•MEASURED_FROM

•THICKNESS

•TW_T

Chapter 18: ITF Statements and Options

THICKNESS_VS_DENSITY 18-95

Chapter 18: ITF Statements and Options

THICKNESS_VS_DENSITY 18-95

StarRC User Guide and Command Reference Version F-2011.06

THICKNESS_VS_DENSITY

Syntax

THICKNESS_VS_DENSITY [ RESISTIVE_ONLY | CAPACITIVE_ONLY ]

{(D1 R1) (D2 R2) (D3 R3) (D4 R4) ... }

Arguments

Argument Description

RESISTIVE_ONLY Applies thickness adjustment to resistance only

CAPACITIVE_ONLY Applies thickness adjustment to capacitance only

D1, D2, D3, D4, ... Density values

R1, R2, R3, R4, ... Relative changes in thickness.

(dT/Tnominal) negative R(dT/T) indicates a decrease in thickness

and vice versa. Even though, R(dT/T) can be any number

between -1 and 1, a number close to 1 or -1 is undesirable. R(dT/

T) cannot be -1.

Description

Use THICKNESS_VS_DENSITY to do one of two methods that assist you in thickness

computation: the single box (linear table) method or the multiple box method.

As shown in the example, the values can be separated by either a comma or space.

Single-Box Method

This option enables you to specify one box in a linear table method for density computation.

Choose a single box size and specify the thickness variation of the conductor in a table. The

box is assumed to be square and the default size of the box is 50 microns. This method does

not require the exhaustive characterization of a multiple box method. To specify the box, use

the DENSITY_BOX_WEIGHTING_FACTOR option.

For a linear table model, specify a multi-point thickness variation versus the density table in

the process file.

Chapter 18: ITF Statements and Options

THICKNESS_VS_DENSITY 18-96

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

The THICKNESS_VS_DENSITY variation affects both resistance and capacitance. However, if

the coefficients for resistance and capacitance are different, then use RESISTIVE_ONLY or

CAPACITANCE_ONLY. The values you specify only apply to the conductor’s resistance or

capacitance.

Multiple-Box Method

To specify a multiple box size and its weighting factor for effective density calculation, you

must characterize the wafer in greater detail than you do in the single box method. This

method is preferred when the single box method does not represent the process behavior.

The density box is assumed to be a square. The maximum size of a density box is 500

microns and the maximum number of boxes is 5.

Example

The following example shows the single-box method:

CONDUCTOR metal3 {

THICKNESS=0.5 SMIN=0.25 WMIN=0.25 RPSQ=0.01

THICKNESS_VS_DENSITY RESISTIVE_ONLY

{(0.1,-0.1) (0.2, 0.1)(0.3, 0.2)(0.4, 0.3)}

}

The following example shows the multiple-box method:

CONDUCTOR metal3 {

THICKNESS = 0.5 SMIN = 0.25 WMIN=0.25 RPSQ = 0.01

THICKNESS_VS_DENSITY{(0.1 -0.1)(0.2 0.1)(0.3 0.2)(0.4 0.3)}

DENSITY_BOX_WEIGHTING_FACTOR {

(10 1) (20 0.23) (30 0.29)

(40 0.18) (50 -0.12)

}

See Also

•DENSITY_BOX_WEIGHTING_FACTOR

•THICKNESS_VS_WIDTH_AND_SPACING

Chapter 18: ITF Statements and Options

THICKNESS_VS_WIDTH_AND_SPACING 18-97

Chapter 18: ITF Statements and Options

THICKNESS_VS_WIDTH_AND_SPACING 18-97

StarRC User Guide and Command Reference Version F-2011.06

THICKNESS_VS_WIDTH_AND_SPACING

Syntax

THICKNESS_VS_WIDTH_AND_SPACING

[ RESISTIVE_ONLY | CAPACITIVE_ONLY ] {

SPACINGS { S1 S2 }

WIDTHS ( W1 W2 }

VALUES { v(S1,W1) v(S2,W1) v(S1,W2) v(S2,W2) }

}

Arguments

Argument Description

RESISTIVE_ONLY Applies thickness adjustment to resistance only

CAPACITIVE_ONLY Applies thickness adjustment to capacitance only

SPACINGS Spacing values specified in ascending order

Units: microns

WIDTHS Width of a conductor. Values are specified in ascending order

Units: microns

VALUES Values represent the relative change in thickness for a conductor.

Order of the components of the values table is determined by the

indexes in the SPACINGS an WIDTHS table. Entry in the VALUES

table are ordered such that SPACINGS indexes change first for a

given index in the WIDTHS table and then this is repeated for all

indexes in the WIDTHS table.

Description

In this method, the variation of thickness as a function of the width of a conductor and

relative spacing to the neighboring conductor is modeled. The variation is modeled in an ITF

with THICKNESS_VS_WIDTH_AND_SPACING specified as a key word in a CONDUCTOR definition.

Chapter 18: ITF Statements and Options

THICKNESS_VS_WIDTH_AND_SPACING 18-98

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

This thickness variation can be either negative or positive. It is a very local phenomenon and

is independent of the density box. If specified with either single or multiple boxes, then this

thickness variation is computed independently from the density box. The effective thickness

is calculated with the following equation:

T Tnom 1 RTf Deff()RTf W S,()RTf SiW()++ +()×=

In this equation,

• Tnom is the nominal thickness specified in the ITF.

• RTf(Deff) is the relative thickness change due to density.

• RTf(W,S) is the relative change in thickness due to width and spacing.

• RTf(SiW) is the relative change in thickness due to silicon width.

The resistance and capacitance is computed after the effective thickness is computed.

Example

CONDUCTOR m1 {

THICKNESS = 0.60 WMIN 0.25 SMIN = 0.25

THICKNESS_VS_WIDTH_AND_SPACING {

SPACINGS { 0.25 0.30 0.50}

WIDTHS {0.25 0.4 0.50}

VALUES {0.3 0.2 0.1

0 -0.1 -0.20

-0.3 -0.2 -0.1}

}

See Also

•DENSITY_BOX_WEIGHTING_FACTOR

•THICKNESS_VS_DENSITY

Chapter 18: ITF Statements and Options

TO 18-99

Chapter 18: ITF Statements and Options

TO 18-99

StarRC User Guide and Command Reference Version F-2011.06

Specifies a conductor layer connected by the via.

Syntax

TO = layer

Arguments

Argument Description

layer The layer connected by the defined via

Description

The TO statement specifies the upper or lower layer connected by the via. A via can connect

only two conductor layers.

You specify this option within a VIA statement.

Example

VIA v1 {

FROM = m2

TO = m3

RPV = 40

AREA = 0.16

}

See Also

•FROM

Chapter 18: ITF Statements and Options

TSV 18-100

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

TSV

Describes a through-silicon via (TSV) layer.

Syntax

TSV tsv_name {

FROM = layer1

TO = layer2

RHO = rho_value

AREA = area_value

THICKNESS = thickness_value

INSULATION_THICKNESS = ins_thickness_value

INSULATION_ER = er_value

[CRT1 = lin_coeff] [CRT2 = quad_coeff] [T0 = nominal_temp]

}

Arguments

Argument Description

FROM = layer1 Conductor layer connected by the TSV

TO = layer2 Conductor layer connected by the TSV

RHO = rho_value Resistivity of the TSV

Units: ohm-microns

AREA = area_value Area of the TSV

Units: square microns

THICKNESS =

thickness_value

Thickness of the TSV

Units: microns

INSULATION_THICKNESS =

ins_thickness_value

Thickness of the insulation layer between the TSV and the

substrate

Units: microns

INSULATION_ER = er_value Relative permittivity of the TSV insulation layer

CRT1 = lin_coeff Layer-specific linear temperature coefficient

Default: 0

CRT2 = quad_coeff Layer-specific quadratic temperature coefficient

Default: 0

Chapter 18: ITF Statements and Options

TSV 18-101

Chapter 18: ITF Statements and Options

TSV 18-101

StarRC User Guide and Command Reference Version F-2011.06

Description

A through-silicon via (TSV) connects metal conductor layers on the frontside and the

backside of the silicon substrate, as shown in Figure 18-9.

Figure 18-9 Cross Section of Through-Silicon Via

To model a TSV, you must include descriptions of the frontside and backside layers in the

ITF file. The syntax of each ITF stack, either the frontside or the backside, follows the same

ITF syntax. Place the TSV statement after the frontside ITF statements and before the

backside ITF statements. For an example of an ITF file that describes a TSV, see “Through-

Silicon Via Process” in Appendix A.

Example

TSV tsv {

FROM=M1 TO=M1b

RHO=0.05 AREA=49.0 THICKNESS=20.0

INSULATION_THICKNESS=0.4 INSULATION_ER=5.5

CRT1=7.0e-03 CRT2=-3.0e-08 }

T0 = nominal_temp Nominal temperature for the layer

Units: degrees Celsius

Default: temperature specified by GLOBAL_TEMPERATURE

Argument Description

Chapter 18: ITF Statements and Options

TVF_ADJUSTMENT_TABLES 18-102

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

TVF_ADJUSTMENT_TABLES

Specifies tables to adjust the bottom thickness variation.

Syntax

TVF_ADJUSTMENT_TABLES {

[BOTTOM_THICKNESS_VS_WIDTH_AND_SPACING {

SPACINGS { S1 S2 ... }

WIDTHS { W1 W2 ... }

VALUES { V(S1, W1) V(S2, W1) ...

V(S1, W2) V(S2, W2) ...

}

}]

[BOTTOM_THICKNESS_VS_WIDTH_AND_DELTAPD {

DELTAPD { D1 D2 ... }

WIDTHS { W1 W2 ... }

VALUES { V(D1, W1) V(D2, W1) ...

V(D1, W2) V(D2, W2) ...

}

}]

}

Description

The TVF_ADJUSTMENT_TABLES statement specifies tables to adjust the bottom thickness

variation from the THICKNESS_VARIATION_FILE.

The TVF_ADJUSTMENT_TABLES statement allows the specification of one or both the

following tables:

•BOTTOM_THICKNESS_VS_WIDTH_AND_SPACING – Bottom thickness adjustment based on

the conductor width and the nearest spacing.

•BOTTOM_THICKNESS_VS_WIDTH_AND_DELTAPD – Bottom thickness adjustment based on

the conductor width and the neighboring tiles pattern density (PD).

These tables are utilized when you run StarRC with the THICKNESS_VARIATION_FILE option

for interfacing with a CMP simulator.

Chapter 18: ITF Statements and Options

TVF_ADJUSTMENT_TABLES 18-103

Chapter 18: ITF Statements and Options

TVF_ADJUSTMENT_TABLES 18-103

StarRC User Guide and Command Reference Version F-2011.06

Example

For example, for layer M1 in the previous tvf_adj.tab, the input in the ITF file should be:

CONDUCTOR M1 {

...

TVF_ADJUSTMENT_TABLES {

BOTTOM_THICKNESS_VS_WIDTH_AND_SPACING {

SPACINGS { 0.100000 0.200000 0.300000 }

WIDTHS { 0.060000 0.120000 0.240000 }

VALUES { 0.500000 0.150000 0.250000

0.100000 0.250000 0.350000

0.150000 0.350000 0.450000

}

BOTTOM_THICKNESS_VS_WIDTH_AND_DELTAPD {

DELTAPD { -0.750000 -0.500000 0.000000 0.500000 0.750000 }

WIDTHS { 0.060000 0.120000 0.240000 }

VALUES { 0.150000 0.500000 0.000000 -0.500000 -0.150000

0.150000 0.500000 0.000000 -0.500000 -0.150000

}

Note that one of the tables inside the TVF_ADJUSTMENT_TABLES could be missing. In this

case, put a "0" for the missing table in the output tvf_adj.tab file.

See Also

•TVF_ADJUSTMENT_TABLES

Chapter 18: ITF Statements and Options

TW_T 18-104

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

TW_T

Syntax

TW_T = float

Arguments

Argument Description

float Topwall thickness

Units: microns

Default: thickness value of the dielectric

Description

Defines the topwall thickness of a conformal layer. TW_T=0 is allowed for conformal

dielectrics. An error message is issued if TW_T is between 0 and 0.005 microns as values

below 0.005 are not allowed. If not specified, the THICKNESS of the dielectric is used as

TW_T.

Example

DIELECTRIC D3 {

THICKNESS=0.2 MEASURE_FROM=TOP_OF_CHIP

SW_T=0.15 TW_T=0.18 ER=5.9

}

See Also

•MEASURED_FROM

•SW_T

•THICKNESS

Chapter 18: ITF Statements and Options

USE_SI_DENSITY 18-105

Chapter 18: ITF Statements and Options

USE_SI_DENSITY 18-105

StarRC User Guide and Command Reference Version F-2011.06

USE_SI_DENSITY

Specifies the density-based thickness variation effect.

Syntax

USE_SI_DENSITY = YES | NO

Arguments

Argument Description

YES Specifies that the thickness variation computation is based on

silicon density.

NO Specifies that the thickness variation computation is based on

drawn (database) density.

This is the default.

Description

Use this optional statement in the ITF when the density-based (THICKNESS_VS_DENSITY or

POLYNOMIAL_BASED_THICKNESS_VARIATION) thickness variation effect applies to silicon

density rather than drawn density.

Example

USE_SI_DENSITY = YES

See Also

•POLYNOMIAL_BASED_THICKNESS_VARIATION

•THICKNESS_VS_DENSITY

Chapter 18: ITF Statements and Options

VARIATION_PARAMETERS 18-106

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

VARIATION_PARAMETERS

Defines variation parameters for a variation-aware ITF file.

Syntax

VARIATION_PARAMETERS {

param1 = {(layer, param_type, coeff_of_variation)

(layer, param_type, coeff_of_variation)

param2 = {(layer, param_type, coeff_of_variation)

(layer, param_type, coeff_of_variation)

...

}

Arguments

Argument Description

param Variation parameter name

layer Layer name

coeff_of_variation Coefficient of variation

param_type Type of parameter. THICKNESS, WIDTH, RHO, and ER are supported.

Description

You can create a variation-aware ITF file by appending variation parameters. The format you

specify in the ITF to represent parameter variations is added to the existing nonvariation-

aware ITF file. There is no need for you to modify the process cross-section or values in the

nominal ITF file.

For more information about the variation-aware ITF format, see Chapter 11, “Variation-

Aware Extraction."

See Also

•SENSITIVITY

Chapter 18: ITF Statements and Options

VIA 18-107

Chapter 18: ITF Statements and Options

VIA 18-107

StarRC User Guide and Command Reference Version F-2011.06

VIA

Describes the properties of a via layer.

Syntax

VIA via_name {

FROM = layer1

TO = layer2

[CRT1 = lin_coeff

| [CRT2 = quad_coeff]

| [CRT_VS_AREA {...}]

| [TO = nominal_temp]]

[RHO = rho_value

| RPV = rpv_value AREA = area_value

| RPV_VS_AREA {...}]

[ETCH_VS_CONTACT_AND_GATE_SPACINGS CAPACITIVE_ONLY {...}

| ETCH_VS_WIDTH_AND_SPACING CAPACITIVE_ONLY {...}

| ETCH_VS_WIDTH_AND_LENGTH CAPACITATIVE_ONLY {...}]

}

Arguments

Argument Description

FROM = layer1 Upper conductor layer connected by the via

TO = layer2 Lower conductor layer connected by the via

CRT1 = lin_coeff Layer-specific linear temperature coefficient

Default: 0

CRT2 = quad_coeff Layer-specific quadratic temperature coefficient

Default: 0

T0 = nominal_temp Nominal temperature for the layer

Units: degrees Celsius

Default: temperature specified by GLOBAL_TEMPERATURE

RHO = rho_value Bulk resistivity of the via or conductor layer.

Units: ohm-microns

Default: RPV x AREA

RPV = rpv_value Resistance per default via

Units: ohms

Chapter 18: ITF Statements and Options

VIA 18-108

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Description

The VIA statement describes the properties of a via layer such as area, resistance,

nonlinear resistance behavior, and the conductor layers connected by the via.

You can must specify the resistive properties of the via layer with one of the following

methods:

•Specify RHO only

• Specify both RPV and AREA

• Specify an RPV_VS_AREA table

Example

The following example shows a simple VIA statement:

VIA VIA1 { FROM=M1 TO=M2 AREA=0.36 RPV=4 }

The following example shows the syntax for a contact bias 2-D etch table:

ETCH_VS_CONTACT_AND_GATE_SPACINGS {

CONTACT_SPACING {c1 c2 c3}

GATE_SPACING (s1 s2 s3 ... }

VALUES { v(c1, s1) v(c2, s1)

v(c1, s2) v(c2, s2) }

}

See Also

•ETCH_VS_CONTACT_AND_GATE_SPACINGS

•RPV_VS_AREA

AREA = area_value Area of default via

Units: square microns

Default: 1.0e -6 / RPV

Argument Description

Chapter 18: ITF Statements and Options

WMIN 18-109

Chapter 18: ITF Statements and Options

WMIN 18-109

StarRC User Guide and Command Reference Version F-2011.06

WMIN

Specifies the minimum width of a conductor.

Syntax

WMIN = float

Arguments

Argument Description

float The minimum width of the layer

Units: microns

Description

Minimum width of a conductor geometry on a layer. This option must be specified in a

CONDUCTOR statement.

Example

CONDUCTOR metal1 {

THICKNESS=1.00 WMIN=0.13 SMIN=0.15 RPSQ=0.015

}

See Also

•SMIN

Chapter 18: ITF Statements and Options

WMIN 18-110

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

19-1

The grdgenxo Command 19

The grdgenxo command is an executable that generates the nxtgrd file. The output file

(*nxtgrd) is a database containing capacitance, resistance, inductance, and layer

information that first undergoes process characterization and is then compiled by the

grdgenxo command function.

This chapter contains the following sections:

•Command Details

•Examples

•Incremental grdgenxo

•Reference Indications

•Error and Warning Conditions

Chapter 19: The grdgenxo Command

Command Details 19-2

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Command Details

Syntax

grdgenxo

[-encrypt]

[-f format_file]

[-h]

-i itf_file

[-inc]

[-itf2TLUPlus]

[-jpg jpg_filename]

-o TLUPlus_filename

[-parse]

[-res_update]

[-usage]

[-V]

Argument Description

-encrypt Writes an encrypted ITF file into the grdgenxo file.

-f format_file Include format file name.

-h Shows command-line options.

-i itf_file Includes the specified ITF file.

-inc Activates an incremental update of grdgenxo.

-itf2TLUPlus Generates a TLUPlus model from an ITF file. This argument

must be specified first in the syntax. The units are fixed as fF

and ohm.

-o TLUPlus_filename Outputs TLUPlus model file name.

-parse Parses ITF file only to check for syntax errors, without starting

an nxtgrd file generation. Messages are reported when syntax

errors are found. If no errors are found, a confirmation message

is given and grdgenxo terminates.

-res_update Allows the update of resistance parameters (such as RPSQ,

RHO_VS_WIDTH_AND_SPACING) in the nxtgrd file from a new ITF

file without processing through the field solver.

-usage Shows command-line options.

-V Includes the version number in the generated grdgenxo file.

Chapter 19: The grdgenxo Command

Examples 19-3

Chapter 19: The grdgenxo Command

Examples 19-3

StarRC User Guide and Command Reference Version F-2011.06

Description

The grdgenxo command-line executable takes a prepared Interconnect Technology Format

(ITF) file or model as input and generates the nxtgrd database. This nxtgrd file is your data

after StarRC process characterization. For more information about process

characterization, see Chapter 3, “Process Characterization Interface.”

The incremental capability lets you run incremental, or successive, grdgenxo runs in the

original run directory after modifications to the ITF file. With the -inc option, grdgenxo

recognizes the modified layers in the ITF for successive grdgenxo runs and regenerates the

capacitance models (for the changed layers only).

The grdgenxo function generates messages when process characterization errors are

found. These messages are displayed on your screen when the command functions.

Examples

This section explains the details of how to use the grdgenxo syntax to accomplish certain

tasks. See the command argument section for details about required and optional

arguments.

Generating a grdgenxo File

To generate a grdgenxo file, use the following syntax. The grdgenxo command followed by

your specified input ITF file are required. The other arguments are optional.

grdgenxo [-h] [-usage] [-V] itf_file

Reading grdgenxo Output

The grdgenxo capacitance tables in the nxtgrd file are written in binary format by default to

save disk space and to enhance parsing time. StarRC can read nxtgrd files in both binary

format and ASCII for backward compatibility.

The ITF copy (at the top of the nxtgrd file) can be encrypted by using the command-line

option -encrypt with grdgenxo. Note that nxtgrd files created with version V-2004.06 are

not backward compatible with earlier versions of StarRC.

Parsing a File

To parse the ITF file to check only for syntax errors, without starting an nxtgrd file generation,

use the following syntax:

grdgenxo -parse itf_file

Chapter 19: The grdgenxo Command

Examples 19-4

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Updating an nxtgrd Database Incrementally

To update an nxtgrd database incrementally after being generated by grdgenxo, use the

following syntax:

grdgenxo -inc itf_file

See “Incremental grdgenxo” on page 19-6 for more details.

To run an incremental process characterization, you need to specify the following command

and options where the nxtgrd database directory is located.

grdgenxo -inc new_itf_file

Before an incremental update of the nxtgrd file can be done, StarRC must make a

comparison between the ITF file used to generate the database and its incrementally

modified version. StarRC does this comparison internally.

Updating an nxtgrd Database From a New ITF File

You can update an nxtgrd database from a new ITF file using the -res_update option to

grdgenxo. StarRC modifies an already existing nxtgrd file to a new nxtgrd file based on

information derived from a new ITF file. To do this, specify the following command:

grdgenxo -res_update new_itf_file -i old_nxtgrd_file -o new_nxtgrd_file

This method allows you to update an nxtgrd file while avoiding field solver processing which

saves computing time. The version number and time stamp is not updated; their original

values are kept intact.

StarRC issues an error message and terminates the job if one of the following conditions

occur:

• If an attempt is made to combine the nxtgrd function -which is a stand-alone

command-line procedure- with other command-line options, such as -inc or any others.

• If an attempt is made to update the nxtgrd file when it is encrypted.

• If an attempt is made to update the nxtgrd file introducing new resistance parameters into

it.

• If an attempt is made to update the nxtgrd file, using ITF parameters not listed in the

following since these affect capacitance models:

Chapter 19: The grdgenxo Command

Examples 19-5

Chapter 19: The grdgenxo Command

Examples 19-5

StarRC User Guide and Command Reference Version F-2011.06

AIR_GAP_VS_SPACING, BACKGROUND_ER, CAPACITIVE_ONLY_ETCH, DAMAGE_ER,

DAMAGE_THICKNESS, DROP_FACTOR, DROP_FACTOR_LATERAL_SPACING, ER, ETCH,

ETCH_VS_CONTACT_AND_GATE_SPACING,ETCH_VS_WIDTH_AND_SPACING: CAPACITIVE,

ETCH_VS_WIDTH_AND_SPACING:ETCH_FROM_TOP, FILL_TYPE, FILL_RATIO,

FILL_SPACING, FILL_WIDTH, GATE_TO_CONTACT_SMIN, MEASURED_FROM, NAME (of

dielectric layer),SIDE_TANGENT, SMIN, SW_T, THICKNESS,

THICKNESS_VS_DENSITY: CAPACITIVE, THICKNESS_VS_WIDTH_AND_SPACING:

CAPACITIVE, TW_T,WMIN, number of layers (conductor, dielectric, via)

Deciding When to Regenerate nxtgrd Capacitance Models

When the field solver utility, grdgenxo, generates a nxtgrd file from an ITF process file

description, it generates a directory of intermediate process characterization files. When the

run is complete, these files are compiled into a single capacitance modeling regression

database: the nxtgrd file.

If you would like to make minor, incremental changes to an ITF process description after a

nxtgrd file has been created, rerun grdgenxo using the previous run directory capacitance

table results.

You can run grdgenxo on a previous run directory only when using the same version of

grdgenxo, and only if the changes you have made to the ITF file do not affect the capacitive

tables. If you are unsure which parameters affect capacitive tables, remove the previous run

directory and regenerate all capacitance tables.

When generating nxtgrd files, keep in mind that you can spawn many grdgenxo processes

(there is no licensing limitation) and the speedup is proportional to the number of CPUs.

Commands that would not affect the capacitive tables include RESISTIVE_ONLY_ETCH and

RPSQ.

Commands that would affect capacitive tables include THICKNESS, SMIN, and WMIN

In grdgenxo (release X-2005.06 and later) changes made to CONDUCTOR parameters are

automatically removed and the capacitive tables regenerated. This can improve grdgenxo

runtime significantly. This incremental capability does not pertain to DIELECTRIC thickness

changes because these impact all capacitive models. Use the -inc command-line option for

this capability and verify that the previous grdgenxo run directory still exists.

TLUPlus Model Generation

Generate a TLUPlus model using the following syntax.

grdgenxo -itf2TLUPlus -i itf_file [-f format_file] -o TLUPlus_file

Note:

For an ift2TLUPlus model generation, the units are fF and ohms.

Chapter 19: The grdgenxo Command

Incremental grdgenxo 19-6

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Distributed Processing

When generating nxtgrd files, you can spawn many grdgenxo processes (there is no

licensing limitation), and the speed increase is proportional to the number of CPUs. This can

be distributed across platforms and machines.

To enable grdgenxo distributed processing,

1. Start an additional process from a different host, or CPU, in the same working directory.

2. Ensure that the grdgenxo versions are the same. To verify this, use the command:

% which grdgenxo

% telnet otherMachine

% cd path/same_working_DIR

% grdgenxo same_ITF_file

You can add additional CPUs at any time. The increased speed is nearly linear with the

number of CPUs. The distributed processing mechanism is fault tolerant. That means, if one

machine dies, the other CPUs continue and complete the remaining characterization tasks.

Incremental grdgenxo

The incremental function of the grdgenxo command lets you update an nxtgrd database

using a modified ITF file. This can save significant development time.

You supply the latest ITF file in the working directory and specify the -inc option when

running grdgenxo. The -inc option distinguishes the run as an incremental generation and

only updates the differences found between the original ITF file information and the new ITF

file you specify.

To run incremental process characterization you need to specify the following command and

options where the nxtgrd database directory is located:

grdgenxo -inc itf_file

Before an incremental update of the nxtgrd file can be done, StarRC must make a

comparison between the ITF file used to generate the database and its incrementally

modified version. StarRC does this comparison internally. Whenever the incremental option

is specified, both of the ITF files should be available for comparison.

In a distributed processing environment, grdgenxo undertakes additional checking to verify

that all processors are using the same ITF file.

Chapter 19: The grdgenxo Command

Reference Indications 19-7

Chapter 19: The grdgenxo Command

Reference Indications 19-7

StarRC User Guide and Command Reference Version F-2011.06

Limitations to Using the Incremental Argument

Data modification using the following conducting layer options has a localized effect on

capacitance values. Therefore, changes can be incrementally updated into an existing

nxtgrd database when desired. The following keyword changes to in the CONDUCTOR

statement are supported:

AIR_GAP_VS_SPACING

CAPACITIVE_ONLY_ETCH

ETCH

ETCH_VS_WIDTH_AND_SPACING

ETCH_VS_WIDTH_AND_SPACING: CAPACITIVE_ONLY

ETCH_VS_WIDTH_AND_SPACING: ETCH_FROM_TOP

MEASURED_FROM

SIDE_TANGENT

SMIN

THICKNESS

WMIN

Modification of the following layer options has more extensive effect on capacitance values

because their effect on the design is global. The following keyword changes to in the

CONDUCTOR statement are not supported:

DROP_FACTOR

FILL_RATIO

FILL_SPACING

FILL_WIDTH

FILL_TYPE

The following ITF file changes are not allowed:

• Any changes to dielectric layers have a wide range of implications on capacitance values.

You should run grdgenxo from the beginning without the incremental option under the

following circumstances.

• Changes that make a difference between total number of conductors or dielectrics.

• Removal of a conductor.

• Modification of resistance and related data on conducting layers is supported.

Reference Indications

The following sections describe suggestions that might assist you when running the

grdgenxo command.

Chapter 19: The grdgenxo Command

Error and Warning Conditions 19-8

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

ITF File Preparation

• If you have added the ETCH_VS_WIDTH_AND_SPACING option to your existing ITF file, you

must rerun grdgenxo after removing the working directory.

• Inappropriate WMIN and SMIN values specified in your ITF file can cause unwanted opens

or shorts of the neighboring layers by applying the etch values provided in the table. In

such a case, a message is printed during the grdgenxo run.

• If the width value in the THICKNESS_VS_DENSITY table is not sorted, grdgenxo sorts it.

Working With Models

• TLUPlus models are generated using grdgenxo from StarRC. A description of the

process must be provided in your ITF file. This can be created by you or supplied by a

CAD design group or foundry. See Chapter 3, “Process Characterization Interface.”

Error and Warning Conditions

This section explains several error and warning conditions specific to the grdgenxo function.

• In a distributed processing (DP) environment, the ITF file name and path specified for

each processor is compared to the ITF specified for the main processor. An error

message is issued, and job execution terminated if the file paths and names are different.

• If the total number of dielectric and/or conducting layers between an updated or

incremental ITF file are not the same as the original saved ITF file, an error message is

issued and execution is terminated. These files cannot be updated using an incremental

update; a completely new grdgenxo generation is necessary.

• Changes you make in an ITF file involving dielectric layers have extensive implications for

capacitance values. In this case, a completely new run of grdgenxo is necessary. An

error message is issued and the job terminates.

• The modification of a conducting layer involving metal fill and drop factor is not supported,

because of their extensive effects on capacitance values. An error message is issued and

the job is terminated. A complete new run of grdgenxo is necessary.

• If grdgenxo is not reading your format file for TLUPlus generation, see “Generating

TLUPlus Models” on page 3-48.

20-1

Mapping File Commands 20

Each database imported to StarRC must be accompanied by a mapping file that links each

physical database layer to a TCAD GRD modeled layer. This chapter describes the

commands that you use in a StarRC mapping file.

Although there is no restriction on the order in which these commands are listed in your file,

you should specify them in the following order:

•conducting_layers

•via_layers

•marker_layers

•remove_layers

•viewonly_layers

•ignore_cap_layers

Chapter 20: Mapping File Commands

conducting_layers 20-2

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

conducting_layers

Maps a conducting layer from the layout database to a conductor in the tcad_grd file.

Syntax

conducting_layers

database_layer grd_layer [device_layer] [rpsq=rpsq_value]

MODEL=model_name

[diffusion_res_model=diff_res_model_name]

Arguments

Argument Description

database_layer Conducting layer name in the design database.

grd_layer Conductor name in the technology file (ITF or nxtgrd) file. Can

also be the SUBSTRATE.

rpsq_value Resistance per square for the design database layer.

model_name Model for parasitic netlist output. The value for this argument is a

string. This value is used by StarRC to write out model names for

parasitic resistors in a parasitic netlist. It is required that all

conducting layers be mapped to a model if you specify the

NETLIST_PARASITIC_RESISTOR_MODEL command. If you

have not specified a corresponding resistor MODEL in the

database, no model will be printed to the parasitic netlist for that

resistor. A warning is issued in the StarRC summary file.

device_layer Layer for resistance extraction of power nets. Specify this

keyword in your mapping file when you are using

POWER_EXTRACT: DEVICE_LAYERS in the command file. The

device_layer keyword can be specified in any order in the

mapping file for the conducting layers when RPSQ and device

model options are used.

diff_res_model_name Model name for user-defined diffusion resistance extraction. The

final netlist prints the model name for the corresponding contact

and device gate as netlist tail comments.

Default: NA

Description

Use the conducting_layers command to map a conducting layer from the layout database

(routing layers, device terminal layers, device layers, and so on) to a conductor in the

TCAD_grd file.

Chapter 20: Mapping File Commands

conducting_layers 20-3

Chapter 20: Mapping File Commands

conducting_layers 20-3

StarRC User Guide and Command Reference Version F-2011.06

Note:

For TCAD GRD layers which use RPSQ_VS_SI_WIDTH or RPSQ_VS_WIDTH_AND_SPACING,

RPSQ override is only possible if specifying RPSQ=0 in the conducting_layers section. A

non-zero RPSQ override in the conducting_layers section is not possible for TCAD GRD

layers using these two resistance modeling functions. You can override the sheet

resistance value contained in the TCAD GRD to which the database is being mapped by

specifying the rpsq value (ohms/sq).

The GRD layers appearing in this category can only be TCAD GRD CONDUCTOR layers. You

can map a database layer to the substrate in this category by specifying SUBSTRATE as the

GRD layer.

Example

Example 20-1

conducting_layers

m2 metal2

m1 metal1

nsd SUBSTRATE

psd SUBSTRATE

Example 20-2

conducting_layers

database_layer GRD_layer RPSQ = rpsq_value MODEL = model_name

database_layer GRD_layer MODEL = model_name

database_layer GRD_layer MODEL = model_name RPSQ = rpsq_value

Example 20-3

conducting_layers

M2 metal2

M1 metal1

POLY fpoly

nsd SUBSTRATE device_layer RPSQ=0.5

psd SUBSTRATE device_layer

welltie SUBSTRATE

subtie SUBSTRATE

ngate gpoly device_layer

pgate gpoly

NWELL SUBSTRATE

via_layers

V1 via1

POLY_CONT polyCont device_layer

DIFF_CONT diffCont device_layer RPV=0.5

When you define multiple Cf tables in the ITF file, the device gate layer that maps to the

corresponding table name must be specified in the StarRC mapping file. To look up the

appropriate gate-to-diffusion table, use the mapping file syntax shown in the following

example.

Chapter 20: Mapping File Commands

conducting_layers 20-4

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Example 20-3 Mapping File for Multiple Tables in the ITF File

conducting_layers

gate database_layer gate grd_layer [table_name=keyword]

If table_name is defined for a gate, StarRC will find and use the corresponding

gate-diffusion capacitance table with same NAME in ITF file.

The following example shows a mapping file that you can use to lookup corresponding

gate-to-diffusion capacitance tables:

conducting_layers

ngate gpoly table_name=NMOS

pgate gpoly table_name=PMOS

tngate gpoly

tpgate gpoly

Given the previous mapping file definition, devices with “ngate” as the gate poly will use the

gate to diffusion capacitance table under NMOS, and devices with “pgate” as the gate poly

will use tables with the PMOS table name in ITF file.

No gate to diffusion capacitance lookup will be applied to the devices with “tngate” and

“tpgate” gates.

Mapping File for User-Defined Diffusion Resistance

The following example shows a mapping file with a model name specified for the

user-defined diffusion resistance extraction flow:

conducting_layers

ngate poly diffusion_res_model=n_high

The final netlist will contain the model name n_high for the contact and its associated device

gate as netlist tail comments. The tail comments are not affected by reduction settings.

See Also

•MAPPING_FILE

•TCAD_GRD_FILE

•POWER_EXTRACT: DEVICE_LAYERS

Chapter 20: Mapping File Commands

via_layers 20-5

Chapter 20: Mapping File Commands

via_layers 20-5

StarRC User Guide and Command Reference Version F-2011.06

via_layers

Maps a via layer in the database to a via layer in the tcad_grd file.

Syntax

via_layers

database_layer grd_layer [device_layer]

[rpv=rpv_value]

[area=via_area]

[MODEL=model_name]

[MAX_VIA_ARRAY_LENGTH = length_in_microns]

[MAX_VIA_ARRAY_SPACING = spacing_in_microns]

Arguments

Argument Description

database_layer Via layer in the design database.

grd_layer Via layer in the in the technology file, ITF, or nxtgrd file.

device_layer Layer for the resistance extraction of power nets. Specify this

keyword in your mapping file when you are using

POWER_EXTRACT:DEVICE_LAYERS in the command file. The

device_layer keyword can be specified in any order in the

mapping file for the via layers when RPV, device model, or via

merging options are used.

rpv = rpv_value Resistance per via.

Units: ohms per via

area = via_area Area of the via.

Units: square microns

MODEL = model_name Specifies a model for parasitic netlist output. The value for this

argument is a string. This value is used by StarRC to write out model

names for parasitic resistors in a parasitic netlist. It is required that

all via layers be mapped to a model if you specify the

NETLIST_PARASITIC_RESISTOR_MODEL command.

If you have not specified a corresponding resistor MODEL in the

database, no model will be printed to the parasitic netlist for that

resistor. A warning is issued in the StarRC summary file.

Chapter 20: Mapping File Commands

via_layers 20-6

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Description

The via_layers statement maps a via layer in the database to a via layer in the tcad_grd file.

You can override the via resistance value contained in the TCAD GRD to which the database

is being mapped, by specifying the rpv_value value and the via_area. The GRD layers

appearing in this category can be only TCAD GRD via layers.

Example

Example 20-4 via_layers Statement

via_layers

V2 via2

V1 via1

SubCont Cont rpv=10 area=0.04

PolyCont Cont rpv=8 area=0.04

Example 20-5 via_layers Statement With Optional device_layer

via_layers

V1 via1

POLY_CONT polyCont device_layer

DIFF_CONT diffCont device_layer rpv=0.5

See Also

•MAPPING_FILE

•TCAD_GRD_FILE

•RPV_VS_AREA

•POWER_EXTRACT: DEVICE_LAYERS

MAX_VIA_ARRAY_LENGTH

= length_in_microns

Specifies the length of a via array to be reduced to a single via.

If you do not specify this argument, an array with via spacing less

than or equal to MAX_VIA_ARRAY_SPACING is reduced to one via

and eventually to one resistor.

Units: microns

Default: 20

MAX_VIA_ARRAY_SPACING

= spacing_in_microns

Specifies the via-to-via spacing. This argument merges vias that lie

within the specified spacing. The merging of vias is restricted by the

MAX_VIA_ARRAY_LENGTH argument.

Typically, you should set MAX_VIA_ARRAY_LENGTH to the DRC

spacing rule for that via layer.

Units: microns

Default: none

Argument Description

Chapter 20: Mapping File Commands

marker_layers 20-7

Chapter 20: Mapping File Commands

marker_layers 20-7

StarRC User Guide and Command Reference Version F-2011.06

marker_layers

Specifies marker layers.

Syntax

marker_layers

database_layer

Arguments

Argument Description

database_layer Name of marker layer in the design database

Description

This command is applicable only in a Hercules flow. Marker layers are objects optionally

derived from text interactions to identify special nets that will become either primary input or

output ports or SKIP_CELLS ports (instance pins) in the StarRC output parasitic netlist.

Example

marker_layers

metal1_pin

poly_pin

metal7_pio

See Also

•MAPPING_FILE

Chapter 20: Mapping File Commands

remove_layers 20-8

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

remove_layers

Specifies layers to be ignored by the extractor.

Syntax

remove_layers

database_layers

Arguments

Argument Description

database_layer Name of the design database layer

Description

The remove_layers command specifies layers to be ignored by the extractor.

Note:

Removing database layers can affect the connectivity of the output parasitic netlist. An

extraction under typical conditions should not require the use of this mapping category.

Example

remove_layers

ntap

ptap

tndiff

tpdiff

See Also

•MAPPING_FILE

Chapter 20: Mapping File Commands

viewonly_layers 20-9

Chapter 20: Mapping File Commands

viewonly_layers 20-9

StarRC User Guide and Command Reference Version F-2011.06

viewonly_layers

Specifies view-only layers to be written to the StarRC extracted view.

Syntax

viewonly_layers

database_layers

Arguments

Argument Description

database_layer Name of the design database layer

Description

The viewonly_layers command specifies the view-only (nonconnectivity) layers to be

written to the StarRC extracted view. The layers specified in this command are written to the

extracted view in the same way as the connectivity layers.

To make the view-only layers visible in the Open Access (OA) view, you must also map these

layers in the layer purpose pair (LPP) mapping file.

Example

The following example shows a portion of a StarRC layer mapping file:

...

remove_layers

nwdiode25_dio

nwdiode33_dio

viewonly_layers

medvtp

...

The following example shows the corresponding LPP mapping file:

...

M5PIN poly drawing poly net poly subnode

M6PIN poly drawing poly net poly subnode

M7PIN poly drawing poly net poly subnode

M8PIN poly drawing poly net poly subnode

M9PIN poly drawing poly net poly subnode

POLYPIN poly drawing poly net poly subnode

medvtp medvtp drawing nil nil nil nil

...

Chapter 20: Mapping File Commands

ignore_cap_layers 20-10

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

ignore_cap_layers

Specifies that the capacitance between certain design database layer-to-layer interactions

is to be ignored.

Syntax

ignore_cap_layers

layer_name1 layer_name2 [layer_name3 ...]

[layer_name1 layer_name2 [layer_name3 ...]]

Arguments

Argument Description

layer_name

layer_name L=value

Input design database layer names. Values (L=value) can be

added to ignore areas to gate and substrate.

NGATE NSD L=value Specifies the n-diffusion length (L=value) for which you want to

ignore the capacitance to the particular NGATE source/drain.

Can be specified for only MOS transistors. If a layer pair is not

part of a MOS definition, a warning is issued.

PGATE PSD L=value Specify the p-diffusion length (L=value of which you want to

ignore the capacitance to the particular NGATE source/drain.

Can be specified for only MOS transistors. If a layer pair is not

part of a MOS definition, a warning is issued.

nsd SUBSTRATE L=value Specify the n-diffusion to substrate length of which you want to

ignore the capacitance.

psd SUBSTRATE L=value Specify the p-diffusion to substrate length for which you want to

ignore the capacitance.

Description

The ignore_cap_layers command specifies that the capacitance between certain design

database layer-to-layer interactions is to be ignored. In addition, you can specify a length

value (or distance) of diffusion where capacitances are ignored.

To partially ignore capacitances for source/drain transistor areas to gate and substrate, use

L=value. This means StarRC ignores the capacitance up to the amount you specify. The

total capacitance on the net with specified capacitance will increase when an L value is

specified.

• All parallel-plate and fringing capacitance components between a specified layer pair are

omitted from the parasitic netlist.

Chapter 20: Mapping File Commands

ignore_cap_layers 20-11

Chapter 20: Mapping File Commands

ignore_cap_layers 20-11

StarRC User Guide and Command Reference Version F-2011.06

• If you specify a design database layer in the ignore_cap_layers section of the mapping

layers file, this function acts independently from the function of the IGNORE_CAPACITANCE

command regardless of the IGNORE_CAPACITANCE setting.

• If more than 2 layers are specified, all the capacitance between every possible

combination is ignored. To ignore the capacitance between the polygons of the same

layer, specify the same layer twice.

The field solver modes FSCOMPARE and FS_EXTRACT_NETS interpret a specified

ignore_cap_layers section when producing field solver results for accuracy validation and/or

netlisting.

Figure 20-1 shows capacitance applied to MOS source and drain.

Figure 20-1 Applying Capacitance to MOS Source/Drain

ngatensd nsd

Area modeled in SPICE

Partially Ignoring Gate Capacitance

Normally StarRC ignores all capacitance between a gate to a source or drain terminal of a

metal oxide semiconductor (MOS) transistor. This is acceptable when the complete

capacitance of that MOS transistor is present in the SPICE model. However, in some cases

the drawn devices have larger source or drain areas than the characterized transistors. To

ignore them completely makes the design inaccurate.

The partial ignoring of gate capacitance can now be specified to help you avoid the double

counting of capacitance already modeled in the device. See Figure 20-2 on page 20-12. To

do this, set a length parameter in the ignore cap section of your mapping file for the specified

layer pair using the ignore_cap_layers command.

Chapter 20: Mapping File Commands

ignore_cap_layers 20-12

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

The conditions under which the length parameter is supported are as follows:

• Both layer1 and layer2 for the specified layer pair should be part of the MOSFET device.

The layer can be the gate terminal layer or substrate while the other is the source/drain

terminal layer.

• The value of ignore_cap_layer must be positive.

Figure 20-2 Defining a Partial Distance to Ignore

C12 C11 C7 C9

C10 C2 C5 C6

C4 C8

C1 C3

gate

source/drain

substrate

ignored area

Example

The following shows a simple example:

ignore_cap_layers

tn_diff NSD nnsd

m1_cap_term SUBSTRATE

The following example specifies a length value for source/drain of the MOS transistor to

partially ignore capacitance, which can cause the total capacitance on a net to increase.

ignore_cap_layers

ngate NSD L=0.1

pgate PSD L=0.1

nsd SUBSTRATE L=0.1

psd SUBSTRATE L=0.1

Chapter 20: Mapping File Commands

ignore_cap_layers 20-13

Chapter 20: Mapping File Commands

ignore_cap_layers 20-13

StarRC User Guide and Command Reference Version F-2011.06

See Also

•MAPPING_FILE

Chapter 20: Mapping File Commands

ignore_cap_layers 20-14

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

A-1

ITF Examples A

This appendix contains examples of ITF files for several process technologies. Each of the

following sections contains a sample ITF file and a diagram of the process cross section:

•Fully Planar Process

•Conformal Dielectric Process

•Gate Poly Process

•Local Interconnect Process

•Dielectric Air Gaps Process

•Layer Etch Process

•Metal Fill Process (Emulated)

•Transistor-Level Process

•Through-Silicon Via Process

Appendix A: ITF Examples

Fully Planar Process A-2

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Fully Planar Process

The following example ITF file describes the fully planar process shown in Figure A-1.

TECHNOLOGY = planar

DIELECTRIC TOP { THICKNESS=3.4 ER=3.9 }

DIELECTRIC D3 { THICKNESS=0.2 ER=4.7 }

CONDUCTOR M2 { THICKNESS=0.6 WMIN=0.5 SMIN=0.5 RPSQ=0.05 }

DIELECTRIC D2 { THICKNESS=1.2 ER=3.9 }

CONDUCTOR M1 { THICKNESS=0.6 WMIN=0.3 SMIN=0.3 RPSQ=0.05 }

DIELECTRIC D1 { THICKNESS=0.725 ER=3.9 }

CONDUCTOR POLY{ THICKNESS=0.125 WMIN=0.3 SMIN=0.3 RPSQ=10.0

}

DIELECTRIC D0{ THICKNESS=0.375 ER=3.9 }

VIA sub_tie { FROM=SUBSTRATE TO=M1 AREA=0.25 RPV=5 }

VIA poly_cont { FROM=POLY TO=M1 AREA=0.25 RPV=4 }

VIA via { FROM=M1 TO=M2 AREA=0.36 RPV=4 }

Figure A-1 Fully Planar Process

POLY

0.2

0.725

1.2

0.125

0.375

SUBSTRATE

3.4

0.6

TOP

Chapter A: ITF Examples

Conformal Dielectric Process A-3

Appendix A: ITF Examples

Conformal Dielectric Process A-3

StarRC User Guide and Command Reference Version F-2011.06

Conformal Dielectric Process

The following example ITF file describes the conformal dielectric process shown in

Figure A-2.

TECHNOLOGY = conformal

$ TOP is planarized by measuring from D2

DIELECTRIC TOP { THICKNESS=3.6 MEASURED_FROM=D2 ER=3.9 }

$ D3 is a conformal dielectric

DIELECTRIC D3 {

THICKNESS=0.2 MEASURED_FROM=TOP_OF_CHIP

SW_T=0.15 TW_T=0.18 ER=5.9 }

CONDUCTOR M2 { THICKNESS=0.6 WMIN=0.5 SMIN=0.5 RPSQ=0.05 }

DIELECTRIC D2 { THICKNESS=1.2 ER=3.9 }

CONDUCTOR M1 { THICKNESS=0.6 WMIN=0.3 SMIN=0.3 RPSQ=0.05 }

DIELECTRIC D1 { THICKNESS=0.725 ER=3.9 }

CONDUCTOR POLY { THICKNESS=0.125 WMIN=0.3 SMIN=0.3 RPSQ=10.0

}

DIELECTRIC D0 { THICKNESS=0.375 ER=3.9 }

VIA DIFF_CONT { FROM=SUBSTRATE TO=M1 AREA=0.25 RPV=5 }

VIA POLY_CONT { FROM=POLY TO=M1 AREA=0.25 RPV=4 }

VIA V1 { FROM=M1 TO=M2 AREA=0.36 RPV=4 }

Figure A-2 Conformal Dielectric Process

POLY

0.2

0.725

1.2

0.125

0.375

SUBSTRATE

3.6

0.6

0.18

0.15

TOP

Appendix A: ITF Examples

Gate Poly Process A-4

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Gate Poly Process

The following example ITF file describes the gate poly process shown in Figure A-3.

TECHNOLOGY = polygate

DIELECTRIC TOP { THICKNESS=1.2 ER=3.9 }

CONDUCTOR M2 { THICKNESS=0.4 WMIN=0.5 SMIN=0.5 RPSQ=0.05

DIELECTRIC D4 { THICKNESS=0.7 ER=3.9}

CONDUCTOR M1 { THICKNESS=0.4 WMIN=0.4 SMIN=0.4 RPSQ=0.05 }

DIELECTRIC D3 { THICKNESS=0.5 ER=3.9 }

CONDUCTOR POLY { THICKNESS=0.2 WMIN=0.3 SMIN=0.3 RPSQ=10.0 }

DIELECTRIC D2 { THICKNESS=0.1 ER=3.9 }

CONDUCTOR GATE { THICKNESS=0.2 WMIN=0.2 SMIN=0.2 RPSQ=8.0 }

DIELECTRIC TOX { THICKNESS=0.2 ER=3.9 }

VIA DIFF_CONT { FROM=SUBSTRATE TO=M1 AREA=0.25 RPV=5 }

VIA POLY_CONT { FROM=POLY TO=M1 AREA=0.25 RPV=4 }

VIA V1 { FROM=M1 TO=M2 AREA=0.36 RPV=4 }

Figure A-3 Gate Poly Process

POLY

GATE 0.1

0.2

1.2

0.4

0.5

0.7 0.4

SUBSTRATE

TOP

TOX 0.2

Chapter A: ITF Examples

Local Interconnect Process A-5

Appendix A: ITF Examples

Local Interconnect Process A-5

StarRC User Guide and Command Reference Version F-2011.06

Local Interconnect Process

The following example ITF file describes thelocal interconnect process shown in Figure A-4.

TECHNOLOGY = polyli

DIELECTRIC TOP { THICKNESS=1.2 ER=3.9 }

CONDUCTOR M2 { THICKNESS=0.4 WMIN=0.5 SMIN=0.5 RPSQ=0.05

DIELECTRIC D4 { THICKNESS=0.7 ER=3.9 }

$ D4 thickness measured from D3

CONDUCTOR M1 { THICKNESS=0.4 WMIN=0.4 SMIN=0.4 RPSQ=0.05 }

DIELECTRIC D3 { THICKNESS=0.6 ER=3.9 }

$ D3 thickness measured from D21

CONDUCTOR LI { THICKNESS=0.3 WMIN=0.4 SMIN=0.4 RPSQ=1 }

$ LI thickness measured from top of D21

CONDUCTOR POLY { THICKNESS=0.2 WMIN=0.2 SMIN=0.2 RPSQ=10.0 }

$ POLY thickness measured from top of D21

DIELECTRIC D21 { THICKNESS=0.2 ER=3.9 }

VIA LI_SUB { FROM=SUBSTRATE TO=LI AREA=0.25 RPV = 4 }

VIA CONT { FROM=LI TO=M1 AREA=0.25 RPV=5 }

VIA V1 { FROM=M1 TO=M2 AREA=0.25 RPV=4 }

Figure A-4 Local Interconnect

POLY LI 0.6

1.2

0.4

0.2 0.3

0.7

SUBSTRATE

TOP

D21 0.2

Appendix A: ITF Examples

Dielectric Air Gaps Process A-6

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Dielectric Air Gaps Process

The following example ITF file describes the dielectric air gaps process shown in Figure A-5.

TECHNOLOGY = airgap

DIELECTRIC TOP { THICKNESS=3.4 ER=3.9 }

DIELECTRIC D3 { THICKNESS=0.2 ER=4.7 }

CONDUCTOR M2 { THICKNESS=0.6 WMIN=0.5 SMIN=0.5 RPSQ=0.05 }

DIELECTRIC D2 { THICKNESS=1.2 ER=3.9 }

CONDUCTOR M1 {THICKNESS=0.5 WMIN=0.3 SMIN=0.3 RPSQ=0.05

AIR_GAP_VS_SPACING {

SPACINGS {0.3 0.5 0.7 1.0 3.0}

AIR_GAP_WIDTHS {0.1 0.09 0.09 0.08 0.07}

AIR_GAP_THICKNESSES {0.2 0.23 0.25 0.26 0.28}

AIR_GAP_BOTTOM_HEIGHTS {0.1 0.14 0.18 0.20 0.22}}

DIELECTRIC D1 { THICKNESS=0.725 ER=3.9 }

CONDUCTOR POLY{ THICKNESS=0.125 WMIN=0.3 SMIN=0.3 RPSQ=10.0

}

DIELECTRIC D0 { THICKNESS=0.375 ER=3.9 }

VIA sub_tie { FROM=SUBSTRATE TO=M1 AREA=0.25 RPV=5 }

VIA poly_cont { FROM=POLY TO=M1 AREA=0.25 RPV=4 }

VIA via { FROM=M1 TO=M2 AREA=0.36 RPV=4 }

Figure A-5 Dielectric Air Gap Process

POLY

0.2

0.725

1.2

0.125

0.375

SUBSTRATE

3.4

0.6

TOP

1.6

LAIR

S = spacing between neighboring lines

(SPACINGS)

W= width of the air gap

(AIR_GAP_WIDTH)

T= thickness of the air gap formed

(AIR_GAP_THICKNESS)

B= height of the bottom of the airgap

from the bottom of metal

(AIR_GAP_BOTTOM_HEIGHT)

L= spacing between the metal and air gap.

((S-W) /2)

M1M1

Chapter A: ITF Examples

Layer Etch Process A-7

Appendix A: ITF Examples

Layer Etch Process A-7

StarRC User Guide and Command Reference Version F-2011.06

Layer Etch Process

The following example ITF file describes the layer etch process shown in Figure A-6.

TECHNOLOGY = etch

DIELECTRIC TOP { THICKNESS=3.4 ER=3.9 }

DIELECTRIC D3 { THICKNESS=0.2 ER=3.9 }

CONDUCTOR M2 {

THICKNESS=0.6 WMIN=0.5 SMIN=0.5 RPSQ=0.05

ETCH=0.1 }

DIELECTRIC D2 { THICKNESS=1.2 ER=3.9 }

CONDUCTOR M1 {

THICKNESS=0.6 WMIN=0.3 SMIN=0.3 RPSQ=0.05

ETCH=0.05 }

DIELECTRIC D1 { THICKNESS=0.725 ER=3.9 }

CONDUCTOR POLY{ THICKNESS=0.125 WMIN=0.3 SMIN=0.3 RPSQ=10.0

}

DIELECTRIC D0 { THICKNESS=0.375 ER=3.9 }

VIA sub_tie { FROM=SUBSTRATE TO=M1 AREA=0.25 RPV=5 }

VIA poly_cont { FROM=POLY TO=M1 AREA=0.25 RPV=4 }

VIA via { FROM=M1 TO=M2 AREA=0.36 RPV=4 }

Figure A-6 Layer Etch Process

POLY

0.2

0.725

1.2

0.375

SUBSTRATE

3.4

0.6

TOP

0.125

Appendix A: ITF Examples

Metal Fill Process (Emulated) A-8

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Metal Fill Process (Emulated)

The following example ITF file describes the metal fill process shown in Figure A-7.

TECHNOLOGY = metal_fill

DIELECTRIC TOP { THICKNESS=3.4 ER=3.9 }

DIELECTRIC D3 { THICKNESS=0.2 ER=3.9 }

CONDUCTOR M2 {

THICKNESS=0.6 WMIN=0.5 SMIN=0.5 RPSQ=0.05

DIELECTRIC D2 { THICKNESS=1.2 ER=3.9 }

CONDUCTOR M1 {

THICKNESS=0.6 WMIN=0.3 SMIN=0.3 RPSQ=0.05

FILL_RATIO=0.4 FILL_SPACING=1.0 FILL_WIDTH=2.0 }

DIELECTRIC D1 { THICKNESS=0.725 ER=3.9 }

CONDUCTOR POLY{ THICKNESS=0.125 WMIN=0.3 SMIN=0.3 RPSQ=10.0

}

DIELECTRIC D0 {THICKNESS = 0.375 ER = 5.2}

VIA sub_tie { FROM=SUBSTRATE TO=M1 AREA=0.25 RPV=5 }

VIA poly_cont { FROM=POLY TO=M1 AREA=0.25 RPV=4 }

VIA via { FROM=M1 TO=M2 AREA=0.36 RPV=4 }

Figure A-7 Metal Fill Process (Emulated)

POLY

0.2

0.725

1.2

0.125

0.375

SUBSTRATE

3.4

M2 0.6

TOP

1.0

0.6

M1FILL

2.0

Chapter A: ITF Examples

Transistor-Level Process A-9

Appendix A: ITF Examples

Transistor-Level Process A-9

StarRC User Guide and Command Reference Version F-2011.06

Transistor-Level Process

The following example ITF file describes the transistor-level process shown in Figure A-8.

TECHNOLOGY=xtor

DIELECTRIC TOP { THICKNESS=3.40 ER=4.3 }

DIELECTRIC D3 { THICKNESS=0.20 ER=3.9 }]

CONDUCTOR M2 { THICKNESS=0.60 WMIN=0.55 SMIN=0.50 RPSQ=0.062

}

DIELECTRIC D2 { THICKNESS=1.20 ER=3.9 }

CONDUCTOR M1 { THICKNESS=0.60 WMIN=0.50 SMIN=0.45 RPSQ=0.062

}

DIELECTRIC D1 { THICKNESS=0.75 ER=3.9 }

CONDUCTOR FP{ THICKNESS=0.30 WMIN=0.35 SMIN=0.40 RPSQ=3.200

}

DIELECTRIC FOX { THICKNESS=0.20 ER=3.9 }

CONDUCTOR GP{ THICKNESS=0.30 WMIN=0.35 SMIN=0.40

RPSQ=3.200 }

DIELECTRIC GOX { THICKNESS=1.02 ER=5.0 }

CONDUCTOR DF{ THICKNESS=1.00 WMIN=1.00 SMIN=0.35

RPSQ=10.00 }

DIELECTRIC D0 { THICKNESS=0.50 ER=3.9 }

VIA via1 { FROM=M1 TO=M2 RHO=0.263 }

VIA pCont { FROM=FP TO=M1 RHO=0.352 }

VIA dCont { FROM=DF TO=M1 RHO=0.500 }

VIA sCont { FROM=SUBSTRATE TO=M1 RHO=0.600 }

Figure A-8 Transistor-Level Process

0.20

1.20

0.20

SUBSTRATE

3.40TOP

FP GP

0.75

0.50

1.02GOX

FOX

dCont

via1

pCont

sCont

M1 M1

Appendix A: ITF Examples

Through-Silicon Via Process A-10

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Through-Silicon Via Process

The following example ITF file describes the through-silicon via process shown in

Figure A-9. The TSV statement must be placed after the frontside ITF statements and before

the backside ITF statements.

TECHNOLOGY = tsv_process

GLOBAL_TEMPERATURE = 25.0

$ Fronside ITF statements

CONDUCTOR M1 {

THICKNESS=0.3 WMIN=0.12 SMIN=0.12 SIDE_TANGENT=0.2

CRT1=7.0e-03 CRT2=-8.0e-07

}

DIELECTRIC ILD_B { ER=5.5 THICKNESS=0.5 }

DIELECTRIC GATE_OXIDE { ER=4.3 THICKNESS=0.03 }

DIELECTRIC FOXIDE_A { ER=5.0 THICKNESS=0.1 }

CONDUCTOR DIFFUSION {

THICKNESS=0.1 WMIN=0.1 SMIN=0.06

CRT1=8.0e-03 CRT2=-1.0e-07 RPSQ=36.0

}

DIELECTRIC FOXIDE { ER=5.0 THICKNESS=0.2 }

VIA via1 { FROM=M1 TO=M2 AREA=0.03 RPV=2.5 CRT1=3.0e-04 CRT2=-6.0e-06 }

$ TSV statement

TSV tsv {

FROM=M1 TO=M1b RHO=0.05 AREA=49.0 THICKNESS=20.0

INSULATION_THICKNESS = 0.4 INSULATION_ER = 5.5

CRT1=7.0e-03 CRT2=-3.0e-08

}

$ Backside ITF statements

DIELECTRIC PASS { ER=9.0 THICKNESS=2.0 }

DIELECTRIC DIELb { ER=5.0 THICKNESS=1.0 }

CONDUCTOR M1b {

THICKNESS=2.0 WMIN=4.0 SMIN=4.0 SIDE_TANGENT=-0.2

CRT1=1.0e-03 CRT2=-7.0e-07

}

DIELECTRIC ILDB{ ER=5.2 THICKNESS=1.0 }

Note:

The locations of the backside dielectric layers ILDB and PASS with respect to the

substrate are shown in Figure A-9.

Chapter A: ITF Examples

Through-Silicon Via Process A-11

Appendix A: ITF Examples

Through-Silicon Via Process A-11

StarRC User Guide and Command Reference Version F-2011.06

Figure A-9 Through-Silicon Via Process

Appendix A: ITF Examples

Through-Silicon Via Process A-12

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

B-1

Command Lists B

The tables in this appendix alphabetically list the StarRC commands and with specific

information about the task groups, flows and license packages that they belong to. The

-clean option to be used for each command is shown in the last section.

•Command List With Task Information

•Command List With Flow and License Information

•Command List With -clean Option Information

Appendix B: Command Lists

Command List With Task Information B-2

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Command List With Task Information

Table B-1 lists the StarRC commands with the following task information:

• Processing – Commands used to read input and process information.

• Layer Mapping – Commands used for linking each database layer to a TCAD GRD file

layer.

• Translation – Commands that control the translation of the input design database into

internal optimized data.

• XREF – Commands directing the method of cross-referencing schematic objects into

layout objects.

• Incremental – Commands used for incremental extraction.

• DP – Commands used to specify the option for the distributed processing during the

parasitic component extraction stage.

• Extraction – Commands associated with the setting of options for parasitic extraction.

• Field Solver – Commands for specifying and controlling the process of performing

extraction with a 3-D field solver and comparing with regular extraction results.

• Netlisting – Commands directing the format and contents of the generated parasitic

netlist.

• Noise – Commands associated with producing a parasitic netlist suitable for noise

analysis.

• Open Access (OA) – Commands associated with generating output parasitic data

conforming to the Open Access standard.

Chapter B: Command Lists

Command List With Task Information B-3

Appendix B: Command Lists

Command List With Task Information B-3

StarRC User Guide and Command Reference Version F-2011.06

Ta ble B - 1 List of Commands With Task Information

Command Name

Processing

Layer Mapping

Translation

XREF

Incremental

Extraction

Field Solver

Netlist

Noise

Open Access

ANALOG_SYMMETRIC_NETS X

AUTO_RUNSET X

BLOCK X

BLOCK_BOUNDARY X

BUS_BIT X X X

CALIBRE_LVS_DEVICE_TYPE_CAP X

CALIBRE_LVS_DEVICE_TYPE_MOS X

CALIBRE_LVS_DEVICE_TYPE_RES X

CALIBRE_OPTIONAL_DEVICE_PIN_FILE X

CALIBRE_PDBA_FILE X

CALIBRE_QUERY_FILE X

CALIBRE_RUNSET X

CASE_SENSITIVE X

CELL_TYPE X

COMPARE_DIRECTORY X

CONLY_NETS X

CONVERT_DIODE_TO_PARASITIC_CAP X X X

COUPLE_NONCRITICAL_NETS X

COUPLE_NONCRITICAL_NETS_PREFIX X

COUPLE_NONCRITICAL_NETS_SUBNODE_SUFFIX X

COUPLE_TO_GROUND X

COUPLE_TO_PCELL_PINS X X X X

COUPLING_ABS_THRESHOLD X X X

COUPLING_AVG_THRESHOLD X X X

COUPLING_MULTIPLIER X X

COUPLING_REL_THRESHOLD X X X

COUPLING_REPORT_FILE X X X

COUPLING_REPORT_NUMBER X X X

COUPLING_THRESHOLD_OPERATION X X X

DENSITY_BASED_THICKNESS X

Appendix B: Command Lists

Command List With Task Information B-4

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

DENSITY_OUTSIDE_BLOCK X

DETECT_FUSE X

EVACCESS_DIRECTORY X

EXTRA_GEOMETRY_INFO X

EXTRACT_RES_BODY_COUPLING X X

EXTRACT_VIA_CAPS X X X

EXTRACTION X

FS_DP_STRING X

FS_EXTRACT_NETS X

FSCOMPARE_COUPLING_RATIO X

FSCOMPARE_FILE_PREFIX X

FSCOMPARE_OPTIONS X

FSCOMPARE_THRESHOLD X

GDS_FILE X

GDS_LAYER_MAP_FILE X

HIERARCHICAL_SEPARATOR X

HN_NETLIST_MODEL_NAME X

HN_NETLIST_SPICE_TYPE X

ICV_ANNOTATION_FILE X

ICV_RUNSET_REPORT_FILE X

IGNORE_CAPACITANCE X

IGNORE_FIELDPOLY_DIFFUSION_COUPLING X

INCREMENTAL X

INCREMENTAL_FORCE_DP X

INSTANCE_PORT X

INSTANCE_PORT_OPEN_CONDUCTANCE X

INTRANET_CAPS X X

KEEP_VIA_NODES X

LEF_FILE X

LEF_USE_OBS X

Table B-1 List of Commands With Task Information (Continued)

Command Name

Processing

Layer Mapping

Translation

XREF

Incremental

Extraction

Field Solver

Netlist

Noise

Open Access

Chapter B: Command Lists

Command List With Task Information B-5

Appendix B: Command Lists

Command List With Task Information B-5

StarRC User Guide and Command Reference Version F-2011.06

LPE_DEVICES X

LPE_PARAM X

MACRO X

MACRO_DEF_FILE X

MAGNIFICATION_FACTOR X

MAGNIFY_DEVICE_PARAMS X

MAPPING_FILE X

MARKER_GENERATION X

MERGE_INSTANCE_PORTS X

MERGE_MULTI_CORNER X

MERGE_VIAS_IN_ARRAY X

METAL_FILL_GDS_FILE X

METAL_FILL_GDS_FILE_NET_NAME X

METAL_FILL_GDS_MAG ?

METAL_FILL_GDS_OFFSET ?

METAL_FILL_OASIS_FILE X

METAL_FILL_OASIS_FILE_NET_NAME X

METAL_FILL_OASIS_MAG ?

METAL_FILL_OASIS_OFFSET ?

METAL_FILL_POLYGON_HANDLING X

METAL_SHEET_OVER_AREA X

MILKYWAY_ADDITIONAL_VIEWS X

MILKYWAY_CELL_VIEW X

MILKYWAY_DATABASE X

MILKYWAY_EXPAND_HIERARCHICAL_CELLS X

MILKYWAY_EXTRACT_VIEW X

MILKYWAY_REF_LIB_MODE X

MODE X

MODEL_TYPE X

MOS_GATE_CAPACITANCE X

Table B-1 List of Commands With Task Information (Continued)

Command Name

Processing

Layer Mapping

Translation

XREF

Incremental

Extraction

Field Solver

Netlist

Noise

Open Access

Appendix B: Command Lists

Command List With Task Information B-6

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

MOS_GATE_DELTA_RESISTANCE X

NET_SEGMENT_CUT_LENGTH X

NET_TYPE X

NETLIST_CAPACITANCE_UNIT X

NETLIST_COMMENTED_PARAMS X

NETLIST_COMMENTS_FILE X

NETLIST_COMPRESS_COMMAND X

NETLIST_CONNECT_OPENS X

NETLIST_CONNECT_SECTION X

NETLIST_CORNER_FILE X

NETLIST_CORNER_NAMES X

NETLIST_COUPLE_UNSELECTED_NETS X

NETLIST_DELIMITER X

NETLIST_DEVICE_LOCATION_ORIENTATION X

NETLIST_FILE X

NETLIST_FORMAT X

NETLIST_GROUND_NODE_NAME X

NETLIST_HIER_PROBE_NODES X

NETLIST_IDEAL_SPICE_FILE X

NETLIST_IDEAL_SPICE_HIER X

NETLIST_IDEAL_SPICE_TYPE X

NETLIST_INCREMENTAL X

NETLIST_INPUT_DRIVERS X

NETLIST_INSTANCE_SECTION X

NETLIST_LOGICAL_TYPE X

NETLIST_MAX_FILE_SIZE X

NETLIST_MAX_LINE X

NETLIST_MERGE_CORNERS X

NETLIST_MERGE_SHORTED_PORTS X

NETLIST_MINCAP_THRESHOLD X

Table B-1 List of Commands With Task Information (Continued)

Command Name

Processing

Layer Mapping

Translation

XREF

Incremental

Extraction

Field Solver

Netlist

Noise

Open Access

Chapter B: Command Lists

Command List With Task Information B-7

Appendix B: Command Lists

Command List With Task Information B-7

StarRC User Guide and Command Reference Version F-2011.06

NETLIST_MINRES_HANDLING X

NETLIST_MINRES_THRESHOLD X

NETLIST_MMC_FORMULA X

NETLIST_MMC_FORMULA_NAMES X

NETLIST_NAME_MAP X

NETLIST_NODE_SECTION X

NETLIST_NODENAME_NETNAME X

NETLIST_PARA_VIEW X

NETLIST_PARASITIC_RESISTOR_MODEL X

NETLIST_PASSIVE_PARAMS X

NETLIST_POSTPROCESS_COMMAND ?

NETLIST_POWER_FILE X

NETLIST_PRECISION X

NETLIST_PRINT_CC_TWICE X

NETLIST_REMOVE_DANGLING_BRANCHES X

NETLIST_RENAME_PORTS X

NETLIST_RESISTANCE_UNIT X

NETLIST_SELECT_NETS X

NETLIST_SIM_OPTIONS X

NETLIST_SUBCKT X

NETLIST_TAIL_COMMENTS X

NETLIST_TIME_UNIT X

NETLIST_TOTALCAP_THRESHOLD X

NETLIST_TYPE X

NETLIST_UNSCALED_COORDINATES X

NETLIST_USE_M_FACTOR X

NETS X

NETS_FILE X

NONCRITICAL_COUPLING_REPORT_FILE X

NUM_PARTS X

Table B-1 List of Commands With Task Information (Continued)

Command Name

Processing

Layer Mapping

Translation

XREF

Incremental

Extraction

Field Solver

Netlist

Noise

Open Access

Appendix B: Command Lists

Command List With Task Information B-8

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

OA_DEVICE_MAPPING_FILE X

OA_LAYER_MAPPING_FILE X

OA_LIB_DEF X

OA_LIB_NAME X

OA_MARKER_SIZE X

OA_PORT_ANNOTATION_VIEW X

OA_PROPERTY_ANNOTATION_VIEW X

OA_SKIPCELL_MAPPING_FILE X

OA_VIEW_NAME X

OASIS_FILE X

OASIS_LAYER_MAP_FILE X

OBSERVATION_POINTS X

OPERATING_TEMPERATURE X

PIN_CUT_THRESHOLD X

PIO_FILE X

PLACEMENT_INFO_FILE X

POWER_EXTRACT X

POWER_NETS X

POWER_PORTS X

POWER_REDUCTION X

PRINT_SILICON_INFO X

PROBE_TEXT_FILE X

PROCESS_CORNER X X

REDUCTION X

REDUCTION_MAX_DELAY_ERROR X

REMOVE_DANGLING_NETS X

REMOVE_FLOATING_NETS X

REMOVE_NET_PROPERTY X

RETAIN_CAPACITANCE_CAP_MODELS X

RETAIN_GATE_CONTACT_COUPLING X

Table B-1 List of Commands With Task Information (Continued)

Command Name

Processing

Layer Mapping

Translation

XREF

Incremental

Extraction

Field Solver

Netlist

Noise

Open Access

Chapter B: Command Lists

Command List With Task Information B-9

Appendix B: Command Lists

Command List With Task Information B-9

StarRC User Guide and Command Reference Version F-2011.06

RING_AROUND_THE_BLOCK X

RING_AROUND_THE_BLOCK_SMIN_MULTIPLIER X

SENSITIVITY X

SHEET_COUPLE_TO_NET X

SHEET_COUPLE_TO_NET_LEVEL X

SHORT_PINS X

SHORT_PINS_IN_CELLS X

SKIP_CELL_AGF_FILE X

SKIP_CELL_PORT_PROP_FILE X

SKIP_CELLS X

SKIP_CELLS_COUPLE_TO_NET X

SKIP_CELLS_COUPLE_TO_NET_LEVEL X

SKIP_CELLS_FILE X

SKIP_INSTANCES X

SKIP_PCELLS X

SKIP_PCELL_LAYERS_FILE X

SLEEP_TIME_AFTER_FINISH X

SPICE_SUBCKT_FILE X

STAR_DIRECTORY X

SUBSTRATE_EXTRACTION X

SUMMARY_FILE X

SYNOPSYS_LIB_FILE X

TARGET_PWRA X

TCAD_GRD_FILE X

TEMPERATURE_SENSITIVITY X

THICKNESS_VARIATION_FILE X

TOP_DEF_FILE X

TRANSLATE_DEF_BLOCKAGE X

TRANSLATE_FLOATING_AS_FILL X

TRANSLATE_RETAIN_BULK_LAYERS X

Table B-1 List of Commands With Task Information (Continued)

Command Name

Processing

Layer Mapping

Translation

XREF

Incremental

Extraction

Field Solver

Netlist

Noise

Open Access

Appendix B: Command Lists

Command List With Task Information B-10

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

TVF_ADJUSTMENT_TABLES X

USER_DEFINED_DIFFUSION_RES X

VIA_COVERAGE X

VIA_COVERAGE_OPTION_FILE X

WIDE_DEVICE_TERM_RESISTANCE X

XREF X

XREF_FEEDTHRU_NETS X

XREF_LAYOUT_INST_PREFIX X

XREF_LAYOUT_NET_PREFIX X

XREF_SWAP_MOS_SD_PROPERTY X

XREF_USE_LAYOUT_DEVICE_NAME X

ZONE_COUPLE_TO_NET X

ZONE_COUPLE_TO_NET_LEVEL X

Table B-1 List of Commands With Task Information (Continued)

Command Name

Processing

Layer Mapping

Translation

XREF

Incremental

Extraction

Field Solver

Netlist

Noise

Open Access

Chapter B: Command Lists

Command List With Flow and License Information B-11

Appendix B: Command Lists

Command List With Flow and License Information B-11

StarRC User Guide and Command Reference Version F-2011.06

Command List With Flow and License Information

Table B-2 shows the availability of each command for use with specific flows and license

packages. “IND” indicates that the command requires the inductance license package.

Ta ble B - 2 List of Commands With Flow and License Information

Flow License

Command Name

All Flows

Milkyway

LEF/DEF

IC Validator

Hercules

Calibre

Shared Database

Custom

StarRC

Ultra

ANALOG_SYMMETRIC_NETS XXXXXXXXXX

AUTO_RUNSET X X X X X X

BLOCK X XXXXXXX

BLOCK_BOUNDARY XXXXXXX- XX

BUS_BIT XXXXXXXXXX

CALIBRE_LVS_DEVICE_TYPE_CAP X X X X

CALIBRE_LVS_DEVICE_TYPE_MOS X X X X

CALIBRE_LVS_DEVICE_TYPE_RES X X X X

CALIBRE_OPTIONAL_DEVICE_PIN_FILE X X X X

CALIBRE_PDBA_FILE X - X X

CALIBRE_QUERY_FILE X X X X

CALIBRE_RUNSET X X X X

CASE_SENSITIVE XXXXXXXXXX

CELL_TYPE X X X X X X

COMPARE_DIRECTORY X X X X X X

CONLY_NETS XXXXXXXXXX

CONVERT_DIODE_TO_PARASITIC_CAP XXXXXXXXXX

COUPLE_NONCRITICAL_NETS XXXXXXXXXX

COUPLE_NONCRITICAL_NETS_PREFIX XXXXXXXXXX

COUPLE_NONCRITICAL_NETS_SUBNODE_SUFFIX XXXXXXXXXX

COUPLE_TO_GROUND XXXXXXXXXX

COUPLE_TO_PCELL_PINS XXXXXXX

COUPLING_ABS_THRESHOLD XXXXXXXXXX

COUPLING_AVG_THRESHOLD XXXXXXXXXX

Appendix B: Command Lists

Command List With Flow and License Information B-12

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

COUPLING_MULTIPLIER XXXXXXXXXX

COUPLING_REL_THRESHOLD XXXXXXXXXX

COUPLING_REPORT_FILE XXXXXXXXXX

COUPLING_REPORT_NUMBER XXXXXXXXXX

COUPLING_THRESHOLD_OPERATION XXXXXXXXXX

DENSITY_BASED_THICKNESS XXXXXXXXXX

DENSITY_OUTSIDE_BLOCK XXXXXXXXXX

DETECT_FUSE XXXXXXXXXX

EVACCESS_DIRECTORY X X X X

EXTRA_GEOMETRY_INFO XXXXXXXXXX

EXTRACT_RES_BODY_COUPLING XXXXXXXXXX

EXTRACT_VIA_CAPS XXXXXXXXXX

EXTRACTION XXXXXXXXXX

FS_DP_STRING XXXXXXXXXX

FS_EXTRACT_NETS XXXXXXXXXX

FSCOMPARE_COUPLING_RATIO XXXXXXXXXX

FSCOMPARE_FILE_PREFIX XXXXXXXXXX

FSCOMPARE_OPTIONS XXXXXXXXXX

FSCOMPARE_THRESHOLD XXXXXXXXXX

GDS_FILE XXXXXXX- XX

GDS_LAYER_MAP_FILE XXXXXXX- XX

HIERARCHICAL_SEPARATOR XXXXXXXXXX

HN_NETLIST_MODEL_NAME X X X X X X

HN_NETLIST_SPICE_TYPE X X X X X X

ICV_ANNOTATION_FILE X X X X

ICV_RUNSET_REPORT_FILE X X X X

IGNORE_CAPACITANCE XXXXXXXXXX

IGNORE_FIELDPOLY_DIFFUSION_COUPLING XXXXXXXXXX

Table B-2 List of Commands With Flow and License Information (Continued)

Flow License

Command Name

All Flows

Milkyway

LEF/DEF

IC Validator

Hercules

Calibre

Shared Database

Custom

StarRC

Ultra

Chapter B: Command Lists

Command List With Flow and License Information B-13

Appendix B: Command Lists

Command List With Flow and License Information B-13

StarRC User Guide and Command Reference Version F-2011.06

INCREMENTAL X X - X X

INCREMENTAL_FORCE_DP XXXXXXX- XX

INSTANCE_PORT XXXXXXX- XX

INSTANCE_PORT_OPEN_CONDUCTANCE XXXXXXX- XX

INTRANET_CAPS XXXXXXXXXX

KEEP_VIA_NODES XXXXXXXXXX

LEF_FILE X - X X

LEF_USE_OBS X - X X

LPE_DEVICES XXXXXXXXXX

LPE_PARAM XXXXXXXXXX

MACRO X X - X X

MACRO_DEF_FILE X - X X

MAGNIFICATION_FACTOR XXXXXXXXXX

MAGNIFY_DEVICE_PARAMS X X X X X X

MAPPING_FILE XXXXXXXXXX

MARKER_GENERATION X X X X X

MERGE_INSTANCE_PORTS XXXXXXXXXX

MERGE_MULTI_CORNER XXXXXXXXXX

MERGE_VIAS_IN_ARRAY XXXXXXXXXX

METAL_FILL_GDS_FILE XXXXX XXX

METAL_FILL_GDS_FILE_NET_NAME XXXXX XXX

METAL_FILL_GDS_MAG XXXXXXXXXX

METAL_FILL_GDS_OFFSET XXXXXXXXXX

METAL_FILL_OASIS_FILE X X X X X

METAL_FILL_OASIS_FILE_NET_NAME X X X X X

METAL_FILL_OASIS_MAG XXXXXXXXXX

METAL_FILL_OASIS_OFFSET XXXXXXXXXX

METAL_FILL_POLYGON_HANDLING XXXXXXXXXX

Table B-2 List of Commands With Flow and License Information (Continued)

Flow License

Command Name

All Flows

Milkyway

LEF/DEF

IC Validator

Hercules

Calibre

Shared Database

Custom

StarRC

Ultra

Appendix B: Command Lists

Command List With Flow and License Information B-14

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

METAL_SHEET_OVER_AREA X X X X X

MILKYWAY_ADDITIONAL_VIEWS X - X X

MILKYWAY_CELL_VIEW X - X X

MILKYWAY_DATABASE X X X X

MILKYWAY_EXPAND_HIERARCHICAL_CELLS X - X X

MILKYWAY_EXTRACT_VIEW X X X X X

MILKYWAY_REF_LIB_MODE X X X X

MODE XXXXXXXXXX

MODEL_TYPE X X X X X X

MOS_GATE_CAPACITANCE X X X X X X

MOS_GATE_DELTA_RESISTANCE X X X X X X

NET_SEGMENT_CUT_LENGTH XXXXXXXXXX

NET_TYPE X X X X X X

NETLIST_CAPACITANCE_UNIT XXXXXXXXXX

NETLIST_COMMENTED_PARAMS X X X X X X

NETLIST_COMMENTS_FILE XXXXXXXXXX

NETLIST_COMPRESS_COMMAND XXXXXXXXXX

NETLIST_CONNECT_OPENS XXXXXXXXXX

NETLIST_CONNECT_SECTION XXXXXXXXXX

NETLIST_CORNER_FILE XXXXXXXXXX

NETLIST_CORNER_NAMES XXXXXXXXXX

NETLIST_COUPLE_UNSELECTED_NETS XXXXXXXXXX

NETLIST_DELIMITER XXXXXXXXXX

NETLIST_DEVICE_LOCATION_ORIENTATION X X X X X X

NETLIST_FILE XXXXXXXXXX

NETLIST_FORMAT XXXXXXXXXX

NETLIST_GROUND_NODE_NAME XXXXXXXXXX

NETLIST_HIER_PROBE_NODES XXXXXXX- XX

Table B-2 List of Commands With Flow and License Information (Continued)

Flow License

Command Name

All Flows

Milkyway

LEF/DEF

IC Validator

Hercules

Calibre

Shared Database

Custom

StarRC

Ultra

Chapter B: Command Lists

Command List With Flow and License Information B-15

Appendix B: Command Lists

Command List With Flow and License Information B-15

StarRC User Guide and Command Reference Version F-2011.06

NETLIST_IDEAL_SPICE_FILE X X X X X

NETLIST_IDEAL_SPICE_HIER X X X X X

NETLIST_IDEAL_SPICE_TYPE X X X X X

NETLIST_INCREMENTAL X X - X X

NETLIST_INPUT_DRIVERS XXXXXXXXXX

NETLIST_INSTANCE_SECTION XXXXXXXXXX

NETLIST_LOGICAL_TYPE X X X X

NETLIST_MAX_FILE_SIZE XXXXXXXXXX

NETLIST_MAX_LINE XXXXXXXXXX

NETLIST_MERGE_CORNERS XXXXXXXXXX

NETLIST_MERGE_SHORTED_PORTS XXXXXXXXXX

NETLIST_MINCAP_THRESHOLD XXXXXXXXXX

NETLIST_MINRES_HANDLING XXXXXXXXXX

NETLIST_MINRES_THRESHOLD XXXXXXXXXX

NETLIST_MMC_FORMULA XXXXXXXXXX

NETLIST_MMC_FORMULA_NAMES XXXXXXXXXX

NETLIST_NAME_MAP XXXXXXXXXX

NETLIST_NODE_SECTION XXXXXXXXXX

NETLIST_NODENAME_NETNAME XXXXXXXXXX

NETLIST_PARA_VIEW X - X X

NETLIST_PARASITIC_RESISTOR_MODEL XXXXXXXXXX

NETLIST_PASSIVE_PARAMS X X X X X X

NETLIST_POSTPROCESS_COMMAND XXXXXXXXXX

NETLIST_POWER_FILE XXXXXXXXXX

NETLIST_PRECISION XXXXXXXXXX

NETLIST_PRINT_CC_TWICE XXXXXXXXXX

NETLIST_REMOVE_DANGLING_BRANCHES XXXXXXXXXX

NETLIST_RENAME_PORTS XXXXXXXXXX

Table B-2 List of Commands With Flow and License Information (Continued)

Flow License

Command Name

All Flows

Milkyway

LEF/DEF

IC Validator

Hercules

Calibre

Shared Database

Custom

StarRC

Ultra

Appendix B: Command Lists

Command List With Flow and License Information B-16

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

NETLIST_RESISTANCE_UNIT XXXXXXXXXX

NETLIST_SELECT_NETS XXXXXXXXXX

NETLIST_SIM_OPTIONS X X X X X X

NETLIST_SUBCKT XXXXXXXXXX

NETLIST_TAIL_COMMENTS XXXXXXXXXX

NETLIST_TIME_UNIT XXXXXXXXXX

NETLIST_TOTALCAP_THRESHOLD XXXXXXXXXX

NETLIST_TYPE XXXXXXXXXX

NETLIST_UNSCALED_COORDINATES XXXXXXXXXX

NETLIST_USE_M_FACTOR X X X X X X

NETS XXXXXXX- XX

NETS_FILE XXXXXXX- XX

NONCRITICAL_COUPLING_REPORT_FILE XXXXXXXXXX

NUM_PARTS XXXXXXX- XX

OA_DEVICE_MAPPING_FILE X X X X X

OA_LAYER_MAPPING_FILE X X X X X

OA_LIB_DEF X X X X X

OA_LIB_NAME X X X X X

OA_MARKER_SIZE X X X X X

OA_PORT_ANNOTATION_VIEW X X X X X

OA_PROPERTY_ANNOTATION_VIEW X X X X X

OA_SKIPCELL_MAPPING_FILE X X X X X

OA_VIEW_NAME X X X X X

OASIS_FILE XXXXXXX- XX

OASIS_LAYER_MAP_FILE XXXXXXX- XX

OBSERVATION_POINTS X XXXXXXX

OPERATING_TEMPERATURE XXXXXXXXXX

PIN_CUT_THRESHOLD XXXXXXXXXX

Table B-2 List of Commands With Flow and License Information (Continued)

Flow License

Command Name

All Flows

Milkyway

LEF/DEF

IC Validator

Hercules

Calibre

Shared Database

Custom

StarRC

Ultra

Chapter B: Command Lists

Command List With Flow and License Information B-17

Appendix B: Command Lists

Command List With Flow and License Information B-17

StarRC User Guide and Command Reference Version F-2011.06

PIO_FILE XXXXXXXXXX

PLACEMENT_INFO_FILE XXXXXXXXXX

POWER_EXTRACT XXXXXXXXXX

POWER_NETS XXXXXXXXXX

POWER_PORTS XXXXXXXXXX

POWER_REDUCTION XXXXXXXXXX

PRINT_SILICON_INFO XXXXXXXXXX

PROBE_TEXT_FILE XXXXXXXXXX

PROCESS_CORNER XXXXXXXXXX

REDUCTION XXXXXXXXXX

REDUCTION_MAX_DELAY_ERROR XXXXXXXXXX

REMOVE_DANGLING_NETS XXXXXXXXXX

REMOVE_FLOATING_NETS XXXXXXXXXX

REMOVE_NET_PROPERTY XXXXXXXXXX

RETAIN_CAPACITANCE_CAP_MODELS X X X X X X

RETAIN_GATE_CONTACT_COUPLING X X X X X X

RING_AROUND_THE_BLOCK X X - X X

RING_AROUND_THE_BLOCK_SMIN_MULTIPLIER X X - X X

SENSITIVITY XXXXXXX- - X

SHEET_COUPLE_TO_NET X X X X X

SHEET_COUPLE_TO_NET_LEVEL X X X X X

SHORT_PINS XXXXXXXXXX

SHORT_PINS_IN_CELLS XXXXXXX- XX

SKIP_CELL_AGF_FILE X X - X X

SKIP_CELL_PORT_PROP_FILE XXXXXXX- XX

SKIP_CELLS XXXXXXX- XX

SKIP_CELLS_COUPLE_TO_NET XXXXXXX- XX

SKIP_CELLS_COUPLE_TO_NET_LEVEL XXXXXXX- XX

Table B-2 List of Commands With Flow and License Information (Continued)

Flow License

Command Name

All Flows

Milkyway

LEF/DEF

IC Validator

Hercules

Calibre

Shared Database

Custom

StarRC

Ultra

Appendix B: Command Lists

Command List With Flow and License Information B-18

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

SKIP_CELLS_FILE XXXXXXX- XX

SKIP_INSTANCES XXXXXXX- XX

SKIP_PCELLS XXXXXXXXXX

SKIP_PCELL_LAYERS_FILE XXXXXXXXXX

SLEEP_TIME_AFTER_FINISH XXXXXXXXXX

SPICE_SUBCKT_FILE XXXXXXXXXX

STAR_DIRECTORY XXXXXXXXXX

SUBSTRATE_EXTRACTION X X X X X X

SUMMARY_FILE XXXXXXXXXX

SYNOPSYS_LIB_FILE X X X X X X

TARGET_PWRA X X X X X X

TCAD_GRD_FILE XXXXXXXXXX

TEMPERATURE_SENSITIVITY XXXXXXXXXX

THICKNESS_VARIATION_FILE XXXXXXXXXX

TOP_DEF_FILE X - X X

TRANSLATE_DEF_BLOCKAGE X - X X

TRANSLATE_FLOATING_AS_FILL XXXXXXXXXX

TRANSLATE_RETAIN_BULK_LAYERS X X X X X X

TVF_ADJUSTMENT_TABLES XXXXXXX- - X

USER_DEFINED_DIFFUSION_RES XXXXXXXXXX

VIA_COVERAGE XXXXXXXXXX

VIA_COVERAGE_OPTION_FILE XXXXXXXXXX

WIDE_DEVICE_TERM_RESISTANCE X X X X X X

XREF X X X X X X

XREF_FEEDTHRU_NETS X X X X X X

XREF_LAYOUT_INST_PREFIX X X X X X X

XREF_LAYOUT_NET_PREFIX X X X X X X

XREF_SWAP_MOS_SD_PROPERTY XXXXXXXXXX

Table B-2 List of Commands With Flow and License Information (Continued)

Flow License

Command Name

All Flows

Milkyway

LEF/DEF

IC Validator

Hercules

Calibre

Shared Database

Custom

StarRC

Ultra

Chapter B: Command Lists

Command List With Flow and License Information B-19

Appendix B: Command Lists

Command List With Flow and License Information B-19

StarRC User Guide and Command Reference Version F-2011.06

XREF_USE_LAYOUT_DEVICE_NAME X X X X X X

ZONE_COUPLE_TO_NET XXXXXXX- XX

ZONE_COUPLE_TO_NET_LEVEL XXXXXXX- XX

Table B-2 List of Commands With Flow and License Information (Continued)

Flow License

Command Name

All Flows

Milkyway

LEF/DEF

IC Validator

Hercules

Calibre

Shared Database

Custom

StarRC

Ultra

Appendix B: Command Lists

Command List With -clean Option Information B-20

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

Command List With -clean Option Information

Table B-3 lists the -clean command that must be used if a change is made to the particular

command.

Ta ble B - 3 List of Commands With -clean Option Information

Command Name

-clean

-cleanT

- cleanX

-cleanFS

-cleanTFS

-cleanXFS

-cleanN

-cleanXREF

-cleanD

ANALOG_SYMMETRIC_NETS

AUTO_RUNSET X

BLOCK X

BLOCK_BOUNDARY X

BUS_BIT X

CALIBRE_LVS_DEVICE_TYPE_CAP

CALIBRE_LVS_DEVICE_TYPE_MOS

CALIBRE_LVS_DEVICE_TYPE_RES

CALIBRE_OPTIONAL_DEVICE_PIN_FILE

CALIBRE_PDBA_FILE X

CALIBRE_QUERY_FILE X

CALIBRE_RUNSET X

CASE_SENSITIVE X

CELL_TYPE X

COMPARE_DIRECTORY X

CONLY_NETS X

CONVERT_DIODE_TO_PARASITIC_CAP X

COUPLE_NONCRITICAL_NETS X

COUPLE_NONCRITICAL_NETS_PREFIX X

COUPLE_NONCRITICAL_NETS_SUBNODE_SUFFIX X

COUPLE_TO_GROUND X

COUPLE_TO_PCELL_PINS X

COUPLING_ABS_THRESHOLD X

COUPLING_AVG_THRESHOLD X

COUPLING_MULTIPLIER X

COUPLING_REL_THRESHOLD X

COUPLING_REPORT_FILE X

Chapter B: Command Lists

Command List With -clean Option Information B-21

Appendix B: Command Lists

Command List With -clean Option Information B-21

StarRC User Guide and Command Reference Version F-2011.06

COUPLING_REPORT_NUMBER X

COUPLING_THRESHOLD_OPERATION

DENSITY_BASED_THICKNESS X

DENSITY_OUTSIDE_BLOCK

DETECT_FUSE X

EVACCESS_DIRECTORY X

EXTRA_GEOMETRY_INFO X

EXTRACT_RES_BODY_COUPLING X

EXTRACT_VIA_CAPS X

EXTRACTION X

FS_DP_STRING

FS_EXTRACT_NETS X

FSCOMPARE_COUPLING_RATIO X

FSCOMPARE_FILE_PREFIX X

FSCOMPARE_OPTIONS X

FSCOMPARE_THRESHOLD X

GDS_FILE X

GDS_LAYER_MAP_FILE X

HIERARCHICAL_SEPARATOR X

HN_NETLIST_MODEL_NAME X

HN_NETLIST_SPICE_TYPE X

ICV_ANNOTATION_FILE

ICV_RUNSET_REPORT_FILE

IGNORE_CAPACITANCE X

IGNORE_FIELDPOLY_DIFFUSION_COUPLING X

INCREMENTAL X

INCREMENTAL_FORCE_DP X

INSTANCE_PORT X

INSTANCE_PORT_OPEN_CONDUCTANCE X

INTRANET_CAPS X

KEEP_VIA_NODES X

Table B-3 List of Commands With -clean Option Information (Continued)

Command Name

-clean

-cleanT

- cleanX

-cleanFS

-cleanTFS

-cleanXFS

-cleanN

-cleanXREF

-cleanD

Appendix B: Command Lists

Command List With -clean Option Information B-22

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

LEF_FILE X

LEF_USE_OBS X

LPE_DEVICES

LPE_PARAM

MACRO X

MACRO_DEF_FILE X

MAGNIFICATION_FACTOR X

MAGNIFY_DEVICE_PARAMS X

MAPPING_FILE X

MARKER_GENERATION X

MERGE_INSTANCE_PORTS X

MERGE_MULTI_CORNER X

MERGE_VIAS_IN_ARRAY X

METAL_FILL_GDS_FILE X

METAL_FILL_GDS_FILE_NET_NAME X

METAL_FILL_GDS_MAG

METAL_FILL_GDS_OFFSET

METAL_FILL_OASIS_FILE

METAL_FILL_OASIS_FILE_NET_NAME

METAL_FILL_OASIS_MAG

METAL_FILL_OASIS_OFFSET

METAL_FILL_POLYGON_HANDLING X

METAL_SHEET_OVER_AREA X

MILKYWAY_ADDITIONAL_VIEWS X

MILKYWAY_CELL_VIEW X

MILKYWAY_DATABASE X

MILKYWAY_EXPAND_HIERARCHICAL_CELLS X

MILKYWAY_EXTRACT_VIEW X

MILKYWAY_REF_LIB_MODE X X

MODE X

MODEL_TYPE X

Table B-3 List of Commands With -clean Option Information (Continued)

Command Name

-clean

-cleanT

- cleanX

-cleanFS

-cleanTFS

-cleanXFS

-cleanN

-cleanXREF

-cleanD

Chapter B: Command Lists

Command List With -clean Option Information B-23

Appendix B: Command Lists

Command List With -clean Option Information B-23

StarRC User Guide and Command Reference Version F-2011.06

MOS_GATE_CAPACITANCE X

MOS_GATE_DELTA_RESISTANCE X

NET_SEGMENT_CUT_LENGTH X

NET_TYPE X

NETLIST_CAPACITANCE_UNIT X

NETLIST_COMMENTED_PARAMS X

NETLIST_COMMENTS_FILE X

NETLIST_COMPRESS_COMMAND X

NETLIST_CONNECT_OPENS X

NETLIST_CONNECT_SECTION X

NETLIST_CORNER_FILE X

NETLIST_CORNER_NAMES X

NETLIST_COUPLE_UNSELECTED_NETS X

NETLIST_DELIMITER X

NETLIST_DEVICE_LOCATION_ORIENTATION X

NETLIST_FILE X

NETLIST_FORMAT X

NETLIST_GROUND_NODE_NAME X

NETLIST_HIER_PROBE_NODES X

NETLIST_IDEAL_SPICE_FILE X

NETLIST_IDEAL_SPICE_HIER X

NETLIST_IDEAL_SPICE_TYPE X

NETLIST_INCREMENTAL X

NETLIST_INPUT_DRIVERS X

NETLIST_INSTANCE_SECTION X

NETLIST_LOGICAL_TYPE X

NETLIST_MAX_FILE_SIZE X

NETLIST_MAX_LINE X

NETLIST_MERGE_CORNERS X

NETLIST_MERGE_SHORTED_PORTS X

NETLIST_MINCAP_THRESHOLD X

Table B-3 List of Commands With -clean Option Information (Continued)

Command Name

-clean

-cleanT

- cleanX

-cleanFS

-cleanTFS

-cleanXFS

-cleanN

-cleanXREF

-cleanD

Appendix B: Command Lists

Command List With -clean Option Information B-24

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

NETLIST_MINRES_HANDLING X

NETLIST_MINRES_THRESHOLD X

NETLIST_MMC_FORMULA X

NETLIST_MMC_FORMULA_NAMES X

NETLIST_NAME_MAP X

NETLIST_NODE_SECTION X

NETLIST_NODENAME_NETNAME X

NETLIST_PARA_VIEW X

NETLIST_PARASITIC_RESISTOR_MODEL X

NETLIST_PASSIVE_PARAMS X

NETLIST_POSTPROCESS_COMMAND

NETLIST_POWER_FILE X

NETLIST_PRECISION

NETLIST_PRINT_CC_TWICE X

NETLIST_REMOVE_DANGLING_BRANCHES X

NETLIST_RENAME_PORTS X

NETLIST_RESISTANCE_UNIT X

NETLIST_SELECT_NETS X

NETLIST_SIM_OPTIONS X

NETLIST_SUBCKT X

NETLIST_TAIL_COMMENTS X

NETLIST_TIME_UNIT X

NETLIST_TOTALCAP_THRESHOLD X

NETLIST_TYPE X

NETLIST_UNSCALED_COORDINATES X

NETLIST_USE_M_FACTOR X

NETS X

NETS_FILE X

NONCRITICAL_COUPLING_REPORT_FILE X

NUM_PARTS X

OA_DEVICE_MAPPING_FILE X

Table B-3 List of Commands With -clean Option Information (Continued)

Command Name

-clean

-cleanT

- cleanX

-cleanFS

-cleanTFS

-cleanXFS

-cleanN

-cleanXREF

-cleanD

Chapter B: Command Lists

Command List With -clean Option Information B-25

Appendix B: Command Lists

Command List With -clean Option Information B-25

StarRC User Guide and Command Reference Version F-2011.06

OA_LAYER_MAPPING_FILE X

OA_LIB_DEF X

OA_LIB_NAME X

OA_MARKER_SIZE X

OA_PORT_ANNOTATION_VIEW X

OA_PROPERTY_ANNOTATION_VIEW X

OA_SKIPCELL_MAPPING_FILE X

OA_VIEW_NAME X

OASIS_FILE

OASIS_LAYER_MAP_FILE

OBSERVATION_POINTS X

OPERATING_TEMPERATURE X

PIN_CUT_THRESHOLD X

PIO_FILE X

PLACEMENT_INFO_FILE X

POWER_EXTRACT X

POWER_NETS X

POWER_PORTS X

POWER_REDUCTION X

PRINT_SILICON_INFO X

PROBE_TEXT_FILE X

PROCESS_CORNER X

REDUCTION X

REDUCTION_MAX_DELAY_ERROR X

REMOVE_DANGLING_NETS X

REMOVE_FLOATING_NETS X

REMOVE_NET_PROPERTY X

RETAIN_CAPACITANCE_CAP_MODELS X

RETAIN_GATE_CONTACT_COUPLING X

RING_AROUND_THE_BLOCK X

RING_AROUND_THE_BLOCK_SMIN_MULTIPLIER X

Table B-3 List of Commands With -clean Option Information (Continued)

Command Name

-clean

-cleanT

- cleanX

-cleanFS

-cleanTFS

-cleanXFS

-cleanN

-cleanXREF

-cleanD

Appendix B: Command Lists

Command List With -clean Option Information B-26

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

SENSITIVITY X

SHEET_COUPLE_TO_NET X

SHEET_COUPLE_TO_NET_LEVEL X

SHORT_PINS X

SHORT_PINS_IN_CELLS X

SKIP_CELL_AGF_FILE X

SKIP_CELL_PORT_PROP_FILE X

SKIP_CELLS X

SKIP_CELLS_COUPLE_TO_NET X

SKIP_CELLS_COUPLE_TO_NET_LEVEL X

SKIP_CELLS_FILE X

SKIP_INSTANCES X

SKIP_PCELLS X

SKIP_PCELL_LAYERS_FILE X

SLEEP_TIME_AFTER_FINISH

SPICE_SUBCKT_FILE X

STAR_DIRECTORY X

SUBSTRATE_EXTRACTION X

SUMMARY_FILE

SYNOPSYS_LIB_FILE X

TARGET_PWRA X

TCAD_GRD_FILE X

TEMPERATURE_SENSITIVITY X

THICKNESS_VARIATION_FILE X

TOP_DEF_FILE X

TRANSLATE_DEF_BLOCKAGE X

TRANSLATE_FLOATING_AS_FILL X

TRANSLATE_RETAIN_BULK_LAYERS X

VIA_COVERAGE X

VIA_COVERAGE_OPTION_FILE X

WIDE_DEVICE_TERM_RESISTANCE X

Table B-3 List of Commands With -clean Option Information (Continued)

Command Name

-clean

-cleanT

- cleanX

-cleanFS

-cleanTFS

-cleanXFS

-cleanN

-cleanXREF

-cleanD

Chapter B: Command Lists

Command List With -clean Option Information B-27

Appendix B: Command Lists

Command List With -clean Option Information B-27

StarRC User Guide and Command Reference Version F-2011.06

XREF X

XREF_FEEDTHRU_NETS X

XREF_LAYOUT_INST_PREFIX X

XREF_LAYOUT_NET_PREFIX X

XREF_SWAP_MOS_SD_PROPERTY

XREF_USE_LAYOUT_DEVICE_NAME X

ZONE_COUPLE_TO_NET X

ZONE_COUPLE_TO_NET_LEVEL X

Table B-3 List of Commands With -clean Option Information (Continued)

Command Name

-clean

-cleanT

- cleanX

-cleanFS

-cleanTFS

-cleanXFS

-cleanN

-cleanXREF

-cleanD

Appendix B: Command Lists

Command List With -clean Option Information B-28

StarRC User Guide and Command Reference F-2011.06

StarRC User Guide and Command Reference Version F-2011.06

StarRC User Guide And Command Reference Star RC

StarRC_User_Guide

Navigation menu

Versions of this User Manual:

Views

Navigation