raphael nxt user guide - · raphael nxt distribution also contains taurus layout which can be used...

Raphael NXTUser GuideVersion X-2006.03, March 2006

ii Raphael NXT User Guide

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

Right to Copy DocumentationThe 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 StatementAll 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.

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

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

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

Service Marks (SM)MAP-in, SVP Café, and TAP-in are service marks of Synopsys, Inc.

SystemC is a trademark of the Open SystemC Initiative and is used under license.ARM and AMBA are registered trademarks of ARM Limited.All other product or company names may be trademarks of their respective owners.

X-2006.03

Contents

About This Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv

Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi

Customer Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii

Accessing SolvNet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii

Contacting the Synopsys Technical Support Center . . . . . . . . . . . . . . . . xviii

Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviii

1. Getting Started. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Raphael NXT Distribution Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Using Raphael NXT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Viewing Design Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2. Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

General Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Theory of Operation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Files and IO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Outputs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Geometry and Coordinates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Dielectric Boxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Metal Boxes (Conductors) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Trapezoidal Conductors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Raphael NXT Conductor Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Net . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Misc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Ground . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Device Layers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Device Layers and -exclude_devices . . . . . . . . . . . . . . . . . . . . . . . . 18

Raphael NXT User Guide iiiY-2006.03

Contents

Fill Nets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Capacitance Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Boundary Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Accuracy and Runtime. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Effect of grids_per_meter Specification . . . . . . . . . . . . . . . . . . . . . . 23

Greens Function Calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Fundamentals of Resistance Extraction in Raphael NXT . . . . . . . . . . . . . . . . 24

Barrier Layer Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Trapezoidal Cross Sections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Using Resistance Extraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Limitations of Resistance Extraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3. Input/Output Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Input Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Technology File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32Command Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32Technology File Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Technology File Guidelines. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Advanced Technology File Examples. . . . . . . . . . . . . . . . . . . . . . . . 35More Technology File Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Design File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39Design File Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Output Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Capacitance Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Capacitance Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

SPICE Style Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Input Specification for Resistance Extraction. . . . . . . . . . . . . . . . . . . . . . . . . . 46

Technology File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Design File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Contact File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47Contact/Node Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47Port Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Distributed RC Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

iv Raphael NXT User GuideY-2006.03

Contents

4. Multi-Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Automatically Configuring Server and Clients . . . . . . . . . . . . . . . . . . . . . . . . . 50

MP Based Extraction with Raphael NXT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Cleaning up after Extractions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

MP Licensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Manually Starting the Server and Clients. . . . . . . . . . . . . . . . . . . . . . . . . 53Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Adding MP Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5. Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

alias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

assert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

build_gf_tables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

See Also. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

ctrlc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

exclude. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Arguments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

See Also. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

extract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Raphael NXT User Guide vY-2006.03

Contents

Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

GLOB Expression Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

See Also. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

import. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

init_extract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

See Also. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

plot_tech . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Arguments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

See Also. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

print_capacitance_matrix. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

DESCRIPTION. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

See Also. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

vi Raphael NXT User GuideY-2006.03

Contents

print_capacitance_report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

See Also. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

print_mp_info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

print_param . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

print_rc_report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

See Also. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

print_resistance_report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

See Also. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

printf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

quit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

read_contact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Raphael NXT User Guide viiY-2006.03

Contents

Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

DESCRIPTION. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

See Also. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

read_gf_tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

See Also. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

read_design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

See Also. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

read_state . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

See Also. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

read_tech. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

See Also. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

resistance_extract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

viii Raphael NXT User GuideY-2006.03

Contents

Arguments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

set_boundary_box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

See Also. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

set_boundary_condition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

See Also. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

set_convergence_goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

See Also. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

set_fill_nets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

set_ground_level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

Raphael NXT User Guide ixY-2006.03

Contents

Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

set_grounded_nets_ok . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

See Also. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

set_layer_inflation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

See Also. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

set_layer_side_tangent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

See Also. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

set_min_capacitance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

See Also. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

set_net_convergence_goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

x Raphael NXT User GuideY-2006.03

Contents

See Also. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

set_rng_seed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

See Also. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

set_statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

set_walk_params . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

set_xcap_convergence_goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

See Also. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

show_boundary_condition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

show_design_nets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

show_extraction_nets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

Raphael NXT User Guide xiY-2006.03

Contents

Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

spf_report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

See Also. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

unalias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

uninit_extract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

See Also. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

unset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

wextract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

NAME. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

See Also. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

which . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

xii Raphael NXT User GuideY-2006.03

Contents

write_design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

See Also. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

write_gf_tables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

Argument . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

See Also. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

write_state . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

See Also. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

write_tech . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

See Also. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

A. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

Technology File Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

The Design File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

The Control File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

Example using APIS and GDS2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

APIS Control File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

Raphael NXT User Guide xiiiY-2006.03

Contents

Identifying Nets for APIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

Running Raphael NXT with APIS Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

Raphael NXT Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

Example using Device Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

More Raphael NXT Design File Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

Technology File Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

Resistance Extraction Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

xiv Raphael NXT User GuideY-2006.03

About This Manual

This manual describes the use of the Synopsys Raphael NXT 3D capacitance extractor. Raphael NXT can extract capacitance of nets in large designs to better than 1% accurate. Raphael NXT can be used by itself (standalone mode) or can be used as part of Synopsys STAR-RCXT.

A distributed processing option is available for use with Raphael NXT. The Raphael NXT distribution also contains Taurus Layout which can be used to view the structures analyzed by Raphael NXT. Refer to Chapter 8 of the Raphael Reference Manual for details on APIS.

Audience

This manual assumes that the user is familiar with integrated circuit design and the concept of electrical capacitance.

Related Publications

For additional information about Raphael NXT, see:■ The documentation installed with the Raphael NXT software and available

through the Raphael NXT Help menu■ The Raphael NXT release notes, available on SolvNet (see Accessing

SolvNet on page xvii)■ Documentation on the Web, which provides HTML and PDF documents and

is available on SolvNet (see Accessing SolvNet on page xvii)

Raphael NXT User Guide xvY-2006.03

About This ManualConventions

■ Synopsys Online Documentation (SOLD), which is included with the software for CD users or is available to download through the Synopsys Electronic Software Transfer (EST) system

■ The Synopsys MediaDocs Shop, from which you can order printed copies of Synopsys documents, at http://mediadocs.synopsys.com

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

• Raphael

• STAR-RCXT

• Taurus Layout

Conventions

The following conventions are used in Synopsys documentation.

Convention Description

Courier Indicates command syntax.

Italic Indicates a user-defined value, such as object_name.

Bold Indicates user input—text you type verbatim—in syntax and examples.

[ ] Denotes optional parameters, such as

write_file [-f filename]

... Indicates that a parameter can be repeated as many times as necessary:

pin1 [pin2 ... pinN]

| Indicates a choice among alternatives, such as

low | medium | high

\ Indicates a continuation of a command line.

/ Indicates levels of directory structure.

xvi Raphael NXT User GuideY-2006.03

http://mediadocs.synopsys.com

About This ManualCustomer Support

Customer Support

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

Accessing SolvNet

SolvNet includes an electronic knowledge base of technical articles and answers to frequently asked questions about Synopsys tools. SolvNet also gives you access to a wide range of Synopsys online services, which include downloading software, viewing Documentation on the Web, and entering a call to the Support Center.

To access SolvNet:

1. Go to the SolvNet Web page at http://solvnet.synopsys.com.

2. If prompted, enter your user name and password. (If you do not have a Synopsys user name and password, follow the instructions to register with SolvNet.)

If you need help using SolvNet, click Help on the SolvNet menu bar.

Edit > Copy Indicates a path to a menu command, such as opening the Edit menu and choosing Copy.

Control-c Indicates a keyboard combination, such as holding down the Control key and pressing c.

Convention Description

Raphael NXT User Guide xviiY-2006.03

http://solvnet.synopsys.com

About This ManualAcknowledgments

Contacting the Synopsys Technical Support Center

If you have problems, questions, or suggestions, you can contact the Synopsys Technical Support Center in the following ways:■ Open a call to your local support center from the Web by going to

http://solvnet.synopsys.com/EnterACall (Synopsys user name and password required).

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

• E-mail [email protected] from within North America.

• Find other local support center e-mail addresses at http://www.synopsys.com/support/support_ctr.

■ Telephone your local support center.

• Call (800) 245-8005 from within the continental United States.

• Call (650) 584-4200 from Canada.

• Find other local support center telephone numbers at http://www.synopsys.com/support/support_ctr.

Acknowledgments

Portions Copyright (c) 1985-90 by Kenneth S. Kundert and the University of California.

Portions Copyright (c) 1988-90 Regents of the University of California.

xviii Raphael NXT User GuideY-2006.03

http://solvnet.synopsys.com/EnterACall

http://www.synopsys.com/support/support_ctr

http://www.synopsys.com/support/support_ctr

11Getting Started

This chapter gives step-by-step instructions for running Raphael NXT.

This chapter contains the following sections:■ Raphael NXT Distribution Contents■ Using Raphael NXT■ Viewing Design Files

Raphael NXT Distribution Contents

The Raphael NXT CD contains the following components:■ Raphael NXT extraction program RANXT which reads the design and

technology in a special format and extracts the total and coupling capacitances at the circuit nodes using the random walk algorithm.

■ The Advanced Parser for Interconnect Structures (APIS) program which is based on the Hercules engine and can read GDS2 designs, process the layers (using Boolean and resize operations), and output data that RANXT can read.

■ Taurus Layout, a limited GDS2 structure viewer and editor.Taurus Layout also can be used to view .tl2 files generated from Raphael NXT designs.

Raphael NXT User Guide 1Y-2006.03

Using Raphael NXT

■ nxt2tl2, a utility script for converting Raphael NXT design files into tl2 files that can be viewed in Taurus Layout.

■ mpconfig, a utility script for starting and shutting down the distributed (multi- processing) version of Raphael NXT.

■ mp_server, mp_client, and ranxt_helper are executables used during multi- procesing. Normally you will not need to run these executables directly.

Using Raphael NXT

To familiarize yourself with the Raphael NXT system for capacitance extraction, follow the steps below:

1. Download the latest Raphael NXT release and install it on your machine.

2. Start Raphael NXT by running RANXT.

3. Familiarize yourself with commands available at ranxt> prompt. For a list of all commands, type:

help at the ranxt> prompt.

For help on individual command, use the help command_name on the ranxt> prompt.

For detailed help, view the man pages of the command by typing:

man command_name on the ranxt> prompt.

4. To put your Raphael NXT commands in a file and execute them in batch mode, type:

ranxt –f file_name

5. To put your Raphael NXT commands in a file and execute them in batch mode with command echoing, type:

ranxt –p file_name

6. When running in batch mode (-p or –f), Raphael NXT aborts if an error occurs. Use the –k command-line option to force Raphael NXT to continue running even when there is an error.

ranxt –k –f file_name

Read the Description and Examples sections to learn how Raphael NXT operates and how to use it.

2 Raphael NXT User GuideY-2006.03

Viewing Design Files


To view Raphael NXT design files, use the following process:

1. Convert the design and technology files into an .tl2 file using the utility program nxt2tl2. The nxt2tl2 perl script is included as part of the Raphael NXT distribution and takes three arguments, the name of the design file, the name of the technology file, and the name of the .tl2 file to create. For example:

nxt2tl2 -design design_name -tech tech_file_name -tl2 name.tl2

2. View the file using Taurus Layout which is included as part of the Raphael NXT distribution.

3. Start Taurus Layout by typing Layout at the prompt tlayout.

4. Using the pulldown menu, select File and Load TL2 and browse for the tl2 file created in Step 1. Layout will display a top-down (the x-y plane) view of the design. You also can create a “cutline” in Taurus Layout and display a cross section through a portion of the design.

If you want to edit the design in this version of Raphael NXT (Y-2006.03), you must save the design as GDS and then regenerate the design file for Raphael NXT using APIS.


22Description

This chapter describes the general specifications, operation theory, input/out files, geometry/coordinates, conductor/ capacitance types, boundary conditions, and runtime of Raphael NXT.

This chapter includes the following sections:■ General Specifications■ Theory of Operation■ Boundary Conditions■ Accuracy and Runtime■ References

Raphael NXT is a true three dimensional (3D) capacitance extractor tool that solves electrostatic equations using statistical methods. When given a physical description of design (geometry of nets and dielectric specification from the process layers), Raphael NXT can compute self and coupling capacitance values of nets with arbitrary user specified accuracy.

Interconnect capacitances, both self and coupling, are of immense importance in sub-micron layouts. Their accurate computation is key to the success of any subsequent timing or signal integrity analyses. Raphael NXT is a tool aimed to compute these capacitances with arbitrary accuracy. Raphael NXT is based on Statistical Floating Random Walk methods and is suitable for large layouts (thousands to millions of conductors). Raphael NXT can read a chip layout (As


General Specifications

GDSII or other geometric format) and compute the total and coupling capacitances at all nets of interest. Raphael NXT had advanced features that allow it to extract capacitance in layouts with floating metal (metal fill) without introducing extra nodes in the Spice netlist. Raphael NXT can be run on a single CPU or in parallel on many machines across a network.

General Specifications

Raphael NXT extracts capacitance by solving the Laplace equation in 3D. Raphael NXT input structures are comprised of ideal conductors and ideal dielectrics with fixed constant dielectric constant. Raphael NXT considers all 3D effects and is capable of calculating total net capacitance and coupling capacitance between nets. Shielding effects of intervening conductors are included in all calculations.

Multiple dielectric layers are supported and can be planar or conformal. Raphael NXT input consists of rectangular boxes that describe the metal conductors. Non-Manhattan geometries are supported by converting nonrectangular polygons into boxes using a staircase approximation. This conversion is done automatically by APIS which is included as a part of Raphael NXT.

Raphael NXT can handle layouts with millions of conductors and extracting thousands of nets with no restriction on the number of metal or dielectric layers. Direct SPICE-type output is available, and Raphael NXT can read GDS2 stream data through the APIS interface which is included as part of Raphael NXT. You can control accuracy and runtime.

Theory of Operation

Raphael NXT calculates capacitance using the floating random walk method, which is outlined below using an intuitive explanation.

In Physics, capacitance is defined as the derivative of the charge in a structure with respect to the potential on its terminals:

If there are N terminals, the capacitance is described by an N-by-N matrix. The self or total capacitances are found on the diagonals of the matrix. The cross or coupling terms are found on the off diagonal elements. If the capacitances are voltage invariant, which is a good approximation for the interconnects in typical

C = dQ/dV


Theory of Operation

ICs, you can calculate the capacitance matrix a row at a time by applying fixed voltages to the terminals and finding the resulting charges on all the terminals.

To calculate the charges, Raphael NXT uses Gauss’s law which states the charge contained in a volume is equal to the surface integral of the normal component of the displacement vector on the volume:

To evaluate this integral, you must construct a Gaussian surface, which is a box that encloses only the conductor being studied. In Raphael NXT, Gaussians are constructed by inflating the boxes that comprise the conductors.

Figure 1 Gaussian Surface in 2D

Raphael NXT evaluates the surface integral using the Monte Carlo method. To do this evaluation, Raphael NXT calculates the surface area A of the Gaussian and then picks N points randomly on the surface and evaluates D at those points. The integral then becomes:

In the 2D example in Figure 1, A is the perimeter of the dotted box (2*h + 2*w) and D would be evaluated at randomly selected points on the dotted box. The component of D normal to the box edges is used. Therefore, for the vertical edges, Dx is used; for the horizontal edges, Dy is used. Each of the selected points will be the starting point for a random walk.

∫ •= dsDQ

Conductor

Conductor

Conductor

Gaussian Surface

h

W

��N

iiD

NAQ

1)(∑

=

=N

i

iDNAQ

1

)(


Theory of Operation

You calculate the displacement vector as the permittivity multiplied by the electric field, and the electric field is the derivative of the potential:

To calculate the potential at a point, a Green’s function (GF) is used. The GF relates the potential at a point to the integral of the potentials on a surface (or line in 2D) which encloses the point:

The simplest example is a circle in free space. For the circle, the potential at the center is the average of the potential along the perimeter. So the integration variable defines the position along the circle (or the angle to the x axis) and runs from 0 to 2π. The GF is simply 1/2π.

The GF integral also can be evaluated using the Monte Carlo method. For the circle, N points on the perimeter are selected, and the potential at the center is their average:

Since the GF is a constant (and does not depend on which point you jump to), the probability of jumping to any point on the perimeter of the circle is equal. Thus, you would generate the jump angle eta uniformly between 0 and 2π.

To find the potential on the original point on the Gaussian surface, you can apply the Green’s integral recursively. Using circles, you can hop from the center to a randomly chosen point on the perimeter of the circle and keep hopping until you land on a point of known potential, i.e., an electrode in the structure.

This hopping action takes a random path through the structure and the circles can be any size so long as they only enclose free space; hence, the name floating random walk. The walks always start on the Gaussian surface and end on an electrode. In practice the largest possible radius for the circle would be chosen, so that each circle would always be touching an electrode. This maximizes the chance that you actually land on an electrode and can end the walk.

)(zV

yV

xVD

∂∂+

∂∂+

∂∂= ε

∫= ηηη dVyxgyxV )(),,(),(

∑=

=N

i

ViN

centerV1

1)(


Theory of Operation

Figure 2 Random Walk Process using Circular GFs

Walks that terminate on the electrode inside the Gaussian contribute to the self charge or self capacitance Cii for the electrode. Walks that terminate on other electrodes contribute to the coupling capacitance between electrodes. Therefore, if a walk starts on the Gaussian surrounding electrode i and terminates on electrode j, the walk will contribute to capacitance Cij.

The final part of the algorithm is to relate the potential back to the electric field and displacement vector. You can do this by differentiating the GF. For example, for the X component of D:

Where r is the radius of the circle. The Cos()/r term is effectively a weighting term. This term can be positive or negative depending on the angle that is randomly selected.

Note: You are only calculating the electric field on the very first hop, so this weighting term is only calculated on the first hop. Subsequent hops only determine the ending point for the walk. Once that the ending point is determined, this weighting term is added either to the self term or the appropriate coupling term.

Therefore, the algorithm (using circles) works as follows:

1. Inflate the target electrode to form a Gaussian box. This box must not touch or contain any other electrodes.

2. If the solution is accurate enough, then quit.

3. Randomly pick a point on the Gaussian box.

Electrode I

Elect J

∑∫=

==N

iCosV

rNDxordVCos

rDx

1

2

0)()(1)()(

21 ηηηηηπ

π


Theory of Operation

4. From this point, calculate the radius r of the largest possible circle that touches but does not intersect any electrodes

5. Generate a random angle eta between 0 and 2π.

6. Calculate Wi = 1/r Cos(eta).

7. Jump to the point eta on the circle.

8. If this point touches an electrode, then add Wi to either:

a. The self capacitance (Cii) if the electrode is the starting electrode, then go to Step 2

b. The coupling capacitance (Cij) if it is not the starting electrode, then go to Step 2.

c. If the point is not on an electrode, go to Step 9.

9. At the new point, calculate the largest possible circle that touches but does not intersect any electrodes.

10. Generate a random angle eta between 0 and 2π.

11. Go to Step 7.

The problem with using circles is that the chance of landing on a point on the circle that touches an electrode is very small. This results in each walk having a very large number of hops and poor performance. To avoid this difficulty, Raphael NXT uses squares instead of circles.

At each step the largest square that touches, but does not intersect any electrodes, is chosen. Since a large portion of the edge of a square can touch an electrode, the probability that a walk will jump to an electrode edge (and terminate) is much larger. The probability of jumping to different points on the square is no longer uniform. The probability of jumping to a point near a corner is lower than jumping to the center of the edge.

Finally, the weighting function is more complicated. However, the advantages of using squares greatly exceed the extra cost of computing the more complicated hop probabilities and weight functions, so Raphael NXT uses squares. For more information, see the article in reference [1].


Theory of Operation

Figure 3 Random Walk Process using Squares

Files and IO

FilesRaphael NXT reads three files:■ Design file contains the description of the layout in the form of boxes, nets,

and net groups.■ Technology file contains descriptions of metal and dielectric layers and their

z coordinates and special flags to indicated device layers. ■ Control file specifies the names of the design and technology files, the steps

to perform in the extractions, and which data to report.

Note: You can interactively control Raphael NXT from a terminal instead of using the control file.

OutputsRaphael NXT produces the following types of output: ■ Capacitance report lists the various type of capacitance Raphael NXT found

at and between nets. ■ Capacitance matrix can be generated, but is typically not useful for large

designs. ■ Capacitance in SPICE format can be created using the spf_report

command.

Electrode I

Elect J


Theory of Operation

■ Raphael NXT also stores information on the boundary conditions and technology.

■ You can save the simulator state to a file so you can restart Raphael NXT later on to continue a simulation from the current point using the write_state and read_state commands.

■ Raphael NXT uses a GF tables which may take several minutes to compute. These tables may be stored in a file for future use to avoid having to recompute them each by using the write_gf_tables and read_gf_tables commands.

Geometry and Coordinates

Raphael NXT extracts capacitance in 3D, so structures for Raphael NXT also must be specified in 3D. In Raphael NXT the IC layout is done in the x-y plane, and the z dimension is typically zero at the surface of the silicon and positive upwards into the oxide. Raphael NXT supports two geometric elements both of which are simple 3D rectangular boxes:■ Box■ Planar box

The box is described by x, y, z coordinates of its two opposite corners:

box y1 y1 z1 x2 y2 z2

x1, y1, and z1 are integers describing the location of the first corner; x2, y2, and z2 are integers describing the second corner.

For the planar box, only the x and y coordinates of two opposite corners are used. The z coordinates come from the layer name through the technology file:

layer_name planar_box x1 y1 x2 y2

layer_name is a string which gives the name of the layer. The z coordinates for the layer are given in the technology file. x1 and y1 are the coordinates of the first corner, and x1 and y2 the coordinates of the second corner.

Box and planar boxes are used in the design file to describe conductor and dielectric regions.


Theory of Operation

Dielectric Boxes

Dielectric boxes may be freely placed throughout the design. There are two steps to this process:

1. Declare the boxes in the technology file using a dielectric_box statement for each value of the relative dielectric constant and range of z coordinates that you expect to be using in your design.

dielectric_block 4.5 0 400dielectric_block 3.7 500 650

2. Within the design file, declare the boxes. These boxes must be regular 3D boxes that are not part of any net. You can use as many of these boxes as you wish. These dielectric boxes will overwrite the normal dielectric layers established by the technology file:

dielectric 4.5 box 0 0 0 100 100 100 box 300 300 300 350 350 350dielectric 3.7 box 500 500 500 550 600 610

Note: There is some computational penalty associated with dielectric boxes (similar to that for conformal layers). If your design has flat planar dielectic layers, it is much more efficient to use the normal dielectric layers in the technology file than to specify these layers as dielectric boxes in the design file.

Metal Boxes (Conductors)

Metal boxes may be freely placed throughout the design using layers and planar boxes or regular 3D boxes. These metal boxes may be part of electrical nets or unassigned. (Unassigned metal boxes will either become part of fill nets or the misc net; see the example below). Indicate that the boxes are metal by using the metal keyword in the design file. Layer names for planar box must have been previously declared in the technology file:

metal box 0 0 0 100 100 100 box 300 300 300 350 350 350 layer1 planar_box 600 655 700 725 layer1 planar_b 800 855 810 825


Theory of Operation

Trapezoidal Conductors

To specify metal layers with a trapezoidal crosssection (in the x-z and y-z planes), use the set_layer_tangent command in the control file. The geometry for the trapezoidal conductor is shown in Figure 4. The side_tangent parameter is a dimensionless number which is the ratio of horizontal change divided by 1/2 of the height of the conductor. If the side_tangent parameter is positive, the trapezoid is smaller at the bottom. If the side_parameter is negative, the trapezoid is smaller at the top. To specify the side_tangent for a given layer use the following in the control file:

set_layer_side_tangent -layer name -tangent number

The layer name refers to the layer name given in the technology file; therefore, only planar boxes may be specified as trapezoidal.

When Raphael NXT calculates the capacitance, Raphael NXT internally accounts for the trapezoidal shape of the electrodes. The runtime penalty for using trapezoidal electrodes is on the order of 40%.

Figure 4 Geometry for Trapezoidal Conductor

A

B

B

SIDE_TANGENT = A/B

W

SIDE_TANGENT < 0

A

B

B

W

SIDE_TANGENT > 0


Theory of Operation

Raphael NXT Conductor Types

Structures in Raphael NXT are composed of conductors and dielectrics. Dielectrics are typically read through the technology file. Conductors are composed of metal boxes and/or planar boxes and are read from the design file. Boxes are specified using the x, y, z coordinates at two opposite corners. planar boxes are specified using the x, y coordinates at two opposite corners, and the z-location and thickness come from the layer name through the technology file.

Raphael NXT has five different conductor types:■ Net and net group■ Misc■ Ground■ Device■ Fill

Each conductor type reports capacitance differently. Conductors are composed of collections of metal boxes, and all the metal boxes in a conductor are assumed to be connected and at the same potential. The following subsections describe the five types of conductors and their reporting rules.

NetNet is the most common and general type of conductor. Random walks are started only from nets and net groups which are collections of nets. Raphael NXT 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 used in the design file:

net net_1metal metal1 planar_box 195 0 200 97 metal box 3 6 9 12 15 18end

Net Group

A net group is a collection of nets assumed to be electrically connected and, therefore, at the same potential. Raphael NXT extracts the capacitance between nets in different net groups but not between nets in the same net group. Net groups are useful when you have a large net and would like to know


Theory of Operation

the capacitance contribution of certain sections of the large net. Net groups are created from nets using the net_group command:

net_group ng_1 net1 net2 net3 …..end

So in this example, net_group ng_1 is made up of the three nets: net1, net2 and net3. The net_group command is used in the design file.

Setting Net Priority

If boxes from two nets in a net group overlap, the net priority can be used to decide which net will be used for reporting the capacitance and which net will be ignored. (This applies only to the portion of the nets where the overlap occurs). In Raphael NXT the net with the higher priority is selected. The priority specification for nets is optional, and all nets that have no priority specified automatically default to a priority of zero.

You can set net priority in two ways:

1. Set the priority explicitly on the nets in the design file:

net net_1a priority 5 metal metal1 planar_box 195 0 200 97endnet net_1b priority 4 metal metal1 planar_box 195 0 200 97endnet_group net_1 net_1a net_1b end

So in the above example, which has two overlapping nets, all the capacitance are reported at net_1a since it has the higher priority

2. Use the -increment_priority option on the read_design command. This causes the priority number on nets to increment each time that a net is read which then causes the nets specified at the end of the file to have the highest priority.

net net_1a metal metal1 planar_box 195 0 200 97endnet net_1b metal metal1 planar_box 195 0 200 97endnet_group net_1 net_1a net_1b end


Theory of Operation

So if this second design is read with:

read_design -file name -increment_priority

Then all of the capacitance are assigned to net_1b since it is specified later and, therefore, has higher priority. If priorities are not specified at all, the capacitance is assigned randomly between the two nets.

Finally if -increment_priority is used and priority on nets is explicitly specified, the explicitly specified nets are placed at a higher priority than all the incremented nets.

MiscMetal boxes that are not part of a net are lumped together into a single large net misc. Raphael NXT then reports the capacitance from individual nets to the single misc net. (Also see Fill Nets on page 18.)

Note: Since Raphael NXT does not start walks at misc, it will not report total capacitance for misc or capacitance from misc to ground.

GroundIf Dirchlet boundary conditions are used (the default), then the edges of the bounding box are electrical ground planes which form a single net called ground. In addition, in the design file, nets may be selected and grounded in which case they become part of ground as well. Raphael NXT reports the capacitance from other nets to ground, but since walks are not started from ground, total capacitance of ground is not reported.

Device LayersBoxes created using the RNX_NWELL, RNX_PWELL, RNX_NDIFF, RNX_PDIFF, RNX_DIFF, or RNX_WELL layer type are referred to as device layers. Planar boxes that are created using the device layers are treated similar to misc nets. Random walks are not started from these boxes, but walks that terminate on them contribute to the coupling capacitance between the nets. Device layer boxes may be placed flush (at the same z coordinate) or above the ground plane. Since walks are not started from the device layer boxes or from the ground plane, a short circuit between the device layers and ground does not result. Using the device layers in this way, you can determine the fraction of the capacitance from other nets that goes to ground and to the net connected to the device terminals. The device layers also are useful for creating PN junctions


Theory of Operation

since boxes that touch and belong to different nets can be created using the device layers.

As their name implies, RNX_PWELL and RNX_NWELL are useful for modeling the PWELL and NWELL layers of an IC. For example, if you connect all the NWELL to a power supply like VDD, you will be able to determine the capacitance from all other nets except ground to VDD. Likewise, if you calculate the capacitance at VDD, you will obtain the correct total capacitance, except the capacitance from the NWELLs to ground (the substrate) will not be included.

The RNX_PDIFF and RNX_NDIFF layers function in a way identical to RNX_PWELL and RNX_NWELL, except they take precedence over RNX_NWELL and RNX_PWELL. Therefore, if a RNX_NDIFF or RNX_PDIFF box overlaps an RNX_NWELL or RNX_PWELL box, the RNX_NDIFF/RNX_PDIFF layer wins. Any walks terminating on the overlap region are assigned to the net connected to RNX_NDIFF/RNX_PDIFF. As expected, RNX_NDIFF and RNX_PDIFF typically would be used for the sources and drains of transistors.

Device Layers and -exclude_devicesThe init_extract command has a special option -exclude_devices:

init_extract –exclude_devices net1 net2 ….

When the –exclude_devices option is specified, walks that terminate on the device layers (RNX_WELL, RNX_PWELL, RNX_NDIFF, RNX_PDIFF, RNX_DIFF, RNX_WELL) are ignored and do not contribute to the net total capacitance of to the coupling capacitance between nets. However, the device layers remain effective as shields. The –exclude_devices option is useful when the device capacitances have been included in some other part of the netlist; e.g., as part of a SPICE transistor model.

By using the -exclude_devices option, the device capacitances will not be counted twice; i.e., counted as contributing to both the interconnect capacitance and the SPICE model capacitance.

Fill NetsA fill net is assumed to be electrically floating, i.e., not connected to any circuit elements in the netlist. The potential at fill nets is effectively determined by solving with its charge on the fill net set equal to zero. Fill nets are used to model fill metal polygons in a chip. Fill metal consists of boxes inserted into a metal layer to improve planarity of the metal layer. Even though fill nets are not


Theory of Operation

electrically connected to anything, they can introduce capacitive coupling between other nets.

For example, as shown in Figure 5, the center electrode is floating while Net 1 and Net 2 are normal circuit nets. The charge on Net 1 is:

Figure 5 Capacitance of a Fill Net

The effective capacitance seen at Net1 is:

And the coupling capacitance between Net 1 and Net 2 is:

Thus, the floating metal increases the total capacitance seen at Electrode 1, and also introduces a larger coupling capacitance between Electrode 1 and Electrode 2.

Specifying Fill Nets, Method 1

Raphael NXT has two ways to specify fill nets:

The first method is to create the fill nets in the same way as regular nets are created, that is using net and box statements. Then in the control file you tell Raphael NXT which nets are fill nets using the set_fill_nets command:

set_fill_nets net1 net2 net….

210

21210111

)(CCC

CCVVCCVQ++−+

=

1

2

Co

C1 C2

210

2101

CCCCCCC

+++

210

21

CCCCC

++


Theory of Operation

For convenience, you can name all fill nets using a consistent naming convention, e.g., appending _fill to their name. Then you can select all fill nets at once using wildcard matching:

set_fill_nets *_fill

Specifying Fill Nets, Method 2

In the second method, you enter the fill nets in the design file as simple boxes that are not part of any net (similar to the misc boxes discussed earlier). Raphael NXT then analyzes connectivity of the boxes and builds the fill nets out of the boxes. Raphael NXT traces the entire connectivity of these boxes, including paths through vias to other layers. Then during the capacitance analysis, the floating fill nets are handled in an appropriate manner. To select Method 2 of specifying fill net, use the -dummy_as_fill switch on the read_design command:

read_design -file my_design -dummy_as_fill

The capacitance of fill nets is not reported in the output, but the changes that fill nets introduced into the capacitance (both coupling and ground) of other nets are included. Since fill nets tend to increase the number of hops needed for walks to terminate on a normal net, it may improve convergence if you specify:

set_walk_params –max_hops 10000

Capacitance Types

Raphael NXT reports four types of capacitance at a node:■ Total capacitance is the capacitance from the net to all other objects in the

simulation.■ Coupling (xcap) is capacitance between to nets that are not part of the same

net group.■ Misc capacitance is capacitance between the target net and other metal

boxes that are not part of any net.■ Ground capacitance is capacitance from the net to the grounded bounding

box or to other grounded nets.

Each capacitance type is reported in a separate section of the Raphael NXT capacitance report. You can select which types of capacitance to report using the various options on the print_capacitance_report command.


Boundary Conditions

For example, to report all four components use:

print_capacitance_report -total -gnd -misc -xcap

Boundary Conditions

Boundary conditions are applied at the six edges of the simulation domain. By default Raphael NXT uses a Dirchlet boundary condition of zero volts. This is equivalent to placing a ground plane along each face of the simulation cube. These ground planes are connected to the Raphael NXT global ground net, so capacitance from nets to the boundary is reported as capacitance to ground.

Note: This is different from Raphael RC2 and RC3 which use a Neumann or reflecting boundary condition at each external edge.

In general the Dirchlet boundary condition used in Raphael NXT causes the reported total capacitance at a node to be higher than 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 Raphael NXT using the set_boundary_condition command. For example, to use Dirchlet for the normal ground plane (silicon surface) and Neumann for the other five faces, use:

set_boundary_condition -bc_xn N -bc_yn N -bc_zn D -bc_xp N -bc_yp N -bc_zp N

You also may specify periodic boundary conditions on the Xp, Xn and Yp, Yn edges. 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 Xp (positive X) edge reenters at the Xn (negative X) side of the device. Periodic boundary conditions are useful for devices with repeated cells like RAM or CCD devices.

Note: Periodic boundary conditions must be specified in pairs; so if Xp is periodic, then Xn must be as well. Likewise, if Yp is periodic, Yn also must be periodic. Periodic boundaries are not available on the Z faces.

Accuracy and Runtime

As with most CAD tools, greater accuracy requires longer runtime. In Raphael NXT there is an inverse quadratic dependence, so in general reducing the accuracy tolerance by a factor of three (from 3 to 1%) results in a 9 times



increase in CPU time. The default accuracy tolerance in Raphael NXT is 1 sigma at 3% for total capacitance. This means that the error in total capacitance for 63% of the nets extracted will be less than 3%.

In general, runtime is proportional to the number of nets extracted. Runtime is also weakly dependent on the overall size of the layout (number of boxes or polygons). Increasing the number of dielectric layers also can cause the runtime to increase since the number of hops required for a walk to reach a conductor will increase.

Small coupling capacitors can be very slow to converge. To determine the value of a coupling capacitor between two electrodes I and J, a walk must start on electrode I and end on electrode J. The smaller the coupling capacitor, the smaller the probability that this will happen, and a larger number of total walks is needed to get accurate total statistics on the coupling capacitor. 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 times more walks are needed to calculate the coupling capacitor 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 these converge the fastest in Raphael NXT.

However, by default Raphael NXT does not check the convergence of coupling capacitors. To force Raphael NXT to converge coupling capacitors, use the set_convergence_goal statement.

For example, to converge coupling capacitors >1e-16 Farads to 10% and self capacitance to 3% use:

set_convergence_goal -perc_self_cap 3 -perc_coup_cap 10 -abs_coup_cap 1e-16

Due to the slow convergence of small coupling capacitors, you must set the absolute goal. Otherwise, Raphael NXT runs indefinitely trying to resolve insignificant coupling capacitors.

Note: If there is one particular coupling capacitor of interest, there is no way to force Raphael NXT to evaluate just that one. Coupling capacitors are evaluated in random order based on where the random walks start and end.

You also can specify different convergence goals for different nets or coupling capacitances between nets within the design. To set convergence goals for individual nets, use:

set_net_convergence_goal -perc_self_cap 1 -abs_coup_cap 1e-16 net1 net2 net3 ...



To specify convergence goals for a coupling capacitance between a pair of nets, use:

set_xcap_convergence_goal -perc_self_cap 2.0 -abs_coup_cap neta net2

If convergence goals are not set for a given net of coupling cap, then the global values set on the set_convergence_goal statement apply. Refer to the user reference manual for more information.

Effect of grids_per_meter SpecificationRaphael NXT performs all geometric calculations using integers and, therefore, all geometries are entered as integers in grid units. In the technology file you can specify how many meters each grid unit represents. It is important to ensure that the grid unit specified is small enough to accurately represent the geometry. Typically, you will want to use about 100 grid units to represent the smallest feature in you process (giving about 1% accuracy in the geometry specification). Therefore, if you have a 90-nm process, (with the smallest feature being about 90 nm in length), you will want to use grids_per_meter = 1e9 in the technology file so that each grid unit represents 1 nm.

The grids_per_meter parameter also has a weak effect on the runtime, with smaller grid units causing a longer runtime. Therefore, while you could use 1e10 grid_units_per_meter for the 90-nm process and get slightly better accuracy, the runtime would be longer (typically about two times longer than with the 1e9 grids_per_meter).

Greens Function Calculation

Raphael NXT precalculates tables of GFs based on the dielectric configuration specified within the technology file. The GFs are used to compute the hop probabilities at different locations within the chip. For a given technology, it is only necessary to generate the GF tables once; they can then be used for multiple designs in that technology. For complex technologies (ones with many dielectric layers), it may take 10 or 15 minutes to generate all the required GFs, so reusing them is attractive.

To calculate a new set of GF tables, first read in the technology file and then use:

build_gf_tables -zc -level 3


Fundamentals of Resistance Extraction in Raphael NXT

The -zc parameter tells Raphael NXT to build GFs which are a function of the z coordinate. If you use -zc, it takes longer to build the tables, but the extraction will run more quickly. Using -zc enables a single hop to span multiple dielectric layers. If you do not specify -zc, Raphael NXT builds only GF pairs, and as a result, hops must stop at every dielectric boundary resulting in a much larger number of hops and slower overall runtimes. The level parameter is used to control the size of the GF cube and may be set to 1, 2 or 3. Usually level=3 is the best choice.

Once that you have built GF tables, you can proceed with the extraction or you can save the tables to disk for use with other designs. To save the tables to disk, use:

write_gf_tables -file name

To use a precalculated set of tables with another design, first read the technology file, then instead of using build_gf_tables, use:

read_gf_tables -file name

Then proceed with the rest of the extraction. Raphael NXT automatically checks to ensure that the GFs read are consistent with the technology file.


Raphael NXT uses the 3D Finite Element Method (FEM) to model the current flow in interconnect conductors and, hence, computes resistance between ports as follows:■ First, Raphael NXT analyzes the 3D boxes of each net and identifies all

connected components. ■ Then each connected component is decomposed into hexahedral

(rectangular) elements, and all overlaps are removed. The hexahedrons are constructed so that the faces of two adjoining hexahedrons always overlap completely. The ports and contacts are then placed into the appropriate hexahedron edges.

■ Then the FEM IDs are assigned to nodes of each box and stitched together to form the complete admittance matrix.

■ Finally, the admittance matrix for each port is obtained by appropriately exciting the component-admittance matrix.



The FEM model used to approximate the potential inside each hexahedron is of the form:

Vi = ai + biX + ciY + diZ + eiXY + fiYZ + giXZ + hiXYZ

The unknown coefficients (a-h) are determined from the potentials at the eight corner points. Using the above function in the Laplace equation and using the boundary condition for current flow at the faces, an equivalent admittance matrix, Ye, is obtained for each element. That is:

Ie = Ye.Ve

where Ie is the vector of currents at the eight corners of an element and Ve is the vector of voltages at the eight corners of the element. Each of the elemental admittance matrices is then stamped into the overall admittance matrix. Finally, using a linear system solver, the required admittance matrix that relates the currents and voltages at the port-contacts is obtained.

Besides 8-node model, the 6-node model is an approximation that computes resistance similar to hand-computation using Rho*l/A, where Rho is the resistivity, l is the length of the wire and A is the area of the wire. The 8-node model is a more accurate model than the 6-node model and is in-line with the physical principles. The 8-node model models the current flow in joints and bends more accurately. However, the 6-node model is still a good approximation that is fast because it has fewer variables to solve for and a more sparse matrix.

Barrier Layer Support

Addition of a barrier layer around the nets is supported through the technology file format called barrier_layer. Its syntax is given in the input format. It allows for the specification of the xy-inflation, positive-z-inflation, and negative-z-inflation of the layer and the resistivity of the barrier layer. Currently, only one barrier layer is supported, and the parent layer has to be a valid metal layer. For a barrier layer specification to be valid, xy-inflation and zp-inflation have to be greater than or equal to 0, and zn-inflation has to be less than or equal to 0.

Trapezoidal Cross Sections

Trapezoidal conductors are supported natively and through an approximation. Trapezoidal conductors are specified using the set_layer_side_tangent command. In the approximation, the geometry is approximated to the center


Using Resistance Extraction

line geometry/nominal geometry of the design, thereby retaining the same cross-sectional area as the trapezoid. Native support of trapezoids exists only in the absence of barrier layers. If both trapezoids and barrier layers are present, the extractor defaults to approximate the trapezoids with center line geometry and a barrier layer around it. Using -apx_trap, the extractor can be forced to approximate to the center line description. Internally, Raphael NXT stores the inner geometry if the conductors have a trapezoidal cross section. Hence, the contacts specification must be specified appropriately to prevent an error.


The resistance_extract command is used to extract the resistance between contacts defined on nets in the design file. This command must be issued after the read_contacts command which reads a contacts file with the set of all contacts and the set of all ports defined on these contacts. A contact can either be a point contact, an area contact, or a 3D box contact. Its input format is defined in Chapter 3. A port, which is a set of at least two contacts across which the resistances need to be computed, must be specified in the contacts file as given in the Input format.

As output, the extractor produces the set of all resistances of each port. This includes both the total resistances at each contact of each port and the inter-contact resistances in each port as shown in the output format. The extractor performs a basic set of checks to test the validity of the specification (e.g., checking if all contacts of a port are electrically connected), and gives warning messages if errors are encountered. In this implementation, all contacts are added to the design first, and then the extraction is performed. Contacts are assumed to be ideal with infinite conductivity.

The print_resistance_report command prints all the inter-contact resistances of each port. With optional switches, it produces the total resistances at each contact of each port also as described here. The time taken by the core routines in resistance extraction can be printed using the print_resistance_times command.

The print_rc_report command prints distributed resistance and capacitance estimates. This requires each net in the design to be associated with a contact in the contacts file as specified in RC specification. The command does not perform any check to test the validity of contact specifications. For example, if two nets are provided the same contact name, no error is thrown. Similarly, if two contacts in the specification are used in two



ports, multiple resistances will be printed out across those two contacts by print_rc_report.

The resistance extractor processes the input port-by-port, and the final output is organized on a port-by-port basis. The information for each port is split into two parts: ■ The first part of the output is the total resistances from each contact. ■ The second part of the output consists of all the pair-wise multi-port

resistance values.

Note: This does not correspond to the direct resistances between pairs of contacts. If a port has only two contacts, then the second part gives the direct resistance between the two contacts. The values of all resistances computed by the extractor are in ohms.

Limitations of Resistance Extraction

This version is the first release of resistance extraction in Raphael NXT, and Synopsys is still developing this capability. In this release, the default set of elements generated is accurate in most situations. However, if detailed analysis of current spreading is important, it may be necessary to use the grid_size parameter on the resistance_extract command to obtain the highest accuracy. Setting the grid_size parameter forces Raphael NXT to subdivide finite elements with edges larger than grid_size. This allows Raphael NXT to more accurately resolve current flow, but also increases the size of the admittance matrix which must be solved resulting in longer calculation times. Some experimentation will be required to obtain a value for grid_size which gives the best accuracy and fastest runtimes. However, without using the grid_size parameter, the accuracy should be equal to or better than other tools such as the resistance analysis in Synopsys Star-RCXT. In the next release, Synopsys plans to have an automatic meshing scheme which will make the use of the grid_size parameter unnecessary.

Synopsys also will be improving the execution speed of this feature in future releases as well as developing better user interfaces for netlist generation. (Suggestions from our users on how to improve resistance extraction are welcome).



ExampleThe following is a simple example of a design with a single line. A contact is placed at each of its ends, and a port is specified across the two contacts. The resistance computed will be the resistance of the wire.

Technology file

technology test_techgrids_per_meter 1e9default_dielectric_constant 1.0layer m1 0 100 0.000000017 st_routing

Design file

design pplatetechnology test_technet AAA metal m1 planar_box 50 0 250 100endend

Contact file

contact a 0 0 50 100 m1contact b 250 0 300 100 m1port two a b

Output

Port ’two’Total Resistances R_1_1 b OTHERS 0.34R_2_2 a OTHERS 0.34

All Resistances R_1_2 b a 0.34


References

References

[1] Y.L. LeCoz and R.B. Iverson, “A Stochastic Algorithm for High Speed Capacitance Extraction in Integrated Circuits,” Solid State Electronics, Vol. 35, No. 7, pp. 1005-1012, 1992.

[2] Subramanian Rajagopalan, (to appear), “A 3-dimensional FEM Based Resistance Extraction”.


References


33Input/Output Files

This chapter describes the three input files read by Raphael NXT and the different types of output reports it generates.

This chapter contains the following sections:■ Input Files■ Output Reports

Input Files

Raphael NXT reads three input files:■ Technology file■ Design file ■ Control file (optional since Raphael NXT can be run interactively)


Input Files

Technology File

Note: Always read a technology file before reading the design file.

The technology file contains vertical profile information relevant to Raphael NXT including the following: ■ Lower and upper coordinates of the metal layers ■ Extents of dielectric slabs and corresponding dielectric constants■ Specification of conformal layers

Command Format# char_comment_stringtechnology NAMEgrids_per_meter DOUBLEdefault_dielectric_constant EPSILON_Rlayer NAME Z_LOW Z_HIGH TYPEdielectric_constant EPSILON_R Z_LOW Z_HIGHconformal_layer LAYER_NAME PARENT_LAYER_NAME XY_INFL ZP_INFL ZN_INFL EPSILON_Rdielectric_block EPSILON_R Z_LOW Z_HIGH

TokensNAME = string

DOUBLE = floating point number

EPSILON_R = relative permittivity, floating point number

Z_LOW = integer, low Z coordinate

Z_HIGH = integer, high Z coordinate

XY_INFL = integer, inflation in XY plane

ZP_INFL = integer, inflation in positive Z direction

ZN_INFL = integer, inflaton in negative Z direction

TYPE = layer type, one of {RNX_ROUTING, RNX_VIA, RNX_PDIFF, RNX_NDIFF, RNX_PWELL, RNX_NWELL, RNX_DIFF, RNX_WELL}

LAYER_NAME = string

PARENT_LAYER_NAME = string, layer to be inflated to create conformal layer.


Input Files

Technology File Exampletechnology mycmos025grids_per_meter 1e9default_dielectric_constant 1.0layer sourcedrain rnx_ndiff -100 0layer m1 rnx_routing 300 700dielectric_constant 3.9 0 1200dielectric_block 5.2 400 720conformal_layer cm1 m1 100 100 0 5.1

Technology File Guidelines■ The name of the technology is specified with technology keyword followed

by a name. This name is referred from the design file as well. For a design, you must specify the underlying technology; otherwise, the references to metal layers can not be resolved.

■ Coordinates are specified in terms of grid units in design and technology files. These coordinates are converted to real values using the scale factor grids_per_meter that indicates the number of grid units present in one meter. For example, if each grid unit is 1 um, then grids_per_meter should be 1e6.

■ Metal and via layers are specified with layer statement. Each layer is specified with a name and its lower and upper z coordinates. Layers of type RNX_ROUTING and RNX_VIA are treated as normal conductors. Layers of type RNX_NWELL, RNX_PWELL, RNX_NDIFF, RNX_PDIFF, RNX_DIFF and RNX_WELL are device layers which also are conductors, but capacitance to them is accounted for using special rules. See Device Layers on page 17 in Chapter 2, “Description”.

■ Dielectric layers are specified with dielectric_constant statement. Each such layer is specified with its relative permittivity (or epsilon_r) and its lower and upper z coordinates.

■ dielectric_block statements are used to declare that there will be dielectric blocks with the specified relative dielectric constant placed throughout the design using dielectric box statements.

Note: You must predeclare these blocks in the technology file so that Raphael NXT will know to include them when performing GF calculations.


Input Files

■ Conformal layers are specified with conformal_layer statement. Each such layer is specified with a reference to the parent layer that should already be defined as a conducting or conformal layer. Each conformal layer is named. The conformal layer details are specified with four parameters:

• XY_INFL, ZP_INFL, ZN_INFL and EPSILON_R. XY_INFL: inflation in positive and negative x and y directions

• ZP_INFL: inflation in the positive z direction

• ZN_INFL: inflation in negative z direction

These inflations are applied to the parent layer and the resulting geometry is treated as a conformal region with relative permittivity specified through EPSILON_R value. More formally, conformal layers are dielectric layers which are inferred from the parent layer. The geometry in the parent layer is inflated in 2D by XY_INFL amount. The inflated 2D geometry is converted into 3D geometry by using the vertical extent of the parent layer with modifications suggested by ZP_INFL and ZN_INFL. If (zt, zb) are the z coordinates of top and bottom of parent layer, then (zt + ZP_INFL, zb -ZN_INFL) is taken as vertical extent for the dielectric layer. If the parent layer also is a dielectric layer, then the 3D geometry of parent layers is subtrated from the currently built dielectric layer.

Note: Only the planar_boxes in the parent layer are considered during the construction of conformal dielectric boxes. Metal objects specified through boxes are not associated with any layer, and hence are not accounted for during the construction of conformal dielectric boxes even if they are present in the parent layer.

■ default_dielectric_constant specifies the default relative permittivity. The epsilon_r of a point in space is taken as the epsilon_r of the dielectric slab in which it is present. If the point is on the interface of two dielectric slabs, then its epsilon_r is taken as the average of corresponding epsilon_r of the two slabs. If point is inside a conformal dielectric region, then its epsilon_r is taken as the dielectric strength of the conformal region. If a point is not in any conformal region and in any dielectric layer, then its epsilon_r is taken as default_dielectric_constant as specified by the user. If this value is not specified, then 1.0 is taken as its default value.


Input Files

Advanced Technology File Examples--------

-Metal layer: layer M1 100 200 rnx_routing layer via12 200 300 rnx_via Layer M2 300 400 rnx_routing Layer ndiff -100 0 rnx_ndiff Layer pwell -100 0 rnx_pwell

-Dielectric layer: dielectric_constant 3.2 100 200 dielectric_constant 7.4 200 250 dielectric_constant 8.2 250 300-Conformal layer: conformal_layer conf_m1 M1 20 20 0 5.0

ZP_INFL ------------------------ | 20 (eps_r=5.0)| | |---------------| | | | | | | | Metal M1 | | |20 | | 20| XY_INFL | | | | ------------------------ ZN_INFL = 0

conformal_layer conf_m1 M1 20 20 20 5.0

ZP_INFL = 20 ------------------------ | 20 (eps_r=5.0) | |---------------| | | | | | | | Metal M1 | | |20 | | 20| XY_INFL | | | | | |---------------| | | 20 | ------------------------- ZN_INFL = 20


Input Files

conformal_layer conf_m1 M1 20 20 -10 5.0

ZP_INFL = 20 ------------------------ | 20 (eps_r=5.0)| | |---------------| | | | | | | | Metal M1 | | |20 | | 20| XY_INFL |___| |___| | | 10 ------------------------- ZN_INFL = -10

conformal_layer conf_m1 M1 20 20 0 5.0 conformal_layer second_conf_m1 conf_m1 20 20 0 7.0

--------------------------------- | 20 (eps_r=7.0) | | ------------------------ | | | 20 (eps_r=5.0)| | | | |---------------| | | | | | | | | | | | Metal M1 | | | |20 |20 | | 20|20 | | | | | | | ----------------------------------

The second conformal is specified with reference to conformal parent layer.

Note: The points inside first conformal still have the Epsilon_r value that of 5.0, while the points outside first conformal but inside second conformal have epsilon_r value that of 7.0. Points on the interface of first and second conformal region have Epsilon_r value of the average, which is:

(5.0 + 7.0)/2 = 6.0


Input Files

More Technology File ExamplesThis example illustrates a uniform technology where the dielectric is assumed to be a uniform material with dielectric constant of 1.0:

#Example of a uniform dielectric technology. ##The scale factor is 1e9, which indicates that 1e9#grid units equals 1 meter. grids_per_meter 1e9

#Name of technologytechnology uniform

#Default dielectric constant in this technology is 1.0#Also since no other dielectric layers are specified it#means that dielectric is 1.0 everywhere.default_dielectric_constant 1.0

#Description of conducting layers. This is a dummy 2 layer#technology.layer cut01 100 200 rnx_vialayer m1 200 300 rnx_routinglayer via12 300 400 rnx_vialayer m2 400 500 rnx_routing

The following example illustrates a uniform technology where the dielectric is assumed to consist of multiple flat planar slabs of material. The dielectric constant does not change within each slab, but different slabs have different dielectric constants:

#Example of a technology with dielectric slabs##The scale factor is 1e9, which indicates that 1e9#grid units equals 1 meter. grids_per_meter 1e9

#Name of technologytechnology slabs

#Default dielectric constant in this technology is 1.0default_dielectric_constant 1.0

#Description of conducting layers. This is a dummy 5 layer#technology.layer cut01 100 200 rnx_vialayer m1 200 300 rnx_routinglayer via12 300 400 rnx_via


Input Files

layer m2 400 500 rnx_routinglayer via23 500 600 rnx_vialayer m3 600 700 rnx_routinglayer via34 700 800 rnx_vialayer m4 800 900 rnx_routinglayer via45 900 1000 rnx_vialayer m5 1000 1100 rnx_routing

#Description of dielectric layersdielectric_constant 3.9 100 200dielectric_constant 4.5 200 300dielectric_constant 3.2 300 400dielectric_constant 4.5 400 500dielectric_constant 3.2 500 600dielectric_constant 4.5 600 700dielectric_constant 3.2 700 800dielectric_constant 4.5 800 900dielectric_constant 3.2 900 1000dielectric_constant 4.5 1000 1100

The following example illustrates a technology file with multiple conformal layers. Metal 3 has a single conformal coating while Metal 4 and Metal 5 each have two conformal coatings:

#Example of a technology with multiple conformal layers##The scale factor is 1e9, which indicates that 1e9#grid units equals 1 meter. grids_per_meter 1e9

#Name of technologytechnology double_conformal


#Description of conducting layers. This is a dummy 5 layer#technology.layer cut01 100 200 rnx_vialayer m1 200 300 rnx_routinglayer via12 300 400 rnx_vialayer m2 400 500 rnx_routinglayer via23 500 600 rnx_vialayer m3 600 700 rnx_routinglayer via34 700 800 rnx_vialayer m4 800 900 rnx_routinglayer via45 900 1000 rnx_vialayer m5 1000 1100 rnx_routing


Input Files


#Description of conformal layers.#There are conformal layers on M3, M4 and M5.conformal_layer conf_m3 m3 10 10 0 8.2conformal_layer conf_m4 m4 10 10 0 8.2conformal_layer conf_m5 m5 10 10 0 8.2

#Description of second conformal layer.#There are double conformal layers on M4 and M5.conformal_layer second_conf_m4 conf_m4 15 15 0 4.0conformal_layer second_conf_m5 conf_m5 15 15 0 4.0

Design File

The design file contains the geometry of the nets in the netlist and is composed of the following elements: ■ Nets can be a list of 3D metal boxes or 2D planar boxes. ■ Boxes are the primary 3D geometric element used to describe conductors

and dielectric regions.■ Dielectric boxes may be placed anywhere in the design; however, the value

of the dielectric constant (epsilon) used for the boxes must have been previously declared in the technology file using a dielectric_block statement.

■ Planar boxes are 2D geometric element used to describe conductors. The z-extent for the 2D planar boxes is obtained from their reference layer described in the technology file.

■ Pincap is an optional parameter; a pin capacitance also can be specified for each net. The pincap value is added to the computed self-capacitance value for that net.


Input Files

■ Priority is an optional paramter. If two nets in the same net group overlap, the capacitance of the overlap region is assigned to the net with the higher prioroty.

■ Net group is a composite net that contains a list of nets belonging to that group. The capacitance for each net in the group is reported separately. In addition, the aggregated self-capacitance value for the net group also can be reported.

■ Metal objects which do not belong to any net are described as 3D or 2D boxes and are assigned to either: a single special net called misc or grouped into separately electrically connected floating nets called fill nets if the -dummy_as_fills command is given on the read_design command.

The syntax of the design file is a follows:■ Entries enclosed in square brackets [ ] are optional. ■ Keys starting with char are character strings.■ Keys starting with int are integers, and keys starting with float are floating

point numbers.

[ # char_comment_string ]design char_nametechnology char_name[ technology_file char_file_name ] [ dielectric float_eps [ box int_x1 int_y1 int z1 int_x2 int_y2 int_z2 ] ]

[ metal[ box int_x1 int_y1 int z1 int_x2 int_y2 int_z2 ][ planar_box int_x1 int_y1 int_x2 int_y2 ]

][ net char_net_name

[ metal [ box int_x1 int_y1 int z1 int_x2 int_y2 int_z2 ] [ planar_box int_x1 int_y1 int_x2 int_y2 ]][ pincap float_cap_value ] [priority int]

end ][ net_group char_net1 [char_net2 ….] end ][ ground_net char_net1 [char_net2 …] end ][ ground_net_group char_net_group1 [ char_net_group2 … ] end ]

end

The box coordinates are the opposite corners of the rectangular boxes. Box coordinates are measured in grid units defined in the technology file.


Input Files

Net names may be any character string which is not one of the following key words:■ design

■ end

■ technology

■ technology_file

■ net

■ box

■ metal

■ dielectric

■ pincap ground_net

■ net_group

■ ground_net_group

■ planar_box

Note: Net names may be as long as you want. If you want to use one of the above keywords as a net name, you can enclose it in double quotes (“) or backslash (\) characters, and Raphael NXT will accept it.

Nets are composed of boxes and/or planar boxes. If a box or planar box is specified outside a net, then it is assigned to the special misc net.

Comments start with a pound sign (#). Text following the (#) character on a line is ignored. Comments can be placed anywhere in the file.

Design File ExamplesThe following simple example of a design file shows that some lines have been indented to improve readability, but this indentation is not required:

design finger_captechnology my2layernet net_1a

metal m1 planar_box 100 0 800 100metal box 100 400 300 800 500 600pincap 1e-15

end# comments can go anywhere.net net_1b

metal m1 planar_box 0 0 100 700


Input Files

endnet_group net_1 net_1a net_1b endend

This example illustrates how the net-group command is used to create a single large electrical net from five smaller ones.

design two_lines technology my_technology

# five segments for line_a net line_a.1 metal box 0 0 0 100 100 100 end net line_a.2 metal box 100 0 0 200 100 100 end net line_a.3 metal box 200 0 0 300 100 100 end net line_a.4 metal box 300 0 0 400 100 100 end net line_a.5 metal box 400 0 0 500 100 100 end

# line_a marked as a net_group composed for five nets # described above net_group line_a line_a.1 line_a.2 # line_a.3 line_a.4 line_a.5 end

# five segments for line_b net line_b.1 metal box 0 200 0 100 300 100 end net line_b.2 metal box 100 200 0 200 300 100 end net line_b.3 metal box 200 200 0 300 300 100 end net line_b.4 metal box 300 200 0 400 300 100 end net line_b.5 metal box 400 200 0 500 300 100 end

# line_b marked as a net_group composed for # five nets described above net_group line_b line_b.1 # line_b.2 line_b.3 line_b.4 line_b.5 end

The following example illustrates the use of the pincap command to attach a fixed capacitance to a net:

design design_with_pincaps

ground_net VSS

#two nets have a specified pincapnet bottom metal box 0 0 0 100 100 10 pincap 1e-14 endnet left pincap 1e-15 metal box 25 0 110 35 100 120 end#no pincap specified for these two netsnet middle metal box 45 0 110 55 100 120 endnet right metal box 65 0 110 75 100 120 end


Output Reports

The following example illustrates a parallel plate capacitor using planar boxes and a technology file:

#Two parallel plates of area 100 X 100, with thickness 10, and #separation on 100 units.

design pplatetechnology two_layernet bottom metal m1 planar_box 0 0 100 100 endnet top metal m2 planar_box 0 0 100 100 endend

#Need to ensure that a tech file is first read into#statcap before this design file is read. The tech#file should contain m1 and m2 layers. Example of#such a tech file is given below (in commented form)##Example Tech File::##technology two_layer#layer m1 0 10 routing#layer m2 110 120 routing

The following example illustrates a parallel plate capacitor created using 3D boxes. No technology file is needed for the metal since all the z coordinate information is contained in the design file. However, a technology file is needed to specify the dielectrics.


design pplatenet bottom metal box 0 0 0 100 100 10 endnet top metal box 0 0 110 100 100 120 endend

Output Reports

Raphael NXT generates several different types of output reports including a capacitance report, capacitance matrix, and a SPICE-style report.


Output Reports

Capacitance Report

print_capacitance_report command gives a column formatted capacitance report. There will be separate sections for total, coupling, grounded and capacitance to the misc net.

Note: The statistical error is included as part of the report. In general the statistical error for coupling capacitances is much larger than the error for the self or total capacitance.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++Capacitance Report::----------------------------------------------------------------------Net-1 Net-2 Capacitance 3-Sigma Error----------------------------------------------------------------------VSS h_left 9.322001e-15 22.87%VSS h_middle 6.969878e-15 29.78%VSS h_right 1.005448e-14 21.05%VSS v_left 9.640878e-15 21.98%VSS v_middle 7.306791e-15 27.19%VSS v_right 1.169291e-14 17.93%h_left h_left 4.402040e-14 2.62%h_left h_middle 1.617008e-14 8.95%h_left h_right 1.514450e-15 32.63%h_left v_left 6.254833e-15 16.25%h_left v_middle 4.871476e-15 18.88%h_left v_right 5.960763e-15 16.30%h_middle h_middle 5.160699e-14 2.78%h_middle h_right 1.620040e-14 8.82%h_middle v_left 4.565670e-15 20.46%h_middle v_middle 3.967006e-15 21.50%h_middle v right 4.796679e-15 19.04%h_right h_right 4.387663e-14 2.62%h_right v_left 5.843091e-15 16.48%h_right v_middle 4.425904e-15 20.82%h_right v_right 5.227709e-15 19.02%v_left v_left 4.458799e-14 2.56%v_left v_middle 1.706664e-14 8.53%v_left v_right 1.501780e-15 35.21%v_middle v_middle 5.181502e-14 2.78%v_middle v_right 1.659333e-14 8.71%v_right v_right 4.473716e-14 2.54%


Output Reports

Capacitance Matrix

print_capacitance_matrix command prints capacitance results in matrix/tabular format. The second section gives the statistical error in the computed capacitances.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++Abbreviations used to report capacitance values:u(microF)=1e-06 n(nanoF)=1e-09 p(picoF)=1e-12 f(femtoF)=1e-15 a(attoF)=1e-18

n1=h_left n2=h_middle n3=h_right n4=v_left n5=v_middle n6=v_right

Capacitance Matrix Report::---------------------------------------------------------------------- n1 n2 n3 n4 n5 n6 n1 44.020f 16.170f 1.5144f 6.2548f 4.8715f 5.9608fn2 16.170f 51.606f 16.200f 4.5657f 3.9670f 4.7967fn3 1.5144f 16.200f 43.876f 5.8431f 4.4259f 5.2277fn4 6.2548f 4.5657f 5.8431f 44.587f 17.066f 1.5018fn5 4.8715f 3.9670f 4.4259f 17.066f 51.815f 16.593fn6 5.9608f 4.7967f 5.2277f 1.5018f 16.593f 44.737f

--------------------------------------------------------------------------------

Associated 3 Sigma Error Matrix(%)::---------------------------------------------------------------------- n1 n2 n3 n4 n5 n6 n1 2.62% 8.95% 32.63% 16.25% 18.88% 16.30%n2 8.95% 2.78% 8.82% 20.46% 21.50% 19.04%n3 32.63% 8.82% 2.62% 16.48% 20.82% 19.02%n4 16.25% 20.46% 16.48% 2.56% 8.53% 35.21%n5 18.88% 21.50% 20.82% 8.53% 2.78% 8.71%n6 16.30% 19.04% 19.02% 35.21% 8.71% 2.54%

SPICE Style Output

The spf_report command generates a SPICE output listing that can be included as part of a netlist for simulation in a SPICE simulator. You can select whether the coupling capacitors or just a model using grounded capacitors are created:

*|DSPF 1.0*|DESIGN e2.gds


Input Specification for Resistance Extraction

*|VENDOR Synopsys*|Program RAPHAEL NXT*|DIVIDER /*|DELIMITER :*|GROUND_NET 0 *CC1 net_1 net_2 3.73468e-16 CG1 net_1 0 6.07966e-16 CG2 net_2 0 6.7796e-16 *** END SPF Model ***


Note: Resistance extraction functionality is limited in this release, refer to Chapter 2 for more details.

The resistance extractor is built on top of the Raphael NXT capacitance extractor framework. Hence, the extractor uses the Raphael NXT input specification predominantly in addition to its own. There are three basic input files needed by the resistance extractor:■ Technology file■ Design file■ Contact file

Technology File

The technology file is the same as Raphael NXT technology file with an extra option to specify the resistivity for each layer. The Layer specification in the Raphael NXT technology file format has been augmented to take an optional parameter to specify the resistivity for each layer.

layerNAMEZ_LOWZ_HIGHTYPE

layerNAMEZ_LOWZ_HIGHRESISTIVITYTYPE

RESISTIVITY is optional and is of double type. Its units is SI units, ohm-m. If RESISTIVITY is not specified, the extractor uses the resistivity of Copper as default.



Example layer m1 0 100 0.000000017 st_routing

By this command line, the resistance of metal layer m1 is defined as 0.000000017 ohm*meter.

Support for barrier layers, high resistivity layers that are conformal to conductors, is also provided through the technology file. Its syntax is:

barrier_layer NAME LAYER_NAME XY_INF ZP_INF ZN_INF RESISTIVITY

where the XY_INF, ZP_INF and ZN_INF are the xy-inflation, positive-z-inflation and negative-z-inflation respectively as defined in the conformal layer specification. RESISTIVITY is the resistivity of the barrier layer. Currently, only one barrier layer is supported and the parent layer has to be a valid metal layer.

Design File

The Design file is the same as Raphael NXT design file which specifies a design for which resistance extraction needs to be done.

Contact File

The contact file is used to specify the contacts and the ports across which resistances need to be computed. This file is specific to the resistance extractor. The specification for contacts and ports is flexible.

Contact/Node Specification If the contact is a 3D box, then the following format can be used:

contactNAMEX_LOWY_LOWZ_LOWX_HIY_HIZ_HI

Note: The above specification allows for point-, line-, area-, and volume-contacts to be specified. If the z-extents of a contact need to be inferred from the layer specification in the technology file, then the following specification can be used:

contactNAMEX_LOWY_LOWX_HIY_HILAYER_NAME

Example contact a -5 0 0 100 m1contact b 500 600 600 605 m1



Two contacts are defined. Both are at the metal layer “m1”. One is rectangle defined by two diagonal vertices (-5, 0) and (0, 100). The other rectangle is defined by two points (500, 600) and (600, 605).

Note: If point- or line-contacts are specified, the extractor converts them into area-contacts internally.

Port Specification The port specification allows for two-port as well as multi-port specification:.

portNAMECONT_NAMECONT_NAME

portNAMECONT_NAMECONT_NAMECONT_NAME...

Example

port p1 a b

For the above command, port p1 is defined through contact a and contact b.

Note: A port must have at least two contacts.

Distributed RC Specification

After extracting resistances and capacitances, the print_rc_report command can be used to print out the extracted resistances and capacitances in a netlist format. To do this, you can use a contact that was used for resistance extraction of a net as a representative contact for connecting the extracted capacitances of that net. You can specify this net-to-contact mapping can in the contacts file and then to view it, use the read_contacts command. Its syntax is as shown below.

netNET_NAMECONT_NAME

Note: If a contact is not specified for a net, then the net name is used by print_rc_report command.


55Commands

This sections describes the Raphael NXT commands.

alias

Name

alias defined as alias.

Syntax

int alias name arg1 ...

assert

Name

assert defines regression test criterion.


build_gf_tables

Syntax

int assert [switches] regexp

Arguments

build_gf_tables

Name

build_gf_tables builds GF tables for the specified technology.

Syntax

int build_gf_tables [-disc_count positive integer] [-zc] [-level integer]

Argument Description

regexp Specifies name of fields that criterion applies to (required)

-e[qual] Field value must be equal to golden value

-no[matches] No fields can match the regular expression

-r[ange] Field value must be within specified range (using -l -p)

-p[ct_range] Field value must be in the specified %%-range (using -l -p) of golden value

-l[ower] -1.0 Defines lower range value for range comparison

-u[pper] -2.0 Defines upper range value for range comparison


build_gf_tables

Arguments

Description

The build_gf_tables command builds GF necessary for the random walk process.

GF relates electric potential or electric field at a point in space with electric potentials on a conformal boundary around the point. Raphael NXT has the following two types of GF:■ EPGF (Electric Potential GF):

• Relates potential at a point to the potentials on a conformal boundary around the point.

• Is a scalar function.■ EFGF (Electric Field GF):

• Relates field at a point to the potentials on a conformal boundary around the point.


-disc[_count] Discretization count.

Default value is 12.

Minimum value is 8 and maximum is 24.

-zc A flag to indicate that z coordinate GFs are to be computed as well. In general, this means a slightly larger computation time and memory for the GF tables. However, in technologies with several dielectric layers, these z coordinate GFs improve the runtime performance of random walks. You should use -zc with build_gf_tables command.

-level A positive integer between [1 .. 3] to indicate the level of GF library. A 1 indicates the minimum size GF library, and 3 indicates maximum size GF library. With Level 3, runtimes for extraction tend to improve in complex dielectric technologies.


build_gf_tables

• Is a vector function with three components.

GFs are dependent on the shape of boundary as well as on the dielectric composition of space inside the boundary. Raphael NXT does the following:■ Computes GFs for cube-shaped boundaries.■ Uses patterns of various dielectric configurations for these cubes.■ Computes GFs for each pattern.■ Archives GFs in a lookup table for ready reference because GFs are

required during the process of random walks.

Since these GFs are expensive to compute on the fly, Raphael NXT computes them up front and stores the archived table.

Note: You should only invoke the build_gf_tables command if a valid technology file has been read into Raphael NXT using the read_tech command.

Note: Most of the time you will want to use:

build_gf_tables -zc -level 3

Examples

To build default set of GFs, use:

ranxt> build_gf_tables

To build GFs with discretization count of 16 and to build z-coordinate GFs, use:

ranxt> build_gf_tables -disc_count 16 -zc

To build a really rich set of z-coordinate GFs (which might take a couple of extra minutes of computation time), use:

ranxt> build_gf_tables -zc -level 3

See Also

read_gf_tables

read_tech

write_gf_tables


ctrlc

ctrlc

Name

ctrlc debug control-c handling.

Syntax

int ctrlc [-poll]

exclude

Name

exclude causes Raphael NXT to ignore capacitance between a pair of layers.

Syntax

int exclude [-l1 name] [-l2 name]

Arguments

Description

The exclude command is used to tell Raphael NXT to ignore the capacitance between a pair of layers.


-l1 Specifies the name of the first layer (Must be a valid name, no wild cards)

-l2 Specifics the name of the second layer (Must be a valid name, no wild cards)


extract

Note: However, the shielding effect of the ignored capacitance is still be included in the simulation.

The exclude command is useful for ignoring the capacitance of MOSFET layers which would typically be included in the SPICE models and, therefore, would not be wanted in the interconnect models.

Example

To exclude the capacitance between metal1 and metal2:

ranxt> exclude -l1 metal1 -l2 metal2

See Also

print_capacitance_matrix

print_param

set_statistics

extract

Name

extract runs extraction for all or specified list of nets in the design.

Syntax

int extract [-mp] [glob_exp1 glob_exp2 ...] <glob_exp> GLOB EXPRESSION

Arguments


regexp Specifies name of fields that criterion applies to (required)


extract

GLOB Expression Syntax

Glob-style string matching is a much simpler form of string matching than regular expression matching. The name glob refers to the file name extension mechanism used in Unix shells called globbing.

A glob, like a regexp, is made of zero or more branches. If there are several branches, the glob should start with a left bracket ({), end with a right bracket (}), and the different branches should be separated with a comma (,) . These characters should be quoted using quote marks (“), e.g., when used literally.

A branch is zero or more “atoms”, concatenated that matches a match for the first, followed by a match for the second, etc. An atom is a glob, a “?” (matching any single character), “*” (matching any sequence of characters), a “'” followed by a single character (matching that character), or a single character with no other significance (matching that character).

Contrary to regular expression matching, a string matches a glob if the match is complete; i.e., the match starts at the first character of the string and ends at its last character.

Description

The extract command is used to invoke the extraction process in Raphael NXT. This command requires that the GF library has already been loaded in Raphael NXT using build_gf_tables or read_gf_tables, and the internal data structures for Raphael NXT have been initialized by the init_extract command. Capacitances are computed for nets specified in the init_extract command.

You also can specify additional nets with the extract command using the glob expressions for which extraction needs to be done. The additional nets can only be specified when running in single processing mode or with serial mode in MP. These cannot be specified with the extract when running in nonserial mode with the -mp flag.

-mp This flag indicates that extraction is to be done with an existing MP client server system. You must ensure that an MP client server system is initialized with the init_extract command.



extract

The capacitance estimated computed by extract can be printed using print_capacitance_report command.

The first line of the file is a description header. Each of the other lines of this file has the format:

layer_index: layer_name, layer_min_z, layer_max_z, side_tangent

For example:

Layer Name z_low z_high side_tanLayer #1: poly 500 900 0.000000Layer #2: via1 900 1900 0.000000Layer #3: met1 1900 2700 0.000000Layer #4: via2 2700 4200 0.000000Layer #5: met2 4200 5400 0.000000Layer #6: diel_const#1 0 0 0.000000Layer #7: diel_const#2 0 5800 0.000000

Note: The plot_tech plots routing layers in one width and via layers in

another width so that you can view the relations in the cross section. If all layers are specified as routing layers, even though physically some of the layers are via layers, the output bitmap will simply be a metal block. Also, all device layers are treated as routing layers when plotting.

Examples

In all the examples, nets can be a net or net group object in the design file. Raphael NXT supports extraction of a net which is not part of any net group or the extraction of the whole net group.

To run extraction for nets named, net_1 and net_2:

ranxt> extract net_1 net_2

To run extraction for nets with names beginning with net_a:

ranxt> extract net_a*

To run extraction for already specified nets in init_extract command:

extract


field

To perform extraction using the existing MP system, you must use init_extract with appropriate -client-server arguments. If that was not done, then extraction proceeds as in single processing mode.

extract -mp

See Also

build_gf_tables

init_extract


print_capacitance_report

read_design

read_tech

field

Name

field sets default field prefix.

Syntax

int field [switches]

-p[refix] String to be used to prefix field name with (required)

help

Name

help prints help about commands.


import

Syntax

int help [switches] [[name]]

-a[ll] include hidden commands

-g[roup] "" list command in given group

-m[atching] "*" list command matching glob

[name] "" command to print help for

import

Name

import gets variables from the environment using getenv().

Syntax

int import [name1 [name2 ...]]

init_extract

Name

init_extract initializes extraction system.

Syntax

int init_extract [-concurrent_mode] [-all_nets] [-client-server server_host_name_port_number] [-f file_name] [-nc integer] [- exclude_devices] [-continue_with_shorts] [-adapt] [glob_exp1 glob_exp2 ...]

<glob_exp> GLOB EXPRESSION (see the syntax in man page for extract command)


init_extract

Arguments


-concurrent_mode The default behavior is serial mode extraction scheme. In this extraction scheme, each net is extracted one by one. Gaussian surface for a net is built, its capacitance extracted till convergence, and Gaussian surface deallocated. The process is repeated until all specified nets are extracted. If -concurrent_mode is specified, then Gaussian surfaces for all the nets are built first and then the random walks are performed simultaneously for all the nets.

-all_nets Indicates that all nets in the design are to be extracted. If this flag is specified, then the list of nets (if also specified) for building active nets is ignored.

-client-server Takes in a server host name with a port number. The host name and port number are delimited with a `:' character in between. For example, server running on host titania at port 6040 is specified as -client-server titania:6040.

-contine_with_shorts When this option is used, Raphael NXT continues extraction even when two nets are shorted. The solver ignores the touching edges and attempts to continue with the extraction. Since the capacitance between two shorted nets is not defined, shorted nets can cause the total capacitance and other capacitances to be inaccurate. Shorted nets may also result in slower than normal convergence due to the abrupt changes in electric field that result. Therefore, you should construct your input in a way that eliminates shorted nets rather than using this option.


init_extract

Description

The init_extract command is used to initialize the extraction system. This command builds basic data structures and configures system for MP usage (if a client-server is specified).

Caution! “concurrent_mode” is not the same as “MP” or “multi-processor” mode. We do not recommend using “concurrent_mode” and “MP” mode at the same time.

-file Takes the name of a file which contains the names of the nets to be extracted. The file should contain the net names on one or more lines separated by spaces. Nets specified in this file will be extracted along with any specified on the init_extract statement itself.

-nc Species the number of clients. In an existing MP client-server framework there may be many clients. But you can specify the maximum number of clients (out of these available clients) to be used for the extraction process. On the other hand if the number of available clients is less than specified by the user, the Raphael NXT server will timeout and report the actual number of clients being used.

-exclude_devices Causes Raphael NXT to ignore capacitance couplings to the device layer boxes. This causes the device layers to act as shields. This option is useful for excluding capacitances that are typically included within MOSFET models (like gate-source capacitance).

-adapt Causes Raphael NXT to use a special algorithm to calculate the placement of the gaussian surface. This algorithm places the surface at the electrical midpoint between the target electrodes. In many cases -adapt results in faster, more accurate capacitance extraction. Adapt is ignored on electrodes composed of more than 150 boxes.



plot_tech

Examples

In all the examples nets can be a net or net group object in the design file. Raphael NXT supports extraction of a net which is not part of any net group or the extraction of the whole net group. To initialize Raphael NXT for extraction nets, net1 and net2:

ranxt> init_extract net1 net2

To initialize Raphael NXT for extraction of all nets having clock as part of its name:

ranxt> init_extract *clock*

To initialize Raphael NXT for extraction of all nets in design and to indicate that the eventual extraction is to be done in concurrent_mode:

init_extract -all_nets -concurrent_mode

To run Raphael NXT in MP mode, extracting all nets on five clients with the server as port 6061 on machine gotti:

init_extract -all_nets -nc 5 -client-server gotti:6061

Refer to the Chapter 4, “Multi-Processing,” for more details.

See Also

build_gf_tables

extract, uninit_extract



plot_tech

Name

plot_tech plots the cross section into a bitmap file based on the information given in the technology file for Raphael NXT.


plot_tech

Syntax

int plot_tech [-file string_file_name] [-width integer_width] [-height integer_height] [-legend]

Arguments

Description

The plot_tech command can be used to plot the cross section of a design into bitmap file. You then can use a shell command xv string_file_name to view the bitmap picture. The plot_tech command should be issued after read_tech command. If there are layers with trapezoidal electrode shape, the set_side_tangent commands should be issued before plot_tech command. Otherwise, the trapezoidal information will not be taken into account. A layer description file is also output into string_file_name.layer for reference.

Example

To plot the cross section into a file named my_tech.bmp with pixels 200*5000 and layer labels on it:

ranxt> plot_tech -file my_tech.bmp -width 200 -height 5000 -legend


-f[ile] The filename where the output bitmap file is to be saved. If you do not specify a file, this command aborts.

-w[idth] The width (in pixels) of the bitmap output. Default is 1000.

-h[eight The height (in pixels) of the bitmap output. Default is 1000.

-l[egend] The flag used to specify whether or not to label the layers using layer index.



See Also

read_tech

write_tech


Name

print_capacitance_matrix reports capacitance estimates in matrix format.

Syntax

int print_capacitance_matrix [-complete] [-e[lim] [glob_expr_1 glob_expr_2 ...]]

Arguments


-c[omplete] Prints capacitances between extracted nets and all other nets in the design, if the statistics level is chosen to be complete by the set_statistics command. The default value is false which prints capacitance estimates only between the extracted nets.

[-e[lim] [glob_expr_1 glob_expr_2 ...]]]

If the elim flag is set, then the nets specified by glob expressions are eliminated and the equivalent capacitances are reported. This is an internal option.

(Ensure set_internal_release is called before this option is called.)



DESCRIPTION

The print_capacitance_matrix command is used to print the capacitance estimates in matrix format. Two matrices are printed:■ One for the capacitance estimates■ One for the corresponding n-sigma error in computing the capacitance

estimates.

If the extracted nets were specified with pin capacitances in the input design file and the statistics level is set to self, then this command also prints capacitance and error matrices corresponding to capacitances and error values which include the pin capacitance numbers for the nets which have been extracted. If there are too many capacitance results which could make the generated matrix difficult to interpret, the tool prints a warning and does not print any capacitance matrix. The results in such a case can be printed by the print_capacitance_report command. The capacitances to be computed can be configured by the set_statistics command and the ones to be printed by the -complete option described above.

Examples

To print the matrix of capacitance estimates:

ranxt> print_capacitance_matrix The following example shows a capacitance matrix for both self and coupling capacitances for a set of five nets:

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++Abbreviations used to report capacitance values: u(microF)=1e-06 n(nanoF)=1e-09 p(picoF)=1e-12 f(femtoF)=1e-15 a(attoF)=1e-18 n1=net_b n2=net_concern n3=net_f n4=net_l n5=net_r

Capacitance Matrix Report:: -------------------------------------------n1 n2 n3 n4 n5 n1 4.0089f 0.9155f 0.1396f 0.3449f 0.4053f n2 0.9155f 3.3630f 0.6764f 0.6901f 0.3585f n3 0.1396f 0.6764f 2.1615f 0.1077f 0.3727f n4 0.3449f 0.6901f 0.1077f 2.1566f 20.099a n5 0.4053f 0.3585f 0.3727f 20.099a 2.0357f -------------------------------------------------------



Associated 1 Sigma Error Matrix(%):: ---------------------------------- n1 n2 n3 n4 n5 n1 1.32% 7.93% 20.71% 13.15% 10.20% n2 7.93% 1.54% 7.21% 7.06% 10.19% n3 20.71% 7.21% 1.93% 17.43% 10.57% n4 13.15% 7.06% 17.43% 1.69% 51.56% n5 10.20% 10.19% 10.57% 51.56% 1.53% ---------------------

See Also


set_statistics


Name

print_capacitance_report reports capacitance estimates in tabular form.

Syntax

int print_capacitance_report [-total] [-misc] [-gnd] [-xcap] [-ig] [-e[lim] [glob_expr_1 glob_expr_2 ...]]



Arguments

Description

The print_capacitance_report command is used to get the capacitance estimates after the extraction process. The results are printed in tabular form


-total Prints separate total capacitance report. Total capacitance of a net is sum of all the capacitances associated with a net. It is also called as self capacitance of the net. If the extracted nets were specified with a pin capacitance in the input design file, then this option prints two reports. In one report capacitances and errors are reported using the pin capacitance for the nets. The other report only prints the numbers computed by Raphael NXT and ignores the pin capacitances if any.

-misc Prints separate miscellaneous capacitance report also. This gives a report of lumped capacitances to all nonextracted nets. This is useful if extraction was done with -mutual as statistics level. In such a case capacitances to all other extracted nets are reported if -xcap is specified; the capacitances to remaining nonground nets are lumped and presented as miscellaneous capacitances.

-gnd Prints separate grounded capacitance report. Grounded capacitance of a net is sum of all its capacitances to nets marked as ground nets.

-xcap Prints coupling capacitances in the capacitance report. By default only the self capacitances are reported.

-ig Prints capacitances with internal ground also.

[-e[lim] [glob_expr_1 glob_expr_2 ...]]]

If the elim flag is set, then the nets specified by glob expressions are eliminated, and the equivalent capacitances are reported.


print_mp_info

and you can configure the results to be printed using the above options. The default behavior of the command is to print the self-capacitance estimates for all the extracted nets.

Examples

To print both the self and coupling capacitance estimates between all the extracted nets:

ranxt> print_capacitance_report -xcap To print the self capacitance estimates for the extracted nets into a file:

ranxt> print_capacitance_report > <filename> To print capacitances with internal ground node, a bounding box is built internally and kept at zero potential. The capacitances to this bounding box are reported as capacitances to sc_ground_net.

ranxt> print_capacitance_report -ig

To print capacitance report with all nonextracted capacitances associated with the net as miscellaneous capacitances:

ranxt> print_capacitance_report -misc

See Also


print_param

set_statistics

print_mp_info

Name

print_mp_info reports Raphael NXT server statistics if running in MP mode.


print_mp_info

Syntax

int print_mp_info

Description

This print_mp_info command shows Raphael NXT server and helper statistics. This command presents:■ Distribution of work among the helpers■ Overhead for each helper■ Elapse and cpu time for the extraction process.

This command also gives an efficiency number that captures the capability of the MP infrastructure. This number can vary due to network and processor load variations.

Examples

To print the report:

ranxt> print_mp_info

This should print a report similar to the following:

------------------------------------------------------------------Raphael NXT MP server running with 5 helpersExtraction time: 23.3 seconds

Client Name %Work %Overhd Elapse Cpu------------------------------------------------------------------angus/10092 28.2 7.5 21.59 21.33toby/8043 27.9 1.9 22.90 22.70titania/25737 9.4 5.9 21.97 21.93angus/10094 26.3 5.4 22.09 21.00kalyani/7286 8.2 1.1 23.09 23.09------------------------------------------------------------------MP Efficiency: 95.3%-----------------------------------------------------------------


print_param

print_param

Name

print_param prints the values for various Raphael NXT parameters.

Syntax

int print_param.

Description

The print_param command can be used to see the current internal values being used by Raphael NXT. The values can be modified by using the set_ command corresponding to the parameter to be changed.

Examples

To print the value of all user-specified parameters:

print_param

If you have not specified the parameter, the command will show the default values used by Raphael NXT. Here is a sample output:

Bounding_box Unspecified

Conductor attraction limit: Unspecified

Convergence goal:(Relative) Self cap error: 0.03, Coupling cap error: Unspecified(Absolute) Self cap error: Unspecified Coupling cap error: Unspecified

Ground level: Unspecified

Minimum capacitance: 1e-18

Rng seed: 12345

N-sigma: 1, min samples: 10, statistics level: mutual


print_rc_report

Gaussian surface inflation: UnspecifiedTiling of Gaussian surface: NoDielectric alignment of Gaussian surface: No

RQ type: OCT2

Total walks: 100000000, Max Hops: 1000Reporting interval: Unspecified, Checking interval: 100000

print_rc_report


Name

print_rc_report reports resistance and capacitance estimates.

Syntax

int print_rc_report

Description

The print_rc_report command is used to print the resistance and capacitance estimates after the extraction process. This command uses the contacts specified for resistance extraction to print out the RC net list. For capacitance, you must specify a contact name for each net. If it is not specified, the net name is used as the default. Also, if a pair of contacts is used in multiple ports, then erroneous resistances are reported.

Example

To print the distributed resistance and capacitance estimates:

ranxt> print_rc_report


print_resistance_report

See Also





Name

print_resistance_report reports resistance estimates. By default, this does not print total resistances.

Syntax

int print_resistance_report

Arguments

Description

The print_resistance_report command is used to get the resistance estimates after the extraction process. The default behavior of the command is to print only the resistances between contacts. The total resistance at each contact also can be printed using optional arguments.


-total Prints the total resistance at each contact.


printf

Examples

To print the inter-contact resistances:

ranxt> print_resistance_report

To print the total and inter-contact resistances:

ranxt> print_resistance_report -total

To print the resistance estimates for the extracted nets into a file:

ranxt> print_resistance_report > <filename>

See Also


printf

Name

printf works like the “C” language printf function to print its arguments.

Syntax

int printf format arg1 arg2 ...

quit

Name

quit ends execution of current script.

Syntax

int quit.


read_contact

read_contact


Name

read_contacts reads the contacts/nodes and ports across which resistance needs to be computed in a design.

Syntax

int read_contacts [-file] string

Arguments

DESCRIPTION

The read_contacts command allows you to specify a set of contacts and ports on the various nets in Raphael NXT. The syntax for contact:

contact NAME X_LOW Y_LOW Z_LOW X_HI Y_HI Z_HI

or:

contact NAME X_LOW Y_LOW X_HI Y_HI LAYER_NAME

A port is specified as a set of nodes. There has to be at least two contacts in a port specification. The syntax for a port:

port NAME CONT_NAME CONT_NAME ...

The read_contacts command needs to be issued after read_tech and read_design commands.


-f[ile] The file containing the contacts/nodes and ports corresponding to resistance extraction.


read_gf_tables

Example

To read resistance data:

ranxt> read_contacts -f <filename>

See Also

read_design

read_tech

write_design

write_tech

read_gf_tables

Name

read_gf_tables reads GF tables for Raphael NXT.

Syntax

int read_gf_tables [-file string] [-check]

Arguments


-f[ile] Input file name.

Specifies the file name to read.

Required argument.

Typically created by a previous call to write_gf_tables.


read_design

Description

Use the read_gf_tables command if you have saved GF tables in a previous call to build_gf_tables followed by write_gf_tables, which writes the file in binary format. This saves time in creating GF tables again and initializes the GF tables in Raphael NXT to correspond to the ones created before. If you have saved a GF tables file, you can use read_gf_tables command instead of build_gf_tables command.

Examples

To read GF tables created in a previous run of Raphael NXT and saved in a file technology.gf_archive:

ranxt>read_gf_tables -file technology.gf_archive

See Also

build_gf_tables

write_gf_tables

read_design

Name

read_design reads the design into Raphael NXT.

-c[heck] Provided for self testing Raphael NXT.

Used to check if the internal state of GF tables as created by command build_gf_tables matches the one read from user-specified file.

Default value is false.



read_design

Syntax

int read_design [-file string] [-no_text] [-no_merge] [-check] [-apx_conformal] [-scale_factor float] [-dummy_as_fills] [-resistance_file string]

Arguments


-f[ile] Input file name.

Specifies the file name to read.

Required argument.

-c[heck] Provides for self testing Raphael NXT and is valid only in -no-text mode; i.e, file to be read is in binary format. This can be used to check if the internal state of design matches the one read from user-specified file. The default value is false. The file to be read is typically a result of command write_design -no-text -file <filename>.

-no_t[ext] Specifies if the file to be read is not in text format. The default behavior is to expect text format file

-no_merge Setting this option disables box merging. Where possible Raphael NXT merges boxes when they are the same width, touching and properly aligned. In most cases it is preferable to merge boxes, so this option will rarely be used. This option is ignored for resistance extraction, and all boxes are merged wherever applicable.


read_design

-apx_conf[ormal] Specifies that conformal layers are to be approximated by bloating the underlying metal layer geometry. The bloat is computed by looking into dielectric strength and thickness of conformal layers around the metal layer. The capacitance numbers computed with this option would approximate the true numbers. The extent of the error introduced by this approximation depends on technology and specific design. It reduces the extraction time at the expense of accuracy. By default this approximation is not used. In some cases use of -apx_conformals may result in faster run times (up to 5 times).

-scale_factor Specifies a scale factor for the design. This should be a positive number. All design coordinates are scaled up with this scale factor. You need to ensure that scaling does not cause overflows and underflows. If it does, then Raphael NXT reports an error and fails on read_design command.

Note: The scale parameter scales the design and technology files as well as control options such as the bounding box.

-resistance_file Specifies the name of a file which contains net name resistance value pairs. These resistance values are used along with the estimated capacitance error to compute timing error at each net. This error is then used as a criteria to determine capacitance. (see set_convergence_goal)



read_design

Description

The read_design command reads a design file for Raphael NXT. See Design File on page 39 for details of design file format with examples.

Examples

To read an ascii design file.

read_design -file my_design

To read a design file and scale it up by a factor of 100:

read_design -file my_design -scale_factor 100

To read a design file from a technology having conformal dielectrics and perform a metal bloat approximation:

read_design -file my_design -apx_conformal

-dummy_as_fills Specifies that all dummy metal objects are to be treated like floating fills. Any metal object belonging to a metal layer, and not tagged as part of any net, is treated as a dummy metal. For Raphael NXT design format, this means planar_boxes (in rnx_routing layer) which are not specified as part of any existing net.

Note: Regular metal boxes (3D boxes) can not be marked as dummy. Capacitances to them would be computed and reported as lumped misc. cap with each extracted net. Fill nets explicitly specified through net_names and marked as floating_fill using set_fill_nets can co-exist with dummy metals inferred as floating_fill with this argument.



read_state

See Also

read_tech

write_design

write_tech

read_state

Name

read_state reads a state file for Raphael NXT.

Syntax

int read_state [-file string] [-check bool]

Arguments

Description

The read_state commands reads in a state file that would have been generated by a call to write_state in a previous Raphael NXT run. The state file has information regarding Raphael NXT internal databases for the


-f[ile] File from which to read the internal state of Raphael NXT.

Required argument.

-c[heck] Provided for self testing Raphael NXT.

Used to verify if the current internal state of Raphael NXT is equivalent to one saved in the user specified file.

Default value is false.


read_tech

technology and design databases and the extraction process. The actual contents of the file depend on internal state of Raphael NXT at the point when the file was saved.

Note: The GF table information is not part of the state and should be read (read_gf_tables) or built (build_gf_tables) separately if desired.

Examples

To read a previously generated state file and verify if it matches the current internal state of Raphael NXT:

ranxt> read_state -file <filename> -check

See Also

write_state

read_tech

Name

read_tech reads a technology file for Raphael NXT.

Syntax

int read_tech [-file string]

Arguments


-f[ile] Contains the technology specifications for Raphael NXT.


resistance_extract

Description

Raphael NXT has an in-built technology specification of a uniform dielectric of dielectric constant 1.0. You can override this technology by specifying a technology file using the format described below.

Examples

To read a technology file:

ranxt> read_tech -f <filename>

See Also

write_design

write_tech

read_tech

resistance_extract


Name

resistance_extract runs resistance extraction to compute resistances across specified ports.

Syntax

int resistance_extract [-model <6 | 8>] [-apx_trap] [-grid_size <n>] [-ratio <1.0>]


resistance_extract

Arguments

Description

The resistance_extract command is used to invoke the resistance extraction process in Raphael NXT. It requires that the contacts/nodes and ports have already been read using the read_contacts command. The resistances computed by resistance_extract are printed. As output, the extractor produces the set of all resistances of each port, both the total resistances at each contact of each port and the inter-contact resistances in each port. The extractor performs a basic set of checks to test the validity of the specification (e.g., checking if all contacts of a port are electrically connected), and throws warning messages as errors are encountered. In this implementation, all contacts are added to the design and then the extraction is performed. Contacts are assumed to be ideal with infinite conductivity. It performs extraction one net at a time. All port resistances pertaining to a net are computed before moving on to the next net.

Barrier layers are fully supported by the extractor and are specified in the technology file format. Resistance extraction for trapezoidal conductors also is


-model [6, 8] Selects the required model of computation. The 8-node model is a more accurate model than the 6-node model and is also the default

-apx_trap Approximates trapezoidal conductors with the center line description of the geometry.

-grid_size <n> Specifies the maximum length of the finite element boxes used to calculate the resistance. <n> is an integer which specifies the maximum size of any in any direction. Use of a smaller number results in smaller boxes, a arger number of total elements, greater accuracy and longer run times

-ratio <1.0> Factor by which grid size increases from the corners. This number must be larger than 1.0.

The larger the ratio, the coarser mesh the tool generates.


set

supported natively. Similarly, CMP is supported. Two resistance extraction models are available to the user:■ The default model is the more accurate FEM based extractor which uses 8

nodes per 3D conductor box to model the potential and current flow inside the box.

■ The other model is an approximate model which follows the rho*L/A approach which uses 7 FEM nodes per 3D box.

Examples

To run resistance extraction:

ranxt> resistance_extract

To run resistance extraction with 6-node model:

ranxt> resistance_extract -m 6

To run resistance extraction by approximating trapezoids:

ranxt> resistance_extract -apx_trap

set

Name

set lists existing variables or sets variable’s value.

Syntax

int set [name1 [name2 ...]]

Description

The set command can establish temporary variables for referencing in Raphael NXT commands.


set_boundary_box

Examples

To set the path to the directory containing input data:

set path /home/ranxt/data

Use the above variable to read a design file named design1 in the above directory:

read_design $path/design1

set_boundary_box

Name

set_boundary_box establishes boundary for extraction.

Syntax

int set_boundary_box [-xl integer] [-yl integer] [-zl integer] [-xh integer] [-yh integer] [-zh integer] [-dist_v_i pos_integer]

Arguments


-xl Lower x coordinate of the box.

-yl Lower y coordinate of the box.

-zl Lower z coordinate of the box.

-xh Upper x coordinate of the box.

-yh Upper y coordinate of the box.

-zh Upper z coordinate of the box.


set_boundary_box

Description

The set_boundary_box command sets a bounding box for the extraction problem. A hollow box is created with the user-specified coordinates. This box is kept as a boundary for random walk process. Geometry outside this box is ignored during the extraction. Typically this box should completely enclose interconnect geometry. All nets for which extraction needs to be done should not touch this box or, preferably, be at a safe distance inside this box. If a bounding box is not provided, then the tool builds one on its own and uses that internally.

Note: If Neuman (reflecting) boundary conditions are being used the bounding box may touch or intersect the metal conductors.

Note: If Neuman (reflecting) boundary conditions are being used, ensure that no extracted nets lie completely outside the bounding box.

Bounding box has a serious impact on the capacitance numbers and also on the convergence behavior of the tool. The boundary conditions on the bounding box are specified using set_boundary_condition. While comparing results of Raphael NXT with any other tool, make sure that the bounding boxes used in both the tools are identical to each other and the identical boundary conditions are used. A smaller bounding box brings the zero potential boundary closer to the nets under extraction. This typically results in higher grounded capacitance values for these nets.

Note: Raphael RC2 and RC3 use Neuman boundary conditions by default.

-dist_v_i If this parameter is specified, then bounding box coordinates (if also specified) are ignored and a bounding box is built by first building the bounding box for the metal objects in the design and then inflating it outwards by the distance specified with -dist_v_i option.



set_boundary_condition

Examples

To set a bounding box from lower box coordinate (-1000, -1000, -1000) to higher box coordinate (1000, 1000, 1000):

ranxt> set_boundary_box -xl -1000 -yl -1000 -zl -1000 -xh 1000 -yh 1000 -zh 1000

To set a bounding box which is 1000 units away from the design geometry region (Design geometry region is taken as a bounding box of the metal objects in design.):

ranxt> set_boundary_box -dist_v_i 1000

See Also

set_ground_level


show_boundary_condition


Name

set_boundary_condition establishes boundary condition for extraction.

Syntax

int set_boundary_condition [-bc_xn string] [-bc_yn string] [-bc_zn string] [-bc_xp string] [-bc_yp string] [-bc_zp string]



Arguments

Description

The Dirichlet boundary condition forces the electric potential to be zero on the boundary. The Neuman boundary condition forces the normal component of the electric field to be zero on the boundary. A periodic boundary condition simulates the boundary of periodically repeated structures. The periodic boundary conditions must be specified in pairs. For example, if surface xn is assigned as periodic boundary, surface xp should be specifed as periodic boundary too. If one of a pair of surfaces (xn and xp, or, yn and yp) is specified


-bc_xn Boundary condition on face of boundary box located at the smallest x-coordinate. One of "D" (for Dirichlet) or "N" (for Neuman) or "P" (for periodic boundary).

-bc_yn Boundary condition on face of boundary box located at the smallest y-coordinate. One of "D" (for Dirichlet) or "N" (for Neuman) or "P" (for periodic boundary).

-bc_zn Boundary condition on face of boundary box located at the smallest z-coordinate. One of "D" (for Dirichlet) or "N" (for Neuman).

-bc_xp Boundary condition on face of boundary box located at the largest x-coordinate. One of "D" (for Dirichlet) or "N" (for Neuman) or "P" (for periodic boundary).

-bc_yp Boundary condition on face of boundary box located at the largest y-coordinate. One of "D" (for Dirichlet) or "N" (for Neuman) or "P" (for periodic boundary).

-bc_zp Boundary condition on face of boundary box located at the largest z-coordinate. One of "D" (for Dirichlet) or "N" (for Neuman).


set_convergence_goal

as periodic boundary, the other will be treated as periodic boundary no matter what boundary condition is assigned to this second surface. No periodic boundary condition can be assigned to zn or zp, because the bottom surface needs to be modeled as virtual ground (Dirichlet boundary condition). By default Raphael NXT assumes a Dirichlet condition on all boundaries. If set_ground_level is used to define a z-coordinate plane and it intersects the bounding box specified using set_boundary_box, then a Dirichlet condition is assumed on the face.

Note: Boundary conditions have a serious impact on the capacitance numbers and also on the convergence behavior of the tool. While comparing results of Raphael NXT with any other tool, ensure that the bounding boxes and the boundary conditions used in both the tools are identical.

Note: If Neuman (reflecting) boundary conditions are being used, the bounding box may touch or intersect the metal conductors.

Note: If Neuman (reflecting) boundary conditions are being used, ensure that no extracted nets lie completely outside the bounding box.

Examples

To set a Dirichlet condition on the lower z plane and a Neuman condition on the other faces of the bounding box:

ranxt> set_boundary_condition -bc_xn N -bc_yn N -bc_zn D -bc_xp N -bc_yp N -bc_zp N

See Also

set_boundary_box

set_ground_level



Name

set_convergence_goal establishes relative error for extraction.


Arguments

Syntax

int set_convergence_goal [-perc_self_cap number] [-perc_coup_cap number] [-abs_self_cap number] [-abs_coup_cap number] [-lump_net_group_cap] [-perc_lost_walks] [-abs_timing number]

Arguments


-perc_self[_cap] Percent error for self capacitance.

Default value is 3%.

-perc_coup[_cap] Percent error for coupling capacitance.

By default only the percentage error for self caps is considered.

-abs_self[_cap] Absolute error for self capacitance.


-abs_coup[_cap] Absolute error for coupling capacitance.


If perc_coup_cap is specified, abs_coup_cap defaults to 1e-17.

-abs_timing Specifies a timing value in seconds. Raphael NXT will calculate the timing error as the capacitance error at the net (or net group) multiplied by the resistance at the net (as specified in the resistance_file on the read_design command). If the calculated timing error is less than the abs_timing value the net will be considered converged.


Arguments

Description

The set_convergence_goal command specifies convergence criterion to Raphael NXT. Convergence specification can be relative, absolute, or based on the timing error for total capacitance. For coupling capacitors percentage and absolute error may be specified. If more that one criteria is given, the looser criteria is used. For example, a percentage error of 5% and absolute error of 0.1fF would result in a 1fF capacitance to be computed up to the accuracy of 0.1fF. If the extracted nets are specified with a pin capacitance in the input design file, then the convergence of the capacitance value for that net is checked with respect to the pin capacitance plus the capacitance value computed by Raphael NXT.

Achieving convergence on coupling capacitance is a very difficult task for Raphael NXT, especially the ones with very small value. Typical use is to specify convergence goals only for the self capacitances. Specifying 1% convergence goal to all the coupling capacitances in a big design could make the tool work for a long time.

It is not possible to specify convergence goals on a per-net basis. Convergence goals apply uniformly to all self and coupling capacitances. However, you can set the convergence goals and extract specific nets and modify the convergence goals and specify some other nets to be extracted.

Note: If the convergence goals are made more stringent, then all currently active nets which do not meet the new convergence criterion; i.e., the capacitance values for them have not converged with respect to the new convergence criterion, will be extracted till they converge with respect to the new criterion.

-lump[_netgroup_cap] Indicates that while computation of self capacitance for a net group, the self capacitances for all constituent nets in the net group should be added and then checked for convergence.

By default each net in the net group is checked separately for its self capacitance convergence.

-perc_l[ost_walks] Gives a warning if the percentage of lost walks on any net exceeds this percentage.

Default is 5%.



set_fill_nets

Examples

To set convergence goal of 3% for self capacitances and 10% for coupling capacitances:

ranxt> set_convergence_goal -perc_self_cap 3 -perc_coup_cap 10

To compute all self capacitances with maximum error of 1fF and all coupling capacitances with maximum error of 0.1fF:

ranxt> set_convergence_goal -abs_self_cap 1e-15 -abs_coup_cap 0.1e-15

See Also

set_statistics

set_fill_nets

Name

set_fill_nets marks specified nets as fill nets in the design.

Syntax

int set_fill_nets [-inflation pos_number] [glob_exp1 glob_exp2 ...]

<glob_exp> GLOB EXPRESSION (see the syntax in man page for extract command)


set_ground_level

Arguments

Description

The set_fill_nets command is used to mark specified nets as fill nets. Raphael NXT does not compute capacitance to these fill nets. Final capacitance report contains equivalent capacitances across non-fill nets.

Examples

To eliminate all nets with name Fill_*:

ranxt> set_fill_nets Fill_*

set_ground_level

Name

set_ground_level establishes z coordinate of ground plane.

Syntax

int set_ground_level [-zcoord integer]


-infl[ation] Inflates each fill net by this number. Whenever a walk terminates on a fill net, it is continued from this net inflation. This number can best be left unspecified as Raphael NXT automatically computes it.


set_grounded_nets_ok

Arguments

Description

The set_ground_level command sets the zero potential z plane for the extraction problem. The location of this ground plane has serious impact on the capacitance numbers and also on the convergence behavior of the tool. While comparing results of Raphael NXT with any other tool, make sure that the ground planes used in both the tools are identical to each other.

Geometry below ground plane is ignored during the extraction problem. All nets for which extraction needs to be done should not touch this plane or, preferably, be at a safe distance above it.

Examples

To set a ground plane at z = 100 units:

ranxt> set_ground_level -zc 100


Name

set_grounded_nets_ok allows nets to touch the ground plane during the extraction.

Syntax

int set_grounded_nets_ok [-verbose] [-dist_rectification integer]


-zc[oord] An integer number indicating the z coordinate of ground plane.



Arguments

Description

Raphael NXT computes self and coupling capacitances for user-specified nets. However, these nets should not touch or intersect with any other grounded or nongrounded nets. This restriction is due to fundamental electrostatic laws that state that capacitance is not defined between two nets which have resistive path between them. However, sometimes you may want to compute capacitances for nets connecting to ground planes. A typical case is the computation of a VLSI net connecting to source or drain regions on the substrate, which also happens to define a ground plane. Under such cases, using the set_grounded_nets_ok command tells Raphael NXT to ignore these ground plane contacts for capacitance computations.

Note: The set_grounded_nets_ok command is a workaround to facilitate capacitance computations for grounded nets. Its implementation disobeys electrostatic laws and, therefore, introduces errors. Use it with caution.


-verbose A flag that indicates a warning message should be delivered for each grounded object encountered during the processing of net or net group extraction. Typically the warning message contains the coordinates of the intersecting or grounded boxes.

-dist_rectification When a net touches ground plane, (strictly speaking) its capacitance with respect to ground plane is not well defined. Raphael NXT allows this ground-shorting by ignoring a small region around the ground plane. By setting dist_rectification, the portion of Gaussian surface within distance dist_rectification of ground plane is ignored during Monte Carlo integration. Higher distance gives better the convergence, but less accurate capacitance values. Typically you should set it to around grid units equivalent to 0.1 um.


set_layer_inflation

Examples

To allow grounded nets in extraction:

ranxt> set_grounded_nets_ok

See Also

set_ground_level

set_layer_inflation

Name

set_layer_inflation specifies xy inflation for a layer.

Syntax

int set_layer_inflation -layer_name <name> -inflation xy_inflation

Arguments


-layer_name Name of the layer for which the inflation is specified. This should match the name of a layer in the technology file.

-inflation Amount by which the geometries in the layer are to be expanded or shrunk in the xy directions. A positive (negative) inflation value means the boxes in that layer will be expanded (shrunk) by inflation in both xy directions. Raphael NXT does not check for possible short (open) created by the expand (shrink) operation. It is the user’s responsibility to give appropriate inflation to keep validity of the design.


set_layer_side_tangent

Description

The set_layer_inflation command is useful in getting capacitance values while considering the possible changes in geometry due to process variation. You can use it to get extreme values of capacitances due to expansion and shrinking of the metals in a layer, which then can be used as an estimate of capacitance variation.

This command has to be given after read_tech, as it refers to layer names in the technology file, and before read_design. Internally Raphael NXT stores the inflated of shrunk geometries, and these can be obtained by a subsequent write_design.

Since the checking of shorts (opens) in the design is an expensive operation, these checks are not made after inflation/shrinking.

Examples

To expand a layer by 10 units:

ranxt> set_layer_inflation -layer 10

See Also



Name

set_layer_side_tangent creates conductors with trapezoidal crossection in the x-z and y-z planes.

Syntax

int set_layer_side_tangent -layer_name <name> -tangent number



Arguments

Description

The set_layer_side_tangent command is useful for creating conductors with trapezoidal cross section. Refer to Figure 6 on page 104 for the definition of how the tangent parameter is used to set up the sidewall angle. The resulting side walls are sloped in both the x-z and y-z plane. Using trapezoidal conductors may result in a runtime penalty of approximately 40%.


-layer_name Name of the layer for which the which is to be converted to trapezoidal cross section. This should match the name of a layer in the technology file.

-inflation Tangent of the side angle (see Figure 6 on page 104). Raphael NXT does not check for possible short (open) created by the expand (shrink) operation. You must maintain the validity of the design.



Figure 6 Geometry for Trapezoidal Conductor

The set_layer_side_tangent command has to be given after read_tech because it refers to layer names in the technology file, and has to be given before read_design.

Examples

To specify that the sides of metal 1 slope inward from the top by 10 degrees tan(10)=0.176:

ranxt> set_layer_side_tangent -layer metal1 -tangent 0.176

See Also

set_layer_inflation

A

B

B

SIDE_TANGENT = A/B

W

SIDE_TANGENT < 0

A

B

B

W

SIDE_TANGENT > 0


set_min_capacitance

set_min_capacitance

Name

set_min_capacitance establishes minimum value of capacitance for estimations

Syntax

int set_min_capacitance number

Description

The set_min_capacitance command sets the minimum value of capacitance for which estimation is done. Any self or coupling capacitance which is found to be of value smaller than this minimum value is treated as a statistical noise and is not reported.

Examples

To set minimum capacitance value of 0.1aF:

ranxt> set_min_capacitance 1e-19

See Also

set_statistics

set_net_convergence_goal

Name

set_net_convergence_goal establishes relative error for extraction on a per net basis.


Arguments

Syntax

int set_net_convergence_goal [-perc_self_cap number] [-abs_self_cap number] [-perc_coup_cap number] [-abs_coup_cap number] [-lump_net_group_cap][glob_exp_1 glob_exp_2 ...]

Arguments






-perc_coup[_cap] Percent error for coupling capacitance.

By default only the percentage error for self caps is considered

-abs_coup[_cap] Absolute error for coupling capacitance.

By default only the percentage error for self caps is considered,

If perc_coup_cap is specified abs_coup_cap defaults to 1e-17

-lump[_netgroup_cap] Indicates that while computation of self capacitance for a net group, the self capacitances for all constituent nets in the net group should be added and then checked for convergence.

By default each net in the net group is checked separately for its self capacitance convergence.

glob_exp1 glob_exp_2 This is the list of nets and net groups for which a specific convergence goal is set


Arguments

Description

The set_convergence_goal command specifies convergence criterion to Raphael NXT. Convergence specification can be relative or absolute. Percentage tolerable errors for self capacitance and coupling capacitance can be specified. Absolute tolerable errors for the same also can be specified. The looser of the two criterion is taken in. For example, a percentage error of 5% and absolute error of 0.1fF would result into a 1fF capacitance to be computed up to the accuracy of 0.1fF. If the extracted nets are specified with a pin capacitance in the input design file, then the convergence of the capacitance value for that net is checked with respect to the pin capacitance plus the capacitance value computed by Raphael NXT.

set_net_convergence_goal statements later in the contol file take prescidence over earlier ones.

To specify convergence goals apply uniformly, use the set_convergence_goal command.

If set_convergence_goal command is issued after set_net_convergence_goal, all the net specific convergence goals are removed.

Examples

set_convergence_goal -perc_self_cap 3.0set_net_convergence_goal -perc_self_cap 2.0 AB*set_net_convergence_goal -perc_self_cap 1.0 -perc_coup_cap 5.0 ABC

In this situation net ABC will have perc_self_cap = 1.0% and perc_coup_cap = 5.0%., Net ABdog would have perc_self_cap = 2% and net FISH would have perc_sel_cap = 3%

See Also

set_statistics


set_rng_seed

set_rng_seed

Name

set_rng_seed establishes seed for random number generator.

Syntax

int set_rng_seed integer

Description

The set_rng_seed command specifies a seed for the random number generators used internally by the tool. Seed should be a nonnegative number. Different extraction runs in single processing mode with same seed should result in exactly same generated outputs.

Examples

To specify seed value 1234:

ranxt> set_rng_seed 1234

See Also

set_statistics

set_statistics

Name

set_statistics establishes statistics details.


set_statistics

Syntax

int set_statistics [-n_sigma integer] [-min_samples integer] [-level <level_type>]

<level_type> self|mutual|complete

Arguments

Description

The set_statistics command is used to control internal statistics engine. The n_sigma value determines the confidence levels on the reported percentage errors. If n_sigma is specified as 3, all the percentage error are correct with 99.8% confidence. Each capacitance value is computed from statistical samples. Through min_samples, you can specify the minimum number of samples for any computation. If any capacitance has samples less than this number, then that capacitance is not computed. By default Raphael NXT stores samples for all coupling capacitances. However, if you are interested only in self-capacitance values, then specify -level self. With -level mutual, self capacitances and coupling capacitances (only) between the extracted nets are reported. With -level complete, all self and coupling capacitances are reported.


-n[_sigma] Uncertainty as number of sigmas.

Default value is 1, which means that all errors are reported with 1-sigma.

-min_sa[mples] Minimum number of samples in any estimation.

Default is two samples.

-level Level of statistics. Optional values are self, mutual, or complete.

Default value is mutual.


set_walk_params

Examples

To set n_sigma as 3, and statistics level as self caps only:

ranxt> set_statistics -n_sigma 3 -level self

To set 100 as minimum samples for any capacitance estimation:

ranxt> set_statistics -min_samples 100

set_walk_params

Name

set_walk_params establishes parameters to specify and control random walks.

Syntax

int set_walk_params [-total double] [-report integer] [-check integer] [-max_hops integer] [-walks_per_net double]

Arguments


-to[tal] Total number of walks to be done.

Default is 1e12.

-rep[ort] Reports capacitance at these many walks.

Default is wait until the end.

-che[ck] Checks convergence at these many walks.

Default is 100,000 walks.

-max_ho[ps] Maximum hops allowed per walk.

Default is 1000 hops.


set_walk_params

Description

The set_walk_params command specifies random walk parameters. Once the specified total number of walks or walks per net is completed, the execution is stopped irrespective of the fact that convergence goals are achieved or not. If both the total walks and walks_per_net parameters are used, execution stops when the first one is reached. If convergence goals are achieved before the specified total number of walks, the execution is also stopped.

Use the -check option to specify how often Raphael NXT checks for convergence of capacitance values. Intermediate results are reported at every user-specified number of walks (specified with -report). Each walk is allowed to have user-specified maximum number of hops. If a walk does not terminate in that many hops, it is assumed to have lost. Lost walks are reported in the final report.

Note: If more that 5% walks are lost, Raphael NXT results become suspicious and a warning is given. In such cases, increase the maximum hops per walk.

Examples

To perform 5 million walks with maximum 200 hops per walk:

ranxt> set_walk_params -total 5000000 -max_hops 200

To see intermediate results at each million walks:

ranxt> set_walk_params -total 5000000 -report 1000000

To do convergence check at each million walks:

ranxt> set_walk_params -total 5000000 -check 1000000

-w[alks_per_net] Maximum number of walks per net for this extraction.

Default is 20,000,000.



set_xcap_convergence_goal

set_xcap_convergence_goal

Name

set_xcap_convergence_goal establishes relative error for extraction on a per coupling capacitance basis.

Syntax

int set_xcap_convergence_goal [-perc_self_cap number] [-abs_self_cap number] [glob_exp_1] [glob_exp_2]

Arguments

Description

The set_xcap_convergence_goal command specifies convergence criterion to Raphael NXT. Convergence specification can be relative or absolute. Percentage tolerable errors for self capacitance and coupling capacitance can be specified. Absolute tolerable errors for the same also can be specified. The milder of the two criterion is used.

For example, a percentage error of 5% and absolute error of 0.1fF would result into a 1fF capacitance to be computed up to the accuracy of 0.1fF. In other words, once either of percentage or absolute goal is achieved, the coupling capacitance is assumed to have converged.






glob_exp1 glob_exp_2 Defines the coupling capacitance by a pair of nets



The set_net_convergence_goal statements later in the control file take precedence over earlier ones.

Note: To specify convergence goals apply uniformly, use the set_convergence_goal command.

Caution! If set_convergence_goal is issued after set_xcap_convergence_goal, all the xcap specific convergence goals are removed.

Examples

set_xcap_convergence_goal -perc_coup_cap 5.0 AB CD

In this situation, the convergence occurs when the coupling capacitance between nets AB and CD is 5%.

See Also


set_net_convergence_goal

set_statistics


Name

show_boundary_condition displays boundary conditions used in extraction.

Syntax

int show_boundary_condition


show_design_nets

Description

The show_boundary_condition command prints the boundary conditions used during the extraction. Currently only zero-potential boundary conditions are supported; hence, this command prints the zero-potential bounding box used as extraction boundary.

Examples

To get the boundary conditions:


Expect an output similar to the following:

Bounding_Box -1000 -1000 -1000 1000 1000 1000Zero electric potential taken on face at x = -1000 (Dirichlet)Zero electric potential taken on face at x = 1000 (Dirichlet)Zero electric potential taken on face at y = -1000 (Dirichlet)Zero electric potential taken on face at y = 1000 (Dirichlet)Zero electric potential taken on face at z = -1000 (Dirichlet)Zero electric potential taken on face at z = 1000 (Dirichlet)

show_design_nets

Name

show_design_nets lists names of nets which are to be extracted.

Syntax

show_design_nets

Description

The show_design_nets command lists the names of nets which are to be extracted.


show_extraction_nets


Name

show_extraction_nets lists names of nets which are to be extracted.

Syntax

int show_extraction_nets

Arguments

Description

The show_extraction_nets command prints net names which are taken in Raphael NXT system as nets to be extracted. Net names are printed one each on a line.

Examples

To get the names of nets being extracted:


Expect an output similar to the following:

net_anet_bnet_c


-groups Shows a marker NET or GRP if the extracted net is native net or a net group. If it is a net group, then it also lists all its constituent nets in separate lines.


source

source

Name

source executes commands from file.

Syntax

int source [switches] [[filename]]

-p[rompt] prompt for each command

-e[cho] echo each command

-a[bort] abort on first error

[filename] "-" file to source

spf_report

Name

spf_report writes an SPF representation of the interconnect capacitnces to a file.

Syntax

int spf_report [-file name] [-xcap] [-min_cap value]

Arguments


-file Specifies the name of the file where the SPF data will be written.


unalias

Description

The spf_report command is used to get the capacitance estimates after the extraction process. A SPICE circuit is built that recreates the same capacitances and is written to a file in SPF form. The default behavior of the command is to print the self capacitance estimates for all the extracted nets.

Examples

To print both the self and coupling capacitance estimates between all the extracted nets to the file my.spf.

ranxt> spf_report -file my.spf -xcap

See Also


print_param

set_statistics

unalias

Name

unalias deletes some alias definitions.

-xcap Prints coupling capacitances in the capacitance report.

By default only the self capacitances are reported.

-min_cap Minimum capacitance to be written to the file. If a coupling capacitance is less than min_cap, the coupling capacitor is not generated, but its value is included in the grounded component.



uninit_extract

Syntax

int unalias name1 name2 ...

uninit_extract

Name

uninit_extract cleans up the extraction system.

Syntax

int uninit_extract [-only_mp]

Arguments

Description

This uninit_extract command shuts down the MP system and cleans up the capacitance data stored in Raphael NXT system. It is recommended to use this command for enabling a graceful shutdown on MP system.

Examples

To shut down only the MP system:

ranxt> uninit_extract -only_mp


-only_mp Indicates that only the MP client-server along with all its servers are to be shut down. The remainder of the capacitance data is kept intact in Raphael NXT system. It is useful to shut down an existing MP system and initialize with another MP system possibly running on some other host with more clients.


unset

See Also

build_gf_tables

extract, init_extract



unset

Name

unset deletes some variables.

Syntax

int unset [name1] [name2] ...

wextract

NAME

wextract runs extraction for a net with a specified window size.

Syntax

int wextract [-net_name string] [-window integer]


wextract

Arguments

Description

The wextract command is used to invoke the extraction process in Raphael NXT. Like the extract command, wextract requires that the GF library has already been loaded in Raphael NXT using build_gf_tables or read_gf_tables. The capacitance estimated computed by extract can be printed using print_capacitance_report command.

The wextract command differs from the extract command in that:■ You can only extract one net at a time with this command. ■ The window size you specify introduces an approximation in the

computations.

In designs with dense geometry typically all the nets significant for extraction of the specified net would be included with a reasonably sized window, and there would not be much loss in accuracy if all the other nets are ignored. The window size should specify the extended region around the net to be extracted. The extended region is obtained by the increasing, by window size, the x-y extent of the net to be extracted.

Note: wextract is not supported in the MP mode.

Examples

To run windowed extraction for net1 with window size 10:

ranxt> wextract -n net1 -window 10


-net Specifies the name of the net to be extracted.

-window Specifies the region around the extracted net. All nets falling outside this region are ignored by the extraction process.


which

See Also

extract

which

Name

which searches for file following path defined by $path.

Syntax

int which name.

write_design

Name

write_design writes a design file for Raphael NXT.

Syntax

int write_design [-file string] [-no-text] [-window] [-xl integer] [-yl integer] [-xh integer] [-yh integer]

Arguments


-f[ile] Specifies the file where the design can be saved in text or binary format.

Required argument.


write_design

Description

The write_design command is used to write the design. This helps in verifying the state of design database as seen internally in Raphael NXT. Use the -text option to get a readable design file. Use the-no-text mode to generate a binary design file which you can use to verify design states using the read_design command.

Examples

To write a file in binary format:

ranxt> write_design -no-text -file design.state

To write a net with a window around it:

ranxt> write_design -net_name clock -window 200

To write design portion intersecting region (-100, -100) to (100, 100):

ranxt> write_design -xl -100 -yl -100 -xh 100 -yh 100

-no-t[ext] Specifies whether the design is to be written in text or binary format.

Default value is text format.

-n[net_name] write_design

Can also be used to selectively write out a design file containing geometry for a net along with its neighborhood. With -net_name, the name of the net can be specified. The neighborhood is selected with window size specified with -window argument.

-w[indow] Specifies a windowing size.

Takes a positive integer argument.

-xl -yl -xh -yh Specifies a 2D box.

The portion of design which intersects with this 2D box is written out. These arguments have higher precedence than -net_name and -window.



write_gf_tables

See Also

read_design

write_gf_tables

Name

write_gf_tables writes GF tables onto the user-specified file.

Syntax

int write_gf_tables [-file]

Argument

Description

The write_gf_tables command is used to write out the GF tables built within Raphael NXT by a previous call to build_gf_tables. The GF tables created internally in Raphael NXT are saved onto the file. The file written by this command can then be read by a corresponding call to read_gf_tables. The configuration of the GF tables depends on how they were built in the previous call to build_gf_tables.

Example

To write GF tables in binary format in a file technology.gf_archive:

ranxt> write_gf_tables -file technology.gf_archive


-f[ile] Output file name where GF tables are to be saved.

Required argument.


write_state

See Also

build_gf_tables

read_gf_tables

write_state

Name

write_state writes a state file for Raphael NXT.

Syntax

int write_state [-file filename] [-every n_minutes]

Arguments

Description

The write_state command is used to obtain a Raphael NXT internal state description. The file generated is in binary format and can be read in Raphael NXT by the read_state command. This can be helpful in saving technology, design, and extraction related internal information. You can then use this state file to initialize the internal Raphael NXT state without having to read the design and technology specifications and also restore the extraction process to that stored in the file.


-f[ile] The filename where the state specifications are to be saved.

Required argument.

-every n Save the state every n minutes.


write_tech

To enable checkpointing use write_state with the -every argument before issuing the extract statement. Raphael NXT then saves a state file every N minutes. You can use these saved files to restart the simulation if the computer that Raphael NXT is running on is accidentally shut down.

Note: The GF table information is not part of the state and should be stored (write_gf_tables) separately if desired.

Examples

To write a state file:

ranxt> write_state -f <filename>

See Also

read_state

write_tech

Name

write_tech writes a technology file for Raphael NXT.

Syntax

int write_tech [-file string]

Arguments


-f[ile] The filename where the technology specifications are to be saved. If the you do not specify any file, the contents are output on stdout.


write_tech

Description

The write_tech command can be used to get a user-readable file that describes the technology specifications as seen internally in Raphael NXT.

Examples

To write a technology file onto stdout:

ranxt> write_tech

See Also

read_tech


44Multi-Processing

This chapter describes Raphael NXT Distributed Processing (DP), i.e., multi-processing (MP), version of Raphael NXT automatic setup of servers and clients, extraction, licensing, and manual setup of servers and clients. In some places this option is referred to as “multi-processing” and in others as “distributed processing”. A special license is needed to use this option.

This chapter contains the following sections:■ Automatically Configuring Server and Clients■ MP Based Extraction with Raphael NXT■ MP Licensing■ Manually Starting the Server and Clients

The MP (or DP) version of Raphael NXT works in the common client-server mode. A server executable is run as a daemon on a host. Clients daemon are added on different hosts (typically one on each host, or as many as number of processors on the host). Then these clients are available as computation resources to the server. Once the clients and servers are available, Raphael NXT only needs to be given the server name and port number. Raphael NXT then communicates with the server, which in turn makes use of available clients to perform the extraction. The entire process is transparent to the end user of the Raphael NXT. The Raphael NXT release comes with a set of executables to facilitate this multi-processing.


Automatically Configuring Server and Clients

One of the advantages of the random walk algorithm is that each walk is independent of all the others so walks may be run in parallel with no loss of accuracy. Raphael NXT MP takes advantage of this property to allow extractions to be performed in parallel on multiple computers with much greater throughput. Raphael NXT MP uses a fine grained parallel algorithm and runs efficiently even if there are different loads on different machines. Raphael NXT MP was tested with as many 70 machines for a single run without significant degradation of efficiency.

Raphael NXT MP also is tolerant of machine failures. If a machine is lost during a run, Raphael NXT selects a new machine from the available clients.

Raphael NXT process can be split across a mixture of machines. For example, you can split a single job across a mixture of SUN and LINUX machines. You also can mix 64-bit and 32-bit architectures. (Although if the job is too big for a 32-bit machine, you must use all 64-bit machines).


The simplest way to use the MP version of Raphael NXT is to use the mp_config script. This script automatically starts up or shuts down all the required client and server processes from a single command. The syntax for using mp_config is the following:

mp_config -port PORTNUM [-server SERVER_NAME] -clients_file FILE_NAME -option <init | shutdown>

■ PORTNUM is the server port number. You will refer to this port inside Raphael NXT when you run.

■ SERVER_NAME is the name of the machine where the server will run. The default is the current machine.

■ FILE_NAME is the name of the file containing the client list. ■ INIT causes the script to start the server and clients. Otherwise, it is

assumed the server is already running and you wish to add additional clients.

■ SHUTDOWN causes the script to kill the server and clients.

To use mp_config, first create a text file containing the host names and architectures for the clients that you with to run on. You may mix architectures if you desire. Each line of the file describes a client machine. The syntax is:

machine_name architecture [cache_directory] [priority]



Current choices for architecture are listed in the following table. Priority may be set to idle, low, normal, and high.

For example, to run on two Linux and one SUN machine, you would create the following file named clients.lst:

tcadlnx1 linux tcadlnx2 linux titania gccsparcOS5 /tmp/mpcache low

Next use mp_config to start the server and clients, and use port number 6060 for communication:

mp_config -port 6060 -server tcadlnx13 -clients_file clients.lst -option init

For example, to run on two Linux and one SUN machine, you would create the following file name clients.lst:

tcadlnx1 linux tcadlnx2 linux titania gccsparcOS5 /tmp/mpcache low

Next use mp_config to start the server and clients, and use port number 6060 for communication:

mp_config -port 6060 -server tcadlnx13 -clients-file clients.lst -option init

This is all that is required to start the clients and servers. The server daemon will be run on machine tcadlnx13 and the client daemon on machines tcadlnx1, tcadlnx2, and titania. Likewise, Raphael NXT extraction will be spread across tcadlnx1, tcadlnx2, and titania. It may be desirable to leave the client and servers running all the time so that you can use Raphael NXT MP at any time without restarting the server and clients. The server and clients consume very little actual CPU resources when Raphael NXT DP is not

Machine Type Keyword

Sun Sparc 32 bit gccsparcOS5

Linux 32 bit Red Hat version linux

Sun Sparc 64 bit sparc64

AMD Opteron 64 bit and64


MP Based Extraction with Raphael NXT

actually being used for extraction. The next section discusses how to access the server from the Raphael NXT control file and run Raphael NXT DP.

MP Based Extraction with Raphael NXT

To perform parallel mode extraction, you need to let Raphael NXT know the host name and port number of the server. This is specified as argument to init_extract command in Raphael NXT. Before any parallel extraction is attempted, you must ensure the server and clients are running. The Raphael NXT user does not need to know anything about the clients. The user only needs to know the server host name and the port number.

There are two entries for multi processing on init_extract:

init_extract -client-server SERVER_NAME:PORT -nc NUM_CLIENTS ■ SERVER_NAME is the name of the server machine■ PORT is the communication port number ■ NUM_CLIENTS is the number of client machines to run on.

When you perform the extraction, you also need to set the –mp flag on the extract command.

For example, to run on the three hosts in the example above and extract all nets in the design:

init_extract -client-server tcadlnx13:6060 -nc 3 -all extract -mp

Cleaning up after Extractions

When you have completed all your work and you want to stop the server and clients and remove their cache directories, use the shutdown option on mp_config.

Note: You do not have to do this. You may want to leave the clients and servers running in case you want to use Raphael NXT MP in the future.

mp_config -port 6060 -server tcadlnx13 -clients-file clients.lst -option shutdown


MP Licensing

MP Licensing

To use Raphael NXT in MP mode, a RANXTDP license and a normal RANXT license are required. On startup, the main program checks out a RANXT token and each client checks out one RANXTDP. These tokens can then be used in any combination. For example, if you have two RANXT tokens and eight RANXTDP tokens, you could run one job on eight processors or run two jobs on four processors at the same time.

Note: RANXTDP tokens are sold by Synopsys in packs of four tokens.

Manually Starting the Server and Clients

The following executables are used when Raphael NXT MP is run:■ mp_server: main server executable.■ mp_client: main client executable. ■ ranxt_helper: an extraction supplement executable used by the clients

to perform extraction jobs assigned to them. This executable is communicated by server to each clients, if they do not already have one. The end user would never use this executable directly.

■ ranxt: the main Raphael NXT executable. The same executable is used for single as well as parallel mode of extraction.

To manually start the server daemon, use the command below. An available port number and the executable root directory need to be passed as an argument to mp_server during invocation. EXEDIR should be set to $RANXT_ROOT/bin

mp_server [-help] [-d DEBUG_PORT] -e EXEDIR PORT_NUMBER -help Usage information EXEDIR Executable root directory DEBUG_PORT Client server debug port PORT_NUMBER Client server port

Example mp_server -e $RANXT_ROOT :6061


MP Licensing

■ -e specifies the location of the RANXT root directory. The server determines the required platforms for each server.

■ -d debug port number specifies the listening port to connect to get the MP server command line. You can telnet to this port and get an MP prompt.

The single trailing argument on the command line specifies the listening port for the client server.

Adding MP Clients

MP clients need to run as daemon on all the machines which your want to use for parallel extraction. During invocation, the host name and port number for the server are needed. It then establishes connection with the server. You also can specify priority to clients which is used to grade the availability of these clients for extraction purposes. The server respects these priorities during work allocation to clients. Typically all networked machines should have a client running on them, with low priority on ones which does not want to share its full extraction capabilities with the server.

mp_client [-help] -cache-dir DIR_NAME [-priority PRIO] SERVER:PORT

■ -help: Usage information ■ DIR_NAME: Directory for caching executables:defaults to /tmp/mpcache ■ PRIO: Process priority (high, normal, low, idle) defaults to idle■ SERVER:PORT: Client-server (host:port)

Examplemp_client -priority normal tcad1:6061

■ -cache-dir specifies where executables will be cached on the client side. This defaults to /tmp/mpcache for Unix. A log for the client also is maintained in this directory in the file log/hostname.pid.

■ -priority provides the default process priority for mp_client. The priority setting is propagated to application clients.


AAExamples

This section contains detailed examples for Raphael NXT.

Technology File Example

The technology file describes the basic layers that make up the chip. For simplicity, in this example there are only two metal layers imbedded in two dielectric layers.

In a real example, you can have as many layers as you want. For this example the ground plane is located at Z = 0. Metal layer m1 is located between Z = 0.3 and Z = 0.6 microns. Metal layer m2 is located between 0.9 and 1.2 microns. The main dielectric is oxide with eps = 3.9, but there is a thin (0.05 um) layer of silicon nitride deposited underneath each of the metal layers.


The Design File

# Comments start with a pound signtechnology my2layergrids_per_meter 1.0e9layer m1 300 600 rnx_routinglayer m2 900 1200 rnx_routingdefault_dielectric_constant 1.0dielectric_constant 3.9 0 250dielectric_constant 7.0 250 300dielectric_constant 3.9 300 850dielectric_constant 7.0 850 900dielectric_constant 3.9 900 1500

The Design File

This example shows how to extract the capacitance of a interdigitated “comb” capacitor to determine how much capacitance the “fingers” of the structure contribute and how much the vertical connecting line contribute.

To do this, you need to make each plate of the capacitor a net group and separate the plate into two nets:■ One for the finger■ One for the vertical strip.

Note: Nets in a net group are assumed to be electrically connected.

To illustrate more features of Raphael NXT, an additional box in metal 2 has been added, and this box has not been assigned to any net. Then the box is assigned to the misc net. Capacitance to it is reported separately.


The Design File

#Comments start with a pound signdesign finger_cap

technology my2layernet net_1a

metal m1 planar_box 100 0 800 100 metal m1 planar_box 100 400 800 500

endnet net_2a

metal m1 planar_box 200 200 900 300 metal m1 planar_box 200 600 900 700

endnet net_1b

metal m1 planar_box 0 0 100 700 end net net_2b

metal m1 planar_box 900 0 1000 700 endmetal m2 planar_box 150 -50 850 800net_group

net_1 net_1a net_1b end net_group net_2 net2_a net2_b end end


The Control File

In the above example, the lines have been indented to make the structure clearer. It is not necessary to indent the lines. An entire net also could be placed on a single line as shown below:

net net_1b metal m1 planar_box 0 0 100 600 end

Currently net names must contain one letter and you cannot use one of the following keywords: ■ box■ planar_box ■ net ■ net_group■ design■ technology■ end

If you want to use these words as names or simple numbers as names, enclose the names within quotes or back slashes.

Note: The one box on layer 2 metal m2 planar_box 150 -50 850 700 is outside any nets, so it becomes part of the special misc net.

The Control File

You can either enter the following at the Raphael NXT prompt or type them into a file and run with the –f file_name option for batch execution. This example reads a technology file and a design file, extracts the capacitances at all nets, and writes the output to the file e1.out.

# A comment starts with a pound sign read_tech -file e1.tec #read the technologyread_design -file e1.des #read the designbuild_gf_tables -zc -level 3 #build Green’s function tableswrite_gf_tables -file my_tech.gf #store tables for use later on#read_gf_tables -file my_tech.gf #next time just read the tablesset_ground_level -zc 0 #set ground plane to z=0init_extract –all #set up to extract all netsextract #extract


Results

print_capacitance_report -total -xcap –misc > e1.out #print total and coupling caps

uninit_extract #finish extractionquit

Results

The simulation takes about four minutes. The results of the simulation (from file e1.out) are shown below.

Note: The capacitances between the nets in the net group are reported separately. This makes it possible to determine the contribution of the fingers (nets 1a and 2a) and the vertical piece (1b and 2b). The capacitance between the fingers (1a to 2a) is much larger than between the fingers and the vertical piece. The capacitance between the two vertical pieces (1b to 2b) is so small that Raphael NXT reports it as zero. There is no capacitance between nets 1a and 1b because 1a and 1b touch each other. A similar situation exists for 2a and 2b.

In this case the accuracy is the default 3% for the self capacitance. The smaller net capacitances (net_1b and net_2b) determine this 3%. Convergence on the coupling capacitance was not checked, but since most of the coupling capacitances were larger than the self capacitances for nets 1b and 2b, the coupling capacitance was determined more accurately. Capacitance to the misc are reported in a separate section. Since the capacitance to the misc net is rather small, its accuracy is not as good.

Note: The total capacitance for the net groups net_1 and net_2 are reported and are nearly the same. It is expected that they should be the same because the structure is symmetric.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++Capacitance Report:---------------------------------------------------------------Net-1 Net-2 Capacitance 1-Sigma Error---------------------------------------------------------------net_1a net_1a 4.330176e-16 0.54%net_1a net_2a 2.735279e-16 0.41%net_1a net_2b 4.571278e-17 1.64%net_1b net_1b 1.251254e-16 2.96%net_1b net_2a 4.574969e-17 1.51%net_2a net_2a 4.421486e-16 0.51%net_2b net_2b 1.158926e-16 2.98%


Example using APIS and GDS2

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++Report of Total Capacitances:---------------------------------------------------------------Net Capacitance 1-Sigma Error---------------------------------------------------------------net_1a 4.330176e-16 0.54%net_1b 1.251254e-16 2.96%net_2a 4.421486e-16 0.51%net_2b 1.158926e-16 2.98%+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++Report of Net-group Self Capacitances:---------------------------------------------------------------Net Capacitance 1-Sigma Error---------------------------------------------------------------net_1 5.581430e-16 0.78%net_2 5.580412e-16 0.74% +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++Report of Miscellaneous Capacitances:---------------------------------------------------------------Net Capacitance 1-Sigma Error---------------------------------------------------------------net_1a 4.416780e-17 3.10%net_1b 1.857294e-17 9.75%net_2a 4.915334e-17 2.95%net_2b 1.173044e-17 15.85%

Example using APIS and GDS2

APIS reads a GDS2 file, performs various geometric operations on the layers (AND, OR, bloat etc.), and analyzes connectivity,

Finally Raphael NXT produces a technology and design file that Raphael NXT can read. In this example, the GDS2 file for the simple layout is shown. This simple layout (file e2.gds) was created using Taurus Layout. This design has four metal conductors on two layers of metal connected using two vias to from two separate nets. The nets will be named net_1 and net_2.


APIS Control File

APIS Control File

APIS reads a control file and the GDS2 file, and generates a design file, a technology file, and a control file that Raphael NXT can read. The only Raphael NXT specific commands are in the HEADER section. When creating a file for Raphael NXT, the information in the WINDOW section is transferred to the boundary conditions used for Raphael NXT. To specify the grid units per meter that Raphael NXT uses, use RANXT_GRIDS_PER_METER. Be sure to use a large enough value to fully resolve all geometries (both in the design and technology). APIS reads the grid units specified inside the GDS2 file and automatically scales the GDS2 data so that the geometries produced for Raphael NXT will be the correct size. APIS can produce output for RC3 at the same time as Raphael NXT. Refer to the APIS User Guide for more information. The complete APIS control file e2.inp is shown below.

HEADER { labeling_file=e2.lab INLIB = e2.gds BLOCK = e2 RANXT_TECH_FILE= mytec.tec RANXT_DESIGN_FILE=e2.des


APIS Control File

RC3_DESIGN_FILE=e2.rc3 RANXT_RUN_FILE=e2.ctl RANXT_GRIDS_PER_METER = 1e9 }assign { metal1 (0) text (21) via1 (1) metal2 (2) text (22)}window { LEFT=-5 RIGHT=5 TOP=5 Bottom=-5 ZMIN=0 ZMAX=10} GEOMETRY { groundplane { LOCATION=0.0 } metal1 { LOCATION=0.3 THICKNESS=0.3 } via1 { LOCATION=0.6 THICKNESS=0.3 } metal2 { LOCATION=0.9 THICKNESS=0.3 } } DIELECTRIC { {EPS=1.0 DEFAULT} {EPS=3.9 LOCATION=0.0 THICKNESS=0.25} {EPS=7.0 LOCATION=0.25 THICKNESS=0.05} {EPS=3.9 LOCATION=0.3 THICKNESS=0.55} {EPS=7.0 LOCATION=0.85 THICKNESS=0.05} {EPS=3.9 LOCATION=0.9 THICKNESS=0.6}}

Identifying Nets for APIS

To specify the names of the nets, use the labeling file. The entries in this file are the desired name of the nets, and the x,y coordinates of a point on one of the


APIS Control File

polygons of the net, and the layer for that polygon. The other way to specify net names is to use text layers. APIS automatically determines which polygons are electrically connected and merges them into nets.

Note: The lengths for the label file are in micron units.

LABEL NAME=net_1 X=-0.2 Y=1.0 LAYER=2LABEL NAME=net_2 X=2.6 Y=-0.8 LAYER=2

To run APIS, type APIS e2.inp at the command line. APIS produces the following design file (e2.des) for Raphael NXT.

Note: The polygons have been merged to form two nets. The technology name has also been included in the design file.

technology_file mytec.tectechnology mytecnet net_1 metal metal1 planar_box 1600 -1400 2200 1200 metal via1 planar_box 1800 800 2000 1000 metal metal2 planar_box -400 600 2200 1200 end

net net_2 metal metal1 planar_box 0 -1000 600 1800 metal via1 planar_box 200 -800 400 -600 metal metal2 planar_box 0 -1000 2800 -400 endend

The following technology file also is generated.

grids_per_meter 1.0e+09# Metal layerslayer metal1 300 600 rnx_routinglayer via1 600 900 rnx_routinglayer metal2 900 1200 rnx_routing# Planar dielectric layersdefault_dielectric_constant 1.000000dielectric_constant 3.900000 0 250dielectric_constant 7.000000 250 300dielectric_constant 3.900000 300 850dielectric_constant 7.000000 850 900dielectric_constant 3.900000 900 1500


Running Raphael NXT with APIS Files

Running Raphael NXT with APIS Files

APIS also generates a control file “e2.ctl” that you can run directly in Raphael NXT which is shown below. You can now run the extraction using the command:

ranxt –f e2.ctl.

# Raphael NXT control file created by APISread_tech -file mytec.tecread_design -file e2.desbuild_gf_tables -zc -level 3write_gf_tables -file mytec.tec.gf#read_gf_tables -file mytec.tec.gfset_boundary_box -xl -5000 -xh 5000 -yl -5000 -yh 5000 -zl 0 -zh 10000set_ground_level -zc 0init_extract -allextractprint_capacitance_report -total -xcap -gnd > e2.des.outuninit_extractquitThe run takes about three minutes, most of which is the time to generate the GF tables. If you want to run another example with the same technology file change the lines that control the GF calculation to the following:

#build_gf_tables -zc -level 3#write_gf_tables -file mytec.tec.gfread_gf_tables -file mytec.tec.gf

Raphael NXT Results

The following output is generated in the file e2.des.out. This is the capacitance report for the interconnect structure.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++Capacitance Report::-------------------------------------------------------------Net-1 Net-2 Capacitance 1-Sigma Error-------------------------------------------------------------net_1 net_1 1.069811e-15 2.94%net_1 net_2 3.658599e-16 5.15%net_2 net_2 1.085429e-15 2.95%

+++++++++++++++++++++++++++++++++++++++++++++++++++++


Example using Device Layers

Report of Total Capacitances::------------------------------------------------------Net Capacitance 1-Sigma Error--------------------------------------------------------net_1 1.069811e-15 2.94%net_2 1.085429e-15 2.95%

+++++++++++++++++++++++++++++++++++++++++++++++++++++++Report of Grounded Capacitances::--------------------------------------------------------Net Capacitance 1-Sigma Error-----------------------------------------------------net_1 6.868952e-16 7.42%net_2 7.317404e-16 7.34%

The following SPICE style output also can be generated in the file “e2.spf” if the following line is added to the control file just after the print_capacitance_report line.

spf_report -file e2.spf -xcap

Coupling capacitances and ground caps have been included in the circuit.

*|DSPF 1.0*|DESIGN e2.gds*|VENDOR Synopsys*|Program RAPHAEL NXT*|DIVIDER /*|DELIMITER :*|GROUND_NET 0 *CC1 net_1 net_2 3.6586e-16

CG1 net_1 0 6.86895e-16 CG2 net_2 0 7.3174e-16

*** END SPF Model ***


This example will extract the interconnect capacitance of the transistor shown below without including the parasitices of the actual transistor. It is often desirable to extract interconnect parasitics without device capacitance since



the device capacitances have already been included in the SPICE transistor models. To aid in this, Raphael NXT includes special device layers which act as shields yet do not contribute any capacitance.

Generating the layers is challenging. First, you must create a layer ndiff which represents n-type diffusion. This layer is created by subtracting poly from the original diffusion layer. This effectively separates the diffusion into source and drain pieces.

Next, you must create the three separate types of contacts from metal to well, source/drain and poly. The thickness of the layers is defined in the GEOMETRY section. The well layer is located below the ground plane (below the silicon surface which is at Z=0). The ndiff layer is located slightly above the silicon surface. This is done so that APIS does not short or connect the ndiff layer to the well layer. If this were to happen, the source, drain, and well would become



shorted together. Later, edit the tech file and place the ndiff layer back below the silicon surface before actually running Raphael NXT.

HEADER { labeling_file=e3.lab INLIB = e3.gds BLOCK = e3 RANXT_TECH_FILE= mytec.tec RANXT_DESIGN_FILE=e3.des }

assign { well (0) diffuse (1) poly (2) metal1 (3) contact (4)}

BOOLEAN(diffuse NOT poly ) temp=ndiffBOOLEAN (well NOT diffuse) temp=pwellBOOLEAN (metal1 AND contact AND pwell) temp=wellconBOOLEAN (metal1 AND contact AND diffuse) temp=difconBOOLEAN (metal1 AND contact AND poly) temp=polycon

GEOMETRY { well { LOCATION=0 THICKNESS=-0.1 } ndiff { LOCATION=0.001 THICKNESS=0.001 } poly { LOCATION=0.3 THICKNESS=0.3 } difcon {location=0.002 thickness=0.9} wellcon {location=0 thickness=0.9} polycon {location=0.6 thickness=0.3} metal1 { LOCATION=0.9 THICKNESS=0.3 } }

DIELECTRIC { {EPS=1.0 DEFAULT} {EPS=3.9 LOCATION=0.0 THICKNESS=1.5}

}As in the preceding example, a label file is used to identify the nets. In this case, they are named d,g,s,w for drain, gate, source, and well. The label file simply picks a point inside of each of the four metal boxes that connect to the transistor terminals. Layer3 corresponds to metal1.

LABEL NAME=w X=-1.4 Y=2.4 LAYER=3LABEL NAME=d X=-1.4 Y=1.2 LAYER=3LABEL NAME=g X=0.4 Y=-1.6 LAYER=3LABEL NAME=s X=2.2 Y=1.2 LAYER=3



The following design file (e3.des) created by APIS is ready for use with Raphael NXT.

Note: Four nets were created, and the different polygons from each were grouped together and connected.

design e3.gdstechnology_file mytec.tectechnology mytecnet w metal well planar_box -1000 2200 -200 2600 metal well planar_box -1000 400 1800 2200 metal wellcon planar_box -800 2200 -600 2400 metal metal1 planar_box -1600 2000 -400 2600 endnet s metal ndiff planar_box 800 800 1400 1800 metal difcon planar_box 1000 1200 1200 1400 metal metal1 planar_box 1000 1000 2400 1600 endnet d metal ndiff planar_box -400 800 200 1800 metal difcon planar_box -200 1200 0 1400 metal metal1 planar_box -1600 1000 0 1600 endnet g metal poly planar_box 200 -400 800 2000 metal polycon planar_box 400 -200 600 0 metal metal1 planar_box 0 -1800 1000 200 endend

The technology file is generated by APIS, but needs some hand editing before it can be used (see the next paragraph).

technology mytecgrids_per_meter 1.0e9# Metal layerslayer well 0 -100 rnx_routinglayer wellcon 0 900 rnx_routinglayer ndiff 1 2 rnx_routinglayer difcon 2 900 rnx_routinglayer poly 300 600 rnx_routinglayer polycon 600 900 rnx_routinglayer metal1 900 1200 rnx_routing# Planar dielectric layersdefault_dielectric_constant 1.000000dielectric_constant 3.900000 0 1200



Unfortunately APIS does not yet know that there are special device layers used to represent transistors. Therefore, you must hand edit the technology file created by APIS and change the layer names. At this time, also move the ndiff layer back down into the substrate. Here is the technology file after editing to move ndiff back into substrate and change device layers well and ndiff to the correct type.

Note: The order of the upper and lower coordinate have been altered to ensure that the lower one always comes first.

technology mytecgrids_per_meter 1.0e9# Metal layerslayer well -100 0 st_pwell # note layer type change and location changelayer wellcon 0 900 st_routing layer ndiff -100 0 rnx_nwell # note layer type change and location changelayer difcon 0 900 rnx_routing # note location changelayer poly 300 600 rnx_routinglayer polycon 600 900 rnx_routinglayer metal1 900 1200 rnx_routing# Planar dielectric layersdefault_dielectric_constant 1.000000dielectric_constant 3.900000 0 1200

The final step is to create the Raphael NXT control file and run Raphael NXT.

The Raphael NXT control file is about the same as the others. The main difference is the -exclude_devices key on the init_extract statement. This tells Raphael NXT to ignore walks that start or terminate on the device layers. This way polygons on the device layers (pwell and ndiff) act as capacitance shields but do not contribute any capacitance to the totals. The other change is to include a set_grounded_nets_ok command with parameter -dist_rectification 100.

This command is needed since the vias for the well and diffusion touch the ground plane. This command causes Raphael NXT to ignore the lower 100 grid units of the via when calculating its capacitance. Since these vias are touching the well and diffusion regions which are at the same potential as the via, the error from ignoring this small piece of the via is insignificant.

read_tech -file mytec_edited.tecread_design -file e3.desbuild_gf_tables -zc -level 3write_gf_tables -file mytec.gf



#read_gf_tables -file mytec.gfset_boundary_box -dist_v_i 3000set_grounded_nets_ok -dist_rectification 100set_ground_level -zc -0init_extract -exclude_devices -all extract print_capacitance_report -xcap -total -gnd > e3.outuninit_extractquit

This job runs in about one minute. The following shows the output from Raphael NXT and the capacitances of the interconnect without the device capacitances, yet including the shielding effect of the source drain and well.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++Capacitance Report:---------------------------------------------------------------Net-1 Net-2 Capacitance 1-Sigma Error---------------------------------------------------------------d d 2.638965e-16 1.08%d g 9.693272e-17 2.80%d s 6.931033e-18 8.77%d w 6.800035e-17 2.66%g g 5.884542e-16 0.95%g s 9.793577e-17 2.71%g w 1.281704e-17 7.65%s s 2.265925e-16 1.15%s w 2.036343e-18 15.12%w w 2.177118e-16 1.10%+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++Report of Total Capacitances:---------------------------------------------------------------Net Capacitance 1-Sigma Error---------------------------------------------------------------d 2.638965e-16 1.08%g 5.884542e-16 0.95%s 2.265925e-16 1.15%w 2.177118e-16 1.10%+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++Report of Grounded Capacitances:---------------------------------------------------------------Net Capacitance 1-Sigma Error---------------------------------------------------------------d 9.470087e-17 3.16%g 3.813735e-16 2.77%s 1.179729e-16 2.78%w 1.353208e-16 2.49%


More Raphael NXT Design File Examples

If the simulation is run without –exclude_devices, then the total gate capacitance increases to 7.84e-16.


This example illustrates how the net-group command is used to create a single large electrical net from five smaller ones:

design two_linestechnology my_technology

# five segments for line_anet line_a.1 metal box 0 0 0 100 100 100 endnet line_a.2 metal box 100 0 0 200 100 100 endnet line_a.3 metal box 200 0 0 300 100 100 endnet line_a.4 metal box 300 0 0 400 100 100 endnet line_a.5 metal box 400 0 0 500 100 100 end

# line_a marked as a net_group composed for five nets described abovenet_group line_a line_a.1 line_a.2 line_a.3 line_a.4 line_a.5 end

# five segments for line_bnet line_b.1 metal box 0 200 0 100 300 100 endnet line_b.2 metal box 100 200 0 200 300 100 endnet line_b.3 metal box 200 200 0 300 300 100 endnet line_b.4 metal box 300 200 0 400 300 100 endnet line_b.5 metal box 400 200 0 500 300 100 end

# line_b marked as a net_group composed for five nets described abovenet_group line_b line_b.1 line_b.2 line_b.3 line_b.4 line_b.5 end

This example illustrates the use of the pincap command to attach a fixed capacitance to a net:

design design_with_pincaps

ground_net VSS

#two nets have a specified pincapnet bottom metal box 0 0 0 100 100 10 pincap 1e-14 endnet left pincap 1e-15 metal box 25 0 110 35 100 120 end#no pincap specified for these two nets



net middle metal box 45 0 110 55 100 120 endnet right metal box 65 0 110 75 100 120 end

The following design illustrates a parallel plate capacitor using planar_boxes and a technology file:


design pplatetechnology two_layernet bottom metal m1 planar_box 0 0 100 100 endnet top metal m2 planar_box 0 0 100 100 endend

#Need to ensure that a tech file is first read into#ranxt before this design file is read. The tech#file should contain m1 and m2 layers. Example of#such a tech file is given below (in commented form)##Example Tech File::##technology two_layer#layer m1 0 10 rnx_routing#layer m2 110 120 rnx_routing

The following design illustrates a parallel plate capacitor created using 3D boxes. No technology file is needed the metal since all the z coordinate information is contained in the design file. However, a technology file is still needed to specify the dielectrics:


design pplatenet bottom metal box 0 0 0 100 100 10 endnet top metal box 0 0 110 100 100 120 endend


Technology File Examples


This example illustrates a uniform technology where the dielectric is assumed to be a uniform material with dielectric constant of 1.0:

#Example of a uniform dielectric technology. ##The scale factor is 1e9, which indicates that 1e9#grid units equals 1 meter. grids_per_meter 1e9

#Name of technologytechnology uniform

#Default dielectric constant in this technology is 1.0#Also since no other dielectric layers are specified it#means that dielectric is 1.0 everywhere.default_dielectric_constant 1.0

#Description of conducting layers. This is a dummy 2 layer#technology.layer cut01 100 200 rnx_vialayer m1 200 300 rnx_routinglayer via12 300 400 tmx_vialayer m2 400 500 rnx_routing

This example illustrates a uniform technology where the dielectric is assumed to consist of multiple flat planar slabs of material. The dielectric constant does not change within each slab, but different slabs have different dielectric constants:

#Example of a technology with dielectric slabs##The scale factor is 1e9, which indicates that 1e9#grid units equals 1 meter. grids_per_meter 1e9

#Name of technologytechnology slabs


#Description of conducting layers. This is a dummy 5 layer#technology.layer cut01 100 200 rnx_vialayer m1 200 300 rnx_routing



layer via12 300 400 rnx_vialayer m2 400 500 rnx_routinglayer via23 500 600 rnx_vialayer m3 600 700 rnx_routinglayer via34 700 800 rnx_vialayer m4 800 900 rnx_routinglayer via45 900 1000 rnx_vialayer m5 1000 1100 rnx_routing


The following example illustrates a technology file with multiple conformal layers. Metal3 has a single conformal coating while metal4 and metal5 each have two conformal coatings:

#Example of a technology with multiple conformal layers##The scale factor is 1e9, which indicates that 1e9#grid units equals 1 meter. grids_per_meter 1e9

#Name of technologytechnology double_conformal


#Description of conducting layers. This is a dummy 5 layer#technology.layer cut01 100 200 rnx_vialayer m1 200 300 rnx_routinglayer via12 300 400 rnx_vialayer m2 400 500 rnx_routinglayer via23 500 600 rnx_vialayer m3 600 700 rnx_routinglayer via34 700 800 rnx_vialayer m4 800 900 rnx_routinglayer via45 900 1000 rnx_via


Resistance Extraction Example

layer m5 1000 1100 rnx_routing


#Description of conformal layers.#There are conformal layers on M3, M4 and M5.conformal_layer conf_m3 m3 10 10 0 8.2conformal_layer conf_m4 m4 10 10 0 8.2conformal_layer conf_m5 m5 10 10 0 8.2

#Description of second conformal layer.#There are double conformal layers on M4 and M5.conformal_layer second_conf_m4 conf_m4 15 15 0 4.0conformal_layer second_conf_m5 conf_m5 15 15 0 4.0


Note: Resistance extraction functionality is limited in this release, refer to Chapter 2, for more details.

This simple example demonstrates the usage of resistance extraction capability of Raphael NXT. The structure is two layers of conductors connected by a via. The resistivity of via layer is 8.5e-8 ohm*meter, which is different with the value of routing layers (1.7e-8 ohm*meter).

To run the case, you must generate four files:■ Technology file res_example.res

Notice how the resistivity of each layer is specified:

technology res_example_tecgrids_per_meter 1e9default_dielectric_constant 1.0layer m1 0 100 1.7e-8 st_routinglayer v1 100 200 8.5e-8 st_routinglayer m2 200 300 1.7e-8 st_routing



■ Design file res_example.des

design res_example_destechnology res_example_tecnet AAA

metal m1 planar_box001000200metal v1 planar_box70050800150metal m2 planar_box50001500200end

end

■ Contact file res_example.res. The contacts represent ideal (zero resistance) connections to the metal layers. A resistance matrix will be extracted at the specified ports.

contact a -10 0 0 200 m1contact c 1500 0 1510 200 m2port two a c

■ Control file res_example.cfg. Here we tell RANXT to read the previous three files and extract the resistance. Note that the grid_size parameter has a strong effect on run time with a smaller grid_size resulting in longer, more accurate runs.

read_tech -file res_example.tecread_design -file res_example.desread_contacts -f res_example.reresistance_extract -grid_size 10

The port resistance between contact a and contact c extracted from Raphael NXT will be 2.173 ohms.


raphael nxt user guide - · raphael nxt distribution also contains taurus layout which can be used...

Documents