EPIC Tools Reference Guide

EPIC Tools 

Reference Guide 

Release 5.4, January 2000 

Comments? 

E-mail your comments about Synopsys 

documentation to doc@synopsys.com

Copyright Notice and Proprietary Information 

Copyright © 2000 Synopsys, Inc. All rights reserved. This software and documentation contain confidential and proprietary 

information that is the property of Synopsys, Inc. The software and documentation are furnished under a license agreement and may 

be used or copied only in accordance with the terms of the license agreement. No part of the software and documentation may be 

reproduced, transmitted, or translated, in any form or by any means, electronic, mechanical, manual, optical, or otherwise, without 

prior written permission of Synopsys, Inc., or as expressly provided by the license agreement. 

Right to Copy Documentation 

The license agreement with Synopsys permits licensee to make copies of the documentation for its internal use only. Each copy shall 

include all copyrights, trademarks, service marks, and proprietary rights notices, if any. Licensee must assign sequential numbers to 

all copies. These copies shall contain the following legend on the cover page: 

“This document is duplicated with the permission of Synopsys, Inc., for the exclusive use of 

__________________________________________ and its employees. This is copy number __________.” 

Destination Control Statement 

All technical data contained in this publication is subject to the export control laws of the United States of America. Disclosure to 

nationals of other countries contrary to United States law is prohibited. It is the reader’s responsibility to determine the applicable 

regulations and to comply with them. 

Disclaimer 

SYNOPSYS, INC., AND ITS LICENSORS MAKE NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, WITH REGARD TO 

THIS MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR 

A PARTICULAR PURPOSE. 

Registered Trademarks 

Synopsys, the Synopsys logo, AMPS, Arcadia, CMOS-CBA, COSSAP, Cyclone, DelayMill, DesignPower, DesignSource, DesignWare, 

dont_use, Eagle Design Automation, Eaglei, EPIC, ExpressModel, Formality, in-Sync, Logic Automation, Logic Modeling, Memory 

Architect, ModelAccess, ModelTools, PathBlazer, PathMill, PowerArc, PowerMill, PrimeTime, RailMill, SmartLicense, SmartModel, 

SmartModels, SNUG, SOLV-IT!, SolvNET, Stream Driven Simulator, Synthetic Designs, TestBench Manager, and TimeMill are 

registered trademarks of Synopsys, Inc. 

Trademarks 

ACE, Behavioral Compiler, BOA, BRT, CBA, CBAII, CBA Design System, CBA-Frame, Cedar, Chip Architect, Chronologic, CoreMill, 

DAVIS, DC Expert, DC Expert Plus, DC Professional, DC Ultra, DC Ultra Plus, Design Advisor, Design Analyzer, DESIGN (ARROWS), 

Design Compiler, DesignTime, DesignWare Developer, Direct RTL, Direct Silicon Access, dont_touch, dont_touch_network, DW 8051, 

DWPCI, Eagle, EagleV, ECL Compiler, ECO Compiler, Falcon Interfaces, Floorplan Manager, Foundation, FoundryModel, FPGA 

Compiler, FPGA Compiler II, FPGA Express, Frame Compiler, Fridge, General Purpose Post-Processor, GPP, HDL Advisor, HDL 

Compiler, Integrator, Interactive Waveform Viewer, Liberty, Library Compiler, Logic Model, MAX, ModelSource, Module Compiler, MS- 

3200, MS-3400, Nanometer Design Experts, Nanometer IC Design, Nanometer Ready, Odyssey, PowerCODE, PowerGate, Power 

Compiler, ProFPGA, ProMA, Protocol Compiler, RMM, RoadRunner, RTL Analyzer, Schematic Compiler, Shadow Debugger, Silicon 

Architects, SmartModel Library, Source-Level Design, SWIFT, Synopsys Graphical Environment, Synopsys ModelFactory, Test 

Compiler, Test Compiler Plus, Test Manager, TestGen, TestSim, TetraMAX, TimeTracker, Timing Annotator, Trace-On-Demand, VCS, 

VCS Express, VCSi, VERA, VHDL Compiler, VHDL System Simulator, Visualyze, VMC, and VSS are trademarks of Synopsys, Inc. 

Service Marks 

TAP-in is a service mark of Synopsys, Inc. 

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

Printed in the U.S.A. 

Document Order Number: 32669-014 HB 

EPIC Tools Reference Guide, Release 5.4

EPIC Tools Reference Guide 

Table of Contents 

About This Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi 

1 Introduction 

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 

2 EPIC Netlist Format 

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 

Syntax Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 

Buses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 

Characters Not Permitted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 

Element and Attribute Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 

Using Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 

Port Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 

Circuit Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 

Capacitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 

Floating Capacitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 

Inductor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 

Bipolar Junction Transistors and Junction Diodes. . . . . . . . . . . . . 17 

BJT Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

iv Table of Contents 

Diode Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 

Reading Diodes as Capacitors . . . . . . . . . . . . . . . . . . . . . . 20 

CMOS Transistor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 

Resistor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 

Voltage Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 

SIN Voltage Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 

EXP Voltage Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 

AM Voltage Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 

SFFM Voltage Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 

Voltage Controlled Voltage Sources . . . . . . . . . . . . . . . . . . . . . . . . 32 

Subcircuit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 

Hierarchical Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 

Net . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 

Gate-level Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 

Timing Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 

SETUP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 

HOLD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 

Edge to Edge (ETOE). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 

Pulse Width (PULSEW). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 

Global Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 

Global Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 

Global Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 

Power and Ground Aliases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 

Netlist Control Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 

Control Option Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 

Option Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 

Parameter Passing in Netlists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 

Parameter Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 

Parameter Passing Using HSPICE Rules . . . . . . . . . . . . . . . . . . . . 71 

General Usage Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 

Functions and Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 

Other Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 

Initial Condition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 

PWL Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 

Sense Pair . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 

Include Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

3 Netlist Compiler and Translators 

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 

Compiled Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 

LSIM Netlist Features and Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 

SPICE Netlist Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 

HSPICE Netlist Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 

General Control Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 

Input File Control Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 

Analysis Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 

Output Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 

Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 

Cadence SPF File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 

SPF Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 

SPF Control Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 

SPF Netlist Reader Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 

Source-to-Drain Checking . . . . . . . . . . . . . . . . . . . . . . . . . 92 

Common SPF Warnings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 

Connectivity Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 

Duplicate Global Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 

Net Does Not Exist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 

Hierarchical SPF Back-Annotation. . . . . . . . . . . . . . . . . . . . . . . . . 94 

Device Parameter Format File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 

EPIC Binary File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 

Control Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 

SPICE Netlist Translator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 

Model File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 

Alias File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 

Default File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 

Diodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 

Resistors and Capacitors . . . . . . . . . . . . . . . . . . . . . . . . . 107 

Default File Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 

spice2e Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 

Command Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 

Command-line Options . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 

Supported SPICE Netlist Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 114 

v 

EPIC Tools Reference Guide

vi Table of Contents 

Ignored SPICE Netlist Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 

SPICE Netlist Syntax to Avoid . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 

Substrate Terminal Bias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 

EDIF Netlist Translator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 

Supported EDIF Constructs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 

Unsupported EDIF Constructs . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 

edif2e Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 


Verilog Netlist Translator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 

vlog2e Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 


The Ecrypt Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 

Level-One Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 

Command Syntax for Level-One Encryption. . . . . . . . . . . . . . . . . 132 

Level-Two Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 

Command Syntax for Two-Level Encryption . . . . . . . . . . . . . . . . 132 

Tutorial: Performing a Level-Two Encryption . . . . . . . . . . . . . . . 133 

Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 

4 EPIC Technology File 

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 

Automatic Technology File Generation . . . . . . . . . . . . . . . . . . . . . . . . . . 140 

Specifying Automatic Technology File Generation . . . . . . . . . . . . 140 

Modifying the Netlist. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 

Running a Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 

Creating a Runscript . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 

Gentech . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 

Sample Control Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 

HSPICE Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 

Example of Other SPICE Types . . . . . . . . . . . . . . . . . . . . 156 

Gentech Control File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 

Section 1 - %lib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 

Section 2 - %model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 

Section 3 - %parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 160

Section 4 - %corner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 

Section 5 - %invoke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 

Section 6 - %options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 

Section 7 - %diode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 

Running Gentech. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 

Gentech Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 

Single-Step and Multiple Step (Batch) Modes . . . . . . . . . 201 

Using Multiple Technology Files. . . . . . . . . . . . . . . . . . . . . . . . . . 204 

Temperatures and Voltages . . . . . . . . . . . . . . . . . . . . . . . 204 

PrintWL Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 

The Technology File Viewer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 

Veritech Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 

Running Veritech. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 

After Running Veritech . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 

If Veritech Aborts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 

5 Stimuli and State Checking 

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 

Stimulus Functions and Vector Functions . . . . . . . . . . . . . . . . . . . . . . . . 219 

Function Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 

Output State Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238 

Vector File Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 

Time Value. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 

Data Vectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 

Continuing Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 

Valid States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 

Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 

Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 

Running the Vector File Using type and signal Commands. . . . . 247 

State Characters Used by EPIC Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . 248 

Logic States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248 

Input Stimulus Characters in Vector Files . . . . . . . . . . . . . . . . . . 251 

Expected Output Characters in Vector Files . . . . . . . . . . . . . . . . 252 

vii 


viii Table of Contents 

6 batchrun Program 

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 

Distributed Computing Capability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 

Batchfile Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261 

Batchfile Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264 

7 Utilities for Dynamic EPIC Tools 

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267 

Meas Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267 

Command Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268 

Command-line Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268 

Edisplay Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269 



Edisplay Control File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 

Eview Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276 



Window Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278 

Menu Bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278 

Text Display Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284 

Message Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284 

Eview Control File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284 

Waveform Display Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285 

SimWave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286 

turboWave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286 

Vector Translation Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287 

Vcd2e Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287 

Command Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288 


Vcd2e Window Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . 289 

Signal Save File Format . . . . . . . . . . . . . . . . . . . . . . . . . . 294 

Translating a File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296

Batch Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298 

Appendix A: Customization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299 

Customizing EPIC Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299 

Customizing Wire Capacitance Estimate . . . . . . . . . . . . . . . . . . . . . . . . 302 

Appendix B: Output Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311 

The .out File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311 

The .act File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324 

The .nact File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326 

The .nodealias File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328 

Warning Messages and the .log File . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330 

Appendix C: Error Output File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331 

The .err File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331 

The Viewerror Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349 



Appendix D: SPICE-independent Voltage Source Syntax . . 351 

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359 

ix 


x Table of Contents

About This Manual 

EPIC Tools Reference Guide describes EPIC utilities and 

features common to EPIC Tools. 

For information on: See: 

A general overview of the 

utilities and features 

The content, format and 

syntax of commands that are 

used in the EPIC circuit 

description file. 

Compiled files, SPICE netlist 

and translator, EDIF netlist 

translator, Verilog netlist 

translator, and the Ecrypt 

utility 

Generating, verifying, and 

viewing technology files 

Stimulus functions; output 

state comparison, and state 

characters used by EPIC 

Tools 

Running TimeMill, PathMill, 

PowerMill, or AMPS in batch 

mode 

Chapter 1, “Introduction” 

Chapter 2, “EPIC Netlist 

Format” 

Chapter 3, “Netlist Compiler 

and Translators” 

Chapter 4, “EPIC Technology 

File” 

Chapter 5, “Stimuli and State 

Checking” 

Chapter 6, “batchrun 

Program”

xii About This Manual 

Audience 

Related Manuals 

For information on: See: 

PowerMill and TimeMill 

simulation output utilities 

This manual is for users of EPIC Tools. 

The following Synopsys manuals in the EPIC tool set provide 

information specific to each EPIC Tool: 

■ PathMill Reference Guide 

■ PathMill User Guide 

■ PowerMill Reference Guide 

■ PowerMill User Guide 

■ RailMill Reference Guide 

■ RailMill User Guide 

■ TimeMill Reference Guide 

■ TimeMill User Guide 

■ AMPS Reference Guide 

■ AMPS User Guide 

The following Synopsys manuals provide further information 

about some of the utilities described in this manual: 

■ turboWave Manual 

Chapter 7, “Utilities for 

Dynamic EPIC Tools” 

Customizing EPIC Tools Appendix A, “Customization” 

Samples of different output 

files. 

Appendix B, “Output Files” 

Sample output error file and 

Viewerror utility 

SPICE-independent voltage 

source syntax supported by 

PowerMill, TimeMill, and 

AMPS 

Appendix C, “Error Output 

File” 

Appendix D, “SPICEindependent 

Voltage Source 

Syntax”

Conventions 

Commands 

■ SimWave Manual 

■ VTRAN Manual 

This manual uses certain style conventions to indicate 

commands, menus, examples, and filenames. 

SYNTAX: 

command_name [argument(s)] 

argument types: keyword | value | tag=value | tag=keyword 

Command Argument Definition 

keyword Keywords are identifiers that must be 

used as they appear. They are shown in 

base font. 

value Values are user-determined. They are 

shown in italic text to distinguish them 

from commands and keywords. 

tag= 

value 

keyword 

Tags can be followed by either a value or a 

keyword. Tags and keywords are in the 

base font. Argument values are in italics 

to distinguish them from commands, 

keywords, and tags. 

xiii 


xiv About This Manual 

Symbol Definition 

| A pipe symbol (|) represents the word “or” and separates choices 

between two or more arguments. 

[ ] Square brackets show that an argument is optional. Nested brackets 

(e.g.]]]]) indicate that if a value is assigned to a given parameter, 

values must also be assigned to preceding parameters. (Nested 

brackets are used only for SPICE-independent voltage source 

functions.) 

... An ellipsis (...) indicates that more than one argument can be 

specified. Ellipsis are used only for multiple arguments with tags. 

SYNTAX: 

report_node_i a[vg] | r[ms] | p[eak] | h[ist] node_name(s) 

For this command, a[vg], r[ms], p[eak], and h[ist] are keywords– 

choose one of these. The node_name(s) are user-determined. 

EXAMPLE 1: 

report_node_i a VDD GND 

In this example, a is a keyword, and VDD and GND are values. 

SYNTAX: 

report_node_ic [a[ll]] [q[uoted]] [for=epic | spice] [time(s)] 

For this command, a[ll] and q[uoted] are optional keywords. The 

tag for= is part of an optional argument for which you can choose 

the keyword epic or spice. The time(s) are user-determined and, 

in this case, optional. 

EXAMPLE 2: 

report_node_ic all for=spice 1u 

In this example, all is a keyword, for= is a tag, spice is a 

keyword, and 1u is a value.

Menu Text, Filenames, and Examples 

Menu text appears in bold, as shown in the following example. 

EXAMPLE 1: 

To start setting up a run, select File→Design Data 

Setup. 

Filenames are shown in the same font as the surrounding text, 

but in italics. 

EXAMPLE 2: 

This is an example of a filename.out being shown in 

text. 

Examples are shown in a courier font as they might appear on 

your screen. Sometimes explanations follow examples, and in 

such cases, anything shown in the example that appears in the 

explanation is shown in the same courier font used in the 

example. 

EXAMPLE 3: 

add_node_cap RS100 275 

In the example, the capacitance value of node RS100 is increased 

by 275 femtofarads. 

xv 


xvi About This Manual

Chapter 1 

Introduction

2 Chapter 1 Introduction

Overview 

Overview 3 

The EPIC Tools Reference Guide provides detailed information 

about the EPIC technology underlying the operations performed 

by EPIC tools. It also contains information about how to use 

various EPIC utilities to generate, interpret, and evaluate 

simulations. Some of the information contained in this guide 

pertains to the full set of EPIC tools, while other material is 

relevant to specific products. 

The EPIC circuit description, or netlist, is one of several netlists 

supported by EPIC that can be used as input to the simulation 

and analysis tools. An entire chapter is dedicated to providing 

detailed information about EPIC circuit elements, timing checks, 

parameter passing, and other components and factors involved 

in setting up the EPIC netlist. Information about the EPIC 

netlist is found in Chapter 2. 

The EPIC netlist compiler supports LSIM, SPICE, Verilog, EDIF, 

and Cadence SPF netlist formats, in addition to its own. It reads 

LSIM and SPICE netlists directly and can translate Verilog and 

EDIF netlists to EPIC format for reading. You can use the Ecrypt 

utility to produce encrypted files. Detailed information about 

how the compiler processes these netlists when working with 

EPIC tools is provided. The netlist compiler is documented in 

Chapter 3. 

EPIC tools use the EPIC technology files to calculate timing and 

power behaviors. These files are created by the Gentech utility, 

which either generates them automatically or extracts them 

from your SPICE. EPIC also provides a utility for verifying the 

accuracy of the generated technology files. The Veritech utility 

runs both your SPICE and an EPIC tool for purposes of 

comparison. Another utility, TechViewer, lets you view an EPIC 

technology file in a graphical format. See Chapter 4 for 

information about these utilities. 

Stimulus and monitoring functions for the dynamic EPIC tools 

(such as PowerMill and TimeMill) are documented in Chapter 5. 


4 Chapter 1 Introduction 

These functions generate input signals to stimulate a circuit, 

and output vectors used to compare simulated to expected 

results. 

Four EPIC tools (TimeMill, PathMill, PowerMill, and AMPS) can 

be run in batch mode. Information about how to use the batchrun 

program is presented in Chapter 6. 

EPIC provides utilities to measure and display simulation 

results. The Meas utility computes the results of .measure 

statements. The Edisplay and Eview utilities measure timing 

results. The waveform display utilities, SimWave and 

turboWave, are also available for your use. EPIC also provides 

two vector translation utilities to translate different types of 

vector formats into EPIC vector format. Information about how 

to use these utilities is described in Chapter 7. 

Appendix A presents detailed information about customizing 

EPIC tools. 

Appendix B explains the formats of the different output files 

generated by EPIC tools. 

Errors encountered during simulation return very detailed 

messages, giving you all the information you need to correct the 

problem. The Viewerror utility is available as an alternate 

method of viewing simulation errors and generating error 

reports. Information about error messages and formats is 

presented in Appendix C. 

Appendix D provides the SPICE-independent voltage source 

syntax supported by PowerMill, TimeMill, and AMPS.

Chapter 2 

EPIC Netlist Format

6 Chapter 2 EPIC Netlist Format

Overview 

Syntax Conventions 

Overview 7 

EPIC uses a unique circuit description to describe circuits. This 

format, the EPIC netlist, is one of several possible netlists that 

can be used as input to EPIC simulation and analysis tools. 

The netlist lists system elements, including single transistors, 

gates, resistors, instantiations of subcircuits, functional models, 

and output probing functions. These elements can be connected 

by input or output nodes to form a network. 

System connectivity is established through the common input, 

output, and biput I/O nodes between the circuit elements. 

This chapter describes the content and of the EPIC netlist, as 

well as the commands and control options you can use. 

You must follow these syntax rules and conventions when 

creating an EPIC netlist: 

■ The maximum length of a name in a netlist (including an 

explicit or implicit hierarchical name) is 1023 characters. An 

error message is generated if you exceed this limit. 

■ A line can be broken at any point, but the break is treated 

like a blank space. You cannot break a line in the middle of a 

name. The backslash (\) is not recognized as a continuation 

character. 

■ Parameter names must start with a letter and can contain 

only letters, digits, underscores (_), and percent signs (%). 

■ Each circuit element is defined by an element identifier 

followed by a list of attributes, and ends with a semicolon (;). 

■ Each attribute consists of an identifier followed by an equal 

sign (=) and the assigned circuit description, all enclosed in a 

pair of parentheses (()). 


8 Chapter 2 EPIC Netlist Format 

Buses 

■ All the items in a statement are case-sensitive. 

■ Spaces are allowed between items. 

■ Comments use the C language syntax. They begin with /* and 

close with */. 

Buses are specified with the sig_name command followed by an 

argument in square brackets ([ ]) giving the range. 

EXAMPLE: 

sig_name[15-0] 

The square brackets following sig_name indicate it is a bus. The 

value 15-0 specifies the width, with the most significant bit first 

and least significant bit last. Bus notation can be modified with 

the ctrl_opt statement. See “Control Option Syntax” on page 46. 

A negative index is allowed in a bus, as shown in the following 

example. 

EXAMPLE: 

bus[-1-7] => bus[-1], bus[0], .., bus[7] 

bus[0--3] => bus[0], bus[-1], bus[-2], bus[-3]

Characters Not Permitted 

Syntax Conventions 9 

The following characters are not permitted in any name: 

; (semicolon) : (colon) 

, (comma) ‘ (single quotation mark) 

{ } (curly brackets) “ (double quotation marks) 

= (equal sign) ( ) (parentheses) 

The following characters are not permitted in node or element 

names: 

- (minus sign) . (period) 

Transistor names cannot begin with the following characters: 

C c 

E e 

L l 

R r 

V v 

These characters causes the transistor to be recognized as a 

voltage-controlled voltage source. 



Element and Attribute Identifiers 

This section contains a list of EPIC element and attribute 

identifiers. The element identifiers specify the type of function 

being defined. 

Element 

Definition 

Identifier 

b Bipolar junction transistor (BJT) or junction diode. 

ef Element function that starts a library function or a 

transistor-level subcircuit. 

is Input stimulus signal. 

os Output signal for display. 

t Transistor, resistor, floating capacitor, or inductor. 

c Capacitor. 

The attribute identifiers indicate input and output pins, the 

internal state information, and any properties associated with 

the element. 

Attribute 

Identifier Definition 

en Element name or instance name of an element in a 

system. Each (en=element_name) must be unique for 

a given level. Do not use a period in the element 

name. 

it Input terminals or nodes of the element. 

ot Output terminals or nodes of the element. 

bt Specifies biput terminals or nodes of the element. 

This identifier can be an input or output terminal, 

depending on the circuit response.

Using Identifiers 

Attribute 

Identifier Definition 

Element and Attribute Identifiers 11 

st Number of states for an element. This identifier 

represents the number of memory words allocated 

when you include the element as an instance. It 

corresponds to the number of internal states in a 

functional model, and the number of entities or 

variables used in the sv field of a library function 

input stimulus signal. 

nn Node name. This identifier is used with the 

capacitance or node specification. 

ov Initial element output value. 

bv Initial element biput value. 

sv Element state value, or element parameter value, 

using the following syntax: 

% (sv=value{,value}) 

m Multiplier for the element: 

% (m=5) 

attr Optional attribute for an element. Currently, it is 

used only for controlling the driving impedance of 

functional models. See netlist_suffix for details. 

The following rules apply to using identifiers: 

■ (st=value) is optional. 

■ (st value) and (sv= ...) can be used only for (ef=...) and 

(is = ...). If used elsewhere, you will get an error message. 

■ If (sv=n_items) is specified and no (st=...) is given, n states 

are assigned in the .elm file. 

■ If (st=m) is specified and no (sv=...) is given, the number of 

states is equal to m states. 



Port Mapping 

■ If both (st=m) and (sv= n_items) are specified, max (m,n) 

states are assigned. If (m>n) then the state values for 

(state[i] | i>n) is assigned a default value of 0. 

■ The parameter names can be specified in any order. 

■ Error messages are returned when: 

◆ Keywords are misspelled or used incorrectly. 

◆ Connectivity errors are encountered. 

There are two methods of port mapping between an ADFMI 

model and the corresponding netlist: position-based port 

mapping (implicit) and name-based port mapping (explicit). 

When using implicit port mapping, the order in which you define 

the ports in your model establishes the port order in the circuit. 

In explicit port mapping, specific names identify which ports are 

to be mapped to which terminals. Figure 1 shows two excerpts 

from sample EPIC netlists. One uses implicit port mapping, the 

other uses explicit port mapping. An excerpt from the 

corresponding model file is also shown.

(ef=DFF)(en=dff_fun)(it=i1,i2,i3) 

Excerpt from EPIC netlist using 

implicit port mapping 

(ef=DFF)(en=dff_fun)(it=IN1(i1), IN2(i2), IN3(i3)); 

Excerpt from EPIC netlist using 

explicit port mapping 

Figure 1 Explicit and implicit port mapping in an EPIC netlist 

Element and Attribute Identifiers 13 

... 

RegisterUserModel() 

{ 

fmDefineModel(“DFF”, dff_ 

fmDefinePort(body,”IN1”, 



... 

} 

Excerpt from ADFMI model file 

For implicit port mapping to work correctly, the order in which 

the ports are listed in the EPIC netlist must be the same as the 

order in which they are defined in the model file. Conversely, 

explicit port mapping is not dependent on the port order, but 

instead identifies the correct mapping using names (IN1 always 

corresponds to i1 regardless of the order in which the ports are 

listed in the netlist). Therefore, using explicit port mapping can 

reduce the occurrence of errors in port mapping. 

NOTE: If you are using SPICE netlists, you can use only implicit port 

mapping. 

If you are using ADFMI modeling with a variable bus (that is, if 

your model file contains an fmDefineVBusPort() function) you 

must always use explicit port mapping. 



Circuit Elements 

Capacitor 

This section explains the EPIC netlist format for the following 

kinds of circuit elements: 

Capacitor 

Floating Capacitor 

Inductor 

Bipolar Junction Transistors and Junction Diodes 

CMOS Transistor 

Resistor 


Voltage Controlled Voltage Sources 

Subcircuit 

Net 

Gate-level Element 

SYNTAX: 

(c=cap_value) (nn=node_name) (m=mult_value); 

EXAMPLE: 

(c=100)(nn=APLL); 

In the example, 0.1 pF capacitance is loading node APLL. 

DESCRIPTION: 

You can specify capacitance value inside a subcircuit or in a toplevel 

definition. When specified in the top level, you can use the 

hierarchical node name. 

You can also specify capacitance with configuration file 

commands. You can use the node_capacitance command to add 

the extracted capacitances from layout data. See the

Floating Capacitor 

Circuit Elements 15 

configuration file command reference for the EPIC tool you are 

using. 


c= 

SYNTAX: 

cap_value 

nn= 

node_name 

m= 

mult_value 

(t=C|c) (en=instance_name) (so=node1) (dr=node2) (fc=value); 

EXAMPLE: 

(t=c)(en=cap1)(so=N1)(dr=N2)(fc=10); 

This example describes a 0.01 pF capacitor between nodes N1 

and N2. 

DESCRIPTION: 

Specifies the value in femtofarads 

that represents the capacitance to 

power or ground. The value can be 

an expression. 

Names the node to which the 

capacitance is attached. 

Specifies a multiplier that causes 

the capacitor to be treated as 

multiple value capacitors connected 

in parallel. 

A floating capacitor is a capacitor that is not connected to a 

voltage or ground node. Floating capacitors are described in the 

EPIC netlist as a different element type with specific netlist 

syntax. 

Although you can simulate the coupling effect for every floating 

capacitor in the circuit, this is not recommended for large 

circuits because it will severely slow the simulation. A more 

practical approach is to model and simulate the coupling effect 

for floating capacitors critical to circuit functionality. Examples 

occur in charge-pump operation or in critical paths where the 

associated Miller effect is critical to path delay. Features and 



Inductor 

commands are provided for you to selectively model and simulate 

the coupling effect of floating capacitors. 

NOTE: PathMill does not accept floating capacitors. Floating capacitors 

need to be split using the ctrl_opt split_floating_cap control 

command. However, PathMill with the Crosstalk Extension 

(CTX) accepts floating capacitors. 


t= 

C | c 

en= 

instance_name 

so= 

node1 

dr= 

node2 

fc= 

value 

SYNTAX: 

Element type. Use either C or c for a 

floating capacitor. 

Capacitor instance name. 

First terminal name. 

Second terminal name. 

Capacitance value in femtofarads. 

(t=L)(en=element_name)(so=node_1)(dr=node_2)(l=ind_value) 

(m=mult_value); 

EXAMPLE: 

(t=L)(en=l12)(so=141)(dr=out)(l=13); 

The example describes an inductor called 112, with nodes 141 

and out, and a capacitance value of 13 nanoHenrys.

DESCRIPTION: 


You use this syntax when specifying an inductor in an EPIC 

netlist. 

Bipolar Junction Transistors and Junction Diodes 

BJT Element 


en= 

element_name 

so= 

node_1 

dr= 

node_2 

l= 

ind_value 

m= 

mult_value 

This section explains the syntax used for bipolar junction 

transistors and diodes. 

SYNTAX: 

Inductor name. 

Node that connects the inductor. 

Second node that connects the 

inductor. 

Inductance value (nH). 

Multiplier value (default =1). 

(b = model_name)(en = tran_name)(ba = base_nodename) 

(co=collector_nodename)(em=emitter_nodename) 

[(bu=bulk_name)] (ar = value); 

EXAMPLE: 

(b=pnp)(en=q1)(co=c)(ba=b)(em=e)(ar=2.5); 

This example describes a bipolar transistor q1 with an area 

factor of 2.5. 



DESCRIPTION: 

Diode Element 

This syntax specifies a bipolar transistor. 


b= 

model_name 

en= 

tran_name 

ba= 

base_nodename 

co= 

collector_nodename 

em= 

emitter_nodename 

bu= 

bulk_name 

ar= 

value 

SYNTAX: 

Specifies the name of the Bipolar 

model matching the name in the 

model file 

Transistor instance name 

Base node name 

Collector node name 

Emitter node name 

Bulk node name 

Area factor of the transistor 

(default = 1) 

(b=model_name)(en=diode_name)(ba=anode_node) 

(co=cathode_node)(ar=value)(pj=value); 

or 

(b=model_name)(en=diode_name)(ba=anode_node) 

(em=cathode_node)(ar=value)(pj=value);

DESCRIPTION: 


The syntax specifies a junction diode. The diode levels are: 

■ Level 1: non-geometric diode. ar and pj are unit-less factors; 

cjo and cjswo in the diode models are F/unit-area and 

F/unit-periphery. 

■ Level 3: geometric diode. ar and pj are area and periphery 

with units. 


b= 

model_name 

en= 

diode_name 

ba= 

anode_node 

co= 

cathode_node 

em= 

cathode_node 

ar= 

value 

pj= 

value 

Diode model name, which matches 

the name in the model file. 

Diode instance name. 

Anode (base) node name. 

Cathode (collector) node name. 

Cathode (emitter) node name. 

Area factor of the diode (default = 1). 

If a Level 3 diode model is used, this 

value is in units of 10 -16m2 . 

Periphery junction of the diode 

(default = 0). If a Level 3 diode 

model is used, this value is in units 

of 10-8 meters. 



The EPIC netlist compiler reads the SPICE diode model 

statement from the netlist. This model must precede diode 

instances. 

If you assign the model statement: The EPIC netlist compiler: 

Level 1 Identifies the diode as a 

junction diode. 

Level 2 Discards the diode. 

Level 3 Converts the diode to a 

capacitor. 

Reading Diodes as Capacitors 

By default, the EPIC netlist compiler converts all diodes to 

capacitors, using the diode model to calculate values. However, 

the control option keep_junc_diode assigns a Level 1 value to 

the diodes. The ACE option can simulate these diodes using the 

bjt.mod diode model. 

The EPIC netlist compiler looks for a .model card for the 

specified diode before instantiating the diode. If you use an EPIC 

format netlist, the .model card must be in a separate HSPICE 

netlist with a filename extension of .spi because the compiler 

accepts only a .model card in an HSPICE netlist. 

For example, to simulate in TimeMill the circuit PLL with an 

EPIC format netlist, the diode model can be specified in a file 

named diode.spi. TimeMill then starts with the following 

command line: 

timemill -n diode.spi PLL -p tech.file 

If there is no .model card, all diodes are assumed to be diodes 

because there is no way to tell if the diode is level 1 or 3. You 

must have an ACE license to simulate these diodes. ar and pj 

are assumed to be unit-less values.

CMOS Transistor 


Level 1 diode 

If a level 1 model card is provided, the diode is converted to a 

capacitor with a value determined by the formula 

(cjo)(ar)+(cjswo)(pj), where ar and pj are the unit-less area 

and periphery factors, respectively. 

Level 3 diode 

If the .model card specifies a level 3 diode, the conversion to a 

capacitor will use the same equation, except that ar and pj are 

in units of 10-16m2 and 10-8m, since the cjo and cjswo units in 

the model file will be in terms of capacitance/area and 

capacitance/length. 

SYNTAX: 

(t=tran_model_name|$para_model_name$) 

(en=tran_instance_name)(ga=gate_name) 

(so=source_name) (dr=drain_name)[(bu=bulk_name)] 

(w=wvalue)(l=lvalue) 

[(di=s2d|d2s|bid|value)] 

[(as=asvalue)][(ad=advalue)] 

[(geo=geovalue)] 

[(ps=psvalue)][(pd=pdvalue)] 

[(nrd=num_drain_sqs)] 

[(nrs=num_source_sqs)] 

[(m=mult_value] 

EXAMPLE 1: 

(t=N)(en=n12)(ga=bus5)(so=out2)(dr=gnd) 

(w=2000)(l=200); 

(t=P)(en=p105)(ga=bus5)(so=out2)(dr=vdd) 

(w=500)(l=200)(di=d2s); 

These statements define a 20μ/2μ N-type transistor as n12 and a 

5μ/2μ P-type transistor as p105. For the p105 transistor, the 



direction of the path search has been set from drain to source, 

node vdd to out2. In this example, as, ad, ps and pd are not 

specified, thus requiring the simulator to use the diffusion 

extension in the technology file to estimate these values. 

EXAMPLE 2: 

(t=P)(en=p1)(ga=A)(so=vdd)(dr=Z)(w=2000)(l=200) 

(as=1000000)(ad=1000000)(ps=3000)(pd=3000); 

(t=N)(en=n1)(ga=A)(so=gnd)(dr=Z)(w=200)(l=200) 

(as=100000)(ad=100000)(ps=1200)(pd=1200); 

These statements define a 20μ/2μ P-type transistor as p1 and a 

2μ/2μ N-type transistor as n1, both with areas and perimeters as 

specified. 

DESCRIPTION: 

The syntax defines N-type and P-type transistors. Depletion Ntype 

and P-type transistors are defined using the same syntax. 

NOTE: Depletion mode transistors are not supported by PathMill. 


t= 

t= 

tran_model_name 

$para_model_name$ 

en= 

tran_instance_name 

ga= 

gate_name 

Specifies the transistor model 

name defined in the technology 

file. The name cannot begin with 

the following characters, in 

either upper- or lowercase: C, E, 

L, R, or V. 

If the name starts and ends with 

$, it is a parametric model name. 

The parametric model name is 

resolved in the same way as an 

ordinary parameter except that 

its final value is a model name. 

Transistor instance name. 

Gate node name.


so= 

source_name 

dr= 

drain_name 

bu= 

bulk_name 

w= 

wvalue 

l= 

lvalue 

Source node name. 

Drain node name. 

Bulk node name. 


Specifies values for channel 

width and length of transistors 

in .01 micron units. The defaults 

are w=1000 if the width is not 

specified, and l=200 if the length 

is not specified. Both values can 

be expressions. 




di= 

s2d | d2s|bid|value 

Specifies the direction for path 

searches. 

The value d2s is used if the 

signal flow direction is from the 

drain to the source; s2d is used 

if the direction is from source to 

drain; bid is used if the 

direction is bi-directional. 

The value can also be a number. 

The values can be 0 

(bidirectional), 1 (drain to 

source), or 2 (source to drain). 

This parameter is ignored if 

specified for TimeMill or 

PowerMill. 

Signal direction is not always 

required for PathMill because 

PathMill handles bidirectional 

signal flow. However, for certain 

kinds of circuits, such as barrel 

shifters, which have a large 

number of pass transistors and 

circuit branches, the direction 

settings are required for 

PathMill. If you know the signal 

flow direction, specifying it can 

speed up the path search process 

considerably.


as= 

asvalue 

ad= 

advalue 

geo= 

geovalue 


Specifies the area of the source 

diffusion in units of 10-16m2 . 

The value is used for calculating 

diffusion capacitance. If not 

specified, the default is the 

effective width times the 

effective diffusion extension, 

which is defined in the 

technology file. The default 

equation can be edited in the 

customize.c module. See 

Appendix A. 

Specifies the area of the drain 

diffusion in units of 10-16m2 . 



specified, the default is the 

effective width times the 

effective diffusion extension, 

which is defined in the 

technology file. The default 

equation can be edited in the 


Appendix A. 

Modifies the value of as and ad 

parameters. The values can be 0, 

1, or 2. You cannot apply 

parameters to this value. 




ps= 

psvalue 

pd= 

pdvalue 

nrd= 

num_drain_sqs 

nrs= 

num_source_sqs 

m= 

mult_value 

Defines the perimeter of the 

source diffusion in 10 -8m units. 



specified, the default is two 

times the effective width plus 

two times the effective diffusion 

extension, which is defined in 

the technology file. You can edit 

the default equation in the 


Appendix A. 

Defines the perimeter of the 

drain diffusion in 10-8m units. 



specified, the default is two 

times the effective width plus 

two times effective diffusion 

extension, which is defined in 

the technology file. You can edit 

the default equation in the 


Appendix A. 

Specifies the number of drain 

resistance squares. The value 

(float) is used for calculating 

delays (default = 0). 

Specifies the number (float) of 

source resistance squares. 

Specifies the number of 

transistors with terminals 

connected in parallel.

Resistor 


SYNTAX: 


(t=R) (en=element_name) (so=source_node) (dr=drain_node) 

(r=value) (m=mult_value); 

EXAMPLE: 

(t=R)(en=R15)(so=INA0)(dr=PX)(r=1500); 

The example defines a 1500 ohm resistor between nodes INA0 

and PX. 


en= 

element_name 

so= 

source_node 

dr= 

drain_node 

r= 

value 

m= 

mult_value 

SYNTAX: 

Element name. 

Source node. 

Drain node. 

Specifies the resistance value 

(integer or real) in ohms. It can 

be an expression. 

Specifies a multiplier that 

causes the resistor to be treated 

as multiple value resistors 

connected in parallel. 

(t=V) (en=element_name) (so=n+) (dr=n-) (v=value); 

EXAMPLE: 

(t=V)(en=vs2ci)(so=10)(dr=25)(v=4.5); 



DESCRIPTION: 

Each node in the circuit can connect to only one voltage source. 

If a node needs more than one voltage source, you must split the 

node into two (for example, by using a resistor). 

SPICE equivalent: 

Vname n+ n- value 

EXAMPLE: 

V1 1 gnd 3.3 


en= 

element_name 

so= 

n+ 

dr= 

n- 

v= 

value 

SIN Voltage Source 

SYNTAX: 

(t=VSIN) (en=element_name) (so=n+) (dr=n-) 

(v=dc,pa,); 

EXAMPLE: 

(t=VSIN)(en=v12)(so=12)(dr=0)(v=0,0.1,1e6,2n,1e8); 


Element name. 

Positive node of the voltage 

source. 

Negative node of the voltage 

source. 

Source value. 

Vname n+ n- dc SIN(dc pa )

DESCRIPTION: 


en= 

element_name 

so= 

n+ 

dr= 

n- 

v= 

dc 

pa 

freq 

td 

df 

pd 

EXP Voltage Source 

SYNTAX: 

(t=VEXP)(en=element_name)(so=n+)(dr=n-) 

(v=v1,v2,); 


EXAMPLE: 

(v=VEXP)(en=v12)(so=12)(dr=0)(v=0,5,1n,5n,10n,5n); 


Element name. 

Positive node of the voltage source. 

Negative node of the voltage source. 

Vname n+ n- EXP(v1 v2 >) 


en= 

element_name 

so= 

n+ 

Source value: 

dc offset voltage (volt) 

peak amplitude (volt) 

frequency (Hz) 

time delay (sec) 

damping factor (1/sec) 

phase delay (degrees) 

Element name. 





dr= 

n- 

v= 

v1 

v2 

td1 

tau1 

td2 

tau2 

AM Voltage Source 

SYNTAX: 

(t=VAM)(en=element_name)(so=n+)(dr=n)(v=sa,); 

EXAMPLE: 

(v=VAM)(en=v12)(so=12)(dr=0)(v=2.5,0,1000,1e6,0); 

DESCRIPTION: 

AM voltage sources have a floating terminal and a terminal 

constant. This constant is connected to VDD, GND, or another 

voltage source. 


Vname n+ n- AM (sa oc fm fc td) 


en= 

element_name 

so= 

n+ 


initial value of voltage (volt) 

pulsed value of voltage (volt) 

rise delay (sec) 

rise time const. (sec) 

fall delay (sec) 

fall time const. (sec) 

Element name. 

Positive node of the voltage source.


dr= 

n- 

v= 

sa 

oc 

fm 

fc 

td 

SFFM Voltage Source 

SYNTAX: 

(t=VSFFM)(en=element_name)(so=n+)(dr=n) 

(v=dc,ac,); 


EXAMPLE: 

(v=VSFFM)(en=v12)(so=12)(dr=0)(v=0,2,20e7,5,1000); 


Vname n+ n- SFFM(dc ac >) 

Command Argument Description 

en= 

element_name 

so= 

n+ 


Source value: 

signal amplitude (volt) 

offset constant 

modulation frequency (Hz) 

carrier frequency (Hz) 

delay time (sec) 

Element name. 





dr= 

n- 

v= 

dc 

ac 

fac 

km 

fs 

Voltage Controlled Voltage Sources 


Source value: 

dc offset voltage (volt) 

carrier amplitude (volt) 

carrier frequency (Hz) 

modulation index (radian) 

signal frequency (Hz) 

(t=E) (en=element_name) (dr=n+) (bu=n-) (so=in+) (ga=in-) 

(a=value); 

EXAMPLE: 

(t=E)(en=esource1)(dr=1)(bu=100)(so=5) 

(ga=18)(a=7 5); 

DESCRIPTION: 

Each node in the circuit can connect to only one voltage source. 

If a node needs more than one voltage source, you must split the 

node into two, for example, by using a resistor. 


en= 

element_name 

dr= 

n+ 

bu= 

n- 

so= 

in+ 

Element name. 



Positive controlling node.

Subcircuit 


ga= 

in- 

a= 

value 

SYNTAX: 

Negative controlling node. 

Voltage gain. 

(subckt=sub_name) (it=...) (ot=...) (bt=...) 

[(pr=prname1:prvalue1, prname2:prvalue2...] 

(m=mult_value); 

{ 

EPIC netlist 

} 


EXAMPLE: 

(subckt=AK)(it=a1,k1)(ot=b)(pr=rval:100, wp:4.6) 

{ 

(ef=OR)(en=or)(it=a1,k1)(ot=x1); 

(ef=INV)(en=inv)(it=x2)(ot=b); 

(t=R)(en=r1)(so=x1)(dr=x2)(r=rval); 

(t=p)(en=p1)(ga=x2)(dr=vdd)(so=x1)(w=wp)(1=100); 

} 

After you define the subcircuit AK in the example, you can place 

it in the subcircuit definition using statements similar to these: 

(ef=AK)(en=myak)(it=c1,c2)(ot=c3) 

(pr=rval:100, wp:4.6); 

(ef=AK)(en=yourak)(it=d1,d2)(ot=d3) 

(pr=rval:200, wp:5.2); 

These examples show the AK subcircuit placed twice. The first is 

named myak, with signals c1 and c2 connected as inputs, signal 

c3 connected as the output, resistor value set to 100 ohms, and 

the width of transistor set to P1=4.6μm. The second is named 

yourak, with signals d1 and d2 connected as inputs, signal d3 



connected as the output, resistor value set to 200 ohms, and the 

width of transistor P1 set to 5.2μ. 

DESCRIPTION: 

You can group elements together and define them as a subcircuit. 

After the subcircuit is defined, you can place it in a circuit one or 

more times. You can also nest it in other subcircuits. 

Subcircuit definitions can be placed anywhere in the netlist. For 

example, you can call for subcircuits at the top of a netlist and 

place the definitions at the end. However, to improve 

performance, a subcircuit definition should be placed before it is 

used in the netlist. 

A circuit description can contain any recognizable circuit 

element, including transistors, resistors, instances of a 

subcircuit, or functional level elements. However, a description 

cannot contain a nested subcircuit definition. It must be defined 

in the circuit description somewhere other than where it is 

called. 


subckt= 

sub_name 

pr= 

prname1:prvalue1. . . 

m= 

mult_value 

Defines the subcircuit name, 

which is called to place an 

instance of the subcircuit using 

the element function (ef). 

prname1 names a parameter in 

the subcircuit. prvalue1 is the 

assigned value if the parameter 

is not redefined elsewhere in the 

netlist. Dimension parameters 

are expressed in microns if the 

HSPICE keyword is included at 

the beginning of the netlist. See 

“Parameter Passing in Netlists” 

on page 69 for more details. 

Specifies a multiplier that 

causes the subcircuit to be 

treated as multiple value 

subcircuits connected in parallel.

Net 

Hierarchical Syntax 


EPIC tools use periods (.) to hierarchically link names. The 

result is unique names. You can combine names in the following 

ways: 

■ InternalNodeName.ElementName=UniqueNodeName 

■ ElementName.SubcircuitElementName=NewElementName 

You can use a hierarchical node name only in configuration and 

interactive commands. 

The instance name myak in the example of subcircuit syntax 

becomes a qualifier for lower nesting-level entities. At the same 

time, the new name establishes the hierarchical structure of the 

element and node names. The following example shows a 

hierarchical node name: 

ALU.multip.reg1.loga.t4.aAM2910.bit5.INP3.t12.PA 

For example, to apply 500 fF of capacitance to the internal node 

x of the myak instance of subcircuit AK, you need the following 

statement in the configuration file: 

node_capacitance myak.x 500 

SYNTAX: 

(net=node1) (nn=node2, node3,...); 

EXAMPLE: 

(subckt=CKT)(it=A1,A2,B1,B2)(ot=D) 

{ 

(t=R)(en=R1)(so=A)(dr=C1)(r=400); 

(t=R)(en=R2)(so=B2)(dr=C2)(r=500); 

(t=R)(en=R3)(so=C)(dr=D)(r=600); 

(net=A)(nn=A1,A2); 

(net=B1)(nn=B2); 

(net=C)(nn=C1,C2); 

} 



The first net statement specifies that ports A1 and A2 are 

connected to node A. 

The second net statement specifies that port B1 is connected to 

port B2. 

The third net statement specifies that internal nodes C, C1, and 

C2 are all connected together. 

This subcircuit definition describes the circuit shown in 

Figure 2. 

B1 

A1 

A2 

B2 

A 

Instance 

R1=400 

R2=500 

C1 

C2 

Figure 2 Net statement example 

C 

CKT 

R3=600 

D

Gate-level Element 

Timing Checks 

SETUP 

DESCRIPTION: 

The syntax defines nodes connected by a net. 


net= 

node1, node2,... 

nn= 

node1, node2,... 

Timing Checks 37 

EPIC provides generic gate-level logic models. For details about 

how to write and use models, see the ADFMI Manual. 

This section provides the syntax, examples and description of 

various timing checks. 

SYNTAX: 

(ef=SETUP) (en=element_name) (it=node1,...noden,refnode) 

(sv=data_edge,ref_edge,constraint); 

EXAMPLE: 

(ef=SETUP)(en=su_check)(it=edge0,edge1,CLK) 

(sv=1,0,220); 

This example requires that the falling edges of signals at edge0 

and edge1 occur at least 2.2 nanoseconds before the rising edge 

of the reference node CLK. If the circuit does not meet this 

requirement, an error is reported in the .err file. 

DESCRIPTION: 

The node specified in (net=...) 

can be a port, a node inside a 

subcircuit, or a global node. 

The node specified in (nn=...)can 

be a port, a node inside a 

subcircuit, or a global node. 

This command specifies a setup time requirement between the 

edges of specified data signals and the edge of a reference signal. 



HOLD 

This measurement is performed by TimeMill and PathMill. An 

error message is returned in the .err file if the measured setup 

time is less than the constraint. The phase relationships are 

defined in the sv field. 


en= 

element_name 

it= 

SYNTAX: 

node1,... noden, 

refnode) 

sv= 

data_edge 

sv= 

ref_edge 

sv= 

constraint 

Element name 

Input terminals or nodes of the 

element 

Defines the edge of the data signal 

to check for verifying the setup 

time requirement. Use one of the 

following values: 

0 = rising edge 

1 = falling edge 

2 = both rising and falling edges 

Specifies the edge of the reference 

signal to check for verifying the 

setup time requirement. Use one 

of the following values: 



Specifies the setup time 

requirement in 0.01 nanoseconds 

(ef=HOLD)(en=element_name)(it=node1,...noden,refnode) 

(sv=data_edge,ref_edge,constraint); 

EXAMPLE: 

(ef=HOLD)(en=holdchk)(it=AD0,BD0,TT,clk1) 

(sv=2,1,540);


Here, both the rising and falling edges of signals at AD0, BD0 and 

TT must be held for at least 5.4 nanoseconds after the falling 

edge of the reference signal at node clk1.If the circuit does not 

meet this requirement, an error is reported in the .err file. 

DESCRIPTION: 

This command specifies a hold time requirement from the edge of 

a reference signal to the edges of specified data signals. This 

measurement is performed by TimeMill and PathMill. An error 

message is issued in the .err file if the measured hold time is less 

than the constraint. The phase relationships are defined in the 

sv field. 


en= 

element_name 

it= 


refnode) 

sv= 

data_edge 

sv= 

ref_edge 

sv= 

constraint 

Element name. 


element. 


to check for verifying the hold time 

requirement. Use one of the 







hold time requirement. Use one of 

the following values: 



Specifies the hold time 

requirement in 0.01 nanoseconds. 



Edge to Edge (ETOE) 

SYNTAX: 

(ef=ETOE)(en=element_name)(it=node1,...noden,refnode) 

(sv=data_edge,ref_edge, min_constraint, max_constraint); 

EXAMPLE: 

(ef=ETOE)(en=etoechk)(it=P10,P20,CLK) 

(sv=1,2,150,200); 

Here, the falling edges of signals at P10 and P20 are checked to 

ensure they are within a 1.5-2 nanosecond delay time, compared 

to the rising or falling edge of the reference signal (node CLK). 

DESCRIPTION: 

This command specifies an edge-to-edge requirement among 

specified signals. This check is performed only by TimeMill. 

The edge-to-edge time requirement is specified between signals 

at node1, node2 and so forth with respect to the signal at 

refnode. The phase relationships are defined in the sv field. 


en= 

element_name 

it= 


refnode) 

sv= 

data_edge 

Element name. 

The input terminals or nodes of 

the element. 


to check for verifying the hold time 

requirement. Use one of the 




2 = both rising and falling edges

Pulse Width (PULSEW) 


sv= 

ref_edge 

sv= 

min_constraint 

sv= 

max_constraint 

SYNTAX: 

(ef=PULSEW) (en=element_name) (it=node1,...node_n) 

(sv=low_min, low_max, hi_min, hi_max); 




hold time requirement. Use one of 

the following values: 




Specifies the minimum hold time 


Specifies the maximum hold time 


EXAMPLE: 

(ef=PULSEW)(en=pwchk)(it=clk1,clk2) 

(sv=150,250,450,550); 

Here, signals clk1 and clk2 are checked for their low pulse 

width between 1.5 and 2.5 ns, and their high pulse width 

between 4.5 and 5.5 ns. 

DESCRIPTION: 

PULSEW specifies a pulse width requirement among specified 

signals. This check is performed only by TimeMill. 



Global Commands 

Global Node 

Pulse widths are specified for signals at node1, node2 and so 

forth. The pulse widths are defined in the sv field. 


en= 

element_name 

it= 

node1, ...node_n 

sv= 

low_min 

sv= 

low_max 

sv= 

hi_min 

sv= 

hi_max 

Some commands work globally. They affect all the data in the 

EPIC netlist file. The global commands are global, param and 

pgalias. 

SYNTAX: 

global node_name1 node_name2 ... node_name_n; 

EXAMPLE: 

global AA DSP BW; 

global X NN YQ BBX a vc vd; 

Element name. 


element. 

Defines the minimum low pulse 

width in 0.01 nanoseconds. 

Defines the maximum low pulse 


Defines the minimum high pulse 


Defines the maximum high pulse 


DESCRIPTION: 

A global node is a node that you can refer to at any level by using 

a single node name. You can make nodes global if you want to

Global Parameters 

Global Commands 43 

access them across subcircuit levels. For instance, you might 

want to designate VDD and GND as global nodes. 

Including a global name as a port in a subcircuit definition 

cancels the global nature of that node for that particular 

subcircuit. For example, if a subcircuit includes the global signal 

VDD in the port definition, you need to specifically connect VDD 

when you instantiate that subcircuit. 

You can include more than one global statement in a netlist file. 

You can place global statements anywhere in the netlist file. 


node_name Specifies the name of a node 

defined as global. 

SYNTAX: 

param name1:value1 name2:value2 ... name_n:value_n; 

EXAMPLE: 

param scalep:10 cjprm:1; 

DESCRIPTION: 

Parameter values set in a global param statement are available 

through the entire netlist. If a local parameter has the same 

name as the global one, the parameter passing rule will dictate 

which value is in effect. For more information, see the control 

option param_passing_rule on page 59. 



Power and Ground Aliases 

SYNTAX: 

pgalias node_name pg_name; 

EXAMPLE: 

pgalias VSS GND; 

pgalias VCC VDD; 

These examples show how to alias VSS to GND and VCC to VDD in 

the netlist. VSS, GND, VCC, and VDD are used as power node names 

in the netlist. 

DESCRIPTION: 

EPIC tools assume that global supply and ground are named VDD 

and GND, unless otherwise specified in the configuration file or by 

the pgalias command. You can use either uppercase or lowercase 

characters, but the cases cannot be mixed. Supply and ground 

signals must be defined in the circuit netlist description for 

proper transistor-level simulation. 

You can specify more than one power-ground alias 

simultaneously in two different pgalias statements. The 

pgalias command can be placed anywhere in the netlist. The 

pgalias command does not assume only one power signal and 

one ground signal are being used. 


node_name Any node name to be aliased. 

pg_name Either VDD or GND.

Netlist Control Options 

Netlist Control Options 45 

The following alphabetical listing shows all of the netlist control 

options. They are defined in this section. 

bus_notation 

case 

cspf_cap_select 

cspf_disable_net 

cspf_name_map_proc 

cspf_net 

cspf_process_ccap 

db_file 

dont_compress_db 

dpf_name_map_proc 

edif2e_args 

edif2e_output_file 

epic_cell_lib_path 

error_undefined_param 

find_top_mod 

floating_nodes_ok 

force_global_model 

global_override_port 

hier_separator 

ignore_excess_pin 

ignore_meas 

keep_0v_dcvs 

keep_distinct_cap 

keep_junc_diode 

keep_unc_node 

max_res_value 

min_cap_value 

min_fcap_value 

min_ind_value 

min_res_value 

netlist_suffix 

nf_expand_inst 

nf_flatten_inst 

param_passing_rule 

parse_error_limit 

prefer_model 

prefer_model_inst 

prefer_model_port_map 

prefer_model_port_map_inst 

print_hir_to_file 

rcr 

rcr_preserve_name 

report_missing_subckt 

report_unused_port 

scale_cap 

scale_cmos_length 

scale_cmos_width 

scale_res 

set_message_limit 

split_floating_cap 

top_module 

user_lib 

vlog2e_args 

vlog2e_output_file 



Control Option Syntax 

You specify all netlist control options in the SPICE netlist using 

the .options statements. You define .options statements at the 

beginning of the SPICE netlist. 

SYNTAX: 

.options ctrl_opt_name=value ... 

If you specify non-alphanumeric characters in a variable, or 

more than one variable as values for a control option, enclose 

each value in double quotation marks. 

The following syntax shows the control options syntax in EPIC 

netlist format: 

SYNTAX: 

Option Definitions 

bus_notation 

ctrl_opt option1[:value1] option2 [:value2 ...]; 

This section shows you how to use the control options. They are 

presented alphabetically. 

SYNTAX: 

ctrl_opt bus_notation:“value”; 

EXAMPLE: 

ctrl_opt bus_notation:“”; 

DESCRIPTION: 

This option modifies bus notation. The value is a three-character 

string specifying the three characters used in bus notation. The 

default value is “[-]”. 

NOTE: This control option does not apply to ADFMI models where the 

only bus notation allowed is the [-] default notation. Also, 

the -b option of the vlog2e command is ignored if used with this 

option. (See the section “vlog2e Command” on page 129.)

case 


SYNTAX: 

ctrl_opt case: l |L|u|U; 

DESCRIPTION: 


This option converts the input netlist to the specified case: l or L 

for lowercase; u or U for uppercase. 

SYNTAX: 

ctrl_opt cspf_cap_select: netline | sum | warning; 

EXAMPLE: 

*|NET x1.out 20fF 

*|GROUND_NET vss 

C1 x1.out vss 2FF 




If the control option is set to sum, 8fF will be added to net 

x1.out. If netline is used, then 20fF will be added to the net. If 

warning is used, then a warning will be printed because the two 

values differ by more than 1%. In this case the sum of the cap 

values will be used. 

DESCRIPTION: 

This option can be used in an SPF file. It affects only those nets 

in which the capacitance can be represented as a single value. It 

lets you set one of three settings for SPF back-annotation of 

capacitance values. 





Argument Definition 

netline Selects the capacitance number on the 

netline (the line that starts with *|Net). 

sum Sums all the capacitance values 

associated with the net. 

warning Issues a warning if the netline and sum 

values differ. 

For more information about SPF files, see the section “Cadence 

SPF File” on page 87. 

SYNTAX: 

ctrl_opt cspf_disable_net:“value”; 

EXAMPLE: 

ctrl_opt cspf_disable_net:“a b c*”; 

DESCRIPTION: 

This option is used with SPF files. It specifies nets in the SPF file 

to be ignored during back-annotation. Wildcards are allowed in 

the net name. 

The cspf_net and cspf_disable_net options can be used 

together. When you use both options, all nets that match those 

specified in cspf_net will be back-annotated, and those specified 

in cspf_disable_net will not. 

NOTE: If a net is specified in both cspf_net and cspf_disable_net, it 

will not be back-annotated. 

SYNTAX: 

ctrl_opt cspf_name_map_proc:“value”; 

EXAMPLE: 

ctrl_opt cspf_name_map_proc:“nm.tcl”;

cspf_net 


DESCRIPTION: 


This option corrects name mismatches between the netlist and 

the Cadence SPF file. For details, see the section “Cadence SPF 

File” on page 87. 

SYNTAX: 

ctrl_opt cspf_net:“value”; 

EXAMPLE 1: 

ctrl_opt cspf_net:“A[*]”; 

This example back-annotates SPF for nets matching A[*]. 

EXAMPLE 2: 

ctrl_opt cspf_net:“B C D”; 

This example back-annotates SPF for nets B, C & D. 

DESCRIPTION: 

This option specifies the nets to which you want parasitic 

information back-annotated in the original netlist. If you don’t 

specify this option, all nets found in the SPF file will be 

processed. You can use this option more than once. Wildcards are 

allowed in the net name. 

SYNTAX: 

ctrl_opt cspf_process_ccap; 

DESCRIPTION: 

This option activates netlist compiler routines that process all 

coupling capacitors in SPF nets. By default, the compiler ignores 

all coupling capacitors in SPF nets. 

The split_floating_cap option affects the coupling capacitors in 

SPF nets if cspf_process_ccap is also specified. 



db_file 


SYNTAX: 

ctrl_opt db_file:filename; 

EXAMPLE: 

ctrl_opt db_file:example; 

This example causes the netlist compiler to generate the header 

file hd_example.edb and the data file example.edb. 

DESCRIPTION: 

This control option is used with the EPIC binary file. It specifies 

the binary file prefix and triggers the generation of the file. 

For further information, see “Device Parameter Format File” on 

page 96. 

SYNTAX: 

ctrl_opt dont_compress_db [: 0|: 1]; 

EXAMPLE 1: 

ctrl_opt dont_compress_db:1; 

This example causes the netlist compiler to generate the 

uncompressed header file hd_example.edb and uncompressed 

data file example.edb. 

EXAMPLE 2: 

ctrl_opt dont_compress_db; 

This example forces the netlist compiler not to compress the 

binary file. The header file and data file are not generated. 

DESCRIPTION: 

This control option is used with the EPIC binary file. It controls 

the compression of the netlist database file. By default, netlist 

database files (.edb) are compressed by gzip. 

For further information, see “EPIC Binary File” on page 98.


edif2e_args 

SYNTAX: 

ctrl_opt dpf_name_map_proc:filename.tcl; 


EXAMPLE: 

ctrl_opt dpf_name_map_proc:map.tcl; 

The map.tcl file is the tcl script containing the tcl name mapping 

procedures. 

DESCRIPTION: 

This control option is used with the device parameter format file 

to convert the element or node names in the file to the format 

used in the original netlist file. 

For further information, see “Device Parameter Format File” on 

page 96. 

SYNTAX: 

ctrl_opt edif2e_args:“value”; 

EXAMPLE: 

ctrl_opt edif2e_args:"-p -r"; 

This example starts the EPIC netlist translator, edif2e, with the 

options -p and -r. 

DESCRIPTION: 

This option specifies the command-line options to run the Edif2e 

utility if an input netlist is in EDIF format. It uses multiple 

command lines; you can specify options enclosed in quotes. 

For information about the Edif2e utility, see “EDIF Netlist 

Translator” on page 118. 



edif2e_output_file 

epic_cell_lib_path 

SYNTAX: 

error_undefined_param 

ctrl_opt edif2e_output_file:filename; 

DESCRIPTION: 

The EPIC netlist compiler reads in an EDIF netlist through the 

EPIC netlist translator edif2e. The translated EPIC format 

netlist is stored in the specified file. 

For information about the Edif2e utility, see “EDIF Netlist 

Translator” on page 118. 

SYNTAX: 

ctrl_opt epic_cell_lib_path:“path_list”; 

EXAMPLE: 

ctrl_opt epic_cell_lib_path:”/cell1:/usr/cell2”; 

This syntax example adds two directories /cell1 and /usr/ 

cell2 to the cell library search path. 

DESCRIPTION: 

This option specifies the path to cell libraries. You can specify 

multiple paths separated by a colon. 

SYNTAX: 

ctrl_opt error_undefined_param; 

DESCRIPTION: 

By default, the netlist compiler assumes the value of an 

undefined parameter to be 0. It issues a warning message but 

continues to run. This option specifies that the undefined 

parameter is to be treated as an error. The netlist compiler 

aborts processing after reporting the error.

find_top_mod 

floating_nodes_ok 

force_global_model 

global_override_port 

SYNTAX: 

ctrl_opt find_top_mod; 

DESCRIPTION: 


This option directs the netlist compiler to find the subcircuit 

definition that has no instantiation and to use it as the top 

module. No value is required. 

SYNTAX: 

ctrl_opt floating_nodes_ok; 

DESCRIPTION: 

By default, floating nodes in a circuit are treated like errors, and 

simulation aborts. This control option forces simulation to 

continue even though floating nodes are encountered. 

SYNTAX: 

ctrl_opt force_global_model; 

DESCRIPTION: 

This control option forces the netlist compiler to treat all SPICE 

models as top-level models. Therefore, the compiler doesn’t 

recognize subcircuit definition static scoping in the netlist. The 

default behavior is such that all models defined in a subcircuit 

definition are associated with the subcircuit scope. 

SYNTAX: 

ctrl_opt global_override_port; 

DESCRIPTION: 

By default, if a node name is defined both as a global node and a 

port of a subcircuit definition, it is used as a port inside the 

subcircuit. If the global_override_port option is set, the node 




ignore_excess_pin 

ignore_meas 

is treated as a global node inside the subcircuit. However, the 

port will not be connected to anything inside the subcircuit. 

SYNTAX: 

ctrl_opt hier_separator:“value”; 

EXAMPLE: 

ctrl_opt hier_separator:"/"; 

DESCRIPTION: 

This option designates a single character as a hierarchical 

separator. 

SYNTAX: 

ctrl_opt ignore_excess_pin; 

DESCRIPTION: 

By default, the EPIC netlist compiler does not allow instances 

with more pins than the number of ports in the subckt definition 

or functional models. Also, it does not allow any pin to be 

connected to a port that does not exist in the subckt or 

functional models. When you specify the ignore_excess_pin 

option, the netlist compiler issues warnings only for those 

instances. Using this option slows the compilation process. 

SYNTAX: 

ctrl_opt ignore_meas [:0|1]; 

EXAMPLE 1: 

ctrl_opt ignore_meas; /* ignore */ 

This example specifies that .measure statements will not be 

processed in the SPICE netlist. 

EXAMPLE 2: 

ctrl_opt ignore_meas:1; /* ignore */

keep_0v_dcvs 

keep_distinct_cap 

keep_junc_diode 


This example also specifies that .measure statements will not 

be processed in the SPICE netlist. 

EXAMPLE 3: 

ctrl_opt ignore_meas:0; /* don’t ignore */ 

This example specifies that .measure statements will be 

processed. 

DESCRIPTION: 

This option specifies whether or not to process .measure 

statements in the SPICE netlist. 

SYNTAX: 

ctrl_opt keep_0v_dcvs; 

DESCRIPTION: 

This control option forces the netlist compiler to retain a zero 

volt DC voltage source. If the netlist doesn’t contain any currentcontrolled 

dependent sources, by default the netlist compiler 

removes a zero volt DC voltage source, and the two terminals are 

connected together. 

SYNTAX: 

ctrl_opt keep_distinct_cap; 

DESCRIPTION: 

By default, when one terminal is connected to a constant voltage 

node, it is treated as node capacitance. This option causes the 

netlist compiler to treat it as a capacitor element. 

SYNTAX: 

ctrl_opt keep_junc_diode; 



keep_unc_node 

max_res_value 

min_cap_value 

DESCRIPTION: 

By default, the netlist compiler converts junction diodes to 

capacitors. This option retains the junction diodes, overriding 

such a conversion. No value is required. 

SYNTAX: 

ctrl_opt keep_unc_node; 

DESCRIPTION: 

By default, the netlist compiler removes all unconnected nodes 

when they constitute more than ten percent of the total number 

of nodes. This option disables this default for situations when 

you want to retain all unconnected nodes. No value is required. 

SYNTAX: 

ctrl_opt max_res_value:”value”; 

DESCRIPTION: 

This option specifies the maximum resistance of a resistor. 

Resistors with values greater than or equal to the maximum 

value are removed as open circuit. The default value is 1e12 

ohms. 

SYNTAX: 

ctrl_opt min_cap_value:”value”; 

DESCRIPTION: 

This option specifies the minimum value of a grounded capacitor. 

Grounded capacitors with a capacitance of less than or equal to 

the specified minimum value are removed from the netlist. The 

default value is 0. Values specified without units are assumed to 

be femtofarads.

min_fcap_value 

min_ind_value 

min_res_value 

SYNTAX: 

ctrl_opt min_fcap_value:value; 

DESCRIPTION: 


This option specifies the minimum value of a floating capacitor. 

Floating capacitors with a capacitance of less than or equal to 

the specified minimum value are removed from the netlist. The 

default value is 0. Values specified without units are assumed to 

be femtofarads. 

SYNTAX: 

ctrl_opt min_ind_value:value; 

EXAMPLE: 

ctrl_opt min_ind_value:0.5; 

This example removes all inductors smaller than 0.5 

nanoHenrys. 

DESCRIPTION: 

This option specifies a minimum value for inductors. Inductors 

with an inductance of less than or equal to the specified 

minimum value are removed from the netlist. The value is in 

nanoHenrys. 

SYNTAX: 

ctrl_opt min_res_value:value; 

DESCRIPTION: 

This option specifies the minimum resistance of a resistor, in 

ohms. Resistors with a value less than or equal to the specified 

minimum value are removed from the netlist and are replaced by 

short circuit. Resistors with parameterized resistance values 

will also be checked against min_res_value. For RailMill the 

default value is 0.01 ohm, otherwise the default is 0.1 ohm. 



netlist_suffix 

nf_expand_inst 

NOTE: When the ctrl_opt rcr command is used, only zero value 

resistors are removed prior to submission to the RC reduction 

algorithm. 

SYNTAX: 

ctrl_opt netlist_suffix:“value”; 

EXAMPLE 1: 

ctrl_opt netlist_suffix:”spice .spic”; 

This example specifies files ending in .spic as SPICE format. 

EXAMPLE 2: 

ctrl_opt netlist_suffix:”edif .ed”; 

This example specifies files ending in .ed as EDIF format. 

EXAMPLE 3: 

ctrl_opt netlist_suffix:”vlog .v”; 

This example specifies files ending in .v as Verilog format. 

EXAMPLE 4: 

ctrl_opt netlist_suffix:”epic”; 

This example specifies files without suffixes as EPIC format. 

DESCRIPTION: 

This option specifies the filename suffix for identifying a netlist 

during a search of cell library directories. The value is a 

character string containing the netlist format and optional 

suffix. The netlist format name is one of the valid keywords used 

with the -n command-line option. If you don’t specify a suffix, a 

file without a suffix will be identified as the specified netlist 

format. For a list of supported formats and corresponding 

suffixes, see the section “Compiled Files” on page 79. 

SYNTAX: 

ctrl_opt nf_expand_inst:”instance [instance] ...”;

nf_flatten_inst 

param_passing_rule 

EXAMPLE: 

ctrl_opt nf_expand_inst:”i1.i2.i4”; 

DESCRIPTION: 


This option lets you control the net flattening hierarchy. During 

the process of hierarchical design flattening, each node has its 

unique name and index throughout the connection hierarchy. 

This option introduces an instance-based boundary to a node so 

that each net connected to the instance is treated as a unique 

node through the hierarchy. The higher instantiations in the 

hierarchy carry the setup from the higher level. instance 

specifies the instance boundary. 

NOTE: If you use both the nf_flatten_inst and the nf_expand_inst 

control options, nf_expand_inst takes precedence. 

SYNTAX: 

ctrl_opt nf_flatten_inst:”instance [instance] ...”; 

EXAMPLE: 

ctrl_opt_nf_flatten_inst:”i1.i2.i4”; 

DESCRIPTION: 

This option lets you control the net flattening hierarchy. During 

the process of hierarchical design flattening, each node has its 

unique name and index throughout the connection hierarchy. 

This option introduces an instance-based boundary to a node so 

that the net connected to the instance is treated as one node. The 

higher instantiations in the hierarchy carry the setup from the 

higher level. instance specifies the instance boundary. 

NOTE: If you use both the nf_flatten_inst and the nf_expand_inst 

control options, nf_expand_inst takes precedence. 

SYNTAX: 

ctrl_opt param_passing_rule:top_down|bottom_up; 



parse_error_limit 

EXAMPLE: 

ctrl_opt param_passing_rule:top_down; 

ctrl_opt param_passing_rule:bottom_up; 

DESCRIPTION: 

This option specifies the parameter passing rule. By default, 

higher level definitions override lower levels (top_down). 

SYNTAX: 

ctrl_opt parse_error_limit:value; 

EXAMPLE: 

ctrl_opt parse_error_limit:5; 

This example causes the compilation to halt after encountering 

five errors. 

DESCRIPTION: 

Without this option, the compiler does not abort due to errors 

until the error count exceeds the default count of 20 errors. Use 

this option to override the default count. 

NOTE: The netlist compiler aborts at fatal errors regardless of the error 

limit specified by this option. 

prefer_model 

prefer_model_port_map 

ctrl_opt prefer_model:“value”; 

ctrl_opt prefer_model_port_map:“value”; 

EXAMPLE: 

ctrl_opt prefer_model:”INV NAND”; 

ctrl_opt prefer_model_port_map:”*”; 

DESCRIPTION: 

These options specify the subcircuit definition names, so that if 

a functional model exists, it will be used instead of the subcircuit 

definition. Wildcards are allowed in the name.

prefer_model_inst 

prefer_model_port_map_inst 

print_hir_to_file 


The difference between prefer_model_port_map and 

prefer_model is the port mapping: prefer_model uses a 

position-based port map, while prefer_model_port_map uses a 

name-based port map. 

The prefer_model_port_map option performs name-based port 

mapping in two steps: 

1 The subcircuit port name is found using position-based port 

mapping. 

2 The port name is used to locate the port of the functional 

model. 

SYNTAX: 

ctrl_opt prefer_model_inst:“instance_model 

[instance_model]...”; 

ctrl_opt prefer_model_port_map_inst: “instance_model 

[instance_model]...”; 

EXAMPLE: 

ctrl_opt prefer_model_inst:i1.i2 mod”; 

ctrl_opt prefer_model_port_map_inst:”i1.i2 mod”; 

DESCRIPTION: 

These control options are instance-based versions of 

prefer_model and prefer_model_port_map. The instance 

model replaces the subcircuit instantiation for the “instance.” 

instance_model must be the full hierarchical instance name. 

The difference between the two control options is port mapping. 

prefer_model_inst uses a position-based port map, while 

prefer_model_port_map_inst uses a name-based port map. 

SYNTAX: 

ctrl_opt print_hir_to_file:filename; 



rcr 

EXAMPLE: 

ctrl_opt print_hir_to_file:hierfile; 

DESCRIPTION: 

The compiler generates a .hir file. Use this option to specify a 

filename to which hierarchical information will be printed. The 

file format is one record per line, and each record has two fields: 

instance hierarchical name and subcircuit name. 

SYNTAX: 

ctrl_opt rcr [:awe]; 

EXAMPLE 1: 

ctrl_opt rcr; 

This example shows that a parallel/series reduction is 

performed. 

EXAMPLE 2: 

ctrl_opt rcr:awe; 

This example shows that awe reduction is performed. Specifying 

awe as the netlist control option value results in a more accurate 

calculation. 

DESCRIPTION: 

Without the rcr option, the default for min_res_value is 0.01 

ohms and the default for the min_cap_value is 0. With the rcr 

option, the tool performs RC reduction, thereby looking for 

parallel and series combinations. The default for min_res_value 

becomes 5 ohms, and the default for min_cap_value becomes 

1fF. RC reduction affects resistors and capacitors with values 

greater than the minimum. You can change the min_res_value 

and min_cap_value defaults.

cr_preserve_name 

SYNTAX: 


ctrl_opt rcr_preserve_name[:“subckt_name [node_name ...]”]; 

EXAMPLE 1: 

ctrl_opt rcr_preserve_name:“INV1 invin invout”; 

This example preserves the names of nodes invin and invout 

in subcircuit INV1. 

EXAMPLE 2: 

ctrl_opt rcr_preserve_name:“XOR2A xor*”; 

This example preserves names for all nodes with names 

beginning with “XOR” in the subcircuit named XOR2A. 

EXAMPLE 3: 

ctrl_opt rcr_preserve_name:“INV1”; 

This example preserves the names of all nodes in the subcircuit 

named INV1. 

EXAMPLE 4: 

ctrl_opt rcr_preserve_name:“/ in out”; 

This example preserves names for the in and out nodes at the 

top-most level. 

DESCRIPTION: 

This control option specifies the name of the subcircuit in which 

nodes are to be preserved during RC reduction. subckt_name can 

contain the wildcard character “*”, as well as hierarchical 

dividers. For the top-most level subcircuit name, use “/”. 



report_missing_subckt 

report_unused_port 

scale_cap 

node_name can also contain the wildcard character “*”. If you 

don’t specify an argument, all node names in the specified 

subcircuit are preserved. 


subckt_name The name of the subcircuit in which 

nodes are to be preserved during 

RC reduction. 

node_name One or more nodes to be preserved 

during RC reduction. 

SYNTAX: 

ctrl_opt report_missing_subckt; 

DESCRIPTION: 

This option directs the netlist compiler to check if all subcircuit 

definitions being called exist after parsing. If they don’t exist, 

the compiler aborts the process. 

SYNTAX: 

ctrl_opt report_unused_port; 

DESCRIPTION: 

This option directs the netlist compiler to report all unused ports 

during subckt instantiation. 

SYNTAX: 

ctrl_opt scale_cap:value; 

EXAMPLE: 

ctrl_opt scale_cap:0.5;

scale_cmos_length 

scale_cmos_width 

scale_res 

DESCRIPTION: 


This option specifies a value for scaling the value of capacitors in 

the design. The value argument is used as a multiplier to the 

values of all capacitors in the design. 

SYNTAX: 

ctrl_opt scale_cmos_width:value; 

ctrl_opt scale_cmos_length:value; 

DESCRIPTION: 

These options specify scale factors for the width or length of 

MOS devices. The options affect only width and length, not area 

and perimeter. The default value is 1. 

EXAMPLE: 

ctrl_opt scale_cmos_width:0.8; 

scale_cmos_length:1.2; 

This example scales the width of each MOS device by 0.8 and the 

length by 1.2. 

SYNTAX: 

ctrl_opt scale_res:value; 

EXAMPLE: 

ctrl_opt scale_res:0.5; 

This example specifies a scale factor of 0.5 for resistance. 

DESCRIPTION: 

This option specifies a scale factor for resistance. The resistance 

value of every resistor is multiplied by this scale factor. The 

default value is 1. 



set_message_limit 

split_floating_cap 

SYNTAX: 

ctrl_opt set_message_limit:”message_id limit”; 

ctrl_opt set_message_limit:”message_type limit”; 

EXAMPLE 1: 

ctrl_opt set_message_limit:”warning 5”; 

This example shows that only 5 warning messages will be 

displayed. 

EXAMPLE 2: 

ctrl_opt set_message_limit:”20201087 0” 

This example shows that all messages with an id equal to 

20201087 will not be displayed. 

DESCRIPTION: 

This control option specifies the output limit for a message ID or 

type. 


message_id An 8-digit message identification 

number, which can be copied from 

the simulation tools log. 

message_type Must be one of the following types 

of messages: ERROR (for error 

messages), WARNING (for warning 

messages), or NORMAL (for 

informational messages. 

limit Specifies the output limit. 

SYNTAX: 

ctrl_opt split_floating_cap [:value]; 

EXAMPLE: 

ctrl_opt split_floating_cap:2.0;

top_module 

user_lib 


This example splits the floating capacitor and doubles the 

capacitance on both nodes. 

DESCRIPTION: 

This option causes the netlist compiler to split all floating 

capacitors in a netlist into two separate capacitors (one at each 

node) connected to ground. The value specifies the splitting ratio 

of the capacitance. Thus, the split node capacitance on each node 

would be the original floating capacitance multiplied by value. 

If you don’t use this option, the netlist compiler reads the 

floating capacitors as unconnected to power or ground. Floating 

capacitors can be processed by TimeMill and PowerMill, but 

PathMill will display a warning and terminate. 

For information about floating capacitors, see “Floating 

Capacitor” on page 15. 

SYNTAX: 

ctrl_opt top_module:cell_name; 

EXAMPLE: 

ctrl_opt top_module:my_top_cell; 

This example specifies my_top_cell as the top cell. 

DESCRIPTION: 

This option specifies the cell to be used as the top module for 

simulation. This option performs the same function as the -m 

command-line option in EPIC tools. 

SYNTAX: 

ctrl_opt user_lib:”library_1 [library_2 ...]”; 

EXAMPLE: 

ctrl_opt user_lib:"get_w.so"; 

param w1:4.5; 

(t=p)(en=m1)(so=1)(dr=2)(ga=3)(w=get_w(1.0, w1)); 

double 



vlog2e_args 

get_w(d1, d2) 

double d1, d2; 

{ 

return d1 * d2; 

} 

This example shows that the width of the transistor m1 is 

calculated by a C function called get_w() which has two 

arguments. The function get_w() is compiled into a dynamic 

linkable library called get_w.so. 

DESCRIPTION: 

This option lets you specify a list of dynamic linked libraries that 

contain functions called by the netlist. All the functions used by 

the netlist are assumed to return a type double and all the 

arguments that are of type double. The maximum number of 

arguments in a function is 20. 

NOTE: Make sure the function in the netlist is consistent with the 

actual C function declaration. 

SYNTAX: 

ctrl_opt vlog2e_args:“value”; 

EXAMPLE: 

ctrl_opt vlog2e_args:"-t"; 

This syntax starts the vlog2e netlist translator with the -t 

option. 

DESCRIPTION: 

This option specifies the command line options to run vlog2e for 

input netlists in Verilog format. Multiple command-line options 

can be specified inside double quotation marks. 

You can use the VLOG2E_ARGS environment variable to control 

how vlog2e is started. If VLOG2E_ARGS is set, it will take 

precedence over the vlog2e control option. 

For information about vlog2e, see “Verilog Netlist Translator” on 

page 124.

vlog2e_output_file 

SYNTAX: 

ctrl_opt vlog2e_output_file:filename; 

DESCRIPTION: 

Parameter Passing in Netlists 69 

The EPIC netlist compiler reads in a Verilog netlist through the 

EPIC netlist translator vlog2e. The translated EPIC format 

netlist is stored in the specified file. 

For information about vlog2e, see “Verilog Netlist Translator” on 

page 124. 

Parameter Passing in Netlists 

Parameters can be defined at four different levels in the EPIC 

netlist: 

■ globally 

■ within a subcircuit 

■ in a subcircuit call 

■ as a subcircuit definition heading 

The rules governing parameter passing allow you to use 

parameters that are defined inside subcircuits and can conform 

to the parameter passing rules used by HSPICE. 

If you want to follow the HSPICE parameter passing convention, 

enter the keyword HSPICE at the beginning of the EPIC netlist. 

For details, see the section “Parameter Passing Using HSPICE 

Rules” on page 71. 

NOTE: When you use the HSPICE keyword, specify the parameters in 

microns, but specify actual device sizes in units of 0.01 microns. 



Parameter Definitions 

The following table shows the four levels at which you can define 

parameters. 

Level Relative Position Definition 

1 Highest level Parameters defined at the global 

level using param statements. See 

Example 1. 

2 Second highest level Parameters defined in a subcircuit 

using param statements that are 

local to the subcircuit. See Example 

2. 

3 Second lowest level Parameters defined in a subcircuit 

call using the (pr=...) statement. See 

Example 3. 

4 Lowest level Parameters defined in a subcircuit 

definition heading using the (pr=...) 

statement. See Example 4. 

EXAMPLE 1:(highest level) 

param global_param: 0; 

EXAMPLE 2:(second highest level) 

(subckt=inv)(it=A)(ot=Z){ 

param n_width: 10 len: 1.0; 

param p_width: 20; 

(t=p)(en=t1)(dr=Z)(ga=A)(so=vdd)(w=p_width) 

(l=len); 

(t=n)(en=t2)(dr=Z)(ga=A)(so=gnd)(w=n_width) 

(l=len); 

} 

EXAMPLE 3:(second lowest level) 

(ef=inv)(en=e1)(ot=x)(it=A)(pr=dl:1.20); 

EXAMPLE 4:(lowest level) 

(subckt=inv)(it=A)(ot=Z)(pr=dl:2){ 

(t=p)(en=t1)(dr=Z)(ga=A)(so=vdd)(w=2000)(l=dl); 

(t=n)(en=t2)(dr=Z)(ga=A)(so=gnd)(w=1000)(l=dl); 

}

Parameter Passing Using HSPICE Rules 

Parameter Passing in Netlists 71 

In addition to the default EPIC parameter passing rules, you can 

specify the HSPICE command in EPIC netlists to use HSPICE 

parameter passing rules. The HSPICE convention specifies that 

parameters defined at higher levels override parameters defined 

at lower levels. 

The following two examples illustrate HSPICE parameter 

passing rules. 

EXAMPLE 1: 

HSPICE; 




(subckt=buf)(it=A)(ot=Z)(pr=dl:1){ 

(ef=inv)(en=e1)(ot=x)(it=A); 

(ef=inv)(en=e2)(ot=Z)(it=x); 

} 

(ef=buf)(en=e1)(ot=out)(it=in); 

In this example, the lengths of all the transistors are 100 (1 

micron). The value used for parameter dl in subcircuit buf 

overrides the definition in subcircuit inv. 

EXAMPLE 2: 

HSPICE; 




} 

(subckt=buf)(it=A)(ot=Z)(pr=dl:1){ 

(ef=inv)(en=e1)(ot=x)(it=A)(pr=dl:1.20); 

(ef=inv)(en=e2)(ot=Z)(it=x); 

} 

(ef=buf)(en=e1)(ot=out)(it=in)(pr=dl:0.80); 



General Usage Rules 

In this example, the lengths of all the transistors are 80 (.8 

micron). The value used for parameter dl is taken from the 

highest level call, the call to subcircuit buf, and not from the call 

to subcircuit inv inside buf, or from the defaults specified in 

subcircuits buf or inv. 

The following rules apply to using parameters. 

■ A parameter name must start with a letter and can contain 

only letters, digits, underscores (_), and percent signs (%). 

■ You can define and use any number of parameters. The order 

of the parameter definitions in an EPIC netlist file is 

arbitrary. All definitions at a given level of hierarchy are 

gathered into a single list and applied to all the statements 

at that level. 

■ The scope of a parameter definition is strictly maintained. In 

other words, a parameter defined in a subcircuit definition 

block can be used only within that block and at levels that 

are lower in the hierarchy. The global level is regarded as the 

highest level in the hierarchy. 

■ A redefinition of a parameter in the same hierarchical level 

replaces the old definition.

Functions and Expressions 

Functions and Expressions 73 

EPIC netlist syntax supports the use of arithmetic expressions 

and functions for specifying values. 

Arithmetic 

Operators 

A function is an arithmetic expression with a specific name. 

Arguments can be passed to a function. You can assign the same 

name to two functions as long as the number of arguments differ. 

The EPIC netlist also supports the following built-in math 

library functions: 

Use the following syntax for a function definition. 

SYNTAX: 

+ (plus) 

- (minus) 

* (asterisk) 

/ (slash) 

% (percent) 

^ (caret) 

addition 

subtraction 

multiplication 

division 

percentage 

exponential value 

Operands Numbers, parameters, or values 

returned from function calls. 

Parentheses Groups any part of the expression to 

change the order of the operations. 

acos cbrt floor pow 

acosh ceil hypot rint 

asin cos log sin 

asinh cosh log10 sinh 

atan exp log1p sqrt 

atan2 expm1 log2 tan 

atanh fabs logb tanh 

define func_name (arg1, arg2, ..., arg_n) = expression; 



Other Statements 

Initial Condition 

EXAMPLE: 

define F(x) = x * 1e-15; 

param c1:20; 

(c=F(10))(nn=A); 

(c=F(c1))(nn=B); 

(c=F(c1 + 10))(nn=C); 

This section explains statements that you can use to specify: 

■ an initial condition on a node. 

■ a node to be simulated in PWL mode. 

■ sense amplifiers. 

■ additional netlists. 

SYNTAX: 

ic node_name value; 

EXAMPLE: 

ic APLL 4.5; 

The example applies an initial condition of 4.5 volts to node 

APLL. 

DESCRIPTION: 

In EPIC netlist format, you can specify an initial condition by 

using the command ic, followed by the node name and value. You 

can specify ic statements inside a subcircuit definition or in the 

top level. For statements specified at the top level, you can use 

the hierarchical node name. You can also specify an initial 

condition in the configuration file.

NOTE: PathMill does not accept initial conditions. 

PWL Specification 

Sense Pair 


SYNTAX: 

pwl node_name_1 [node_name_2...]; 

Other Statements 75 

node_name Name of the node to which the initial 

condition is attached. 

value Voltage value assigned to the node at 

time zero. 

EXAMPLE: 

pwl APLL; 

In the example, the node APLL is simulated in PWL mode. 

DESCRIPTION: 

In the EPIC netlist format, you can specify a node to be 

simulated in PWL mode with the pwl command, followed by a 

node name. You can also specify a PWL node in the configuration 

file. 

NOTE: PathMill does not accept PWL mode in a netlist. 


node_name Name of the node to be simulated in 

PWL mode. 

NOTE: The gate capacitance is integrated over the supply voltage range 

including the subthreshold low portion. As a result, the average 

is higher for higher voltages. It should always be less than the 

strong inversion maximum C ox value. 

SYNTAX: 

sense_pair element_name_1 [element_name_2]; 



Include Files 

EXAMPLE: 

sense_pair t1 t2; 

This example defines the transistors t1 and t2 as a sense pair. 

DESCRIPTION: 

In EPIC netlist format, you can specify a sense pair by using the 

sense_pair command, followed by two element names. This 

command specifies sense amplifiers. You can also specify a sense 

pair in the configuration file. 

NOTE: PathMill does not accept the sense_pair command. 


element_name Specifies the name of the 

transistors defined as a sense pair. 

SYNTAX: 

include filename 

DESCRIPTION: 

In the EPIC netlist, use the include statement to include 

another netlist file. The included file must also be an EPIC 

netlist. The netlist compiler reads the contents of the included 

file at the location where you specify the include statement. 

Nested include files are allowed. A netlist recursively including 

itself is not allowed. 


filename Specifies the name of an additional 

netlist. 

NOTE: The .inc statement is for HSPICE format.

Chapter 3 

Netlist Compiler and 

Translators

78 Chapter 3 Netlist Compiler and Translators

Overview 

Compiled Files 

Overview 79 

This chapter describes the EPIC netlist compiler and provides 

information about the netlist formats supported by the compiler. 

It also shows you how to work with Cadence SPF files, device 

parameter format files, and to set up an EPIC binary file. 

Information about utilities that translate SPICE, EDIF and 

Verilog netlists to EPIC netlists is also provided, as well as how 

to use the Ecrypt utility for encrypting netlist files, which can be 

read by the compiler. 

Netlists are compiled every time you start an EPIC simulator. 

When you use the compiler, a message appears on the screen 

indicating the compiler is in use. The compiler does not produce 

intermediate files during compilation. 

The netlist compiler supports the following netlist formats, 

shown with their abbreviations. 

Netlist Format Abbreviation 

LSIM lsim 

SPICE spice 

Verilog vlog 

EDIF edif 

EPIC epic 

Cadence SPF cspf 

To specify netlist formats, use the -n command-line option. 

SYNTAX: 

-nformat 


80 Chapter 3 Netlist Compiler and Translators 

EXAMPLE: 

-nspice net1 -nvlog net2 

This example reads net1 as a SPICE netlist and net2 as a 

Verilog netlist. 

If you specify a netlist without a format option (that is, -n is not 

followed by a format), use a filename with one of the following 

suffixes to indicate a particular format. 

Format Filename Suffix 

LSIM .N, .n 

SPICE .sp, .spi, .SP, .SPI 

Verilog .v, .V 

EDIF .ed, .edif, .ED, .EDIF 

EPIC .en, .EN 

Cadence SPF .spf, .dspf, .cspf, .hspf 

Device Parameter Format .dpf 

EPIC Binary File .edb 

A filename with either no extension or with a different extension 

from those listed above indicates the netlist is in EPIC netlist 

format. 

EXAMPLE: 

-n net1.spi net2.v net3.x 

This example reads net1.spi as a SPICE netlist, net2.v as a 

Verilog netlist, and net3.x as an EPIC netlist. 

You can specify netlists of mixed format with the -n commandline 

option. 

The netlist compiler can read LSIM and SPICE format netlists, 

but separate licenses are required for each format. For Verilog or 

EDIF netlists, the netlist compiler will first call vlog2e or

Compiled Files 81 

edif2e, respectively, to convert the netlist to EPIC format before 

reading it in; however, no EPIC netlist file will be produced. 

The netlist compiler provides library support. You can specify 

netlist library directories in three ways: 

■ Use the environment variable EPIC_CELL_LIB_PATH 

■ Set the environment variable EPIC_CELL_LIB_PATH with 

the netlist control option epic_cell_lib_path 

■ Use the -L command-line option when running most EPIC 

tools. (For details, see the reference guide for the tool you are 

using.) 

Specify library directories as a list of directory names separated 

by colons (:). 

Directories are searched in the same order in which you list 

them. The directories specified in EPIC_CELL_LIB_PATH are 

searched first before those specified in the -L command-line 

option. The EPIC_CELL_LIB_PATH, if set externally, overrides 

the setting in the netlist. Whenever there is an instantiation, 

and no subcircuit definition or functional model of that name is 

found, the netlist compiler searches the library directories for a 

file with that element name, with or without a recognized 

extension, as described previously. The search occurs in the 

following order: no extension, .en, .EN, .sp, .SP, .spi, .SPI, .n, 

.N, .ed, .ED, .edif, .EDIF, .v, .V. 

The netlist compiler can detect encrypted netlist files (.eef) with 

the Ecrypt utility. For information about this utility, see “The 

Ecrypt Utility” on page 131. 



LSIM Netlist Features and Limitations 

LSIM supports: 

■ four terminal transistors 

■ parameter passing in LSIM is supported 

■ EPIC stimulus in a separate file 

LSIM does not support: 

■ the BUILDMODE statement, an LSIM compiler directive 

that allows you to select between multiple simulation models 

■ EPIC stimulus inside an LSIM netlist 

EXAMPLE: 

CELL A A(d=.5){ 

IN a; 

OUT b; 

R R1 r=d*10 s=a d=b; 

} 

The parameter d in the cell calculates the value of the r 

parameter. 

SPICE Netlist Characteristics 

Characteristics of a SPICE netlist include: 

■ All ports in subcircuits are bidirectional. To instantiate a 

SPICE subcircuit in an EPIC netlist, use (bt=...). 

■ The following elements are supported: resistor, capacitor, 

diode, BJT, MOSFET, and independent source (only dc, pwl 

and pulse). 

■ The negative node of an independent source is assumed to be 

ground. 

■ Unsupported statements are saved in the .ignore file.

HSPICE Netlist Syntax 

General Control Options 

Input File Control Options 

HSPICE Netlist Syntax 83 

This section provides information about HSPICE netlist syntax. 

All essential HSPICE syntax is supported. 

The EPIC netlist compiler interprets only EPIC netlist control 

options and those in the following list. All others are ignored. 

ASPEC DEFL DEFW SEARCH 

DEFAD DEFNRD SCALE TNOM 

DEFAS DEFPD SCALM WL 

If SCALE and one or more DEFAD, DEFAS, DEFL, DEFNRD 

DEFPD, or DEFW options are defined, SCALE must be defined 

first; otherwise, the MOSFET default will not be scaled properly. 

The input file control options are: 

.DCVOLT .IC .OPTIONS 

.END .INCLUDE .PARAM 

.ENDS .LIB .SUBCKT 

.EOM .MACRO 

.GLOBAL .MODEL 

NOTE: .ALTER is treated the same as .END, and subsequent options are 

ignored. 

The SPICE netlist reader reads standard SPICE and HSPICE 

netlists with commands placed anywhere in the netlist. 

Specify all netlist control options in the SPICE netlist using the 

.options statement. Define an .options statement, or 

statements, at the beginning of the SPICE netlist. For 



Analysis Options 

Output Control 

information about control options, see “Netlist Control Options” 

on page 45 and “SPF Control Options” on page 88. 

.options ctrl_opt_name= “value” ... 

EXAMPLE: 

.options case=”U” bus_notation=”” 

min_cap_value=”10f” 

The EPIC netlist compiler understands .TRAN and .TEMP. 

Transient monte carlo, transient temperature sweep, transient 

parameter sweep, and transient optimization are not supported. 

You can use the .TRAN statement simulation end point to set the 

simulation end time (for TimeMill and PowerMill only). This is 

equivalent to the -t command-line option. 

The EPIC netlist compiler supports output control in HSPICE 

netlists with the following features: 

■ .PRINT, .PLOT, and .PROBE statements are supported and 

are treated exactly the same. 

■ Transient analysis only. Statements specifying other types of 

analyses (DC, AC, etc.) will be ignored. 

■ In addition to supporting the .PRINT TRAN v(a,b) 

expression, the simulator also supports the general .PRINT 

label_name=par(f(x1, x2, x3,...)) expression, where operands 

in the function “f” can be pin currents, branch currents, node 

voltages, or some label previously defined by a .PRINT 

statement. Operators can be ^, +, -, *, /, sin(), cos(), and so on. 

■ The label type (math, voltage, or current) is automatically 

detected and incorporated into the signal name and attribute 

in the .index line printed in the EPIC .out file. For example, 

for the statement .PRINT diff=par(v(a)-v(b)), the signal 

name “v(diff)” and attribute “v” are used in the output file.

Elements 

HSPICE Netlist Syntax 85 

This section shows how elements are supported by the EPIC 

netlist compiler. 

Rxxx - Resistor 

You can specify either the resistance or the model to 

automatically calculate the resistance. 

Cxxx - Capacitor 

You can either specify capacitance directly or use the 

automatic calculation if the model is given. 

Lxxx - Inductor 

Supported in linear form only. 

Kxxx - Mutual Inductor 

Supported in standard HSPICE format. 

Txxx - Ideal Transmission Line 


Vxxx - Independent Voltage Source 

All source types except AC are supported. The syntax for 

each supported source type is found in Appendix D. For 0v 

dc voltage source, if no current controlled elements are 

present in the circuit, it will be discarded. Its two 

terminals will be connected together. 

Ixxx - Independent Current Source 

All source types except AC are supported. 

Exxx - Voltage Controlled Voltage Source 

Supported with the ACE engine in the following forms: 

linear, polynomial, pwl, transformer, behavior, delay, linear 

combination, multi-input gate and laplace function. 

Gxxx - Voltage Controlled Current Source 


linear, polynomial, pwl, behavior, vcr, vccap, multi-input 

gate and laplace function. 



Fxxx - Current Controlled Current Source 


linear, polynomial, pwl, delay, and multi-input gate. 

Hxxx - Current Controlled Voltage Source 


linear, polynomial, pwl, and multi-input gate. 

Dxxx - Diode 

With the ACE engine, the netlist compiler reads in level 1, 

level 2 and level 3 diodes. No conversion is performed. 

Without ACE, the level 2 diode is discarded; the level 3 

diode is converted to capacitor. If keep_junc_diode is not 

set, level 1 diode is converted to capacitor. The netlist 

compiler assumes that the diode is reverse biased; cjo and 

cjswo are calculated average values. (For information about 

reading diodes as capacitors, see “Reading Diodes as 

Capacitors” on page 20.) 

Qxxx - BJT 

Without ACE, this is ignored by default. 

Mxxx - MOSFET 

The EPIC netlist format permits the use of three terminals 

to describe the connection of a four-terminal MOS device. 

The default bulk name is VDD for PMOS and GND for NMOS. 

This default connection differs from HSPICE. 

Jxxx - JFET or MESFET 


Xyyy - Subcircuit Element 


NOTE: Uxxx - Lossy Transmission is not supported by the EPIC netlist 

compiler.

Cadence SPF File 

SPF Processing 

Cadence SPF File 87 

The EPIC netlist compiler interprets a file with a .cspf extension 

as a Cadence SPF file. Here is an example of how to specify an 

SPF file as part of your run: 

powrmill -n example.cspf 

NOTE: The .cspf extension tells the netlist compiler that this is a 

Cadence SPF file. Without the .cspf extension, you must specify 

-ncspf filename. 

The SPF information for a particular netlist is discarded if the 

EPIC netlist compiler detects any one of the following 

connectivity errors: 

■ The net does not exist in the netlist. 

■ The pin or instance pin does not exist in the netlist. 

■ A pin or instance pin does not connect to the net in the 

netlist. 

■ The SPF information for a net describes an unconnected 

network. 

For each SPF net, the netlist compiler creates a subcircuit 

definition containing all the parasitics and creates an instance of 

the subcircuit at the top level. The SPF net name is used for the 

subcircuit definition name. The instance name is in the format 

“cspf”, where XXX is the SPF net name. To specify the 

instance port connections, use the EPIC back-annotation naming 

convention, as follows: 

P- Pin identifier 

I- Instance pin identifier 

: Instance port delimiter 



SPF Control Options 


EXAMPLE 1: 

: * 

*|NET A 1.028E-04FF 

*|P (A O 0.00E00PF 30.39 3.00) 

*|I (XI4:PA0 XI4 PA0 I 0.00E00PF 19.67 2.67) 

*|S (A:2 30.31 2.67) 

R1 A A:2 1.37614E-03K 

RD1 A XI4:PA0 0.00E00K 

CD1 XI4:PA0 VSS 0.00E00PF 

C1 A VSS 4.81112E-05PF 

C2 A:2 VSS 6.01185E-05PF 

EXAMPLE 2: 

(subckt=A)(bt=A,XI4:PA0){ 

(t=R)(en=R1)(so=A)(dr=A:2)(r=1.37E-03K); 

(t=R)(en=RD1)(so=A)(dr=X14:PA0)(r=0.00E00KK); 

(c=4.811E-05PF)(nn=A); 

c=6.011E-05PF)(nn=A:2); 

} 

(ef=A)(en=cspf)(bt=P-:A,I-XI4:PA0); 

The SPF net in Example 1 is treated like an EPIC subcircuit in 

Example 2. The instance’s first biput port is connected to "P-:A" 

(net A), and the second biput port is connected to "I-X14:PA0" 

(port PA0 of instance X14). 

This section provides descriptions of the control options that can 

be used in the SPF file. 

SYNTAX: 

ctrl_opt cspf_cap_select: netline | sum | warning 

EXAMPLE: 

*|NET x1.out 20ff 

*|GROUND_NET vss 


C2 x1.out vss 2FF





If the control option is set to sum, 8ff will be added to net 

x1.out. If netline is used, then 20ff will be added to the net. If 

warning is used, then a warning will be printed because the two 

values differ by more than 1%. In this case the sum of the cap 

values will be used. 

DESCRIPTION: 

This option affects only those nets in which the capacitance can 

be represented as a single value.You can select one of three 

settings for SPF back-annotation of capacitance values. 


netline Selects the capacitance number on the 

netline. The netline is the line that 

starts with *|Net. 

sum Sums all the capacitance values 

associated with the net 

warning Issues a warning if the netline and sum 

values differ 

All of the following conditions must be present to collapse SPF 

into a single capacitance value: 

■ SPF net is not reduced SPF (RSPF.) 

■ No instance pins are defined for the net. 

■ No subnodes are defined for the net 

■ Only capacitor elements are defined for the net 

SYNTAX: 

ctrl_opt cspf_name_map_proc:“value”; 

EXAMPLE 1: 

ctrl_opt cspf_name_map_proc:“nm.tcl”; 

This example specifies the name-mapping procedure file nm.tcl. 



cspf_net 

EXAMPLE 2: 

/* FILE: name_map.tcl */ 

proc cspf_name_map {a} { 

regsub /X [string toupper $a] {} b 

return $b 

} 

This name mapping procedure strips leading Xs from the 

instance name and converts them to uppercase in the SPF file. 

DESCRIPTION: 

For the netlist compiler to correctly process connectivity 

information, the net names, pin names, and instance pin names 

must match the hierarchical name in the original netlist. If there 

is a mismatch, you can use a name mapping procedure to correct 

it. The name mapping procedure is a TCL procedure called 

cspf_name_map_proc. It takes one argument, the name (pin 

name or instance pin name) in the SPF file, and returns a name 

that matches the hierarchical name in the original netlist. 

Use this control option to specify the filename containing the 

name mapping procedure. The netlist compiler will 

automatically call the procedure for every net name, pin name, 

instance pin name, driver name, and load name encountered. 

An example of the name mapping file (cspf_name_map.tcl) can be 

found in EPIC_HOME/machind/lib/epic. 

SYNTAX: 

ctrl_opt cspf_net: “value” 

EXAMPLE 1: 

ctrl_opt cspf_net:"A[*]"; 

This example back-annotates SPF for nets matching A[*]. 

EXAMPLE 2: 

ctrl_opt cspf_net:"B C D"; 

This example back-annotates SPF for nets B, C & D.



DESCRIPTION: 


This option specifies the nets to which you want parasitic 

information back-annotated in the original netlist. If you do not 

specify this option, all nets found in the SPF file will be 

processed. You can use this option more than once. Wild cards 

are allowed in the net name. 

SYNTAX: 

ctrl_opt spf_disable_net:“value”; 

EXAMPLE: 

ctrl_opt cspf_disable_net:“a b c*”; 

DESCRIPTION: 

This control option specifies nets in the SPF file to be ignored 

during back-annotation. Wildcards are allowed in the net name. 

The cspf_net and cspf_disable_net options can be used 

together. When you use both options, all nets that match those 

specified in cspf_net will be back-annotated, and those specified 

in cspf_disable_net will not. 

NOTE: If a net is specified in both cspf_net and cspf_disable_net, it 

will not be back-annotated. 

SYNTAX: 

ctrl_opt cspf_process_ccap; 

DESCRIPTION: 

This option activates netlist compiler routines that process all 

coupling capacitors in SPF nets. By default, the compiler ignores 

all coupling capacitors in SPF nets. 

The split_floating_cap option affects the coupling capacitors in 

SPF nets if cspf_process_ccap is also specified. 



SPF Netlist Reader Limitations 

This section describes the limitations of the SPF netlist reader. 

The limitations are: 

■ Limited source-to-drain connection checking. See the 

“Source-to-Drain Checking” section that follows. 

■ Only DelayMill can handle multiple drivers in RSPF files. All 

other EPIC tools will probably fail to recognize multiple 

drivers without issuing an error message. 

Source-to-Drain Checking 

If the netlist compiler detects any mismatch in source-to-drain 

connections described in the transistor netlist and the Cadence 

SPF file, it automatically makes corrections, but the net name 

specified must be the highest level name. 

EXAMPLE: 

/* transistor netlist */ 

(subckt=test)(it=A)(ot=B) { 

(t=p)(en=p1)(so=A)(dr=B).... 

... 

} 

(ef=test)(en=test1)(it=n1)(ot=n2); 

Use the following format for the Cadence SPF file: 

*Cadence SPF file 

*|NET n1... 

*|p1:d... 

R1 p1:d n1:1 100 $ n1 is connected to source in 

netlist ... 

The mismatch in the following Cadence SPF file cannot be 

detected. 

* Cadence SPF file 

*|NET test1:A $ test1:A is the same as n1 

*|l p1:d 

R1 p1:d test1:A:1 100

Common SPF Warnings 


This section lists and describes common SPF warnings. 

Connectivity Error 

When you back-annotate an SPF net, the SPF net must have the 

same number of instance pins as the real net, for the particular 

level of hierarchy involved. If connections are made to higher 

levels of the netlist, then the SPF net information must include 

a pin statement. The SPF net must also be connected. If the 

connectivity in the RC network is disjoint, a message appears, as 

shown in the following example. 

EXAMPLE: 

WARNING:0x2020807c:SPF connectivity error on 

node’topi’ 

spf net ’topi’ has the following missing instance 

pins: 

- x3.m1:g (connecting back to x1:i) 

- x3.m0:g (connecting back to x1:i) 

WARNING:0x2020807e:SPF connectivity error on 

node’topi’ 

spf net ’topi’ is discarded because it contains 

2 disconnected components: 

- component # 0 contains the following pins: 

x4:i 

- component # 1 contains the following pins: 

x1:i 

x2:i 

x3:i 



Duplicate Global Node 

A net that traverses several levels of hierarchical is backannotated 

with several individual net statements, and if you try 

to back-annotate the same individual net section again, this 

error message appears. 

EXAMPLE: 

duplicate global node I-x1.m0:d 

duplicate global node I-x1.m1:d 

Net Does Not Exist 

The net cannot be located in the main circuit database. This can 

happen if the hierarchy character in the SPF file is not the same 

as in the main circuit netlist. 

EXAMPLE: 

WARNING:0x2020807b:SPF net junk does not exist. 

Discarded. 

Hierarchical SPF Back-Annotation 

Hierarchical SPF (HSPF) back-annotation is similar to the 

normal (flat) SPF back-annotation with two exceptions: 

■ The SPF file is used to describe parasitics inside all 

instantiations of a module 

■ Back-annotation is done for all instances of the module 

Before using an SPF file for hierarchical back-annotation, make 

sure the SPF file does not contain any connectivity errors. To 

clear errors: 

1 Use the -ncspf command line option to force the hierarchical 

SPF file to be interpreted as a normal SPF file 

2 Use the -m command line option to specify the top-level 

module name.


3 If necessary, use the cspf_name_map_proc control option to 

specify a TCL procedure to resolve any name mapping issues. 

The same TCL procedure will also be needed for hierarchical 

back-annotation. 

4 After making sure the SPF file is cleared of errors, use the 

command-line option -nhspf or name the SPF file with the 

.hspf extension to prepare the SPF file for hierarchical backannotation. 

If the SPF file already has .SUBCKT/.ENDS statements, the 

netlist compiler will automatically use this information. 

NOTE: The netlist compiler uses only the module name and ignores 

everything else on the .subckt line. 

SPF for multiple modules can also be described in one SPF file 

with multiple .SUBCKT/.ENDS statements. If there is no 

.SUBCKT/.ENDS statement in the SPF file and you do not want 

to edit the SPF file to add these statements, you an rename the 

filename using the module name as the filename prefix. 

In the following example, mux04.spf is the SPF file for module 

mux04. 

EXAMPLE 1: 

1% pathmill -n netlist -ncspf mux04.spf -m mux04... 

This example runs PathMill analysis only on module mux04. The 

file mux04.spf is used as a normal Cadence SPF file. 

EXAMPLE 2: 

2% pathmill -n netlist -nhspf mux04.spf... 

In this example, the PathMill analysis is done on the full 

chip.The file mux04.spf is specified as hierarchical SPF file and 

will be back-annotated to every instance of mux04. 

NOTE: You cannot selectively back-annotate certain instances. If 

hierarchical SPF information is provided for one module, then 

all instances of that module will get back-annotation 

information. 



Device Parameter Format File 

The Device Parameter Format file (.dpf) is a flattened listing of 

transistors with post-layout parameter values. The format is 

similar to SPICE. After reading in the .dpf file, the netlist 

compiler replaces the corresponding transistor parameter value 

with the extracted value. 

The following example of a netlist file shows two inverters 

chained together. 

*net.spi 

.global vdd 

.subckt inv in out 

mp vdd in o vdd pmos w=11.24u 1=0.4u as=0 ad=0 ps=0 pd=0 

mn gnd in o gnd nmos w=7.80u 1=0.4u as=0 ad=0 ps=0 pd=0 

.ends 

x1 a b inv 

x2 b c inv 

.end 

The .dpf file for this circuit is net.dpf and contains a listing of the 

transistors with extracted as, ad, ps and pd values, as follows: 

*net.dpf 

x1.mp vdd a b vdd pmos ad=1.559p as=1.559p pd=0.784u ps=0.784u 

x1.mn gnd a b gnd nmos ad=1.245p as=1.245p pd=1.632u ps=0.784u 

x2.mp vdd b c vdd pmos ad=1.559p as=1.559p pd=0.784u ps=0.784u 

x2.mn gnd b c gnd nmos ad=1.245p as=1.245p pd=1.632u ps=0.784u 

.end 

The command syntax for power simulation for this circuit 

including the .dpf file is: 

powrmill -nspice net.spi -ndpf net.dpf ... 

The netlist compiler uses the element name in the .dpf file to 

locate the corresponding transistor inside the database. It uses 

the node name to check if the transistor’s source and drain


Device Parameter Format File 97 

terminals are swapped. Therefore, the name of the .dpf file must 

conform to the following naming conventions: 

■ The hierarchical separator used in the .dpf file must be the 

same as that used in the original netlist file. 

■ The format of the hierarchical name can be in either topdown 

or bottom-up format. 

You can add an extra character in front of the element name. For 

example, the following names can be used in the previous 

example of a .dpf file: x1.mp, mp.x1, or mx1.mp. 

If you use a different naming convention in the .dpf file, you 

must use the control option dpf_name_map_proc to cause the 

tcl script to convert the element or node names in the .dpf file to 

the format used in the original netlist file. 

NOTE: The naming convention in all .dpf files for a circuit must be 

consistent. 

The following control option can be used with the .dpf file. 

SYNTAX: 

ctrl_opt dpf_name_map_proc:filename.tcl 

EXAMPLE: 

ctrl_opt dpf_name_map_proc:map.tcl 

The map.tcl file is the tcl script containing the tcl name 

mapping procedures. 

DESCRIPTION: 

This control option is used to convert the element or node names 

in the .dpf file to the format used in the original netlist file. 

An example of the name mapping file (dpf_name_map.tcl) can be 

found in EPIC_HOME/machind/lib/epic. 



EPIC Binary File 

The EPIC binary file is used to repeat simulation of the same 

netlist design under the same tool. Compile time can be as much 

as ten times faster if you use the binary file. 

The EPIC binary file is always generated by the EPIC netlist 

compiler. The file consists of two files: a header file 

(hd_filename.edb) and a data file (filename.edb). By default, the 

netlist compiler compresses the data file with gzip. 

The netlist compiler interprets a file with a .edb extension as an 

EPIC binary file. You need only to specify the data filename on 

the command line; the compiler derives the header filename from 

the data filename. 

EXAMPLE: 

powrmill -n example.edb 

This example shows you how to include the example.edb binary 

file in the run. 

NOTE: Before you use the EPIC binary file, you need to consider the 

following characteristics: 

■ All netlist-related control options and configuration 

commands affect the content of binary files. You cannot 

change any of the control options when you choose to have 

the netlist compiler read the binary file instead of 

recompiling netlist files. 

■ The EPIC binary file is platform-dependent. 

■ The EPIC binary file is tool-dependent. Thus, binary files 

generated by PowerMill are not compatible with PathMill. 

■ You cannot compile another netlist when using a binary file.

Control Options 

db_file 


SPICE Netlist Translator 99 

The following control options can be used in the EPIC binary file: 

SYNTAX: 

ctrl_opt db_file:filename; 

This control option specifies the binary file’s prefix and triggers 

the generation of the file. 

EXAMPLE: 

ctrl_opt db_file:”example”; 

This example causes the netlist compiler to generate the header 

file hd_example.edb and the data file example.edb. 

SYNTAX: 

ctrl_opt dont_compress_db:[0|1]; 

This option controls the compression of the netlist database file. 

By default, netlist database files (.edb) are compressed by gzip. 

EXAMPLE: 

ctrl_opt dont_compress_db:”1”; 

This example causes the netlist compiler to generate the 

uncompressed header file hd_example.edb and the uncompressed 

data file example.edb. 

SPICE Netlist Translator 

This section describes how to translate a SPICE netlist to an 

EPIC netlist using the EPIC spice2e utility. 

This utility reads three files that must be in the local directory: 

modelfile, aliasfile and defaultfile. Each file modifies the 

translation in a specific way. These filenames are reserved for 



Model File 

spice2e usage and cannot be used for any other purpose in the 

local directory. 

SYNTAX: 

model subcircuit_name 

[inputs n] 

[outputs n] 

[biputs n] 

[state n] 

[external] 

end model 

EXAMPLE 1: 

model SUBCKT100 

inputs 2 

outputs 1 

biputs 8 

inputs 3 

outputs 2 

state 1 

end model 

This example defines SUBCKT100 as a subcircuit with five input 

pins, three output pins, and eight bidirectional pins. The pins 

are listed in the following order: the first two pins are input pins, 

the third is an output pin, pins 4 through 11 are bidirectional, 

and so on. SUBCKT100 has one state and is expanded when 

referenced. 

You can use the abbreviation .sub (or .SUB) in place of .SUBCKT 

in your SPICE file. You can use either all lowercase or uppercase 

characters for this abbreviation. 

EXAMPLE 2: 

model INV 

inputs 1 

outputs 1 

external 

end model

Alias File 


This example defines a second subcircuit, INV, that has one 

input and one output pin. There are no bidirectional pins and no 

state information. The keyword external suppresses the 

translation of the subcircuit and calls a model or expects a 

subcircuit definition from another netlist file during simulation. 

DESCRIPTION: 

The model file contains the following subcircuit information: 

■ Number of input pins, output pins, and biput pins 

■ Pin ordering for subcircuit interface 

■ Number of states 

■ Whether the subcircuit should be expanded or a model 

substituted from a model library 

SYNTAX: 

set original_name as translated_name 

EXAMPLE: 

set 0 as gnd 

set 1 as vdd 

set VDD as vdd 

set GND as gnd 

set vss as gnd 

set %VCC! as vdd 

set %VBB! as gnd 

set VCC as vdd 

set 200 as RDN 

In this example, the first line translates all nodes named 0 in the 

SPICE netlist to GND in the EPIC netlist. The sixth line 

translates all references of %VCC! in the SPICE netlist to VDD in 

the EPIC netlist. 

DESCRIPTION: 

The alias file contains aliases for nodes in the SPICE netlist. The 

set command maps node names that are not allowed in the EPIC 



netlist to legal EPIC node names. The most common example is 

translating !VDD, a standard name used in layout-versusschematic 

programs, to either vdd or VDD, as required by EPIC 

tools. During translation, node names in the SPICE netlist 

specified in alias file set commands are converted to the 

alternate node name. 


original_name Specifies the node name in the 

SPICE netlist 

translated_name Specifies the new node name in the 

EPIC netlist 

SYNTAX: 

alias original_name as vdd | gnd 

EXAMPLE: 

alias CCD as vdd 

alias Q[0] as gnd 

In this example, spice2e recognizes the node names CCD and 

Q[0]. They are kept in the EPIC netlist as multiple names of 

power nodes for separate power reporting. 

At the same time, spice2e generates the following configuration 

file commands: 

set_vdd CCD 

set_gnd Q[0] 

The name of the configuration file is specified by the 

spice2e -b or spice2e -o command arguments. You must 

include the configuration file generated by spice2e when 

running EPIC tools. 

DESCRIPTION: 

Use the alias command for multiple VDD and GND nodes. In the 

EPIC netlist, you can use multiple names for VDD and GND 

nodes, which indicate power nodes. The spice2e translator 

associates the related capacitors so they are not separated from 

the capacitors connected to them. The original node names are 

kept in the EPIC netlist.

Default File 

Diodes 


Here are examples of lines translated by spice2e. 

SPICE example: 

C1 RCD CCD 1f => spice2e => (C=1) (NN=RCD); 

MOS example: 

M1 3 4 CCD CCD pmos... spice2e => (T=pmos) (...) (SO=CCD)... 

The default file specifies information required to map SPICE 

MOS, diode elements, resistors, and capacitors to EPIC netlist 

format. 

To specify the default length and width of MOS devices, and to 

replace SPICE MOS model names with EPIC MOS model names, 

use the following syntax: 

spice_model default_width default_length EPIC_model 


spice_model Specifies the name of the SPICE 

model 

default_width Specifies the default width in 

microns 

default_length Specifies the default length in 

microns 

EPIC_model Specifies the EPIC model name 

that replaces the SPICE model 

name 

You can keep the diodes in EPIC netlists by using the 

spice2e -d command argument if both of the following 

conditions are true: 

■ These diodes are not source or drain to substrate diodes 



■ These diodes are nongeometric (area AREA and peripheral 

PJ are dimensionless factors, HSPICE level 1) diodes 

If the spice2e -d command argument is not used, by default 

spice2e converts diodes to capacitors. This means the diode 

capacitance parameters must be placed in the default file for 

conversion. Source or drain to substrate diodes or geometric 

diodes (area AREA and peripheral PJ are values with units, 

HSPICE level 3) must be converted to capacitors. 

There are two ways to compute the capacitance values when a 

diode is converted. The first, less accurate method, is to use the 

following formula: 

=Area x cj + Perimeter x cjp 

You need to provide the voltage average capacitances cj and cjp. 

You cannot directly apply the zero-biased capacitance model 

values cjo and cjp in the preceding formula since the capacitance 

value will be too large. Instead, the average values should be 

roughly 0.67 times the zero-biased values. 

Use the following syntax to specify the values in the default file: 

SYNTAX: 

spice_diode_model cj cjp EPIC_diode_model 


spice_diode_model Specifies the name of the SPICE 

diode model 

cj Specifies the average bottom 

junction capacitance 

cjp Specifies the average sidewall 

peripheral capacitance 

EPIC_diode_model Specifies the EPIC model name 

that replaces the SPICE model 

name


The second method applies a more accurate calculation for 

computing the capacitance by using the equations provided for 

the cja and cjsw commands (see page 183). The variables in the 

equations are described in the following syntax: 

SYNTAX: 

spice_diode_model keyword=value ... EPIC_diode_model 

Keyword Definition 

cjo, cj, or cja Zero-bias junction capacitance epr 

unit junction bottom area in farads 

per unit area. The default value is 

0. 

cjp or cjsw Zero-bias junction capacitance per 

unit junction periphery in farads 

per unit junction periphery (PJ). 

The default is 0. 

pb, phi, vj, or pha Area junction contact potential in 

volts. The default is 0.8 volts. 

php Periphery junction contact 

potential in volts. The default value 

is that of pb. 

mj, m, or exa Area junction grading coefficient. It 

is dimensionless with a default 

value of 0.5. 

mjsw or exp Periphery junction grading 

coefficient. It is dimensionless with 

a default value of 0.33. 




vdd Supply voltage in volts. The default 

is 5.0. 

level Diode model level. The default is 1. 

Level 1 represents a nongeometric 

diode model and is translated to 

EPIC diodes by the spice2e -d 

command argument. Other levels 

represent a geometric diode model 

not supported by EPIC tools and 

can be converted only to capacitors. 

Adding the level keyword to the 

default file can cause the 

spice2e -d command argument to 

be overlooked and mistranslate the 

geometric diodes to EPIC diodes. 

The definitions for spice_diode_model and EPIC_diode_model are 

the same as in the first method.

Resistors and Capacitors 

SYNTAX: 

spice_model keyword=value ... EPIC_model 


You can use the keyword-value pairs to specify the following 

parameters: 


SHRINK Shrinking factor with a default 

value of 1.0 

RSH Sheet resistance per square. The 

default is 0.0. 

DLR The difference between drawn 

length and actual length used for 

resistor calculation. The default is 

0.0 

DEL The difference between drawn 

width and actual width or length 

used only for capacitors. The 

default is 0.0 

DW The difference between drawn 

width and actual width. The default 

is 0.0. 

COX Bottom-wall capacitance. The 

default is 0.0. 

CAPSW Side-wall capacitance. The default 

is 0.0. 

The value 1.0 is used for SCALM. 



Default File Example 

Figure 1 shows an example of a default file. 

ptr 1100 200 P 

ntr 500 200 N 

PSH 1000 200 P 

NSH 500 200 N 

PMOS 500 200 P 

NMOS 200 200 N 

P 500 200 P 

N 200 200 N 

DIODE1 1.2e-15 0.6e-15 DIODE1 

DIODE2 cjo=2.5e-16 cjsw=2.8e-16 exp=0.23 exa=0.55 phi=0.9 

php=0.88 vdd=3.5 level=1 DIODE2 

Figure 1 Sample default file 

The first line translates all PMOS in the SPICE netlist that have 

the model name ptr to the model P in the EPIC netlist. The first 

line also assigns all PMOS in the SPICE netlist a default width 

of 11 microns and a length of 2 microns whenever the width and 

length are not specified. The second line translates NMOS 

named ntr in the original SPICE netlist to the model N in EPIC 

format and assigns them the default width of 5 microns and the 

default length of 2 microns. 

The next to last line specifies an average area capacitance factor 

of 1.2 femtoFarads per square micron and an average junction 

periphery capacitance of 0.6 femtoFarads per micron for the 

diode named DIODE1 in the SPICE netlist. The last line specifies 

all the parameters needed for spice2e to perform an average 

calculation for diode model DIODE2. It is recommended that you 

use this method for more accurate calculation.

spice2e Command 


The spice2e command translates a SPICE netlist into an EPIC 

format netlist. 

Command Syntax 

SYNTAX: 

spice2e -i spice_netlist 

[-b configfile] 

[-c min_cap] 

[-d] 

[-h] 

[–m main_circuit] 

[-n] 

[-o netlist] 

[-f hspice | precise] 

[-q number] 

[-r] 

[-s] 

[-u m | f ] 

[-R min_res] 

[-1] 

[-2] 

[-A aliasfile] [-D defaultfile] [-M modelfile] 

Command-line Options 

This section describes the command-line options used with 

spice2e. 

-b configfile 

This option instructs spice2e to translate extracted 

capacitor netlist elements (with hierarchical node names) 

to configfile with configuration commands, as follows: 

node_capacitance hierarchical_node_name value 

If there are scale factors or multi-device parameters 

specified for a capacitor, they cannot be printed to the 



configuration file because the parameters might have to be 

re-calculated. The capacitors have to stay in the netlist. 

This option also places corresponding configuration 

commands of translations of other SPICE commands into 

the configfile, such as .PRINT TRAN, V1 1 0 DC, I2 2 gnd, 

and PWL. If you do not use this option, these configuration 

commands are put in a file called xxx.cfg, where xxx is the 

string specified by the -o argument. 

-c min_cap 

This option specifies the minimum capacitance value for 

the EPIC netlist. Any capacitor with a capacitance of less 

than min_cap is discarded. The min_cap value is in 

femtoFarads. This feature is used in conjunction with 

automatic layout extraction programs that generate 

parasitic capacitance values at every node in the circuit. It 

is very useful in saving time and memory when processing 

a circuit with a large number of capacitors. 

-d This option translates SPICE diodes into EPIC diodes. 

Only nongeometric diodes can be translated to EPIC 

diodes. Geometric diodes with a level value other than 1 in 

the default file can be converted only to capacitors. (For 

details, see the section “Diodes” on page 103.) If this option 

is not used, spice2e converts SPICE diodes to capacitors, 

and some model parameters must be defined in the default 

file. 

-h This option returns a usage message. 

-i spice_netlist 

This option specifies the SPICE netlist filename. If this is 

not used, spice2e takes the UNIX standard input. This 

option replaces the following UNIX syntax: 

spice2e < spice_netlist 

-m main_circuit 

This option specifies the name of a main circuit (name of 

top-level subcircuit). spice2e assumes that the top-level 

circuit is the main circuit name. This option is required 

when translating a netlist output by Dracula’s LPE 

program. It strips the definition of the named subcircuit.


-o netlist 

This option specifies the EPIC netlist filename. spice2e 

places the converted SPICE netlist into this file. If this 

option is not used, spice2e creates UNIX standard output. 

This option (with the -i option) replaces the following UNIX 

syntax: 

spice2e < spice_netlist > netlist 

-f hspice | precise 

This option specifies the type of SPICE netlist being 

translated. Using -p or -f has the same effect. One of the 

major differences is in the parameter passing rules. In the 

HSPICE-like SPICE netlist, the parameter values of the 

instances override the values in the subcircuit definition. 

The default is the HSPICE-like SPICE netlist. Other 

proprietary SPICE names are allowed and will be included 

by special arrangement. 

-r This option specifies the order of the width and length 

parameters in the transistor description of the SPICE 

input file. The default order is width followed by length. 

Use this switch to reverse the reading order to length 

followed by width. 

-u m | f 

This option can be used to override the default units for 

capacitance, width, and length in the input SPICE netlist. 

The -u m option changes the default unit width and length 

from micron to meter. The -u f option changes the default 

unit for capacitance from farad to femtoFarad. The -u mf 

and -u fm options specify both conditions. 

A warning is generated if the resulting capacitance value is 

too small (less than 0.01 fF), or too large (more than 

1x106 fF). 

-1 This option translates floating capacitors. A floating 

capacitor is one that is not connected to a power node. 

Power nodes are those named vdd, VDD, gnd, or GND, and 

nodes set or aliased to these names by the aliasfile set and 



alias commands. By default, no floating capacitors are 

translated. 

NOTE: If you are running PathMill, do not specify this option. 

-2 This option specifies that capacitors not connected to power 

nodes (that is, floating capacitors) are replaced with two 

duplicate capacitors to GND. Without a -2 (or -1) option, 

these floating capacitors are not translated. 

NOTE: The -1 and -2 options are mutually exclusive. 

-q number 

The number value is an integer from 0 to 2047; the default 

is 10. The file spice2e.ignore is created if the SPICE netlist 

contains lines not supported (no translation, ignored) by 

the current version of spice2e. The first word of these 

ignored lines will be printed in the file spice2e.ignore for 

reference. The title line and comment lines are also printed 

up to the specified number of characters. If number is 0, 

the title line and comment lines are not printed. spice2e 

automatically removes the file spice2e.ignore if it is empty. 

-R min_res 

This option, expressed in ohms, specifies the minimum 

resistance value for the EPIC netlist. Any resistance value 

less than min_res is discarded, and the two terminal nodes 

are connected with a net statement. 

-s This option reverts to the old method of handling the 

substrate terminal using configuration commands that 

inform the EPIC simulator about special substrate bias 

conditions. You need to include the configuration file 

generated by spice2e as the last configuration file used. 

The -x argument is needed for EPIC simulations to retrieve 

hierarchical names properly if nodes or elements inside a 

subcircuit are specified in the configuration file using the 

subckt configuration command. The generated


configuration file commands are accepted only by TimeMill 

and PowerMill. 

-n This option prevents the first input line from being 

ignored. 

-A, -D, -M 

These options specify the file or pathnames of the alias file, 

default file, or model file, respectively, if their names are 

not aliasfile, defaultfile, or modelfile, or they do not reside 

in the working directory. 

EXAMPLE: 

spice2e -i alu.spi -o alu.tm -m incdec16 -c 100 

This example translates the SPICE netlist file alu.spi and 

generates an EPIC netlist file called alu.tm. The definition 

for top-level subcircuit incdec16 is removed. Since the –c 

option is specified, all capacitance values in the SPICE 

netlist of fewer than 100 femtoFarads are ignored. 

spice2e uses the default units 10 -12m2 of AS and AD if no 

units are explicitly defined. The default unit for PS and PD 

is 10-6m. EXAMPLE: 

SPICE input: 

MO out in 1 1 p2n W=20.00u l=2.00u AD=160.00p 

+ AS=160.00p PD=36.00u PS=36.00 

aliasfile: 

set 1 as vdd 

defaultfile: 

p2n 10 2 p 

This example produces the following entry in the EPIC 

netlist: 

(t=p)(en=MO)(ga=in)(so=vdd)(dr=out)(w=2000) 

(l=200)(ad=1600000)(as=1600000)(pd=3600) 

(ps=3600) 



NOTE: The units for as and ad are scaled to (.01 micron) 2 in the EPIC 

netlist. The units for ps and pd are scaled to .01 micron. 

Supported SPICE Netlist Syntax 

The following list shows the statements, constructs, and SPICE 

syntax that spice2e can translate from the original SPICE 

netlist to EPIC format: 

BJT Element QXXXXXXX Junction Diode Element (level 

1) DXXXXXXX 

Capacitors CXXXXXXX .MACRO statement 

.END statement MOSFET Element 

MXXXXXXX 

.ENDS statement .PARAM statement 

.EOM statement .PRINT TRAN/DC (to 

configuration file) 

.GLOBAL statement Resistors RXXXXXXX 

.IC (.DCVOLT) V(XXX)= Subcircuit Calls XYYYYYYY 

.INCLUDE statements and 

nested INCLUDE statements 

.SUBCKT statement 

spice2e can also translate independent sources (VXXX, IYYY 

DC, PWL, and PULSE types only). These are translated to 

proper configuration commands in a configuration file. See the 

“spice2e Command” on page 109 for more information about the 

configuration file.


A special comment can be used in the SPICE netlist to indicate 

the signal flow direction for a MOS transistor. 

EXAMPLE: 

MP000 VDD T Y VDD P W=15U L=4U $*S 

MN000 OUT A B VSS N W=10 L=4 $*D 

The preceding lines are translated to: 

(T=P)(EN=MP000)(GA=T)(SO=Y)(DR=VDD)(W=1500)(L=400) 

(DI=S2D); 

(T=N)(EN=MN000)(GA=A)(SO=B)(DR=OUT)(W=1000)(L=400) 

(DI=D2S); 

NOTE: The signal direction information is used only by PathMill. 

Ignored SPICE Netlist Syntax 

Comments To Indicate 

Flow Direction 

Definition 

$*S Signal flows source to drain 

$*D Signal flows drain to source 

There are statements, constructs, and SPICE syntax that 

spice2e does not translate. If they exist in the SPICE netlist, 

they are not converted. 

You can check the spice2e.ignore file after running spice2e to 

see which lines in the SPICE netlist were not converted. (See the 

explanation about the -q number argument in the section 

“spice2e Command” on page 109 for information about 

controlling the printout of the title and comment lines.) For lines 

that were not converted, use EPIC configuration commands to 

model the effects during an EPIC simulation or analysis. 

The spice2e.log file is also created. It keeps real-time messages 

on the standard error (screen) for reference. 



The following list shows the statements, constructs, and SPICE 

syntax that spice2e ignores. 

.AC statement .NOISE statement 

.ALTER statement .OP statement 

Comment statement .OPTIONS statement 

.CONTROL statement .PC statement 

.DC statement .PLOT statement 

.DCVOLT statement (other .PRINT statement (other than 

than "V(XXX)=" syntax) TRAN/DC) 

.DEL LIB statement .SENS statement 

.DISTO statement .SYSTEM statement 

.FOUR statement .TEMP statement 

.IC statement (other than 

"V(XXX)=" syntax) 

.TF statement 

JFET & MESFET elements 

JXXXXXXX 

.TITLE statement 

.LIB library call statement .TRAN statement 

Linear dependent sources Transmission Lines 

GXXXXXXX, EXXXXXXX, 

FXXXXXXX, HXXXXXXX 

TXXXXXXX 

.MODEL statement 

.nodeSET statement 

.WIDTH statement 

SPICE Netlist Syntax to Avoid 

The following list contains statements, constructs, and SPICE 

syntax that spice2e cannot accept. You must remove the 

following syntax from the SPICE netlist before using spice2e. 

■ Fowler-Nordheim Diode Elements (HSPICE level 2) 

■ BJT Models (NPN and PNP) 

■ JFET & MESFET Models 

■ MOSFET Model (PMOS & NMOS)

Substrate Terminal Bias 


spice2e selectively outputs the substrate terminal in syntax 

(BU=...) to the EPIC netlist if the substrate is not power. 

TimeMill and PowerMill automatically handle the bias 

conditions. 

By default, spice2e assumes the substrate terminal (BULK) of a 

MOS is connected to either VDD (for PMOS) or GND (for NMOS). 

The following special bias conditions are exceptions: 

■ The substrate is connected to an electrical source that is not 

a power node (multiple VDD or GND nodes might have 

different names). In this case, the MOS has no body bias 

effects. (spice2e does not consider the possibility of a 

substrate being connected to the electrical drain node for the 

normal operation of circuits because forward bias would 

occur between the substrate and the source.) 

■ The substrate is connected to a node other than a power node 

or the electrical source node. In this case, the body bias is 

determined by the voltage on the substrate node. 

spice2e handles these two special substrate bias conditions by 

keeping the substrate terminal using the (BU=...) syntax in the 

EPIC netlist. TimeMill and PowerMill will handle it correctly. 

Alternatively, you can use the older method of generating a 

configuration file containing bias commands. See the 

information about the -s command-line option in the section 

“spice2e Command” on page 109 for details. 

NOTE: The generated configuration file commands work only with 

TimeMill and PowerMill. 



EDIF Netlist Translator 

This section describes edif2e, the EPIC netlist translator, that 

converts gate-level and transistor-level netlists from EDIF 

format to EPIC format. It is normally automatically called by the 

EPIC netlist compiler for EDIF netlist files, and can also be used 

as a stand-alone utility. 

The edif2e utility supports a Synopsys structured gate-level 

flow for ASIC and custom ICs. Although EDIF can describe 

various electronic design data, including behavior, logic models, 

netlists, schematics, and mask layout, edif2e translates only 

netlist data and ignores all other data. It was specifically 

designed to enable Synopsys Design Compiler users to analyze 

their designs with EPIC tools. 

edif2e supports hierarchical netlist descriptions. It can 

translate both flat and hierarchical netlists, but it does not 

flatten a hierarchical netlist. The hierarchical structure of the 

output is the same as the input. See the Electronic Design 

Interchange Format Version 200, ANSI/EIA 548 publication 

for further information about EDIF. 

NOTE: edif2e does not support encryption or library search. 

Supported EDIF Constructs 

The following EDIF constructs are supported: 

■ Version 200 Level 0 (basic, only literal constants permitted) 

complexity description 

■ Keyword level 0 (no keyword abbreviations) 

■ EDIF rename construct 

■ Conversion from net-based to terminal-based connectivity 

model 

■ Hierarchical netlist description

EDIF Netlist Translator 119 

■ Direction constructs (input, output, or bidirectional) 

■ external construct 

■ EDIF’s view-cell library three-layer structure 

■ status construct 

■ design construct 

■ joined construct 

■ parameter and parameterAssign constructs 

Unsupported EDIF Constructs 

edif2e does not support the following EDIF constructs: 

■ simulate construct 

■ timing construct 

■ logic modeling and all related constructs 

■ mustJoined, weakJoined, permutable, and 

nonPermutable constructs 

■ criticality construct 

■ netDelay and portDelay constructs 

■ dcFaninLoad, dcFanoutLoad, dcMaxFanin, 

dcMaxFanout, and acLoad constructs 

■ unused attribute 

■ portImplementation construct 

■ figure construct 

■ Global net 

■ globalPortRef construct 

■ array, portBundle and netBundle constructs to group 

ports and nets 



edif2e Command 

■ RIPPER cell 

■ EDIF subnets and tie cells 

■ scale construct 

■ All userData constructs 

The edif2e command translates gate-level and transistor-level 

netlists from EDIF format to EPIC format. 

SYNTAX: 

edif2e -i edif_file -o epic_file 

[-h] 

[-m prop_name1 prop_name2 ...] 

[-p] 

[-v] 

[-b] 

[-m] 

[-r] 

[-c] 

[-e] 


The following command-line options can be used with edif2e. 

-i edif_file 

Specifies input netlist files in EDIF format. The default is 

UNIX standard input. 

-o epic_file 

Specifies the netlist file that will be created in EPIC 

format. The default is UNIX standard output.

-h 

Provides command-line help. 


-m prop_name1 prop_name2 

Specifies properties to be used as parameters. 

-p Generates an EPIC netlist without port mapping. 

-v Verbose. 

-b Generates an EPIC netlist with all port direction bt 

(INOUT). 

-r Renames ports, instances, and nets containing the rename 

construct in the EDIF file. 

EXAMPLE: 

edif2e -i edif_file -o epic_file -r 

This example shows how to use the rename construct (-r). 

-c Preserves the case in the netlist. 

-e Includes in the character set all special characters 

documented in EDIF version 2.00. 

DESCRIPTION: 

The EDIF design structure is translated to the EPIC netlist top 

level. The original EDIF design structure is: 

(design design_name (cellRef cell_name 

(libraryRef library_name))), 

The EPIC netlist top level is: 

(ef=cell_name) (en=design_name) (it=...) (ot=...)(bt=...) 

In the EDIF rename command (rename edif_id new_name), 

the EPIC netlist takes edif_id as the only option. edif2e does not 

replace the edif_id with the new_name. The EDIF identifier is 

used as cell, net, instance names, and so on. EDIF identifiers are 

not case-sensitive. edif2e translations put all identifiers in 

uppercase. 

edif2e supports the parameter, parameterAssign, and 

property constructs. The property construct allows you to 

specify properties to be treated as parameters. To do this, you 



must use the -m option in the edif2e command line. Then you 

need to define a cell that maps the EDIF leaf cell information to 

EPIC primary elements. (See the cell example that follows.) Use 

the result of the edif2e run and the defined cell as EPIC 

simulator input. 

EXAMPLE: 

(subckt=NFET) (bt=D,G,S,B)(pr=WF,LF) { 

(t=nfet)(en=nt)(ga=G)(so=S)(dr=D)(bu=B) 

(w=WF)(l=LF);} 

(subckt=PFET) (bt=D,G,S,B)(pr=WF,LF) { 

(t=pfet)(en=nt)(ga=G)(so=S)(dr=D)(bu=B) 

(w=WF)(l=LF);}


Set the Synopsys edifout variable as shown in Figure 2. 

edifout_array_member_naming_style "%s[%d]" 

edifout_array_range_naming_style "%s[%d:%d] 

edifout_dc_script_flag "" 

edifout_design_name "" 

edifout_designs_library_name "DESIGNS" 

edifout_display_instance_names "false" 

edifout_display_net_names "false" 

edifout_external "false" 

edifout_ground_name "__logic_0__" 

edifout_ground_net_name "" 

edifout_ground_net_property_name "CP_GROUND" 

edifout_ground_net_property_value "GND" 

edifout_ground_pin_name "__logic_0_pin__" 

edifout_instance_property_name "" 

edifout_instantiate_ports "false" 

edifout_match_vhdl_names "false" 

edifout_merge_libraries "false" 

edifout_name_oscs_different_from_ports "false" 

edifout_name_rippers_same_as_wires "false" 

edifout_netlist_only "true" 

edifout_no_array "true" 

edifout_numerical_array_members "false" 

edifout_pin_direction_in_value "" 

edifout_pin_direction_inout_value "" 

edifout_pin_direction_out_value "" 

edifout_pin_direction_property_name "" 

edifout_pin_name_property_name "" 

edifout_portinstance_disabled_property_name "VCC" 

edifout_portinstance_disabled_property_value"VCC" 

edifout_portinstance_property_name "" 

edifout_power_and_ground_representation "net" 

edifout_power_name "__logic_1__" 

edifout_power_net_name "" 

edifout_power_net_property_name "CP_POWER" 

edifout_power_net_property_value "VCC" 

edifout_power_pin_name "__logic_1_pin__" 

edifout_skip_port_implementations "false" 

edifout_target_system "" 

edifout_top_level_symbol "true" 

edifout_translate_origin "" 

edifout_unused_property_value "" 

edifout_write_attributes "false" 

edifout_write_constraints "false" 

edifout_write_properties_list {} 

Figure 2 edif2e variable settings 



Verilog Netlist Translator 

This section describes vlog2e, the EPIC netlist translator that 

converts gate-level and transistor-level netlists from Verilog to 

EPIC netlist format. It is normally automatically called by the 

EPIC netlist compiler for Verilog netlist files, and can also be 

used as a stand-alone utility. 

vlog2e supports structural element and construct translation 

from the Verilog language to the EPIC proprietary netlist 

format. The utility recognizes all Verilog constructs and 

supports cell-based structural translation. It also supports 

certain behavioral constructs that are used as structural 

elements such as assign statements. 

Notice the following characteristics of vlog2e: 

■ vlog2e does not do semantic checking 

If the Verilog file has semantic errors, such as an undefined 

bus, vlog2e will probably generate incorrect output and not 

generate any error messages. It is very important that you 

run the Verilog netlists through a full-blown Verilog 

compiler, such as VCS, before using vlog2e. 

■ vlog2e generates 2e instance names for gates when no 

instance name is given in the source Verilog file 

■ vlog2e supports port-map-by-name 

EXAMPLE: 

module RAM(ADDR, DATA, ENB, RD, WR); 

input ADDR, ENB, RD, WR; 

inout DATA; 

endmodule 

module BRD; 

RAM bnk0(.ADDR(addr_bus), .ENB(enable0), 

.RD(read), 

.DATA(data_bus), .WR(write)); 

RAM bnk1(.ADDR(addr_bus),

Verilog Netlist Translator 125 

.ENB(enable1),.WR(write), 

.DATA(data_bus), .RD(read)); 

RAM bnk2(.ADDR(addr_bus), .ENB(enable2), 

.RD(read), 

.DATA(data_bus), .WR(write)); 

RAM bnk3(.DATA(data_bus), .ENB(enable3), 

.RD(read), 

.ADDR(addr_bus), .WR(write)); 

CPU (addr_bus, data_bus, clock, int_vec); 

endmodule 

This is translated to: 

(subckt=BRD) 

{ 

(ef=RAM)(en=bnk0)(bt=ADDR(addr_bus), 

ENB(enable0), 

RD(read), DATA(data_bus), WR(write)); 


ENB(enable1), 

WR(write), DATA(data_bus), RD(read)); 


ENB(enable2), 

RD(read), DATA(data_bus), WR(write)); 

(ef=RAM)(en=bnk3)(bt=DATA(data_bus), 

ENB(enable3), 

RD(read), ADDR(addr_bus), WR(write)); 

(ef=CPU)(en=v2e_0)(bt=addr_bus, data_bus, clock, 

int_vec); 

} 

(subckt=RAM)(bt=ADDR, DATA, ENB, RD, WR) 

{ 

} 

■ vlog2e supports concatenation on ports 

EXAMPLE: 

module concat; 

foo I4({a[1], b[1]}, c); 

foo I0(.A({a[1], b[1]}), .D(c)); 

endmodule 




(subckt=concat) 

{ 

(ef=foo)(en=I4)(bt=a[1], b[1], c); 

(ef=foo)(en=I0)(bt=A(a[1], b[1]), D(c)); 

} 

■ Supply nets are translated to constant drive functions 

EXAMPLE: 

module supplies; 

supply0 a, b, c; 

supply1 D; 

AND4 (Y, a, b, c, D); 

endmodule 


(subckt=supplies) 

{ 

(is=zero)(en=supplies_0_0)(ot=a, b, c); 

(is=one)(en=supplies_1_1)(ot=D); 

(ef=AND4)(en=v2e_0)(bt=Y, a, b, c, D); 

} 

■ vlog2e supports single-bit expressions with a value of 0 or 1, 

and bit-expressions with lengths greater than 1 

EXAMPLE 1: 

foo (.a(1'b0), .b(1'b1)); 


(ef=foo)(en=v2e_1)(bt=a(GND), b(VDD)); 

EXAMPLE 2: 

module mod1; 

mod2 I1(8’b00100101); 

endmodule 

module mod2(a); 

input [7:0] a; 

endmodule



(subckt=mod1) 

{ 

(ef=mod2)(en=I1)(bt=GND,GND,VDD,GND,GND,VDD,GND,V 

DD); 

} 

(subckt=mod2)(bt=a[7-0]) 

{ 

} 

■ vlog2e handles net assignments and bus assignments 

EXAMPLE 1: 

assign n1 = a; 


(net=n1)(nn=a); 

EXAMPLE 2: 

module mod1; 

wire [7:0] a, b; 

assign a = b; 

endmodule 


(subckt=mod1) 

{ 

(net=a[0])(nn=b[0]); 

(net=a[1])(nn=b[1]); 

(net=a[2])(nn=b[2]); 

(net=a[3])(nn=b[3]); 

(net=a[4])(nn=b[4]); 

(net=a[5])(nn=b[5]); 

(net=a[6])(nn=b[6]); 

(net=a[7])(nn=b[7]); 

} 

■ vlog2e re-maps escaped identifiers if you select the -n option 

EXAMPLE: 

module escape; 



FOO (\mul_11/n1002, \mul_11/ab[15][2]); 

endmodule 


(subckt=escape) 

{ 

(ef=FOO)(en=v2e_0)(bt=_mul_11_n1002, 

_mul_11_ab_15__2_); 

} 

The vlog2e utility does not support the following: 

■ logic gate, MOS transistor, or UDP translations 

■ translation of expression on ports 

■ translation of parameter passing (ignored) 

■ translation of dynamic bit/part selection 

■ translation of opening or closing square brackets ([and]) and 

the leading backslash (\) will be skipped 

vlog2e generates two files: the .ignore file and the .xrf file. The 

.ignore file contains a list of the parameters and user-defined 

primitives that were ignored by vlog2e. The .xrf file contains a 

list of names that were converted by vlog2e.

vlog2e Command 


The vlog2e command performs structural element and construct 

translation from the Verilog language to the EPIC proprietary 

netlist format. 

SYNTAX: 

vlog2e -i in_file(s) -o out_file 

-t [name] 

[-h] 

[--version] 

[-b] 

[-n] 


The following command-line options can be used with vlog2e. 

-i in_file | files... 

Input filename, or a list of input filenames. 

-o out_file 

Output filename. 

-t [name] 

Keeps the port type instead of treating all ports as 

bidirectional. Specifying a module name is optional. 

-h 

Displays help. 

--version 

Prints version number. 

-b “” 

Controls vlog2e output. The value is a three-character 

string specifying the three characters used in bus notation. 

The default value is “[-]”. 



When vlog2e is used as a stand-alone tool, the -b option 

specifies the characters that will be used when Verilog bus 

notation is translated into the EPIC netlist format. 

NOTE: The -b option is ignored if it is added to control options. 

-n 

If you have an escaped identifier in the Verilog source that 

looks like a bus, you need to use the bus_notation option 

to change Verilog bus notation syntax to avoid name 

conflicts. For example, by default, the Verilog escaped 

identifier is translated from “\a[5]” to “a[5]”; so if you 

have a verilog bus with the name “a[5]”, a name conflict 

results. 

You can use either the -b option or the bus_notation 

control option to assign bus notation syntax that will 

prevent name conflicts. 

Reverts netlist notation to version 3.x syntax. In 3.x, any 

nonalphanumeric characters were mapped to an 

underscore. 

When vlog2e is run, a vlog2e.xrf file is created. This file 

maps the original Verilog identifiers to the translated EPIC 

identifiers. 

The following table shows ASCII character mapping. 

ASCII Mapping ASCII Code Ranges (0 -127) 

Codes Not Allowed 0 (null character) 

Codes Causing Termination of 

Escaped Identifiers 

8-10, 32 

Codes Mapped to Underscore 1-7, 11-31, 33-47, 58-64, 92, 

94, 96, 123-127 

Codes Not Mapped 48-57, 65-91, 93, 95, 97-122

The Ecrypt Utility 

The Ecrypt Utility 131 

The following table shows the result of all possible combinations 

of options. 

No output filename -o out_file 

No input files stdin → stdout stdin → out_file 

-i in_file in_file → stdout in_file → out_file 

List For each infile in the 

list: 

in_file→infile.en 

List → out_file 

There are many useful applications for the option combinations. 

For example, to translate a set of design modules, each of which 

is contained in a separate file, provide a list of the filenames. A 

set of translated files with an .en extension is produced. 

The ecrypt utility encrypts netlist files. The EPIC netlist 

compiler automatically detects and compiles encrypted netlist 

files, eliminating the need to decrypt these files first before 

running simulation. 

There are two levels of encryption supported by this utility: 

■ A first-level encryption, for which only the ecrypt utility is 

needed 

■ A second-level encryption, for which you provide an 

additional internally-defined decryption utility in addition to 

the ecrypt utility 

NOTE: There is no decryption utility provided with the ecrypt utility, so 

exercise caution when deleting your original netlist files. 



Level-One Encryption 

Encrypted files can be further compressed using the gzip/ 

compress utility. The final netlist files will have the .eef.gz, 

.eef.Z, .cef.gz, or .cef.Z extensions. 

With a level-one encryption, the ecrypt utility produces new 

encrypted files with a .eef filename extension. The original 

netlist files are not deleted. 

Command Syntax for Level-One Encryption 

Level-Two Encryption 

ecrypt -i filename1 [filename2 ...] 

EXAMPLE: 

ecrypt -i Test.spi 

This example encrypts the Test.spi netlist file. The resulting 

encrypted output filename is Test.spi.eef. 

With level-two encryption, the level-two utility receives an 

encrypted netlist file and produces level-two encrypted netlist 

files with a .cef extension. Use this level of encryption when you 

want to use the extra protection provided by your own encryption 

utility. 

Command Syntax for Two-Level Encryption 

ecrypt -l 2 -i filename1 [filename2 ...] 

Syntax Part Definition 

ecrypt Encryption utility 

-l 2 Level-two encryption 

-i filename Input file(s) to be encrypted


For the two-level encryption to function properly, use the 

following steps: 

1 Create level-one encrypted files by encrypting your netlist 

files with your own encryption utility. 

2 Create level-two encrypted files using the ecrypt utility on 

the level-one encrypted files. 

NOTE: You can remove the original and the level-one encrypted files. 

Tutorial: Performing a Level-Two Encryption 

The following table lists the files needed for this tutorial. 

Filename Description 

Test.spi Netlist file 

cdcrypt Customer-defined decryption utility 

which receives encrypted data from 

stdin and produces decrypted output to 

stdout 

CUS_ENCRYPT -i [original_file] -o Customer-defined encryption utility 

[encrypted file] 

ecrypt The encryption utility 

Procedures 

Use the following procedures to produce level-two encrypted 

netlist files. 



Encryption: 

1 The method used to create level-one encrypted files varies 

with the encryption utility provided by the user. In this case, 

you will use the CUS_ENCRYPT encryption utility as 

defined previously. 

Use the following command to produce a level-one encrypted 

netlist file, Test_e.spi, from the original Test.spi 

CUS_ENCYPT -i Test.spi -o Test_e.spi 

2 Use the following command to produce the level-two 

encrypted file, Test_e.spi.cef, from the level-one 

encrypted file, Test_e.spi 

ecrypt -l 2 -i Test_e.spi 

3 Use the following command to remove the original and the 

level-one encrypted files 

rm Test.spi Test_e.spi 

cdcrypt installation: 

1 Copy cdcrypt to a directory. In this case, to the ~user/ 

decrypt_dir directory. 

cp cdcrypt ~user/decrypt_dir 

2 Add the new directory to the main path, as follows: 

set path=(~user/decrypt_dir $path) 

3 Use the which command to ensure that you can find the 

cdcrypt command. 

which cdcrypt


You can now perform simulations using the Test_e.spi.cef 

encrypted netlist file. 

NOTE: No encryption method is completely safe. Use of the ecrypt 

utility constitutes agreement that you will take full 

responsibility for any loss or damage caused by using this utility. 


136 Chapter 3 Netlist Compiler and Translators

Chapter 4 

EPIC Technology File

138 Chapter 4 EPIC Technology File

Overview 

Overview 139 

EPIC technology files are look-up tables used by EPIC tools to 

calculate timing and power behaviors. The EPIC Gentech utility 

generates the technology file using SPICE netlists and models to 

characterize the CMOS process. All the effects modeled by your 

SPICE, such as short channel effect, velocity saturation effect, 

and body-bias effect, are taken into account. 

You can run Gentech as a stand-alone utility, which requires 

creating a control file before generating a technology file. 

Alternatively, you can automatically generate a technology file 

by simply adding parameters to your SPICE netlist for the 

following types of SPICE: HSPICE, SMARTSPICE, and other 

proprietary SPICES. Using the automatic technology file 

generating feature lets you add new resistor sizes to models 

between runs without having to regenerate a technology file. 

EPIC tools also directly support BSIM1, MOS9 and BSIM3 

models, which are automatically enabled if no technology files 

are specified. 

The TechViewer utility provides you with a graphic 

representation of an EPIC technology file. 

The recommended way to verify the accuracy of the generated 

technology files is by using the actual circuits that you might 

have, and running these with your SPICE and one of the EPIC 

tools for comparison. 

Another possible way to verify circuit accuracy is to use the 

EPICVeritech utility. This utility tests very specialized circuits 

to detect device-level inaccuracies. 

NOTE: Veritech can frequently give false negatives, so it should not be 

relied on as a gating factor for technology file accuracy. Running 

your own circuit using your SPICE is still the best way to Verify 

your technology file. 


140 Chapter 4 EPIC Technology File 

Automatic Technology File Generation 

EPIC automatic technology file generation simplifies and 

enhances the process of generating technology files. It is 

available in TimeMill, PowerMill, PathMill and AMPS for use 

with HSPICE, SMARTSPICE, and many proprietary SPICE 

types. 

Automatic technology file generation offers several advantages 

over the conventional process of manually generating technology 

files. Technology files are generated directly from a SPICE 

netlist without requiring you to run a separate Gentech process. 

This also eliminates the need to specify each technology file in 

your runscript. It also enables you to add new transistor sizes to 

models between runs without having to regenerate the 

technology file. This method also creates a technology file (one 

file per process model) as an output of the simulation. 

The following sections describe command-line options and the 

commands you add to the netlist to implement automatic 

technology file generation. They also describe the basic process 

for using this feature in a typical simulation run. By following 

the simulation run example, you should be able to use automatic 

technology file generation in most situations. 

Specifying Automatic Technology File Generation 

The following options can be specified on simulation tool’s 

command line to generate a technology file. They are: 

-z prefix 

This option is used specifically to run the automatic 

technology file generation feature. It can accept pathnames 

as part of the prefix description, enabling you to specify a 

central library directory. This option is used in place of the 

-p command line option, which you use to explicitly specify 

the technology file used for a simulation.

Modifying the Netlist 

EXAMPLE: 

Automatic Technology File Generation 141 

timemill -n net.sp -c config -o slow125_4v -z 

/usr/lib/techfiles/slow125_4v 

-r always | never | compare | warning 

This option gives you several optional commands related to 

regenerating technology files. For example, you can specify 

the simulator to issue a warning if the models in the netlist 

are different from the models in the technology file. 

NOTE: Using this option might not produce the desired 

results. 

For more information about the command-line syntax, see the 

reference guide for the tool you are using. 

A SPICE netlist is the only input required to run the automatic 

technology file feature. However, there are some modifications 

you will need to make to the netlist prior to running a 

simulation. 

There are several control commands unique to automatic 

technology file generation that you can specify in the netlist 

following the title line. These EPIC-specific commands 

customize the technology file generation by assigning the 

Gentech parameters to the technology control file. Each 

command is preceded by the *epic tech command, as shown in 

the following syntax: 

*epic tech= “command” 



binary 

SYNTAX: 

*epic tech=“gentech_parameter binary” 

DESCRIPTION: 

The binary command causes the generation of a binary file. 

NOTE: This command is valid only with TISPICE, HSPICE, 

SMARTSPICE, and HPSPICE. 

You cannot use this command with the simulation tool’s -A 

option.

ody_bias 

SYNTAX: 

*epic tech=“body_bias 0 vbsend vbsstep” 

EXAMPLE: 

*epic tech= “body_bias 0 20 0.5” 

DESCRIPTION: 


This command specifies the final vbs or vsb voltage and the 

voltage step size for the vbs sweep. 

If you have a circuit that will have higher than normal voltages 

for body-bias considerations, you might need to use this 

command. For example, you could use it if you have a high 

voltage charge pump in a flash memory circuit that pumps to 20 

volts. This would cause a sweep from 0 to 20 volts in 0.5 volt 

steps. 



direct 

SYNTAX: 

*epic tech= “direct” 

DESCRIPTION: 

This command combines direct and technology file device 

models. If your netlist contains this command, direct device 

models are used whenever possible. All other models are 

expected to be characterized using a technology file. The 

supported direct device models are BSIM1, BSIM3, and Phillips 

MOS9 (HSPICE level 50).

gentech_parameter 

SYNTAX: 


*epic tech=“gentech_parameter any_command [value]” 

EXAMPLE: 

*epic tech= “gentech_parameter vgs 0 10 0.2” 

DESCRIPTION: 

This command sets any specified Gentech parameter command 

in the netlist. 

NOTE: The Gentech commands vgs, vds, body_bias, and delta_vt are 

recognized without the gentech_parameter prefix. For 

example, the following two commands are equivalent: 

*epic tech=“gentech_parameter vgs 0 10 0.2” 

*epic tech=“vgs 0 10 0.2” 



invoke 

SYNTAX: 

*epic tech= “invoke spice_syntax” 

EXAMPLE: 

*epic tech=”invoke hspice %input > %output” 

DESCRIPTION: 

This command specifies the command syntax for running SPICE 

in a particular environment. Use the invoke command to 

explicitly specify the HSPICE path for the machine on which you 

are running the simulation. A softlink, such as ~spice/etc/ 

etc is not acceptable. 

The %input and %output keywords control the command syntax. 

You can add preprocessors, postprocessors, and so on, by creating 

a script. 

EXAMPLE 1: 

*epic tech=”invoke /path/name/to/hspice %input > 

%output” 

This example runs HSPICE via the specified path. 

EXAMPLE 2: 

*epic tech=“voltage 5” 

*epic tech=“invoke /path/name/to/hspice %input > 

%output” 

This example shows a minimum set of control commands.

lratio 

wratio 

SYNTAX: 

*epic tech=“lratio length_ratio” 

*epic tech=“wratio width_ratio” 


EXAMPLE: 

*epic tech=“lratio 1.2” 

*epic tech=“wratio 1.2” 

These examples multiply the default MOS device channel length 

and width by 1.2 or, equally, 20%. This setting allows 20% steps 

between MOS channel widths and lengths in the SPICE netlist. 

Any device falling between these steps is not be included in the 

techfile. During simulation, interpolation is used to determine 

channel current for a missing device size (W/L) combination. 

DESCRIPTION: 

These parameters change the MOS device channel width and 

length selection ratio. The default equivalent is setting the 

lratio and wratio parameters to 1.01, which generates curves in 

the technology file for all transistor sizes in the netlist. 



speed 

SYNTAX: 

*epic tech=“gentech_parameter speed” 

DESCRIPTION: 

This command increases the speed of technology file generation. 

This is not the default, but it is the recommended mode. 

NOTE: This command can be used only with HSPICE, SMARTSPICE, 

HPSPICE, and Spectre2.

3dtable 

SYNTAX: 

*epic tech=“3dtable” 


DESCRIPTION: 

This command provides the option of using a 3D ids table for all 

devices. It presently works for only the directly-supported 

BSIM3 model. 



vds 

vgs 

SYNTAX: 

*epic tech=“vds 0 vdsend vdsstep” 

*epic tech=“vgs 0 vdsend vdsstep” 

EXAMPLE: 

*epic tech= “vds 0 5 0.05” 

*epic tech=“vgs 0 5 0.05” 

DESCRIPTION: 

These commands specify the final voltage and the voltage step 

size for the sweeps in the technology file. You might want finer 

resolution on vgs or vds to minimize interpolation errors. For 

example, you might want a 0.05 volt step between vgs values and 

vds values for each curve.

voltage 

SYNTAX: 

*epic tech=“voltage value” 

EXAMPLE: 

*epic tech=“voltage 5.0” 


DESCRIPTION: 

This command sets the normal *epic tech=“voltage value” vds 

voltage for the characteristic curve sweeps. It is required 

because it is difficult to automatically determine the supply 

voltage in a SPICE netlist. For example, VDD might have a name 

other than “VDD” in the netlist. 



Running a Simulation 

This section describes how to run a simulation with automatic 

technology file generation. The example uses the basic 

commands you will need to run the feature. 

A SPICE netlist is the only input required to run the automatic 

technology feature. 

Before you start, make sure the SPICE netlist contains only 

those components and statements accepted by EPIC tools. All 

models must be specified in either the netlist, a .lib statement, 

or an .include statement. Additionally, the temperature for the 

simulation must be specified in the SPICE netlist using the 

.temp statement. 

Creating a Runscript 

The runscript for a simulation using automatic technology file 

generation is slightly different from a standard runscript. 

EXAMPLE: 

timemill -n netlist.spi -c config -t 20000 -z typ 

In the example, the -z option also specifies typ as the prefix for 

the generated technology files. TimeMill or PowerMill creates 

the technology filenames using any prefix you specify, including 

pathnames to central technology file directories. 

The -p option is not used in the script because -z triggers 

TimeMill or PowerMill to automatically create the applicable 

technology filenames. 

Technology files are created for each unique MOS model name in 

the netlist. For example, if the netlist contains MOS models 

nchan and pchan, TimeMill or PowerMill will create two 

technology files named typ_tech_nchan and typ_tech_pchan. 

After you start the runscript, the simulator immediately starts 

running Gentech if a technology file is not found. This is

Gentech 

Gentech 153 

confirmed by messages displayed on the screen. The simulator 

executes after the technology files are built. Once the initial 

technology files are created, you can use the same runscript in 

successive runs, and technology file generation will be skipped. 

The Gentech utility generates technology files. Gentech submits 

all necessary SPICE runs to characterize the range of CMOS 

sizes specified. Gentech currently runs with HSPICE, 

SMARTSPICE, SPECTRE, and many proprietary SPICE types. 

The Gentech program uses information from a control file that 

includes the SPICE models, the range of CMOS sizes, the 

operating temperature and supply voltage, and the command 

syntax to run your SPICE. Figure 1 shows a diagram that 

illustrates the flow of a Gentech run. 

A directory called examples/gentech located in the EPIC root 

directory contains a Gentech example. In that directory: 

■ The readme file explains how to use Gentech. 

■ The file ctrl.typ.25c_5v is a sample control file. 

■ run is a sample runscript. 



Control File 

Gentech 

Technology File 

Figure 1 Gentech run flow 

Sample Control Files 

SPICE Input 

SPICE Output 

SPICE 

Several examples of Gentech control files are provided here to 

help you start running Gentech with limited reference to the 

details given in later sections. A percent sign (%) starts a new 

section of the control file. 

HSPICE Example 

Figure 2 shows an example of a Gentech control file for HSPICE. 

For all other SPICE types, see the section “Example of Other 

SPICE Types” on page 156.

%lib 

.lib "/cmos/model_file" nom 

.lib ’/cmos/model_file’ wcs 

.inc ’include_file’ 

%model 

.model nch nmos 

.model pch pmos 

%parameters 

NW 1.6 4 10 100 400 

N_LENGTH 0.35 

NW1 10 

N_LENGTH1 0.5 1 8 

PW 1.6 5 50 300 400 

P_LENGTH 0.35 

PW1 2 10 

P_LENGTH1 0.5 1.2 5 8 

vds 0 2.7 0.3 

vgs 0 2.7 0.3 

body_bias 0.4 0.8 1.2 1.6 2 

speed 

%corner 

temperature 85 

voltage 2.7 

%invoke 

/usr/local/meta/h93/sun4/hspice %input > %output 

Figure 2 Example of Gentech control file for HSPICE 

Gentech 155 

Notice the use of %lib and %model in this example. Several 

library files and an include file are specified in the %lib section 

using HSPICE .lib and .inc commands. You must then specify 

the model names for NMOS and PMOS in the %model section, to 

clarify which one to use if many model names exist in your 

library files. When several model sections with names such as 

nch.1 and nch.2 or pch.1 and pch.2 are in the library files to 

model the same NMOS and PMOS process, but correspond to 

different size ranges by the model parameters lmin, lmax, 

wmin, and wmax, specify the model root name nch and pch in 

the %model section, as shown in this example. HSPICE will pick 

up the correct model extension names. 



NOTE: The same control file can be used for SMARTSPICE and some 

proprietary SPICE types. For SMARTSPICE, add the following 

lines: 

% option 

scale=1u epic 

After the control file is created, run Gentech with HSPICE on the 

control file example using the following command line: 

$gentech -c ctrl.wcs.85c_2.7v.hsp -f hspice -t\ 

tech.wcs.85c_2.7v.hsp -q 

When Gentech is finished, you can use your SPICE on your 

sample design and the EPIC tool with the generated tenchology 

file on your sample design and compare the output to check the 

accureacy of the generated technology file. 

Example of Other SPICE Types 

You should run Gentech with the -q option for HSPICE, 

SMARTSPICE, and some proprietary SPICE types (see “HSPICE 

Example” on page 154). 

For other SPICE types, you need to provide the following values 

in the %parameters section: 

■ ldiff and wdiff values 

■ lmlt and wmlt values if they are not equal to 1 

■ rsh values if they are not zero when nrd and nrs values are 

used in your SPICE netlists, or your SPICE defaults nrd and 

nrs are non-zero values 

■ ds_length values if they are used to calculate default nrd 

and nrs values or any of the ad, as, pd, and ps values 

Figure 3 shows an example of a Gentech control file for 

SPECTRE. In general, for all SPICE types other than HSPICE, 

the control file format follows this example except for using the 

%lib section. In this example, the NMOS and PMOS models are

Gentech 157 

listed directly in the %model section and the %lib section is not 

used. 

$ cat ctrl.27c_5v.spe 

%model 

model enmos bsim1 type=n \ 

tox=3.0e-08 dl=0.24 dw=-0.10 rsh=55.0 \ 

cgdo=360e-12 cgso=360e-12 cgbo=0.0 cj=550e-06 \ 

mj=0.5 pb=0.7 cjsw=500e-12 mjsw=0.43 js=2.0e-06 

model epmos bsim1 type=p \ 

tox=3.0e-08 dl=0.08 dw=0.10 rsh=75.0 \ 

cgdo=360e-12 cgso=360e-12 cgbo=0.0 cj=540e-06 \ 

mj=0.5 pb=0.7 cjsw=600e-12 mjsw=0.53 js=10.0e-06 

%parameters 

new_format 

model_alias enmos n 

model_alias epmos p 

body_bias 0.5 1 1.5 2 3 

NW 5 300 

PW 5 150 

N_LENGTH 1 

P_LENGTH 1 

vgs 0 5 0.5 

vds 0 5 0.5 

ldiff 0.12 0.04 

wdiff -0.05 0.05 

rsh 55 75 

ds_length 2.67 

%corner 


voltage 5 

%invoke 

/spectre/spectre -f nutascii -r %output %input 

Figure 3 Gentech control file example for SPECTRE 

The new_format command in the %parameters section is for 

SPECTRE only and is required if your version of SPECTRE is 

newer than version cds43. The command syntax shown in the 

%invoke section should be used to start SPECTRE, but the 

pathname to your SPECTRE may be different. 

The command to run Gentech is: 

$gentech -c ctrl.27c_5v.spe -f spectre -t tech.27c_5v.spe 



Gentech Control File 

The models used in this sample control file are the SPECTRE 

native models. If the SPICE2 models are used, use -f spectre2 

instead of -f spectre to run Gentech with SPECTRE. 

The control file contents are briefly explained using comments in 

the above example. Further details can be found in the next 

section. 

This section describes details of the Gentech control file. The 

control file is divided into six sections. Each section starts with a 

percent sign (%) and a keyword at the beginning of the line. The 

sections are: 

■ Section 1 - %lib 

■ Section 2 - %model 

■ Section 3 - %parameters 

■ Section 4 - %corner 

■ Section 5 - %invoke 

■ Section 6 - %options 

■ Section 7 - %diode 

Sections 1 through 4 are required; sections 5, 6 and 7 are 

optional. Each section can be used only once in the control file 

and can appear in random order. The semi-colon (;) is the 

comment character for this file. 

Section 1 - %lib 

This section is required when you specify SPICE model files, 

include files, or any other lines needed in SPICE runs executed 

by Gentech. All lines of text in the %lib section are included in 

the SPICE netlists. 

When model files are specified, you must also provide the model 

names in the %model section. Otherwise, Gentech will not know 

which model names to use. For HSPICE, if a common model root 

name is used in model files, HSPICE will select a proper section 

of model with the root name and extension name based on MOS

Gentech 159 

width and length. In the following HSPICE example, proper 

models will be selected with model names tn.xxx or tp.yyy, based 

on width and length from the file mylibrary.lib inside the skew 

entry tntp, and from the file secondlib.lib. Here, xxx and yyy 

represent extension names which are proper character strings. 

EXAMPLE: 

%lib 

.lib ’mylibrary.lib’ tntp 

.inc "secondlib.lib" 

... 

%model 

.model tn nmos 

.model tp pmos 

%parameters 

... 

Section 2 - %model 

This section is mandatory and includes MOS models for SPICE. 

One NMOS model and one PMOS model can be listed here if the 

%lib section is not used. You can specify both models, but both 

are not needed if the sizes for only n or p are specified in the 

%parameters section. The dummy model is not needed when 

building a separate technology file for depletion NMOS. 

If you have models of NMOS and PMOS for different size ranges, 

but with the same root model names, you can use the %lib 

section to specify model files instead of a single model for NMOS 

and PMOS. But, you must specify the model names here using 

the syntax .model name [n|p]mos. 

EXAMPLE: 

%model 

.model n2n nmos 

.model p2n pmos 

%lib 

.include "model_file" 



One technology file can have only one NMOS and one PMOS 

model name, and one temperature and voltage condition. If you 

have multiple NMOS or PMOS models, see the section “Using 

Multiple Technology Files” on page 204. 

Section 3 - %parameters 

This section sets up geometric, electrical, model, and 

performance parameters. There are also parameters that help 

set up the format of the resulting technology file. The following 

table includes all the commands. 

Command Definition Comments 

nw (or n_width) 

nl or n_length) 

pw (or p_width) 

pl (or p_length) 

pn_ratio 

ldiff 

wdiff 

lmlt (or l_scale) 

wmlt (or w_scale) 

mlt (or wl_scale) 

vgs 

vds 

Specifies MOS size 

combinations in μm. 

Specifies lateral diffusion 

values in μm. 

■ Mandatory, but n or p 

sizes may be omitted. 

■ pn_ratio is not 

recommended if it does 

not specify the exact p 

widths. 

■ Allows nw, nw1, nw2,..., 

up to nw199; similar for 

pw and [n|p]_l. 

Mandatory for almost all 

SPICE types if -q option is 

not specified. 

Specifies scaling if not 1. Mandatory for all SPICE 

types if -q option is not 

specified. 

Specifies ids table voltage 

ranges. 

body_bias Specifies sampling voltages of 

vbs. 

Beginning value should be 

0. Ending value should be 

max |vdd-vss and divisible 

by the increment value. 

See the description of 

body_bias on page 174.


model_alias Maps SPICE model names to 

names (t=..) in EPIC netlists, 

if they are different. 

Gentech 161 

This is copied to the 

technology file so you can 

edit the entry without 

using this command in the 

control file. 

ds_length Default d/s extension length. ■ This is copied to the 



using this command in 

the control file. 

rsh Sheet resistance. 

■ Not needed if -q option is 

specified. 

■ This is copied to the 



using this command in 

the control file. 

no_nrd_nrs If RSDW model parameter is 

used. 

nrd_nrs_caps Improves the calculation of 

capacitance when rsh is large. 

new_format Specifies that input output 

format is new. 

■ Not needed for HSPICE 

unless you want to 

correct values found by 

Gentech. 

Only for one proprietary 

SPICE. 

Only for one proprietary 

SPICE. 

Only needed for SPECTRE 

version cds43 or newer. 

cjgate Specifies model value cjgate. Only mandatory for 

HSPICE acm 3 if the -q 

option is not specified. 

cg 

cov 

cja 

cjsw 

Overwrites average 

capacitances found by 

Gentech if the -q option is not 

specified. 

cg and cov are mandatory 

to provide cgdo values for 

acm 1. 




tox 

cox 

cgdo 

cgso 

cgbo 

Overwrites entries used by 

TimeMill and PowerMill’s 

acc_branch configuration 

command. 

Same effect as hand-editing 

the entries. 

delta_vt Model subthreshold currents. Simulations will be slowed 

down. 

vto Specifies model value vto. Not needed except for 

SPECTRE levels 4, 5, 6. 

case Controls SPICE file formats in 

upper- or lowercase. 

unit_wl 

unit_adas 

unit_pdps 

unit in w= and l= 

unit in ad= and pd= 

unit in pd= and ps= 

If there are no characters 

in the commands unit_wl, 

unit_adas, or unit_pdps, 

there will be no unit 

character in the SPICE 

input file generated by 

Gentech. 

wd Default WD parameter. Allows the extracted value 

to be overridden. Works 

only with HSPICE. 

speed Increases the speed with 

which the technology file is 

generated. 

binary Creates a binary technology 

file, reducing the amount of 

required disk space. 

Works with HSPICE, 

SMARTSPICE, HPSPICE, 

and Sprectre2. 

Works with TISPICE, 

HSPICE, SMARTSPICE, 

and HPSPICE. 

The model_alias, rsh and ds_length commands copy their 

respective values to the technology files. You do not need to use 

them in the control file, but edit these values directly in the 

technology files, when needed, without rerunning Gentech. 

These values directly affect the functionality and accuracy of the 

technology files.

Gentech 163 

Use the cg, cov, cja, and cjsw commands carefully and only if 

necessary to improve the average capacitance accuracy in the 

technology files. The effect of putting these values in the control 

file and running Gentech is the same as hand-editing all of the 

respective entries directly in the technology file. The cg and cov 

commands are required to provide the cgdo model parameters 

when the acm value is set to 1. 

The tox, cox, cgdo, cgso, and cgbo commands are used to 

overwrite the respective entries in the technology files. These 

values are needed only if you apply the configuration file 

command acc_branch in TimeMill or PowerMill simulations. 

The ldiff, wdiff, lmlt, wmlt, rsh, and ds_length commands are 

not needed for HSPICE. Instead, Gentech finds these values 

automatically and echoes them on the stdout and in the 

gentech.log file, as shown in “HSPICE Example” on page 154. 

Gentech requires an acm value in the control file. You can still 

use these commands to overwrite the result found by Gentech if 

it finds the wrong values. 

The syntax for each command in the %parameters section 

follows. 



nw / n_width 

pw / p_width 

nl / n_length 

pl / p_length 

SYNTAX: 

nw [size_range] 

n_width [size_range] 

pw [size_range] 

p_width [size_range] 

DESCRIPTION: 

These commands set NMOS or PMOS widths used in 

calibrations. Units are in microns. Spaces are used as delimiters 

between width values. The maximum value for size range is 199. 

SYNTAX: 

nl [size_range] 

n_length [size_range] 

pl [size_range] 

p_length [size_range] 

DESCRIPTION: 

These commands set NMOS or PMOS lengths. Units are in 

microns. Ranges of different sizes can be specified in the 

%parameters section using the following syntax. The maximum 

value for size range is 199. 

pw p_width(s) 

nw n_width(s) 

p_length p_l(s) 

n_length n_l(s) 

pw1 p_width(s) 

nw1 n_width(s) 

p_length1 p_l(s)

n_length1 n_l(s) 

... 

nw199 n_width(s) 

n_length199 n_l(s) 

Gentech 165 

EXAMPLE 1: 

nw 1 2 3 

n_length 1 2 

pw 1 2 

p_length 1 1.5 

nw1 10 20 

n_length1 10 

pw1 100 

p_length1 5 

Example 1 characterizes the following sizes for n (width/length): 

1/1, 2/1, 3/1, 1/2, 2/2, 3/2, 10/10, 20/10. The example also 

characterizes the following sizes for p: 1/1, 2/1, 1/1.5, 2/1.5, 100/ 

5. 

You can specify ranges beginning with nw, nw1, and so on. The 

upper range can extend to nw199. The same is true for pw, nl, 

and pl. It’s not necessary to have both n and p sizes specified for 

each range. If a pn_ratio is specified, that ratio will be used to 

determine the widths of the PMOS, provided no explicit pwn has 

been specified. 

EXAMPLE 2: 

pn_ratio 2 

nw 2 4 

n_length 1 2 

p_length 1 1.5 

nw1 10 

n_length1 2 

pw1 10 

p_length1 4 

Example 2 characterizes the following MOS sizes for n: 2/1, 4/1, 

2/2, 4/2, 10/2. The MOS sizes for p are characterized as follows: 

4/1, 8/1, 4/1.5, 8/1.5, 10/4. 



If your circuit has several different MOS sizes, you might include 

all the sizes in the control file. However, Gentech will each have 

to be run at least once, incurring additional time and disk space 

for loading huge technology files. If you choose to run Veritech, 

you will also have to be run it mulitple times and incur the same 

overhead. Instead, you should include all the lengths and just 

samples of the widths. This is true for a scalable process since all 

the capacitance and ids entries in the technology files are 

normalized data. 

Because of potential accuracy problems, EPIC tools issue a 

warning in the .log file if any length in the EPIC netlist is not 

found in the technology file.

pn_ratio 

SYNTAX: 

pn_ratio ratio_value 

EXAMPLE: 

pn_ratio 2 

Gentech 167 

DESCRIPTION: 

This command is used to determine PMOS channel widths if the 

pw command is not specified. 



acm 

SYNTAX: 

acm 0 | 1 | 2 | 3 

EXAMPLE: 

acm 2 

DESCRIPTION: 

This specifies the acm (area calculation method) value for 

diffusion (drain or source to substrate) capacitance. The cg and 

cov commands are mandatory when acm is set to 1. The cjgate 

command is mandatory when acm is set to 3. 

NOTE: If the -q option is specified, you do not need to specify acm, 

cjgate, cg, or cov. 

Although the HSPICE .options aspec command sets acm to 1, 

the acm value in the model lines overwrites it. Therefore, always 

take the acm value from the model lines. If acm is not specified 

in the model lines, the latest version of HSPICE defaults the 

acm value to 0. 

This command is mandatory for HSPICE. It is needed for only 

one proprietary SPICE type. It sets acm values to 1 if it is an 

automod=100 case.

ldiff 

wdiff 

SYNTAX: 

ldiff n_ldiff p_ldiff 

wdiff n_wdiff p_wdiff 

Gentech 169 

EXAMPLE: 

ldiff -0.1 -0.15 ; eg ln= 1 μm,ln effective = 1.2μm 

; eg lp= 1 μm,lp effective = 1.3μm 

wdiff 0.45 0.55 ; eg wn= 4 μm, wn effective =3.1μm 

; eg wp= 4 μm, wp effective =2.9μm 

DESCRIPTION: 

These commands specify the lateral diffusion for MOS lengths 

and widths. The effective length and width of each MOS are 

calculated as: 

Leff = Ldrawn * lmlt - 2 * ldiff 

Weff = Wdrawn * wmlt - 2 * wdiff 

The values are real numbers in microns. The lateral diffusion 

values ldiff and wdiff are not subject to scaling lmlt and 

wmlt. This command is not needed for HSPICE unless Gentech 

fails to find the accurate ldiff and wdiff values. 

NOTE: ld in HSPICE is also called dlat or latd. xl in HSPICE is also 

called dl or ldel or dell. xw in HSPICE is also called dw or wdel 

or delw. 



The ldiff and wdiff values for different SPICE types are listed in 

the following table. 

SPICE Type Idiff wdiff 

SPECTRE level 1, 2, 3 scalm * (ld - xl / 2) scalm * (wd - xw / 2) 

SPECTRE 

level 4 (bsim1), 

5 (bsim2), 10(bsim1_5) 

scalm * (dl - xl) / 2 scalm * (dw - xw) / 2 

SPECTRE (if Berkeley 

SPICE2 models used) 

PSPICE 

Berkeley SPICE2 

Berkeley SPICE3 

ld 0

wl_scale /mlt 

l_scale / lmlt 

w_scale /wmlt 

SYNTAX: 

wl_scale n_mlt p_mlt 

or mlt n_mlt p_mlt 

l_scale n_lmlt p_lmlt 

or lmlt n_lmlt p_lmlt 

w_scale n_wmlt p_wmlt 

or wmlt n_wmlt p_wmlt 

EXAMPLE 1: 

l_scale 0.8 

w_scale 0.8 

Gentech 171 

EXAMPLE 2: 

; for HSPICE if a scaling of 0.25 required but not 

; specified in HSPICE .model lines: 

% parameters 

lmlt 0.25 

wmlt 0.25 

% options 

scale=0.25e-6 

; HSPICE also requires a unit scaling from meter to 

micron 

For HSPICE, lmlt and wmlt commands in the %parameters 

section are not needed unless Gentech fails to find the correct 

values. However, they are still required in the %options section, 

if applicable, because the contents of the %options section belong 

to the SPICE netlist created by Gentech. 

DESCRIPTION: 

These commands handle scaled processes. The lmlt and wmlt 

values are floating point numbers. If two numbers are supplied, 

the first is used for NMOS and the second for PMOS. If only one 



number is supplied, that number applies to both NMOS and 

PMOS. The wl_scale and mlt commands scale both the length 

and width using the same value. 

This is needed for SPICE types other than HSPICE if the scaling 

values do not equal 1. This is needed for HSPICE only if Gentech 

finds wrong scaling values. 

When using a scaled technology file, the pre-scaled sizes should 

be used in the Gentech control file and the EPIC netlists. 

NOTE: These commands are required if scaling is used in the SPICE 

.model lines, .options lines, other commands in SPICE library 

files, .options, or other commands in actual SPICE netlists. If 

scaling is specified in the SPICE .model lines (for example, lmlt 

and wmlt values in SPICE models), using lmlt and wmlt 

commands in the %parameters section is sufficient. If scaling is 

specified in .options or commands other than .model lines, 

regardless of whether or not it is in a library file, the lmlt and 

wmlt commands in the %parameters section are required, along 

with a proper scale parameter in the %options section. This is 

because Gentech may create a .options scale=1e-6 line for 

unit conversion which overwrites the .options scale=0.25e- 

6 line in the SPICE library file. The %options section will then 

create a last .options scale=0.25e-6 line in the SPICE 

netlist to overwrite again.

vds 

vgs 

SYNTAX: 

vds 0 vde vdi 

vgs 0 vge vgi 

EXAMPLE 1: 

vds 0 6 0.2 

vgs 0 6 0.2 

EXAMPLE 2: 

vds 0 2.7 0.15 

vgs 0 2.7 0.15 

Gentech 173 

DESCRIPTION: 

These are the drain-to-source and effective gate-to-source 

voltage ranges. Their beginning, ending, and incremental values 

are specified for measuring the device currents. Notice that the 

effective vgs is defined as the gate to source voltage minus the 

threshold voltage. You should choose the incremental values vdi 

and vgi so the ending values for vde and vge are their integer 

multiples. 

The ending values vde and vge must be greater than the voltage 

value specified in the %corner section. The voltage value 

determines the voltage range used to calculate the average 

capacitances. A warning is issued if these voltage values differ 

significantly. 



body_bias 

SYNTAX: 

body_bias 0 vbe vbi 

EXAMPLE: 

body_bias 0 5 0.1 

DESCRIPTION: 

For HSPICE, SPICE2, and several other SPICE types, you can 

use this syntax to specify the range of the sampling voltages with 

the ending value vbe and increment value vbi of the source to 

substrate reverse bias voltage. This will create a new table data 

of threshold voltages in the technology file, and will improve the 

simulation accuracy, especially for TimeMill and PowerMill. If 

this body_bias command is not specified, the ending voltage vbe 

defaults to the ending voltage vde specified in the vds command, 

and the increment voltage vbi defaults to 0.1. 

In certain cases, the following syntax might be used: 

SYNTAX: 

body_bias vs1 vs2 vs3 vs4 vs5 

EXAMPLE:. 

body_bias 0.5 1 1.5 2 3 

DESCRIPTION: 

This is needed if you want to specify the sampling source to 

substrate reverse bias voltages, where threshold voltages are 

measured other than the default voltage points of 0.8, 1.2, and 2 

volts. When the body_bias command is not used, Gentech 

sweeps the vbs values from 0 to voltage using 0.1V increments. 

For all SPICE types, a maximum of five sampling voltages can be 

specified. The vs values are in volts and must monotonically 

increase and not be zero.

model_alias 

SYNTAX: 

model_alias true_name alias1 alias2 ... 

EXAMPLE:(technology file) 

model_alias NCH n nmos nch 

model_alias TP p 

Gentech 175 

EXAMPLE:(EPIC netlist) 

(t=p)(en=p1)(dr=z)(ga=A)(so=vdd)(w=600)(l=80); 

(t=n)(en=n1)(dr=z)(ga=A)(so=gnd)(w=300)(l=80); 

(t=nch)(en=n2)(dr=z)(ga=A)(so=vdd)(w=300)(l=80); 

(t=nmos)(en=n3)(dr=z)(ga=A)(so=vdd)(w=300)(l=80); 

Both examples model MOS p1 based on the SPICE model TP and 

models MOS n1, n2, and n3 based on the SPICE model NCH. 

Aliases p1, n1, n2, and n3 are used in EPIC and SPICE netlists. 

Model true names TP and NCH appear in SPICE models used in 

the Gentech control file and in the generated technology file. 

DESCRIPTION: 

This maps the true_name used in the SPICE model to the MOS 

names in the netlist. You can map multiple MOS names to one 

SPICE model name. Each model_alias command is copied to the 

technology file. If you have an existing technology file and need 

to use this command, you can simply add the command to the 

technology file without rerunning Gentech. 

The argument true_name is the name in the SPICE model. The 

alias arguments are the names in the netlist. 

This is only needed if the SPICE model names are different from 

the names used in the netlists. 

When you are using multiple technology files, be careful to avoid 

name mapping conflicts when using this command. See “Using 

Multiple Technology Files” on page 204 for more details. 



ds_length 

SYNTAX: 

ds_length diffext 

EXAMPLE: 

ds_length 2.4 

DESCRIPTION: 

This command copies only the diffext values to the technology 

file. This value is not used by Gentech, even in calculating the 

average capacitances. Therefore, the diffext value can be edited 

directly in the technology file without rerunning Gentech. 

This is needed if any of the ad, as, pd, ps, nrd, and nrs MOS 

attributes are not specified in the netlist, and the default value 

depends on the diffext value. 

The argument diffext is the drain and source extension length. 

This dimension is used in conjunction with MOS widths to 

determine the default values of the area and perimeter of drain 

and source when ad, as, pd and ps are not specified in the 

netlists. Some SPICE types also use the diffext value to 

determine default nrd and nrs values if they are not specified in 

the netlist.

W 

Gentech 177 

Figure 4 illustrates a MOS transistor cross-section showing 

diffext. 

source L 

gate 

Figure 4 MOS transistor cross-section showing difftext 

drain 

DIFFEXT 

Drain Contact 

To match HSPICE, diffext should be 2*HDIF when acm is 2 or 3, 

and should be 0 if acm is 0 or 1, where HDIF is an HSPICE model 

parameter. This command is not needed for HSPICE unless 

Gentech fails to find the correct diffext values. 



rsh 

SYNTAX: 

rsh n_rsh p_rsh 

EXAMPLE: 

rsh 50 75 

DESCRIPTION: 

This specifies the sheet resistance values in ohms per square 

used by the nrd and nrs MOS attributes from the netlist. The nrd 

and nrs attributes contain the drain and source resistance 

squares. 

This is needed when nrd and nrs MOS attributes are used in 

SPICE netlists, or when nrd and nrs are not used but SPICE 

defaults them to some nonzero value. In the latter case, check 

that the calculateNRSH() function in the customize.c file 

returns the same values as SPICE. See “Customizing EPIC 

Tools” on page 299 for further details. 

The values for n_rsh and p_rsh can be obtained from your SPICE 

model. These values can be directly edited in the technology file 

without rerunning Gentech. 

For HSPICE, Gentech will find the proper rsh values with 

temperature effects included. You use this command only if 

Gentech fails to extract the rsh values correctly.

no_nrd_nrs 

SYNTAX: 

no_nrd_nrs 

EXAMPLE: 

no_nrd_nrs 

DESCRIPTION: 

Gentech 179 

This causes Gentech not to use nrd and nrs MOS attributes in 

the SPICE runs. Therefore, possible RSDW model parameter 

effects can be characterized in the technology files. 

This is used by only one proprietary SPICE type, which 

sometimes needs to model the RSDW model parameter effect 

instead of the rsh model parameter. Use this command only if 

your SPICE model contains the RSDW parameter. 



nrd_nrs_caps 

SYNTAX: 

nrd_nrs_caps 

EXAMPLE: 

nrd_nrs_caps 

DESCRIPTION: 

This causes Gentech to add small nrd and nrs values in the 

SPICE runs when extracting the average capacitances. This 

prevents inaccuracies caused by possible large resistance values 

from rsh multiplied by nrd or nrs in SPICE models. If you do not 

do this, the SPICE .tran results will not settle down, even after 

a very long simulation time. 

This is used by only one proprietary SPICE type, which has huge 

rsh model values, and defaults nrd and nrs to (1), which causes 

inaccuracies in extracting average capacitances. If your rsh 

values, either by default or in the models, are within several 

hundred ohms per square, or if your SPICE defaults nrd and nrs 

to zero, you don’t need to use this command.

new_format 

SYNTAX: 

new_format 

EXAMPLE: 

new_format 

Gentech 181 

DESCRIPTION: 

This informs Gentech the SPECTRE output format is new. This 

is needed only for SPECTRE versions cds43 - ver.4.3.94 or later. 



cjgate 

SYNTAX: 

cjgate n_cjgate p_cjgate 

EXAMPLE: 

cjgate 3e-10 2.8e-11;cjgate values in SPICE unit F/m 

DESCRIPTION: 

This is needed only for the HSPICE acm 3 case. It is not needed 

if the -q command-line option is specified. Under that condition, 

it is mandatory to provide the cjgate model parameters. The 

cjate values are in units of F/m, as in HSPICE models.

cg 

cov 

cja 

cjsw 

SYNTAX: 

cg n_cg p_cg 

or cg n|p tox|cox tox|cox 

or cg n tox|cox n_tox|n_cox p tox|cox p_tox|p_cox 

SYNTAX: 

cov n_cov p_cov 

or cov n|p cgdo|cgso cgdo 

or cov n cgdo|cgso n_cgdo p cgdo|cgso p_cgdo 

SYNTAX: 

cja n_cja p_cja 

or cja n|p cj cjo mj mj pb pb 

Gentech 183 

or cja n cj n_cjo mj n_mj pb n_pb p cj p_cjo mj p_mj pb p_pb 

SYNTAX: 

cjsw n_cjsw p_cjsw 

or cjsw n|p cjsw cjswo mjsw mjsw pbsw pbsw 

or cjsw n cjsw n_cjswo mjsw n_mjsw pbsw n_pbsw p cjsw 

p_cjswo mjsw p_mjsw pbsw p_pbsw 

The cg command provides the average gate capacitance value. 

The cov command provides the SPICE model value cgdo, which 

is the gate-to-drain overlap capacitance. EPIC assumes cgdo is 

equal to cgso, the SPICE model value of gate-to-source overlap 

capacitance. 

These four commands are used to overwrite the average 

capacitance in the technology file when necessary. They 



overwrite the following values in the technology file for all the 

MOS devices: 

■ the averaged values calculated by Gentech on the gate (sum 

of gate-to-source, gate-to-drain, and gate-to-substrate, 

excluding the overlap) 

■ the overlap (gate-to-drain, gate-to-source overlap) 

■ the diffusion junction (drain-to-substrate, source-tosubstrate) 

bottom area 

■ the diffusion side wall capacitances 

These capacitance values appear in the gate_cap and diff_cap 

data lines in the technology files. 

Adding these commands to the control file and rerunning 

Gentech have the same effect as hand-editing the respective 

entries in the following data lines in a technology file: 

gate_cap model_name nmos|pmos width length cg 

diff_cap model_name nmos|pmos width length 

cov cja cjsw 

Use these commands with care. The cov and cg commands 

should be used together. The cja and cjsw commands should also 

be used together. Otherwise, you might disturb the overall 

capacitance accuracy. These sets of commands are not correlated 

to each other. For example, using the cov and cg commands will 

not affect the cja and cjsw data entries, which remain as values 

calculated by Gentech. 

To use these commands, you can provide the necessary model 

parameters tox, cox, cgdo, cjo, mj, pb, cjswo, mjsw, pbsw and 

let Gentech calculate the average capacitance values using the 

following equations. Then all the parameters are in SPICE units: 

tox is in m, cox and cjo are in F/m 2 , cgdo and cjswo are in F/m. 

If the equations used by your SPICE are different than the 

following ones, you may provide the final average capacitance 

values directly. If so, the values should be in EPIC units: cg and 

cja are in fF/10 -16 m 2 , cov and cjsw are in fF/10 -8 m. The

Gentech 185 

following calculations and unit conversions are performed by 

Gentech when you provide the model parameters. You will have 

to do the same unit conversions if you use a different set of 

equations when providing the final average values. 

If TOX is given in units of meters: 

E E sio2 

Cg 0.9 o 

= ------------------- = 

TOX 

If COX is given in units of F/m 2 : 

(0.1 is used for unit conversion) 

The two preceding equations give averaged Cg in required EPIC 

units of fF/10 -16 m 2 . Although cg versus vgs is a quite 

complicated function, using the constant value 0.9 to multiply 

the maximum value at zero bias is a good approximation for the 

average cg value for most applications. 

If CGDO is in units of F/m: 

This gives averaged Cov in required EPIC units of fF/10 -8 m. 

Cja and Cjsw are averaged values in the reverse bias vsb voltage 

range from zero to VDD. 

If Cja is in units of F/m 2 : 

3.105 10 12 – 

× 

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

TOX 

Cg= 0.9 × 0.1 × Cox= 0.09Cox 

Cov 10 7 = × CGDO 

PB vdd 1 MJ) 

Cja ------------------------------- 1 -------- ⎞ 

vdd( 1 – MJ) 

PB ⎠ – ( 

= 

⎛ + 

– 1 ( 0.1 )CJO 

⎝ 

This gives Cja in required EPIC units of fF/10 -16 m 2 , where 0.1 is 

used for unit conversion. 



If Cjsw is in units of F/m: 

PBSW 

vdd 1 MJSW) 

Cjsw ----------------------------------------- 1 ---------------- ⎞ 

vdd( 1 – MJSW) PBSW⎠ 

– ( 

⎛ + 

– 1 10 

⎝ 

7 

= 

( )CJSWO 

This gives Cjsw in required EPIC units of fF/10 -8 m, where 10 7 is 

used for unit conversion. 

tox, cox, cgdo, cgso, pb, pbsw, mj, mjsw, cjo, cjswo are SPICE 

model parameters. cgso usually equals cgdo. pbsw usually 

equals pb if pbsw is not defined. 

Notice that a semicolon (;) starts an in-line comment. 

EXAMPLE 1: 

%parameters 

cov n cgdo 2.1e-10 p cgdo 1.9e-10; (cgdo values in 

SPICE unit F/m) 

;or use the next one 

;cov 2.1e-3 1.9e-3 

;(cov values in EPIC unit fF/1e-8m) 

cg n tox 180e-10 p tox 180e-10 

;(tox values in SPICE unit m) 

;or use either one of the next two 

;cg n cox 1.91667e-3 p cox 1.91667e-3 

;(cox values in SPICE unit F/m2) 

;cg 1.725e-4 1.725e-4 

;(cg values in EPIC unit fF/1e-16m2) 

If there is a need to overwrite the average diffusion capacitances 

found by Gentech, use the cja and cjsw commands together.

Gentech 187 

EXAMPLE 2: 

%parameters 

cja n cj 8e-4 mj 0.6 pb 1.02 p cj 6e-4 mj 0.55 

pb0.7 

;(cj values in SPICE unit F/m2),or use 

the next one 

;cja 4.22e-5 2.93e-5 

;(cja values in EPIC unit fF/1e-16m2) cjsw n cjsw 

3e-10 mjsw 0.23 pbsw 0.7 p cjsw 1.33e-10 

mjsw 0.23 pbsw 0.6 

;(cjsw values in SPICE unit F/m),or use the next one 

;cjsw 2.19e-3 9.5e-4 

;(cjsw values in EPIC unit fF/1e-8m) 



tox 

cox 

cgdo 

cgso 

cgbo 

SYNTAX: 

tox n_tox p_tox 

cox n_cox p_cox 

cgdo n_cgdo p_cgdo 

cgso n_cgso p_cgso 

cgbo n_cgbo p_cgbo 

EXAMPLE: 

tox 180e-10 180e-10; (meters, m) 

cox 1.92e-3 1.92e-3; (F/m 2 ) 

cgdo 2.2e-9 2.3e-9; (F/m) 

cgso 2.2e-9 2.3e-9; (F/m) 

cgbo 0 0; (F/m) 

DESCRIPTION: 

This data is used by the configuration command acc_branch in 

TimeMill or PowerMill simulations. The units are consistent 

with SPICE models (therefore, different from the EPIC units 

used in the technology file), and are shown in the example. Note 

that a semicolon (;) starts an in-line comment. 

If Gentech fails to include these values from SPICE models in 

the technology file, these commands can overwrite respective 

data lines in the technology file, and have the same effect as 

hand-editing the technology file with these entries. 

NOTE: A binary technology file cannot be hand-edited.

delta_vt 

SYNTAX: 

delta_vt n_delta_vt p_delta_vt 

EXAMPLE: 

delta_vt -0.5 0.5 

NOTE: You should use the values shown in this example. 

DESCRIPTION: 

Gentech 189 

The command delta_vt shifts the original threshold voltage by 

the amount specified. The amount of shift you specify should not 

be too large. 

This command is needed only when you want subthreshold 

currents included in the technology files and simulations. 

TimeMill and PowerMill simulations will slow down when these 

commands are used. 

You do not need to specify this command for automatic 

technology file generation; the default is used instead. 



vto 

SYNTAX: 

vto n_vto p_vto 

EXAMPLE: 

vto 0.7 -0.8 

This example indicates that the threshold voltage for NMOS is 

0.7 volts and the threshold voltage for PMOS is -0.8 volts when 

the source to bulk voltage is 0 under the nominal temperature of 

your models. 

DESCRIPTION: 

This command specifies the threshold voltage for MOS with a 

zero source-to-bulk voltage at nominal temperature. This is used 

to calculate the body-bias effects (the relationship between 

threshold voltage and source-substrate bias level) at the 

temperature specified in the %corner section. 

This is needed only for SPECTRE levels 4 (BSIM1), 5 (BSIM2), 

and 10 (BSIM1_5) models. 

For any unsupported SPICE type, if the SPICE can do a .OP run 

to print the threshold voltages at a specified temperature, this is 

not needed and not recommended in your Gentech SPICE runs. 

If this command is needed but not provided, Gentech attempts to 

read vto directly from the SPICE model. However, that might 

not be successful when the files listed in the %lib section are not 

readable or vto is not called vto in your model. In those cases, 

vto should be constructed by some other parameters. Therefore, 

you should specify the vto parameter when necessary. 

The vto values are real numbers, given in volts.

case 

SYNTAX: 

case upper | lower 

EXAMPLE: 

case upper 

Gentech 191 

DESCRIPTION: 

You can specify upper- or lowercase characters for the SPICE 

netlists created by Gentech. The library and model cards are not 

affected by this command. 



unit_wl 

unit_adas 

unit_pdps 

SYNTAX: 

unit_wl wl_char 

unit_adas adas_char 

unit_pdps pdps_char 

EXAMPLE 1: 

unit_wl 

EXAMPLE 2: 

unit_wl u 

unit_adas p 

unit_pdps U 

DESCRIPTION: 

You use these commands to overwrite the unit character used in 

the SPICE input file produced by Gentech if the defaults do not 

work. The defaults are either with or without a ‘U’ for geometries 

w, l, pd, ps; and with or without a ‘P’ for ad and as. Only the first 

character is taken as the new unit scaling character. If there is 

no character or a blank is used, the SPICE netlists will have no 

unit character for the corresponding geometry entry.

speed 

SYNTAX: 

speed 

DESCRIPTION: 

Gentech 193 

The addition of the speed command to the control file increases 

the speed with which the technology file is generated. 

NOTE: This command can be used only with HSPICE, SMARTSPICE, 

HPSPICE, and Spectre2. 



binary 

SYNTAX: 

binary 

DESCRIPTION: 

The binary command in the control file causes the generation of 

a binary file. 

NOTE: This command is valid only with TISPICE, HSPICE, 

SmartSpice, and HPSPICE. 

You cannot use this command with the simulation tool’s -A 

option.

temperature 

voltage 

Section 4 - %corner 

Gentech 195 

This section specifies the supply voltage and the temperature for 

the technology file. This section is mandatory. 

SYNTAX: 

temperature temperature 

voltage voltage 

EXAMPLE: 


voltage 3.3 

DESCRIPTION: 

The argument temperature is in degrees Celsius, and voltage is 

in volts. The voltage value should be the same as the vde and vge 

values in the vds and vgs commands in the %parameters 

section. The EPIC tool will issue a warning if these voltage 

values differ significantly. If you have different parts of a circuit 

operating under several voltages or temperatures, see the 

section “Using Multiple Technology Files” on page 204 for 

details. 

Section 5 - %invoke 

This section, which is mandatory, lets you specify the command 

syntax to start your SPICE. Use full pathnames for commands. 

EXAMPLE: 

/vendor/ees/runprecise [options] [%input%output] 

The arguments in brackets, though optional, are recommended. 

The keywords %input and %output let you control the command 

syntax to run your SPICE. You can add preprocessors, 

postprocessors, and so on, by creating a script that takes %input 

and %output as arguments. 



The following rules apply to the use of the keywords %input and 

%output: 

■ Both keywords must be separated by spaces. 

■ Multiple %input and %output keywords are accepted, with a 

limit of ten each. 

■ Any special preprocessing or post-processing should be done 

in a script which takes %input and %output keywords as 

arguments. 

EXAMPLE: 

%invoke 

/usr/joe/bin/my_SPICE 

You can use the %input and %output keywords in the line that 

Gentech substitutes with the names of SPICE input and output 

files, respectively. For example, if you start SPICE using 

my_SPICE -h -b -x abc -r input_file -o output_file, 

you can use the following syntax with the keywords in the 

control file: 

%invoke 

my_SPICE -h -b -x abc -r %input -o %output 

Note: SPECTRE users must use the %invoke syntax in the 

%invoke section. 

If your site runs a preprocessor on an HSPICE netlist and a postprocessor 

for the output, you can package everything into the 

following script called run_my_SPICE: 

#!/bin/sh -f 

SPICE_pre_proc < $1 > /tmp/foo 

/usr/bin/SPICE -h -b -x abc -r /tmp/foo -o 

/tmp/bar 

SPICE_post_proc < /tmp/bar > $2 

rm -f /tmp/foo /tmp/bar 

exit 0 

NOTE: This script assumes that its first argument ($1) is the name of 

the input file and the second ($2) is the name of the output file.

Gentech 197 

If this script is made executable, then you only need to change 

your control file to the following: 

%invoke 

run_my_SPICE %input %output 

Because you are running a different type of SPICE, you might 

also have to change the format of the input netlist that Gentech 

produces for SPICE runs. You can do this by either writing a 

translator or running a preprocessor. You can run such a 

translator before running the actual SPICE. This can be 

accomplished easily in the %invoke section. 

Section 6 - %options 

Section 6 allows you to include any SPICE options that would 

normally appear in the .OPTIONS lines in the SPICE netlist. For 

any other lines that must be in the SPICE netlist, use the %lib 

or %model section. 

SYNTAX: 

% options 

 

The .options keyword is not included because it is generated 

automatically. If you type .options scale=0.25e-6, Gentech 

creates .options .options scale=0.25e-6 in the SPICE 

netlist which might cause a SPICE failure. 

The defaults that are automatically placed in the SPICE netlist 

are: 

all except SPECTRE:.options nomod limpts=100000 

numdgt=7 

PSPICE/SPICE2:.WIDTH IN=80 OUT=132 

HSPICE: 

.OPTIONS SCALE=1.0E-6 CO=132 INGOLD=2 NXX 

.options ignore_measure="0" 



SPICE3:.WIDTH OUT=150 

PRECISE:.WIDTH 133 

SMARTSPICE:.OPTIONS NOMOD LIMPTS=100000 NUMDGT=7 

WIDTH=120 EPIC 

NOTE: EPIC does not support GOAL= statements or AC and DC modes. 

Section 7 - %diode 

Running Gentech 

This section can contain only diode models in SPICE format. 

This information is stored in a technology file for use by EPIC 

tools during simulation. Using this method, you can avoid 

having to keep diode models in the netlist. 

This section describes the syntax and control options used to run 

Gentech. It also explains how to run the utility in single-step and 

multiple-step modes. 

Gentech Syntax 

SYNTAX: 

gentech -c control_file 

-f SPICE_name 

[-t tech_file] 

[-b] 

[-a] 

[-m] 

[-x] 

[-n] 

[-h] 

[-q] 

EXAMPLE: 

gentech -f your_SPICE -c control.cmos -t tech.cmos

This example instructs Gentech to use the control file, 

control.cmos. Gentech runs your_SPICE to create a 

technology file named tech.cmos. 

DESCRIPTION: 

Gentech 199 

The Gentech command line option -c specifies the input control 

filename, -f specifies the SPICE type you are using, and -t 

specifies the output technology filename. 

The command-line options for the gentech command are: 

-b Turns on the multiple-step (batch) mode. Use this when 

your SPICE does not reside on your current network (for 

example, if your SPICE runs on a mainframe), monitoring 

the Gentech run, or other purposes. See “Running Gentech 

in Multiple-step Mode” on page 202 for more details. 

NOTE: This option should be used if a SPICE license is 

unavailable on your network. If a SPICE license is 

available on another host within the same network, 

create a script to remote login to the SPICE host 

machine and submit the SPICE job. Specify the 

name of the script in the %invoke section. The -b 

option cannot be used with the -q option. 

-a Accumulates the spice input and output files from a singlestep 

run (interactive mode not using the -b option) for the 

purpose of reporting a problem. 

If you encounter problems, rerun Gentech in an empty 

directory using the multiple-step run mode with the -b 

option to accumulate spice.in1, spice.out1, spice.in2, and 

spice.out2 files, and send them with the control file to 

EPIC. If your SPICE does not allow running Gentech in 

multiple-step mode, or you do not have the time to finish 

the multiple-step run, use the -a option with the singlestep 

run to accumulate the needed SPICE files. 

If disk space is limited, delete some MOS sizes in the 

control file before reporting the problem. 

-c control_file 

Specifies the name of the control file. See “Gentech Control 




-f spice_name 

Specifies the name of the SPICE to be run by Gentech. The 

following formats are supported: HSPICE, PRECISE, 

SPECTRE, SPECTRE2, SMARTSPICE, PSPICE, SPICE2, 

SPICE3, HSPICE_like, SPICE2_like, and some proprietary 

SPICE types. 

-f SPECTRE2 applies when a SPICE2 model is used with 

SPECTRE. It runs a SPICE2 mode of SPECTRE. -f 

SPECTRE applies when a SPECTRE model is used, and 

runs the SPECTRE native language. -f HSPICE_like and - 

f SPICE2_like are used on unsupported SPICE types when 

customizing. 

-t tech_file 

Specifies the output technology filename. The default is 

technology.prm. 

-x Allows you to use SPECTRE BSIM models without 

specifying vto in the control file. 

NOTE: This option is not needed for HSPICE or PRECISE. 

-n Tells Gentech that your SPICE does not support dual. DC 

sweep for generating Ids tables. Gentech issues more 

SPICE runs to sweep vgs and vds separately. This is turned 

on by default for SPECTRE. 

-h Prints command-line help. 

-q Runs quick mode (for HSPICE, SMARTSPICE, and some 

proprietary SPICE types only). Using this option causes 

Gentech to read the parameters directly from the SPICE 

model information. Gentech runs faster in this mode. You 

do not need to specify acm, cjgate, cov, cg, ldiff, wdiff, 

lmlt, wmlt, and so on, in the control file. In some cases, 

this option generates a more accurate technology file. 

-m Instructs Gentech to extract lateral diffusion values (ldiff 

and wdiff) from the SPICE models specified in the control

Gentech 201 

file. This works with SPICE2, SPICE3, HSPICE, PSPICE, 

SPECTRE, and others. 

If -m is not specified, the ldiff and wdiff values are either 

taken from specified ldiff or wdiff control file commands, 

or calculated by running SPICE. 

If you are using HSPICE, use the -q option instead of the 

-m option. 

If you are not using HSPICE, you should set the ldiff and 

wdiff parameters in the control file. The following warning 

is issued if you let Gentech calculate values for ldiff and 

wdiff by running SPICE. 

gentech: WARNING: No ldiff/wdiff specified in 

Control File. 

gentech: WARNING: Extracted values may be 

inaccurate and may affect simulation accuracy. 

Single-Step and Multiple Step (Batch) Modes 

You can run Gentech in single-step and multiple-step (batch) 

modes. In either mode, you should save the spice.in1, spice.in2, 

spice.out1, and spice.out2 files in case you have to rerun 

Gentech or report a problem. In single-step mode, you must use 

the -a command argument to generate these files. 

Running Gentech in Single-step Mode 

In single-step mode, Gentech directly runs your SPICE, 

according to the syntax in the %invoke section of the control file, 

and iterates several SPICE runs for each size until the 

technology file is created. You need to type the gentech 

command only once. 

If you can run your SPICE and obtain a result in the local 

directory, you can run Gentech by using either one of the 

following command lines: 

gentech -c control.cmos -f your_SPICE -t tech.cmos 

or 



gentech -c control.cmos -f your_SPICE -t tech.cmos 

-a 

This reads the control.cmos file and builds the technology file 

tech.cmos as follows: 

1 Generates a SPICE netlist named spice.in. 

2 Runs SPICE to generate the SPICE output. The file must be 

named spice.out. 

3 Reads the SPICE output and adds an entry to the tech.cmos 

file. 

4 Repeats steps 1 through 3 until tech.cmos file is complete. In 

both steps 1 and 2, the spice.in and spice.out files are 

overwritten. 

If the -a command argument is used, all the SPICE files will be 

saved in spice.in1, spice.in2, spice,out1, and spice.out2 files, 

requiring additional disk space. You can use these files if you 

have to rerun Gentech in multiple-step mode or to report a 

Gentech problem. You might rerun Gentech when you want to 

overwrite the average capacitance. 

Running Gentech in Multiple-step Mode 

If you must run SPICE on a batch machine or an unconnected 

remote machine, the single-step method will not work since the 

SPICE jobs go into a queue and are run in the background. 

Therefore, you must run Gentech in multiple-step mode. Three 

Gentech and two SPICE runs are required. The output of the 

first SPICE run is needed to build the input for the second. The 

steps are: 

1 On your local machine, type: 

gentech -f SPICE_type -c control_file 

-t tech_file -b 

This creates a file called spice.in1.

Gentech 203 

2 Run SPICE using the file spice.in1, and name the output file 

spice.out1. 

3 Move the spice.out1 file to the directory from where you 

originally ran Gentech and rerun the utility by typing: 

gentech -f SPICE_type -c control_file 

-t tech_file -b 

This creates a file called spice.in2. 

4 Run SPICE using input file spice.in2, and name the output 

file spice.out2. 

5 Move the file spice.out2 to the directory from where you 

originally ran Gentech and rerun the utility a third time 

using the same command syntax as above. The technology 

file is created. 

NOTE: Do not delete or edit the control file, technology file, spice.in1, 

spice.out1, spice,in2, or spice.out2 files during the process. 

Because Gentech checks the time the files were either created or 

edited, editing may occur in the wrong sequence for the process. 

The input files to SPICE spice.in1 and spice.in2 have many 

SPICE runs in a single file. Your SPICE must be able to take 

multiple runs as one job. SPECTRE and some proprietary SPICE 

types cannot do this for the supported SPICE types. But any 

SPICE type can use the -a command argument to run Gentech 

first in single-step mode. Multiple-step mode is then possible 

with the available spice.out1 and spice.out2 files. 

Multiple-step mode does not run SPICE directly. It is convenient 

when a rerun of Gentech is needed to overwrite average 

capacitance or to report a Gentech problem. The following steps 

show how to rerun Gentech to overwrite average capacitance, if 

needed. 

1 After you’ve completed steps 1 through 5 above, save the 

original technology file using another filename. Keep files 

spice.out1 and spice.out2. 



2 Enter the appropriate cg, cov, cja, cjsw commands in the 

control file. 

3 Rerun steps 1 through 5, but replace “Run SPICE...” with 

“Touch spice.out1” or “Touch spice.out2” in steps 2 and 4. 

4 After the new technology file is generated, use the UNIX diff 

command on the new and original technology files to verify 

the changes on the diff_cap and gate_cap data lines. 

Using Multiple Technology Files 

A Gentech control file does not accept more than one NMOS 

model and one PMOS model. You need to run Gentech separately 

when you have depletion NMOS models, several process corners, 

multiple supply voltages, or charge pump circuits. If you run 

Veritech, it also needs to be run separately under these 

circumstances. 

EPIC tools accept multiple technology files when you use 

multiple -p command line arguments. Therefore, do not 

concatenate or edit the technology files. (If necessary, use the 

Gentech control file commands to change the technology files.) 

You can build a runscript to generate multiple technology files by 

using gentech and veritech as basic commands. 

Model names and model_alias lines cannot conflict when using 

multiple technology files. 

Be sure to use different model names in the %model sections and 

different model_alias lines in the %parameters section for all 

your different models among multiple control files and 

technology files. For information about the %model section, see 

“Section 2 - %model” on page 159. 

Temperatures and Voltages 

Different temperatures are allowed. Using different model 

names, you can model various parts of your circuit and simulate

PrintWL Utility 

PrintWL Utility 205 

them under several temperatures. Make sure the temperature 

differences are significant so that the results will be meaningful. 

Different supply voltages are also allowed. However, you must 

use the set_voltage configuration command to properly reset 

the supply voltage. Otherwise, EPIC tools might use the last 

supply voltage read from the multiple technology files. Inside 

each technology file, the voltage command in the %corner 

section is used to decide the voltage range to calculate the 

average capacitance by Gentech, and the vgs and vds commands 

in the %parameters section determine the range for ids tables. 

Therefore, the ending vgs and vds values and the voltage value 

should be the same in one file, but can be different in multiple 

technology files. 

PrintWL is a utility that generates a file containing all transistor 

sizes used in a netlist. The file is in a format that can be used as 

part of a Gentech control file to compile a technology file. 

PrintWL reads netlist information from all compatible netlist 

programs. 

When you run PrintWL, it finds NMOS and PMOS model pairs in 

the netlist and generates an output file for each pair. If PrintWL 

finds an NMOS or PMOS model it cannot pair, it generates an 

individual output file for the extra model. This utility generates 

several output files, depending on the number of models in the 

input netlist. The default output files are WL1, WL2, WL3, and 

so on. You can use the -o option to rename the output file prefix. 

PrintWL classifies netlist model names beginning with the letter 

N or n as NMOS models, and models beginning with the letters 

P or p as PMOS models. If PrintWL encounters model names that 

do not begin with the letters N or P, it prompts you to specify 

whether the model names identify NMOS or PMOS models. The 

PrintWL output file contains transistor width and length 

descriptions in Gentech control file format. If any two transistors 



have the same width and length measurement, PrintWL lists 

only one of those transistors in the output file. 

The PrintWL utility sorts transistors by size, listing the smallest 

transistor first. 

SYNTAX: 

printWL [-m main_circuit_name...] 

[-N n_model_name...] 

[-P p_model_name] 

[-o output_file_prefix] 

[-f value] 

[-g] 

[-h] 

[-L library_path] 

[-a] 

-n netlist ... 

The command-line options are: 

-m top_circuit_name 

This option specifies the top level circuit name, or the 

topmost circuit name for the given netlist. 

-N n_model_name... 

This option specifies the NMOS model name. The default 

model name is N, or n. 

-P p_model_name... 

This option specifies the PMOS model name. The default 

model name is P, or p. 

-o output_file_prefix 

This option specifies the output file prefix. The default prefixes 

are: WL.1, WL.2, WL.3, and so on.

PrintWL Utility 207 

-f This option specifies the number of decimal places to be 

printed depending on the desired level of precision. Values 

are 0 through 10; the default value is 2 decimal places. 

-g This option instructs printWL to truncate the model name 

suffix. 

-h This option displays the command and its options. 

-L library_path 

This option specifies the cell library path. 

-a This option instructs printWL to process files even though 

a main circuit is not defined in the design. This option is 

similar to -L except that subcircuit definitions do not reside 

in individual files. This option is ignored if -m is used. 

-n netlist ... 

This option specifies the input netlist names. 



Figure 5 shows a sample netlist, which is the primary input to 

the PrintWL utility. 

HSPICE; 

pgalias vdd! vdd; 

pgalias gnd! gnd; 

(subckt=inv)(it=A)(ot=Y) 

(pr=pl:0.6,pw:16,nl:0.5,nw:5){ 

(t=n)(en=N4)(ga=A)(dr=Y)(so=gnd!)(w=nw)(l=nl); 

(t=p)(en=P5)(ga=A)(dr=vdd!)(so=Y)(w=pw)(l=pl); 

} 

(ef=inv)(en=I8)(it=B)(ot=A) 

(pr=nl:6,nw:1.1,pl:3,pw:1.1); 

(ef=inv)(en=I7)(it=C)(ot=D) 

(pr=nl:0.5,nw:11,pl:0.6,pw:26); 

(ef=inv)(en=I6)(it=B)(ot=C) 

(pr=nl:0.5,nw:3.4,pl:0.6,pw:8); 

(ef=inv)(en=I5)(it=A)(ot=B) 

(pr=nl:0.5,nw:1.4,pl:0.6,pw:3.6); 

(t=p1)(en=P4)(ga=PREF)(dr=A)(so=vdd!)(w=120)(l=60); 

(t=n1)(en=N3)(ga=PREF)(dr=DEC3)(so=A)(w=500)(l=50); 

(t=n)(en=N2)(ga=ADR)(dr=DEC2)(so=DEC3)(w=500)(l=50); 

(t=n)(en=N1)(ga=ADR)(dr=DEC1)(so=DEC2)(w=500)(l=50); 

(t=n)(en=N0)(ga=ADR)(dr=gnd!)(so=DEC1)(w=500)(l=80); 

Figure 5 Sample netlist for PrintWL example

The Technology File Viewer 209 

The following two figures (collectively Figure 6) show sample 

output files that are generated by the printWL -n netlist 

command: 

The Technology File Viewer 

WL1: 

%model 

.model n1 nmos 

.model p1 pmos 

%parameters 

N_LENGTH1 0.50 

NW1 5.00 

P_LENGTH1 0.60 

PW1 1.20 

WL2: 

%model 

.model n nmos 

.model p pmos 

%parameters 


NW1 5.00 


NW2 5.00 1.40 3.40 11.00 


NW3 1.10 


PW1 3.60 8.00 26.00 


Figure 6 Examples of printWL-n netlist output files 

The technology file viewer, TechViewer, lets you view an EPIC 

format technology file graphically. The TechViewer is 

automatically installed if you are running TimeMill, PowerMill, 

PathMill, or RailMill. No other installation is needed. 



Veritech Utility 

To use TechViewer: 

1 Type techViewer. 

2 Select File → Open Technology File. 

The temperature and voltage of the power supply are 

displayed. The models from the specified technology file are 

listed. 

3 Select a model from the list. 

4 Click on the Show Tables button(s). 

This displays graphs for vt and ids. 

Clicking on the vt/iv curve windows displays the relevant 

data information on the status banner. 

Selecting another model while graphs are displayed 

automatically updates the opened graphs. 

5 To quit, select File → Exit. 

You can use the Veritech utility to verify the accuracy of the 

technology file created by Gentech. However, Veritech only tests 

on very special circuits, and the tests frequently give false 

errors. Therefore, the recommended verification flow for 

technology files is to run your SPICE on an actual design and 

run EPIC tools with the generated technology files on that same 

design. You can then compare the two to check for accuracy. 

The Veritech utility works with the following SPICE types: 

HSPICE, PRECISE, SMARTSPICE, PSPICE, SPICE2, SPICE3, 

and some proprietary SPICE types. Make sure your version of 

SPICE is supported.

Technology File 

Veritech 

Veritech 

Report 

Veritech Utility 211 

The utility runs with the EPIC Tools TimeMill, PowerMill, and 

PathMill. An EPIC tool license is necessary. Figure 7 shows the 

flow of a Veritech run. 

Figure 7 Flow of a Veritech run 

Running Veritech 

SPICE Input 

SPICE Output 

EPIC Input 

EPIC Output 

Veritech provides the following validations: 

SPICE 

TimeMill 

PathMill 

or 

PowerMill 

■ The results of several test circuits, based on the given 

technology file, match reasonably well with SPICE. 

■ All technology data values are within reasonable numeric 

ranges. 

■ All technology data matches the corresponding SPICE model 

parameters. 

This section shows the syntax and command-line options for the 

veritech command. It also describes the results of a Veritech 

run and the steps you should take if the run is aborted. 



SYNTAX: 

veritech tech_file -f spice_type 

[-o out_file] 

[-b] [-B] 

[-h] 

The command-line options used with the veritech command are: 

tech_file 

This is the technology file which includes the control file 

and the SPICE model (listed in the %model section, or in a 

readable file referenced by the .include or .lib commands 

in the %lib section). The technology file can be in 

compressed format. 

NOTE: Veritech treats the %lib control file keyword in the 

same way as Gentech. 

-f spice_type 

This can be used to specify the type of SPICE if Veritech 

fails to decide the SPICE type after examining the %invoke 

section. The accepted SPICE types are: HSPICE, SPICE2, 

SPICE3, PSPICE, SmartSpice, PRECISE, and a number of 

proprietary versions of SPICE. Check to see if your SPICE 

version is supported. 

-o out_file 

This specifies the output filename. It is mandatory except 

when -b is used. 

-b, -B 

This runs batch mode. If SPICE is not available on your 

machine, first use -b to generate all SPICE input files, then 

use -B when all SPICE output files are ready. 

EXAMPLE: 

veritech techfile -b 

This generates all SPICE input files. Run SPICE remotely, 

bring back all SPICE output files, and type the following 

command line:

veritech techfile -b -o out_file 


-d Debug mode saves all intermediate files and echoes some 

model parameters. This is useful when you are reporting 

a Veritech problem. 

-h This option prints command line help. 

Veritech commands are shown in the following examples. 

EXAMPLE 1: 

veritech tech.8.typ.2 -f hspice 2 0.8 1 0.7 -g -o 

report & 

EXAMPLE 2: 

veritech technology.prm -o veri.out 

(Writes out to screen only.) 

NOTE: Veritech automatically detects if PowerMill, TimeMill, or 

PathMill exist on the machine. If PathMill is used, there will be 

no Test 4 since PathMill does not report the final voltages on a 

node. 

Veritech compares simulation results generated by running your 

SPICE and one of the EPIC tools and generates a pass/fail 

status for each result. This status is determined by checking 

whether the difference falls within a pre-determined, allowable 

margin of error. 



After Running Veritech 

If you run Veritech and find that only a very small portion of the 

sizes in any test have large percentage errors, the technology file 

is still sufficiently accurate, as long as their corresponding data 

in the technology file behave roughly the same as other MOS 

sizes. 

To improve the accuracy of a technology file, carefully check all 

the warnings given by Veritech, edit the control file accordingly, 

and generate a new technology file. Run Veritech again to verify 

the improvements. 

NOTE: Remember that Veritech runs very specialized device-level 

circuits that can result in false errors. The best way to check 

accuracy is to run a sample circuit on your SPICE and then run 

the same circuit using of the EPIC tools. Generate the 

technology file and compare for accuracy. 

If Veritech Aborts 

If Veritech aborts, check all the simulation output and .err files 

remaining in the working directory. This can be done easily if 

you start Veritech in a directory that contains only necessary 

files (the technology file and model library files, if applicable). 

The following conventions are used by Veritech for creating the 

input and output files: 

■ When rise and fall times are 0.1ns, the following files are 

generated for tests 1,2,4,5, and for test 3 (SPICE only): 

◆ veritech_netn (netlist files to EPIC Tools PathMill, 

PowerMill, or TimeMill) 

◆ veritech_cfgn (configuration files to EPIC Tools) 

◆ pathmilln.out (PathMill analysis output files) 

◆ powrmilln.out (PowerMill simulation output files) 

◆ timemilln.out (TimeMill simulation output files)

◆ SPICEn_in (SPICE input files) 

◆ SPICEn_out (SPICE output files) 


■ When rise and fall times are 5ns, the following files are 

generated for tests 1,2,5: 

◆ veritech_netnr (netlist files to EPIC Tools) 

◆ veritech_cfgnr (configuration files to EPIC Tools) 

◆ pathmillnr.out (PathMill analysis output files) 

◆ powrmillnr.out (PowerMill simulation output files) 

◆ timemillnr.out (TimeMill simulation output files) 

◆ SPICEnr_in (SPICE input files) 

◆ SPICEnr_out (SPICE output files) 

You can manually rerun the most recent case to determine why 

Veritech aborted. This is usually because the PathMill, 

PowerMill, TimeMill, or SPICE run failed. 

EXAMPLE 1: 

timemill -n net5r -c cfg5r -p tech_file -t 80 -o 

timemill5r 

This is an example of the command you can use to rerun 

TimeMill. 

EXAMPLE 2: 

spice3 -b -r spice5r_out < spice5r_in 

This is an example of the command you can use to rerun SPICE. 


216 Chapter 4 EPIC Technology File

Chapter 5 

Stimuli and State 

Checking

218 Chapter 5 Stimuli and State Checking

Overview 

Overview 219 

The dynamic EPIC tools require input stimulus of some form. 

Input stimulus can be either individual time-varying signals or 

a vector pattern. Special EPIC functions are available to provide 

input stimulus if none is specified in a SPICE netlist. Some 

stimulus functions generate stimulus patterns based on 

parameters specified in the function calls. 

An output vector is a state pattern used to compare simulated to 

expected results. 

This chapter explains the various stimulus functions as well as 

the format of the vector pattern. 

Stimulus Functions and Vector Functions 

EPIC provides ten stimulus functions. Some of the EPIC input 

stimulus functions generate an input stimulus based on 

parameters specified in the function call. Stimulus generator 

functions are clk, cnt, ptn, and tgl. 

Another group of stimulus functions allows data or test vectors 

pre-stored in a specified file to be referred to at user-defined time 

steps. These functions are nsvt, vec, and vec_chk. The function 

vec_chk verifies the simulator results with respect to the 

expected circuit response during a simulation. The functions vec 

and nsvt offer a combination of input stimulus and vector 

checking, and are the most widely used. 

Another group of stimulus functions that set stimulus values are 

one, udf, and zero. 

Multiple stimulus function calls can be placed into one file and 

submitted to the dynamic tool using the -n option on the 

command line. 


220 Chapter 5 Stimuli and State Checking 

Function Definitions 

EXAMPLE: 

powrmill -n netlistfile stim -p techfile -t time 

-c cfgfile 

If you are using a vector pattern as input stimulus, you submit it 

directly to the dynamic tool using the -nvec option on the 

command line. 

EXAMPLE: 

powrmill -n netlistfile -nvec vectors -p techfile 

-t time -c cfgfile 

(See “Running the Vector File Using type and signal Commands” 

on page 247.) The input vectors for the vec, vec_chk, or nsvt 

specification are stored in separate data files. 

The following types of functions are described in this section and 

are ordered alphabetically: 

■ Clock Stimulus (clk) 

■ Counter Stimulus (cnt) 

■ Pattern Stimulus (ptn) 

■ Toggle Stimulus (tgl) 

■ Vector Stimuli and Vector Checking (nsvt, vec, vec_chk) 

■ Logic Constants (one, udf, zero)

clk 

c1 

SYNTAX: 

Function Definitions 221 

(is=clk) (en=element_name) (ot=signal_list) [(ov=orig_values)] 

(sv=start_t, toggle_t, prd, rise_time, fall_time); 

OR 

(is=clk) (en=element_name) (ot=signal_list) [(ov=orig_values)] 

(sv=start_time:val, toggle_time:val, period:val, rise_time:val, 

fall_time:val); 

EXAMPLE: 

(is=clk)(en=CLOCKa)(ot=c1,c2,c3,c4)(ov=0,0,0,0) 

(sv=10,20,40,5.0,7.5); 

The same clock specification is applied equally to nodes c1, c2, 

c3, and c4; (ov=0,0,0,0) is optional. 

Figure 1 shows an example of a clk function. 

40 

5.0 7.5 

0 1 2 3 4 5 6 7 8 9 10 

Figure 1 clk function 

DESCRIPTION: 

Time (ns) 

This function defines a clock which has a repetitive waveform 

pattern with a clock period. The default number of states is 5. 



The second syntax shows a long form, using keywords recognized 

by the EPIC simulators. 


element_name The unique name that represents 

this particular instance of this 

function 

signal_list Nodes to be stimulated by the 

resulting clk pattern 

orig_values Sets the initial clock output states; 

if it is not specified, the default is 

the zero state 

start_t Defines the starting time of the 

clock operation, and is measured 

in nanoseconds. The signals will 

start to rise or fall at this time. 

toggle_t Defines the incremental time, 

after the start time, when the 

clock state begins to change, and is 

specified in nanoseconds 

prd Defines the clock period in 

nanoseconds 

rise_time, fall_time Specifies the rise and fall time 

durations, respectively, in 

nanoseconds. They can be specified 

in floating point or integer 

formats. 

The default rise/fall times are 

zero, which generates a squareedged 

waveform without rise/fall 

slopes. The rise/fall times are 

imposed on start_t and toggle_t, 

which specify the start of the 

rising and falling edges.

cnt 

in1 

in0 

SYNTAX: 


(is=cnt) (en=element_name) (ot=msb,..,lsb) (ov=orig_value(s)) 

(sv=start_t, inc, rf_t); 

OR 

(is=cnt) (en=element_name) (ot=msb,..,lsb) (ov=orig_value(s)) 

(sv=start_time:val, inc:val, rf_time:val); 

EXAMPLE: 

(is=cnt)(en=count)(ot=in1,in0)(ov=0,0)(sv=10,10,1) 

; 

Multiple ot’s and ov’s are allowed, but must be separated with 

commas (,). 

Figure 2 shows an example of a cnt function. 

1.0 ns 

0 10 20 30 40 

Figure 2 cnt function 

DESCRIPTION: 

Time (ns) 

This function defines an n-bit up-counter. The output signals 

count up from the LSB at the right towards the MSB at the left. 

The starting time, the increment period, and the signal rise/fall 

time are defined in the sv field. The default number of states is 3. 



The second syntax demonstrates a long form using keywords 

recognized by PowerMill and RailMill. 


element_name This unique name represents this 

particular instance of this function. 

msb,..,lsb This is a list of nodes representing 

the most to the least significant 

bits. 

orig_value(s) Defines the initial values for 

msb,...,lsb. The default is zero(es) if 

not specified. 

start_t At start_t, the value of the nodes 

increment by one from orig_value. 

The units are in nanoseconds. 

inc The increment period. The units 

are in nanoseconds. 

rf_t Specifies one value used for the 

rise/fall time. If not specified, the 

default is zero. The units are in 

nanoseconds.

fixed_rf 


The new vector file command, fixed_rf, which is used by 

nsvt and vec, causes the rise/fall/slope commands to 

define a fixed rise/fall time that is not affected by the 

starting voltage. If this command is not used, the rise/fall/ 

slope commands define a fixed slew (rise/fall) rate of the 

input signal change, and the rise/fall time can vary with 

the starting voltage. 

EXAMPLE: 

rise 2.5 

fall 1.5 

fixed_rf 

This example sets the rise and fall times of all inputs in the 

vector to a fixed 2.5 ns and 1.5 ns, respectively, regardless 

of the starting voltage for the input. 

This command can be overridden by the configuration 

command set_vec_opt. 



nsvt 

SYNTAX: 

(is=nsvt) (en=vector_file) (ot=signal_list); 

EXAMPLE: 

(is=nsvt)(en=my_vectors)(ot=A,B,C[15-0],X,D[7-0]); 

This an example entry in the netlist which calls the nsvt 

function. 

Figure 3 shows how typical data in a vector file might appear. 

The radix and io lines are explained in the vector file description. 

The keyword period entry specifies the time interval in 

nanoseconds at which the test vector, or the signals, are to be 

invoked. The period of data invocation is defined inside the 

vector file. A line beginning with a semicolon is a comment. (See 

“Vector File Format” on page 239.) 

; A B C[15-0] XD[7-0] 

radix 1 1 4 4 4 4 14 4 

; specify input and output signal 

io i b i i i u oo o 

period 20 

;data output at 0ns, 20ns, 40ns, ... 

;data to follow 

1 0 0 0 0 0 10 0 

0 1 a b c d 01 2 

0 0 4 e d d 02 1 

0 1 4 e d e 1 4 0 

Figure 3 Vector file data example 

DESCRIPTION: 

This function provides a method for reading in a file containing 

input stimuli and output comparisons to be applied at fixed 

intervals. The stimulus and comparison data is organized in a 

tabular format without absolute times in the vector section. 

The timing information associated with the vectors is specified 

within a period (interval), using the period command. Each new 

vector comes one interval after the previous vector. The first 

vector is applied at time 0.


The rise/fall/slope time can be specified for the signals in the 

vector file. The signal radix and its type (input, output, biput) 

can also be specified. For input and biput signals, the stimulus 

drive resistance can be specified by the keyword out. See 

output_resistance in “Vector File Format” on page 239. 

The default time unit for all time parameters, including rise/fall/ 

slope time, is a nanosecond. It can be changed using time_scale 

as explained in “Vector File Format” on page 239. The default 

resolution in the time specification is 0.01ns. You can use the 

set_sim_tres configuration command to change it. See the 

TimeMill or PowerMill reference guide. 

The valid state characters for input stimuli and output 

comparison are documented in “State Characters Used by EPIC 

Tools” on page 248. 


vector_file Specifies the file to be read. It can be 

either a full pathname or a relative 

pathname, as long as the search path 

can locate the vector file containing the 

vectors used to force the specified nodes 

to the proper values during the 

simulation. In the vector file, radix, 

slope, io, and output_resistance are 

used in the same way as in the vec 

specification. 

signal_list Specifies the list of signal names 

corresponding to the data provided in 

the vector file. 



one 

SYNTAX: 

(is=one) (en=element_name) (ot=signal_list); 

EXAMPLE: 

(is=one)(en=HI)(ot=VE,Kdata_edge); 

This sets VE and Kdata_edge to constant ONE. 

DESCRIPTION: 

The stimulus specification one sets the stimulus value to a 

constant ONE.

ptn 

cck1 

SYNTAX: 

(is=ptn) (en=element_name) (ot=signal_list) 

(sv=bit_duration,rf_time,bit_pattern); 


EXAMPLE: 

(is=ptn)(en=gen1)(ot=cck1,cck2) 

(sv=2,0.2,0,1,1,0,1,0,0,1,1,0); 

This example shows a stimulus pattern with a bit duration of 2ns 

(first argument in the "sv=" field) and a 0.2ns rise-fall time 

(second argument in the "sv=" field). The pattern starts with 

logic 0 (third argument). Then it starts to rise to logic 1 at time 

2ns (fourth argument). It reaches logic 1 at 2.2ns since the risefall 

time is 0.2ns. It stays at logic 1 for another duration (fifth 

argument), then starts to fall to logic 0 at 6ns (sixth argument). 

The remaining arguments control the waveform for the rest of 

time in the same way. 

Figure 4 shows an example of a ptn function. 

0.2 0.2 

0 2 4 6 8 10 12 14 16 18 20 

Time (ns) 

Figure 4 ptn function 

DESCRIPTION: 

This function creates an input stimulus from a bit pattern. The 

default number of states is greater than, or equal to, 3 depending 



on the sv function. Multiple ot’s are allowed, but must be 

separated with commas. 


element_name This unique name represents this 


signal_list Specifies a list of nodes stimulated 

by the resulting ptn pattern. 

bit_duration Specifies the time in nanoseconds 

for each bit in the given pattern, 

and can be specified in either 

floating point or integer format. 

rf_time Specifies the rise and fall duration 

in all the bit patterns in either 

floating point or integer formats. 

bit_pattern Specifies the desired pattern of a 

stimulus variation in binary format 

such as 1,1,0,1. The pattern repeats 

itself continuously in time. The 

pattern can be as long as required, 

but it must be at least one number 

long.

tgl 

gg10 

SYNTAX: 


(is=tgl) (en=element_name) (ot=signal_list) (ov=orig_value(s)) 

(sv=rf_time, toggle_times...); 

EXAMPLE: 

(is=tgl)(en=sig1)(ot=gg10)(ov=1) 

(sv=1.0,2,4,10,12,15); 

Figure 5 illustrates this example. 

1.0 

0 2 4 6 8 10 12 14 16 

Time (ns) 

Figure 5 tgl function 

DESCRIPTION: 

This function defines a toggle stimulus which toggles output 

between 1 and 0, according to a list of non-zero toggle times. 

There is no limit to the number of toggle times. The default 

number of states is greater than or equal to 2, depending on the 

sv function. 


element_name Specifies a unique name for this 


signal_list Lists the nodes stimulated by the 

resulting tgl pattern. Multiple 

signal lists must be separated by 

commas (,). 




orig_value(s) Defines the initial states. This is 

important because the states are 

changed at the subsequent 

toggle_times. Multiple values must 

be separated by commas (,). 

rf_time Defines the signal rise/fall duration 

in nanoseconds. The start point on 

the rise/fall slope is coincident with 

the toggle times. 

toggle_times Specifies values measured in 

nanoseconds. It is referenced from 

Time0 and must be listed in 

ascending time order.

udf 

SYNTAX: 

(is=udf) (en=element_name) (ot=signal_list); 

EXAMPLE: 

(is=udf)(en=und)(ot=IDN); 

This sets IDN to a constant undefined state. 


DESCRIPTION: 

The stimulus specification udf sets the stimulus value to a 

constant undefined state. 



vec 

SYNTAX: 

(is=vec) (en=vector_file) (ot=signal_list); 

(is=vec)(en=test_vector)(ot=bus[15-0],vin,vout); 

This example specifies that the file (test_vector) is a vec file 

to stimulate or compare bus [15-0], vin, and vout. 

Figure 6 shows the sample file. The rise time 3ns and fall time 

2.25ns are applied to all input signals (bus[15-0], vin). The 

output resistance 100 Ohms is applied to input (biput) signals 

(bus[11-8]) when the state L/H/Z are applied to the signals at 

times 200ns, 300ns, and 500ns. 

; 

; test_vector: an example vec file 

; 

; bus[15-0] vinvout 

radix 4444 1 1 

io iiii i o 

rise 3.00 

fall 2.25 

; 

; 

output_resistance 100 

; output resistance applied to all input 

; signals when the input states are L/H/Z. 

0.00 3A58 0 1 

100.00 5050 1 0 

200.00 5H50 1 0 

300.00 9L9E 0 1 

400.00 604B 0 1 

Figure 6 Sample vector file 

DESCRIPTION: 

This function provides a method for reading in a file containing 

input stimuli and output comparison. The stimulus and 

comparison information is organized in a tabular format with 

absolute times on the left and data vectors on the right.


The rise/fall/slope time can be specified for the signals in the 

vector file. The signal radix and its type (input, output, biput) 

can also be specified. For input and biput signals, the stimulus 

drive resistance can be specified by the keyword out. See 

output_resistance in the “Vector File Format” on page 239. 

The valid state characters for input stimuli and output 

comparison are documented in “State Characters Used by EPIC 

Tools” on page 248. 


vector_file Specifies the file to be read. It can 

be either a full pathname or a 

relative pathname, as long as the 

search path can locate the vector 

file containing the vectors used to 

force the specified nodes to the 

proper values during simulation. 

signal_list Specifies the nodes to be forced or 

compared. 



vec_chk 

SYNTAX: 

(is=vec_chk) (en=vector_file) (it=signal_list); 

EXAMPLE: 

(is=vec_chk)(en=alu.chk)(it=a1,b[1-0],fbus[39-0]); 

This is an example of an entry in a EPIC netlist that calls the 

vec_chk function. It specifies the file (alu.chk) where the 

vectors are found. The nodes in the EPIC netlist that are checked 

are a1, a single bit signal; b[1] and b[0], two bits from the bus 

labeled b; and 40 bits from fbus. 

Figure 7 shows how typical data in the alu.chk file might appear. 

Comments are preceded by a semicolon. The radix statement 

matches the bit width of the specified nodes: 1 matches the 

single-bit a1; 2 matches the two-bit width of b[1-0]; and so 

forth. The actual vectors are specified with floating point times 

in the left fields and the vector values in the right fields. At time 

100 ns, the line is extended to the next line using a backslash. 

;this illustrates the features of the vec_chk format 

radix 12 4444444444 ;specifies signal radix 

;time is on the left and signals on the right 

10 10 7f00001111 

10.37 11 adadaDadad 

14.2 01 3333333333 

100 01 010\ 

10107f7 

100.13 1222 12345689 

;columns are deliberately misaligned to show generality but 

;would in most cases be aligned for ease of reading 

Figure 7 vec_chk file sample 

DESCRIPTION: 

This function provides a method of reading in a file containing 

expected data values. The expected data information is 

organized in a tabular format that has absolute time on the left 

and data vectors on the right. See the TimeMill or PowerMill 

reference guide. Any differences between the expected data


stored in vector files and the simulation results are flagged with 

an error message in the .err file. 

The data file for vec_chk follows the same format as for vec, 

with the exception that the io, output_resistance (out), slope, 

rise, and fall commands are not necessary because all vectors 

are expected outputs. See the “Vector File Format” on page 239 

for details. 


vector_file Specifies the file to be read 

containing expected data. It can be 

a full pathname or a relative 

pathname, as long as the search 

path can locate the vector file. 

signal_list Specifies the nodes in the EPIC 

netlist to be checked by this 

function. Notice that vec_chk uses 

it, not ot, to call signal_list, because 

it is a monitor, not a signal 

generator. 



zero 

SYNTAX: 

(is=zero) (en=element_name) (ot=signal_list); 

EXAMPLE: 

(is=zero)(en=Z0)(ot=A1,BK,DL); 

This example sets A1, BK, and DL to constant ZERO. 

DESCRIPTION: 

The stimulus specification ZERO sets the stimulus value to a 

constant ZERO. 

Output State Comparison 

All vector stimulus functions (nsvt, vec, vec_chk) in the EPIC 

netlist can be used to specify vector files to check the circuit’s 

state during simulation. In addition to state comparison, the 

vector files specified in the nsvt and vec functions can also be 

used to specify input stimuli to drive the circuit. For more 

information, see “Stimulus Functions and Vector Functions” on 

page 219. 

The logic state of a node is defined by the state level and state 

attributes (see “Logic States” on page 248 for details). By 

default, the simulator calculates only the state levels for all 

nodes. The state attributes are not simulated due to the 

computation overhead associated with these attributes. You need 

to use configuration commands such as vchk_node_opt or 

print_node_opt to instruct the simulator to simulate these 

attributes. 

At the comparison times specified in the vector file, the output 

vectors are compared with the circuit’s state. A node passes the 

state comparison only if both its state level and state attributes 

match the state character specified in the vector file. 

For example, assume that vchk_node_opt z_state=1 is given 

in the configuration file, and a node is at the “1” state. The

Vector File Format 

delay 

Vector File Format 239 

expected state specified in the vector file is “H.” The simulator 

flags a state comparison error for the node since the node is not 

at the expected floating state. 

This section describes vector file format conventions. This file, 

which is also referred to as the stimulus file, is used for stimulus 

and output comparison applications in nsvt, vec, and vec_chk. 

The vector file commands are: delay, fall, high, io, low, 

output_resistance (out), radix, rise, signal, slope, time_scale, 

and type. Their descriptions follow. 

This command is used by nsvt, vec and vec_chk. 

The delay statement causes the applying time for each vector in 

the vec, vec_chk, ornsvt file to have the specified time delay. The 

default units for delay time are nanoseconds and can be scaled 

up or down by the time_scale command. The time delay can be 

positive or negative. For positive delay, the first state of a vector 

will be used for vector initialization. For negative delay, the state 

of the vector at time 0 will be used for vector initialization. 

SYNTAX: 

delay delay_value 

EXAMPLE: 

delay 90.5 

The delay in this example causes a 90.5 ns time delay of the 

applying time for each vector in the nsvt or vec file. 

EXAMPLE: 

delay -25.0 

The delay in this example causes a -25ns time shift against the 

time for each vector in the nsvt or vec file. 



high 

low 

EXAMPLE: 

Consider the following sample values in the vec file: 

Time 0 10 20 30 

A 1 0 1 0 

If delay=10, at time 0, A is assigned with the value 1. 

The realized values for A are 

Time 0 10 20 30 40 

A 1 1 0 1 0 

If delay=-10, at time 0, A is assigned with the value 0. 


Time 0 10 20 

A 0 1 0 

If delay=-5, at time 0, A is assigned with the value of 1. 


Time 0 5 15 25 

A 1 0 1 0 

These commands are used by nsvt and vec. 

The high and low statements can be used to describe the high 

voltage (one) and low voltage (zero) for input and biput nodes. 

The unit for voltage values is Volt.

io 

SYNTAX: 

high high_voltage 

low low_voltage 


EXAMPLE: 

high 3.3 

low 0.0 

The high/low voltages of individual nodes can be overridden by 

configuration commands set_vec_opt and set_node_stv. 

This command is used by nsvt and vec. 

An io statement containing input and output signals can be 

placed after radix to indicate that both input and output signals 

are specified in the data file. The statement begins with io, 

followed by i,b,o, oru. If the io line is not used in vec or nsvt 

files, all signals are treated as inputs. 

The 

Indicates that the corresponding signal is: 

character: 

i input 

b bidirectional input (with L/H/Z stimuli) 

o output 

u unused 

Here is an example of an io statement: 

EXAMPLE: 

io iiiioooobobobouu 

An i indicates that the corresponding signal is an input and the 

stimulus is used to stimulate the circuit. 

NOTE: A warning message is generated whenever an input node is not 

connected to any element or functional model in the vector input 

file. 



As a convenience for identifying bidirectional input and output 

pairs, you can use a b identifier to indicate bidirectional inputs. 

The simulator will also preview your vector files. See 

vchk_node_opt in the TimeMill or PowerMill reference guide to 

decide if any input signal line needs to be simulated as a biput 

signal. This conversion happens when the input signal has an L, 

H, or Z state since these states mean that the signal is not an 

ideal voltage source, so it becomes bidirectional. See “Input 

Stimulus Characters in Vector Files” on page 251. 

A node can be driven by an input/biput signal and at the same 

time checked by output signals in the same vec file. This is done 

by using an io statement to specify which column of the vector is 

for input/biput stimuli and which column of the vector is for 

output comparison. 

An o indicates that the corresponding signal is to be used to 

check the simulation result. That is, the specified output value 

at the specified time is to be compared against the simulated 

result. If they are different, an error message is reported in the 

.err file. 

A u indicates that the corresponding signal column is to be 

ignored by the simulation. 

output_resistance 

This command is used by nsvt and vec. 

A drive resistance can be specified for primary inputs or biputs 

using the output_resistance command or the keyword out. The 

primary inputs/biputs must be in state the L or H state in order 

for the simulator to simulate the drive resistance. 

If 0 or 1 is specified for input/biput signals, the simulator will 

ignore the drive resistance because 0 or 1 means a strong drive. 

If output_resistance is not specified for an input/biput signal 

with an L or H state, it will be treated as floating, which is the 

same as specifying infinite drive resistance because the circuit is 

open. 

The drive strength is defined with a resistance value in ohms, 

and it follows the keyword out. 

This drive resistance can be overridden by the configuration 

command set_vec_opt.

period 

radix 


The following example shows the first two input signals with a 

drive strength of 150 Ohms: 

EXAMPLE: 

radix 1111444411 

slope 1.5 

io iiibooooii 

out 150 

0 LL11ae2201 

50 1001773411 

This command is used by nsvt only. 

A period statement specifies the fixed time interval applied 

between two consecutive vectors in the nsvt file. The time unit is 

nanosecond. 

SYNTAX: 

period time_in_ns 

EXAMPLE: 

period 2.5 

This statement specifies the interval to apply vectors is 2.5 ns. 


The first non-comment line in the file may specify the number of 

bits (the radix) associated with each input signal. The format for 

this line is radix as the first non-white space, followed by a data 

sequence representing the radix for each column. The format is 

shown in the following example: 

EXAMPLE: 

radix 1111 441313412 2231 4444444 

This example indicates four single-bit binary signals followed by 

two hex signals, followed by a binary, then an octal, and so on. If 

no radix is specified, it is automatically assumed that all signals 

are binary signals. 



rise 

fall 

slope 

signal 

These commands are used by nsvt and vec. 

EPIC defines rise/fall as 0%-100% for a rising edge, and 100%-0% 

for a falling edge. You can specify the rise and fall times 

individually with rise and fall statements. All of the time 

parameters are specified in nano-seconds. 

SYNTAX: 

rise rise_value 

fall fall_value 

The rise and fall times can also be specified with a single slope 

statement. 

SYNTAX: 

slope slope_value 

This statement causes the rise and fall times of all the vectors in 

the vec or nsvt file to have the nanosecond value specified in 

slope_value. The default is 0 nanoseconds. This command is not 

used by vec_chk. 

The rise/fall/slope can be overridden by the configuration 

command set_vec_opt. 

NOTE: The absolute time of each vector must increase by at least the 

slope value from the previous waveform. 


The signal specifies the list of input/output signal names. If you 

do not want to use the EPIC netlist to call this vector file, use 

type and signal. See “Running the Vector File Using type and 

signal Commands” on page 247. 

SYNTAX: 

signal node_names...

time_scale 

type 

Time Value 


EXAMPLE: 

signal a1 b[1-0] c[2-0] 

This example shows that the vector file is driving/monitoring six 

signals: a1, b[1], b[2], c[2], c[1], c[0]. 

This command is used by nsvt, vec, and vec_chk. 

The time_scale command specifies a scaling factor for all the 

time values in the vector file including rise/fall/slope. 

SYNTAX: 

time_scale scaling_factor 

EXAMPLE: 

time_scale 0.001 

Scales all the time values by 0.001. 


The type command specifies the vector file type. Valid vector file 

types are vec, vec_chk and nsvt. If you do not want to use the 

EPIC netlist to call the vector file, use type and signal. See 

“Running the Vector File Using type and signal Commands” on 

page 247. 

SYNTAX: 

type vector_file_type 

EXAMPLE: 

type vec 

The time value for each vector is specified in the first non-white 

space on any line. The units are nanoseconds and may be 

integral or decimal, with a resolution down to .01 ns. This time 

entry is accepted only by vec and vec_chk; nsvt does not accept 

time. 



Data Vectors 

Continuing Data 

Valid States 

Comments 

Examples 

For nsvt, the keyword period, followed by a value in 

nanoseconds, defines the vector time intervals. Each new vector 

is applied one period after the previous vector. 

The actual data vectors follow the time specification. There must 

be one data entry for every entry in the radix specifier. The data 

must be separated from the time entry by white space, but the 

data can contain white space. 

Data can be continued from one line to the next by terminating a 

line with a back slash (\). This allows the entry of very long 

groups of input signals. A carriage return indicates the end of a 

single data vector. 

Valid states are described in the section “State Characters Used 

by EPIC Tools” on page 248. 

Comments begin with a semicolon (;), and can appear at any 

point along a line. EPIC tools ignore characters that appear after 

a semicolon (;). 

The following syntax shows an example of an entry in the EPIC 

netlist that calls the vec function. 

EXAMPLE: 

(is=vec)(en=test_vectors)(ot=a1,b[1-0],c[2-0], 

d[3-0],fbus[39-0], cntrl[8-0], rd, wr, ps, cs); 

This example specifies the test_vectors file in which the vectors 

are found. The nodes in the EPIC netlist that are forced are a1, 

a single-bit signal; b[1] and b[0], two bits from the bus labelled


b; three bits from bus c, four bits from bus d, 40 bits from fbus, 

and so on. 

Figure 8 shows typical data in the test_vectors file. 

;this illustrates the features of the vector input format 

radix 1234 4444444444 111111111 4 ;specifies bit count for each column 

slope 3.84 ;specifies the rise and fall time in ns. 

;time will be on the left and signals to the right 

0 0000 fffFff ffff 0101011111;note free format 

10 137f 0000 1111 33 111111111 5 

20 1111 adadaDadad 000000000 9 

30 0123 3333333333 111111111 4 

40 ZZZz uuuuuuuUuu 010101010 6\ 

50 1222 123456890a 000000000 3 

;columns are deliberately misaligned to show generality but 

;would in most cases be aligned for ease of reading 

Figure 8 test_vectors file sample 

Semicolons begin comments. The radix statement has an entry 

for each column specifying the number of bits in each: 1 matches 

the single-bit signal a1; 2 matches the two-bit width of b[1-0]; 

and so forth. 

The slope identifier causes the simulator to attach a 3.84ns rise 

and fall time to all the transitions specified. This rise and fall 

time starts at the transition times specified. For example, at 

10ns, the first bit changes from a zero to a one. The simulator 

starts this transition at 10ns and finishes the transition at 

13.84ns. 

The actual vectors are specified with floating-point times in the 

left fields and the vector values in the right fields. At time 40ns, 

high impedance and unknown states are specified. 

Running the Vector File Using type and signal Commands 

Instead of calling the vector functions by using an EPIC netlist, 

you can include the type and signal commands in the vector file 

and run the vector file with -nvec[tor] on the command line. The 

signal directions ot or it are automatically associated with the 

type of vector function specified. 



The previous example can do away with the EPIC netlist by 

adding type and signal commands to the test_vectors file, as 

shown in the following example: 

EXAMPLE: 

type vec 

signal a1 b[1-0] c[2-0] d[3-0] fbus[39-0] cntrl[8- 

0] rd wr ps cs 

Then you can directly give the vector file to simulation tools: 

EXAMPLE: 

powrmill -n spice_netlist -nvec test_vectors..... 

This method is recommended if you are using non-EPIC netlist 

for simulation, such as SPICE, and you want to use the EPIC 

vector file. Because if you use an EPIC netlist to call the vec 

function, then you will have a mixed netlist format. Unlike 

SPICE, EPIC format is case-sensitive and recognizes VDD as 

power node, so mixing the two netlist formats causes the netlist 

compiler to be case-sensitive, and the special node names defined 

in EPIC format are passed the to SPICE netlist also. So directly 

passing the vector files to simulation avoids the side effects of 

mixing netlist formats. 

State Characters Used by EPIC Tools 

Logic States 

This section provides information about: 

■ logic states 

■ input stimulus characters in vector files 

■ expected output characters in vector files 

Since EPIC simulation tools use detailed device models to 

simulate the transistor-level circuits, the simulators can 

describe the circuit's logic state in a more detailed way than 

many switch-level and gate-level logic simulators.

State Characters Used by EPIC Tools 249 

A node's logic state is defined by two entities: state level and 

state attributes. There are three state levels: ZERO, ONE, and 

UNDEF (undefined). A node's state level is: 

■ ZERO, if its voltage is smaller than or equal to the node's low 

threshold voltage 

■ ONE, if its voltage is larger than or equal to the node’s high 

threshold voltage 

■ UNDEF, if its voltage is between the node’s high and low 

threshold voltages 

The state attributes are the special conditions associated with 

nodes. The attributes include: floating (high impedance state), 

unset condition, don't care (X), and biput driving. 

For example, a state level ONE with the floating attribute is the 

“H” state. A state level ZERO with non-biput-driving is the “N” 

state. 

The physical meanings of the state attributes are: 

■ floating: The node is not driven by any source nodes through 

any conducting paths. It is also referred to as high 

impedance state to reflect the fact that all paths from source 

nodes to the floating node are with high impedance. 

■ unset condition: A node is in the unset condition if it is never 

explicitly initialized by set_node_ic nor set by signals 

propagated from any source nodes. The unset condition 

indicates the node is never meaningfully set, and its voltage 

value may be meaningless. Once it is set by a meaningful 

signal, it will not return to the unset condition. 

For example, a dangling node’s state is in the unset 

condition. Although an EPIC simulator and many SPICE 

simulators assign 0V to a dangling node, the node can have 

any voltage value in a real circuit. 

■ X-state (don’t care, unknown): Represents that the node’s 

state is unknown. It can be ONE, ZERO, ‘Z’, and so on. In 



synthesis terms, X-state means “don’t care”, which can be 

used to simplify the Boolean sum of products. 

The X-state propagation is different from the unset condition 

calculation as follows: 

◆ X-state is a valid input state (from vector stimuli 

configuration command set_node_icx). The unset 

condition cannot be an input state. 

◆ A node can change from X-state to another state, and go 

back to X-state later. A node can never go back to the 

unset state if it has been set. 

■ biput-not-driving: indicates that a biput node is not driven 

by the external source at this moment, and its state is 

determined by the node’s neighboring circuit. 

There is a precedence ordering among the state attributes: 

unset > don't care > floating > biput driving 

This means if a node is floating and unset, it will be reported as 

unset. 

A set of 11 characters are used to represent node logic states. 

There is a corresponding set of integer numbers for the state 

characters to be used in the .out file. 

The following table lists all state characters, with corresponding 

state numbers shown in parentheses. 

State Level logic-0 logic-1 UNDEF 

Attributes State Characters and Numbers 

plain state 

(no attribute) 

‘0’ (0) ‘1’ (1) ‘U’ (2) 

floating ‘L’ (3) ‘H’ (4) ‘Z’ (5)

NOTE: All state characters are case-insensitive. 

Input Stimulus Characters in Vector Files 


State Level logic-0 logic-1 UNDEF 

Attributes State Characters and Numbers 

biput not 

driving 

‘N’ (6) ‘T’ (7) ‘Y’ (8) 

unset ‘?’ (9) ‘?’ (9) ‘?’ (9) 

don’t care ‘X’ (10) ‘X’ (10) ‘X’ (10) 

The following table lists the acceptable state characters to 

specify the input stimuli in the vector file. They are the state 

characters for the single-bit signals. (See “radix” on page 243 for 

details.) For multiple-bit signals, hexadecimal numbers '0', '1', 

'2', ..., '9', 'A', 'B', ..., 'F' can be used. If any non-numerical state 

character is specified for a multiple-bit signal, it means all bits 

of the signal are in the specified state. All input state characters 

are case-insensitive. 

Input State Definition 

‘0’ drive to logic ZERO 

‘1’ drive to logic ONE 

‘U’ drive to logic ZERO (same as '0') 

‘L’ + floating to logic ZERO; or 

+ resistive drive to logic ZERO 

‘H’ + floating to logic ONE; or 

+ resistive drive to logic ONE 

‘Z’ floating (not driving) 

‘X’ + drive to X (don’t care) state if X-state 

propagation is requested; or 

+ drive to logic ZERO (same as ‘0’) 



When a floating state ('L', 'H', 'Z') is specified for the input signal 

and no drive resistance is specified (which is the same as 

specifying infinite drive resistance), the node state is determined 

by circuit elements connected to the node. If a drive resistance is 

specified for the signal by either the keyword out in the vector 

file or the configuration command set_vec_opt r=, ‘L’ and ‘H’ 

will work as described on in the section “output_resistance” on 

page 242. 

If the node is not channel-connected to any other elements, 'L' 

will change the node's state to 'L' (floating with logic level 

ZERO); 'H' will change the node's state to 'H' (floating with logic 

level ONE); 'Z' will make the node floating and it state level 

unchanged. 

If 'X' is specified for the signal, it drives the node to X state when 

X-state propagation is turned on by configuration commands. 

Otherwise, 'X' is the same as input stimulus '0'. 

Expected Output Characters in Vector Files 

Since a node's logic state is defined by two entities (state level 

and state attributes), the output vectors check state levels as 

well as state attributes. 

For example, if vchk_node_opt z_state=1 is used, the 

expected state 'H' will check if a node is floating and at state 

level ONE. If the node is not floating or not at state level ONE, a 

comparison error will be flagged. The expected state '1' will 

check if a node is NOT floating and at state level ONE. 

If vchk_node_opt z_state=1 is not used, both 'H' and '1' will 

only check if a node is at state level ONE. The node's floating 

attribute will not be checked. 

The following tables list all the acceptable state characters for 

expected outputs in the vector file for TimeMill and PowerMill. 

They are the state characters for the single-bit signals. For the 

multiple-bit signals, hexadecimal numbers '0', '1', '2', ..., '9', 'A', 

'B', ..., 'F' can be used. If any non-numerical state character is


specified for a multiple-bit signal, it means all bits of the signal 

are in the specified state. All output state characters are caseinsensitive. 

For more information, see “radix” on page 243. 

TimeMill 

Expected State Definition 

‘-’ don’t check 

‘0’ logic ZERO 

‘1’ logic ONE 

‘U’ logic ZERO if vchk_node_opt u_state=2 

or 

logic UNDEF if vchk_node_opt 

u_state=1 

or 

don’t check if vchk_node_opt u_state=0 

‘L’ logic ZERO 

and 

floating if z_state is checked 

‘H’ logic ONE 

and 


‘Z’ the same as expected state ‘U’ 

and 


‘N’ logic ZERO 

and 

biput node driven by circuit if 

biput_drive is checked 

‘T’ logic ONE 

and 





TimeMill 


‘Y’ the same as expected state ‘U’ 

and 



‘X’ the same as ‘-’ 

or 

X state if x_state is checked 

‘?’ the same as ‘-’ 

or 

unset_state if unset_state is checked 

PowerMill 


‘-’ don’t check 

‘0’ logic ZERO 

‘1’ logic ONE 

‘U’ logic ZERO if vchk_node_opt u_state=2 

or 

logic UNDEF if vchk_node_opt 

u_state=1 

or 

don’t check if vchk_node_opt u_state=0 

‘L’ logic ZERO 

and 


‘H’ logic ONE 

and 


‘Z’ the same as expected state ‘U’ 

and 

floating if z_state is checked


PowerMill 


‘N’ the same as expected state ‘0’ 

‘T’ the same as expected state ‘1’ 

‘Y’ the same as expected state ‘U’ 

‘X’ the same as ‘-’ 

‘?’ the same as ‘-’ 


256 Chapter 5 Stimuli and State Checking

Chapter 6 

batchrun Program

258 Chapter 6 batchrun Program

Overview 

Overview 259 

The batchrun script runs TimeMill, PathMill, PowerMill, or 

AMPS in batch mode with various parameters. 

SYNTAX: 

batchrun product_name batch_file 

DESCRIPTION: 

The batchrun command runs a script you have written. 


product_name timemill, pathmill, powrmill, or 

amps. 

batch_file Specifies the name of the batch 

script you wrote. 

Distributed Computing Capability 

The batchrun program can distribute jobs to multiple 

computers. Multiple jobs can be executed concurrently. The 

information required is in a host file that specifies the host 

names of available computers. 

To perform distributed computing, all filenames in the batchfile 

must be in the network-full-path format or in relative paths to 

the working directory. A network full path means a pathname 

which is accessible to multiple computers through computer 

networks, with all computers referring to the same file or 

directory by giving a network full path name. The working 

directory is the directory specified by the environment variable 

EPIC_BATCHRUN_DIR, or the directory where the batchrun 

script is executed if EPIC_BATCHRUN_DIR is not set. 

It is important to designate different outputs using the -o option 

for different job runs. Since multiple jobs are run simultaneously 


260 Chapter 6 batchrun Program 

on multiple computers, their outputs might overwrite each other 

if they use the same output file. 

The batchrun.hosts file specifies the host names of the computers 

to execute different jobs. Its format is one host name per line. 

EXAMPLE: 

maui 

oahu 

lanai 

maui 

In this example, maui, oahu, and lanai are host names of 

available computers, and maui is a multiprocessor computer 

capable of running two jobs at the same time. Once a computer 

completes a job, batchrun assigns a new one to it. 

It searches for the host file in the following order: 

1 Checks for the environment variable 

EPIC_BATCHRUN_HOSTS, which sets a path to the host 

file. 

2 Uses the batchrun.hosts host file in the working directory. 

3 If steps 1 and 2 fail, uses only the local host to run jobs. 

The batchrun program generates a temporary Bourne shell 

script in the working directory for the program command 

execution. This temporary script will be deleted after batchrun 

is completed. Therefore, you must have write permission to the 

working directory. 

The batchrun program uses remote shell rsh to invoke remote 

processes for running a job on a remote computer. The pathname 

of the working directory must be visible to all computers 

specified in the host file. If EPIC_BATCHRUN_DIR is not set, 

the program uses a Bourne shell environment variable, PWD, to 

set the working directory, that is, the directory where the 

batchrun command is executed. Depending on the network file 

system setup, PWD might not be a network full path. You should

Batchfile Format 

FILE 

Batchfile Format 261 

set EPIC_BATCHRUN_DIR before starting the batchrun 

program. EPIC_BATCHRUN_DIR must be a network full path. 

If you encounter permission problems while doing rsh, see your 

system administrator. Also, see the UNIX manual page on rsh 

for details. 

The batchfile has three statements: FILE, RUN, and DATA. 

Each statement keyword must start at the beginning of a line. 

You can set off comments in the batchfile by beginning the 

comment line with a pound sign (#). You can include comments in 

FILE and DATA statements. 

SYNTAX: 

FILE filename 

 

 

 

... 

END 

EXAMPLE: 

FILE temp.config 

add_node_cap N1 $CLOAD1 


END 

EXAMPLE: 

This example creates a file called temp.config and includes as 

its contents add_node_cap N1 and add_node_cap N2.The 

parameters are preceded by dollar sign ($). The parameter 

values are specified in the DATA statement. 



RUN 

DATA 

DESCRIPTION: 

The FILE statement specifies the file to be created and the 

contents in the file. You can specify the FILE statement more 

than once in the batchfile. 

SYNTAX: 

RUN arguments 

EXAMPLE: 

RUN -n NET -p $TECH 

This syntax runs the EPIC tool on the NET netlist and uses the 

technology files specified by the TECH parameter in the DATA 

statement. 

DESCRIPTION: 

The RUN statement specifies the command-line options for 

TimeMill, PathMill, PowerMill or AMPS. You can specify the 

RUN statement only once in the batchfile. 

Arguments for the RUN statement can be parameters specified 

in the DATA statement by preceding the parameter name with a 

dollar sign ($). 

SYNTAX: 

DATA param1 param2 param3 ... 

 

 

 

 

... 

END

Batchfile Format 263 

EXAMPLE: 

DATA CLOAD1 TECH OUTFILE 

10 best_5v.tech best_5v_c10 



10 worst_4.5v.tech worst_4.5v_c10 


100 

END 

worst_4.5v.tech worst_4.5v_c100 

DESCRIPTION: 

The DATA statement specifies the value of the parameters for 

each run. The list of parameter names follows DATA in the 

command line. Each set of parameter values is specified on a 

separate line. Each value is separated by a space. Each set is 

used to run the simulator once. Parameters are referred to in the 

FILE and RUN statements (similar to specifying shell variables 

in a UNIX shell using $name). The DATA statement can be 

specified only once in the batchfile and must be the last 

statement in the file. All lines that appear after END in the 

DATA statement are ignored. 



Batchfile Example 

Figure 1 shows a sample batchfile for running TimeMill with 

different loading capacitances and technology files. 

batchrun timemill batchfile 

batchfile: 

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

# to specify capacitances for nodes N1 and N2 

FILE temp.config 



END 

RUN -n net -p $TECH -c config1 temp.config -t 100 -o $OUTFILE 

DATA CLOAD1 TECH OUTFILE 







END 

Figure 1 Sample batchfile for running TimeMill 

Six simulations will be run for this TimeMill batchrun. The 

output file best_5v_c10 will contain the result of a simulation 

performed using best_5v.tech as the technology file, including a 

load of 10fF on nodes N1 and N2. 

The other runs use: 

Load on N1 & N2 Technology File Output 

20fF best_5v.tech best_5v_c20.out 

100fF best_5v.tech best_5v_c100.out 

10fF worst_4.5v.tech worst_4.5v_c10.out 

20fF worst_4.5v.tech worst_4.5v_c20.out 

100fF worst_4.5v.tech worst_4.5v_c100.out

Chapter 7 

Utilities for Dynamic EPIC 

Tools

266 Chapter 7 Utilities for Dynamic EPIC Tools

Overview 

Meas Utility 

Overview 267 

This chapter describes the various utilities you can use to specify 

the type of information you want to obtain from simulation 

results. These utilities are: 

■ Meas: Computes the results of .measure statements in 

SPICE or HSCPICE netlists 

■ Edisplay: Controls the formation of simulation results 

■ Eview: Views simulation results via a graphical interface 

The SimWave and turboWave utilities enable you to view 

analog and digital waveforms. 

This chapter also presents two utilities that enable vector file 

translation: vcd2e and VTRAN. 

These utilities are described in the following sections. 

This is a post-processing utility for computing the results of 

.meas (or .measure) statements in SPICE or HSPICE netlists. 

This utility allows you to find the .meas results without running 

an entire simulation. This is useful, for example, if you want to 

modify the .meas statements in the netlist and compute the new 

results without having to rerun the entire simulation. 

To run the meas utility, you need to have an EPIC or FSDB 

output file and a SPICE netlist containing .meas statements. 

When the meas utility is run, it first parses the .out or the .fsdb 

file to get the signal waveforms and then generates results for 

the .meas statements specified in the given netlist. All signals in 

the netlist must have corresponding waveforms in the output file 

or the utility will fail. 


268 Chapter 7 Utilities for Dynamic EPIC Tools 



meas [-p] 

[-n netlist_file] 

[-s EPIC_out_file] 

[-o meas_out_file] 

The meas command-line options are: 

-p Forces meas to parse only the .meas statements in the netlist. 

Setting this option reduces CPU time and memory 

consumption. If this option is not set, meas will parse the 

entire netlist. 

CAUTION: Under the following two conditions, using this option could cause 

Meas to fail to generate results: 1) the .meas statements contain 

nodes aliased to some other nodes, or 2) the .meas statements 

contain signals like i(X), where X denotes an element. 

-n Specifies a SPICE or HSPICE netlist file containing .meas 

statements. 

-s Specifies the EPIC (or FSDB) output file to be used as input 

to the Meas utility, for example, powrmill.out. 

-o Specifies the name of the output file generated by the Meas 

utility. The default filename is meas.meas.

Edisplay Utility 


Edisplay Utility 269 

Edisplay is a program that controls formatting of simulation 

results. It shows the simulation output as a table of logic states 

and floating point values. The translation between the logic state 

value stored in the output file and the Edisplay output is shown 

in the following table. The EPIC output file numbers are defined 

in the section describing the double integer line on page 317. 

EPIC Output File Edisplay Output 

0 0 

1 1 

2 U 

3 L 

4 H 

5 Z 

6 N 

7 T 

8 Y 

9 ? 

10 X 

edisplay [-i in_file_name] 

[-b begin_time] 

[-e end_time] 

[-f control_file] 

[-h] 

[-m error_file] 

[-I] 

[-o out_filename] 

[-p caption_step] 

[-r] 




[-s interval_step] 

[-t] 

[-d delay_measure_file] 

[-g time_tolerance] 

[-w sp_pwl_inode] 

[-v sp_pwl_file] 

[-l] 

This section defines the command-line options for the edisplay 

command. 

-i in_file_name 

Specifies the input file to Edisplay, such as powrmill.out or 

timemill.out. If the -i option is not specified, Edisplay looks 

first for timemill.out, then powrmill.out. 

-b begin_time 

Specifies the beginning time step to be printed. The default 

is 0.0 ns. 

-e end_time 

Specifies the ending time step to be printed. The last time 

printed is the most recent event at or before the specified 

time. The default is the ending time of the simulation. 

-f control_file 

Specifies the name of the control file you wish to use. This 

file lets you specify which signals to display and their 

formats (that is, binary, hex, and so on). See the “Edisplay 

Control File” on page 275. 

-h Command-line help. 

-m error_file 

Merges the comparison errors into the output. An asterisk 

(*) is used to mark the lines that have errors. If a 

comparison error appeared in the timemill.err file, then 

edisplay -m timemill.err produces the result shown in 

the following example:

EXAMPLE: 


T ...... 

I n.nnnO 

M nInnnU 

E 1N234T 

0.00 011010 

4.00 *U----- 

5.00 *-----1 

10.00 100101 

20.00 100101 

23.00 *-----0 

30.00 100101 

35.00 *--U--- 

40.00 10010 

If specified with the -s option, error lines are printed even 

if the error does not occur at the time interval specified by 

the -s option. 

EXAMPLE: 

output_filter edisplay -I 

-I Instructs Edisplay to read the input from the standard 

input device. This is useful when running TimeMill or 

PowerMill in the interactive mode. The configuration file 

command shown in the preceding example gives a text 

display of the simulation results while the simulation 

continues to run. 

-o out_filename 

This option specifies the name of the output file containing 

the simulation result of Edisplay processing. If this option 

is not used, the output goes to the standard output. 

EXAMPLE: 

......O 

......U 

T ..d...T 

I ppa...P 

M hht...U 

E 12aABCT 



0.00 000UUUU 

10.00 100UUUU 

10.25 1001UUU 

20.00 1011UUU 

20.82 1010UUU 

30.00 0010UUU 

35.00 0110UUU 

35.01 01100UU 

35.02 011001U 

35.03 0110010 

40.00 0100010 

55.00 0000010 

60.00 1000010 

61.47 1001010 

80.00 0001010 

85.00 0101010 

85.01 0101110 

85.49 0101100 

86.08 0101101 

-p caption_step 

Inserts the signal caption section at specified intervals in 

the simulation results. This is the number of lines to be 

printed between signal captions. It is useful for splitting 

the output file into printable pages. The default displays 

the caption only once. 

EXAMPLE: 

SCEDDDDLLLLC 

EKN01231111L 

R..........K 

I......BCAN. 

A........._. 

T L.........1. 

I _........... 

M I........... 

E N........... 

0.00 1U1UUUUUUUUU 


SCEDDDDLLLLC 

EKN01231111L 

R..........K

I......BCAN. 

A........._. 

T L.........1. 

I _........... 

M I........... 

E N........... 


0.19 1U1UUUUUUUU0 

0.29 1U11UUUUUUU0 

0.43 1U11UUU0U0U0 

0.43 1U11UUU0U0U0 

0.54 1U111UU010UU 


-r Changes the bottom-justified signal caption header to topjustified. 

The following table shows you the effect of using 

the -r option. 

With the -r Option Without the -r Option 

T ...... T InnnnO 

I .nnnnO I NnnnnU 

M InnnnU M .1234T 

E N1234T E ...... 

-s interval_step 

Specifies the selected strobe time for output. For example, 

if the clock signal is invoked every 20 ns, interval_step can 

be set at 20 to print the result at each toggle of the clock. 

The interval step is offset by the beginning time; for 

example, the time specified by the -b option. The default 

beginning time is 0. If this option is not specified, an output 

display appears whenever any output signal changes. 

-t Prints the values of a signal only when it toggles or 

changes state. When a signal does not toggle, its state is 



represented by a period (.). The default displays all signal 

states at each interval. 

-d delay_measure_file 

The name of the file that stores the result of the measure 

statement included in the control file specified by the -f 

option. 

-g time_tolerance 

Tolerance used for error merging of the -m option. Edisplay 

ignores errors within the tolerance of the time specified in 

nanoseconds. The time_tolerance argument is specified as 

a floating point. 

-w sp_pwl_node 

This option generates a SPICE PWL input command line 

for the specified analog node in the file given in the -v 

option. Only one node can be specified. When specifying the 

node, the signal type (v, i, I, or di/dt) must be given, and 

must be surrounded by single or double quotes. 

EXAMPLE: 

edisplay -w 'i(n2)' -v spice.file 

-v sp_pwl_file 

This specifies the name of the output file containing the 

PWL command line specified by the -w option. 

-l Instructs Edisplay to display only digital logic values, and 

to ignore all analog voltage or current values. 

DESCRIPTION: 

This command provides options to control the formatting of 

simulation results. Node names are written vertically in a 

caption at the top of each display table. 

CAUTION: Edisplay does not do interpolation. If Edisplay outputs lines 

between points of an analog signal, the value of the first point 

will be repeated.

Edisplay Control File 


The Edisplay control file can be used to further control output 

printing. When a control file is specified with the -f option on the 

edisplay command line, only nodes defined by the print 

commands in the control file are output. If the first line of the 

control file contains the !append statement, all nodes defined by 

the control file are displayed, followed by those in the TimeMill 

or PowerMill output file. 

The following types of statements are supported: 

■ Logic signals to be printed: 

print_node n1 n2... 

■ Analog signals to be printed: 

print_node_current i(a1) i(a2)... 

print_node_average I(a1) I(a2)... 

print_node_voltage v(b1) v(b2)... 

■ Math signals to be printed: 

print_node_math m(a1) M(a1) dm/dt(a2) M_rms(a2) 

■ Spaces to be inserted between signals: 

spa #_of_spaces 

If #_of_spaces is not specified, the default is 1. 

■ Group signals to be printed: 

hex/oct/big/bio group_name n1 n2 n3... 

■ Specifying the statement !append in the first line of the 

control file causes the signals in the TimeMill or PowerMill 

output to be displayed after any other signals specified in the 

control file. Otherwise, only signals defined in the control file 

are displayed. 

!append 

print_node n1^ n1 n2 n3 

spa 1 

print_node_current i(a1) 

print_node_voltage v(b1) 



Eview Utility 

spa 3 

print_node n0 

print_node n1 

print_node n2 

bio bn3 n3 

hex bn n7 n6 n5 n4 n3 n2 n1 n0 

oct bn1 n3 n3 n1 n0 

big bn2 n2 n1 n0 

■ Measure the maximum rise/fall time delays between two 

nodes. 

measure n1 n2 

The example prints the maximum R to F, R to R, F to F, F to 

R delays between n1 and n2. The results are stored in the file 

specified by -d. If -d is not specified, they are printed to the 

standard output. 

■ High impedance bus may be printed in either hexadecimal or 

Z value. 

show_hiz_hex 

If show_hiz_hex is included in the control file, it will turn 

on the hex representation, and the bus value HLHL will be 

shown as A (hex). Otherwise, HLHL will be shown as Z. 

Mixed-state buses such as 10HL will be shown as A. 

■ User-defined state symbols are allowed. 

define_value 7 Y 

This example would force Edisplay to show the state value 7 

for Y in the EPIC output file instead of the default symbol T. 

Eview is a post-processing utility for viewing simulation results. 

It offers some major Edisplay features, and several additional 

capabilities: 

■ Graphical interface for browsing tabular results



■ Hierarchical analog and digital signal selector 

Eview Utility 277 

■ Search-and-highlight signals (analog and digital), and/or 

errors 

eview [-eo EPIC_out_file] 

[-ee EPIC_err_file] 

[-cf control_file] 

The eview command-line options are: 

-eo Specifies the EPIC simulation output file to Eview, such as 

powrmill.out, timemill.out. If not specified, Eview looks 

first for the timemill.out file, then powrmill.out file. Analog 

signals will only be displayed when a value is reported in 

the .out file. 

-ee Specifies the EPIC comparison error file to Eview, such as 

the powrmill.err or timemill.err file. If not specified, Eview 

looks first for timemill.err, then powrmill.err. 

-cf Specifies the control file you want to use. This file allows 

you to specify which signals will be displayed and their 

formats, such as hex or oct. See the section “Eview Control 




Window Layout 

Menu bar 

Message 

area 

Signal names 

Simulation 

time 

Logic values 

Figure 1 Eview window 

The Eview window is divided into three areas: menu bar, text 

display, and message area. 

Menu Bar 

The menu bar contains five pull-down menus: File, Edit, 

Search, Options, and Help.

Figure 2 shows the Eview File menu. 

Figure 2 Eview File menu 

The File menu options are: 


■ Load EPIC .out File: Select an EPIC simulation output file 

and load it into the Eview environment. 

■ Load EPIC .err File: Select an EPIC comparison error file 

and load it into the Eview environment. 

■ Load Control File: Select a predefined control file and load 

it into the Eview environment. 

■ Save Result: Save the current Eview result in the text 

display window to a user-specified file. 



■ Exit: Exit Eview. 

Figure 3 shows the Edit menu options. 

Figure 3 Eview Edit menu 

The Edit menu options are: 

■ Edit Nodes: Pops up a node selector to allow you to pick up 

the digital and analog signals from the selected EPIC 

simulation output file. 

■ Error Tolerance: Ignores the comparison errors in the 

specified tolerance time frame. The tolerance is specified in 

nanoseconds. Ignoring takes effect only if the EPIC .err file 

has comparison errors.


■ Show Result: Shows the tabular result of an EPIC .out file 

with comparison errors, if any. After you load the EPIC .out 

file into the Eview environment, select this menu to see the 

tabular result. Otherwise, the text display window will 

remain empty. 

Figure 4 shows the Search menu. 

Figure 4 Eview Search menu 



The Search menu options are: 

■ Search Node: Search and highlight the user-specified signal 

in the text display area. 

■ Search Time: Search and highlight the user-specified time 

frame (in nanoseconds) in the text display area. 

■ Search Value: Search and highlight all nodes with the value 

you specify in the pop-up window. 

■ Search Next Error Time: Search and highlight the next 

comparison error time stamp in the text display area. 

Searching and highlighting will take effect only if the EPIC 

.err file has been loaded. 

■ Search Next Error Value: Search and highlight the next 

comparison error value in the text display area. Searching 

and highlighting will take effect only if the EPIC .err file has 

been loaded.

Figure 5 shows the Options menu. 

Figure 5 Eview Options menu 


The Options menu’s single menu item is Strobe Time. This 

accesses a window in which you specify the strobe time for 

output. The default beginning time is 0. If you do not specify 

strobe time, an output display appears whenever any output 

signal changes. 



Text Display Area 

The text display area is composed of a node name area and a 

time/value area. The node name area shows selected signal 

names displayed vertically. Analog signals are displayed only 

when a value is reported in the .out file. 

The time/value area shows the values and time stamps of 

selected signals. If no value is reported for a specific time on an 

analog signal, and other signals are reported, Eview will print a 

dotted line for the specified signal. The values displayed for 

analog signals will be in E format and in units of volts or 

amperes. 

Message Area 

There are three fields in the message area: outFile, errFile, 

and ctlfile. They display the current files being used by Eview. 

Eview Control File 

■ outFile: Indicates the selected EPIC simulation output file. 

■ errFile: Indicates the selected EPIC comparison error file. 

■ ctlFile: Indicates the selected control file. 

The Eview control file can be used if you already know which 

signals are included. Only nodes defined by the print commands 

in the control file are shown in the text display area. 

The following types of statements are supported: 

■ For printing logic signals: 

print_node n1 

print_node n2 

■ For printing a group of signals: 

hex/oct group_name n1 n2 n3... 

■ Math signals to be printed: 

print_node_math m(a1) M(a1) dm/dt(a2) M_rms(a2)

■ For inserting spaces between signals: 

spa 

■ For analog signals: 

print_node_current i(s[2]) 

print_node_average l(s[3]) 

Waveform Display Utilities 285 

EXAMPLE: 

print_node_voltage v(s[4]) 

print_node A[2] 

print_node B[2] 

print_node COUT 

spa 

print_node S[3] 

spa 

print_node CIN 

spa 

hex AB_GROUP A[0] B[0] A[1] B[1] A[2] B[2] 





oct AB_GROUP A[0] B[0] A[1] B[1] A[2] B[2] 

Waveform Display Utilities 

While the simulation output is generating, the output data can 

be piped to the waveform display utility using the 

set_print_filter configuration command. EPIC offers two standalone 

waveform display utilities: SimWave and turboWave. 

These third-party utilities have been integrated with PowerMill 

and TimeMill for viewing analog and digital waveforms. Both 

utilities can be used as stand-alone tools to view PowerMill or 

TimeMill .out files, or simulation results as you are working. 

An additional license is required for each utility. 



SimWave 

turboWave 

This section briefly describe the use of SimWave. See the 

SimWave User Manual or access Help in SimWave for more 

information. 

To use SimWave as a stand-alone utility, type: 

wd foo.out @ 

You can use a signal browser to select signal names. The basic 

procedure is to select names from the browser, then drag-anddrop 

them into the waveform window. 

To use SimWave for viewing simulation results while you are 

running the simulation, add the following line to your simulation 

configuration file: 

set_print_filter wd 

If you want to generate an output file in isdb format, use the 

following configuration command: 

set_print_format for=isdb 

This section briefly describes how to use turboWave. See the 

turboWave User Manual or access Help in turboWave for more 

information. 

To use turboWave as a stand-alone utility: 

1 Type: % turbowave & 

2 Click on File, then choose Open from the slider menu to load 

simulation result file(s). 

3 Click Add, then Apply or OK in the signal browser to 

display waveforms. 

4 Use the browser to add and apply signals.

Vector Translation Utilities 287 

5 To display waveforms while running a simulation, add the 

following line to your EPIC configuration file: 

set_print_filter turboWave -i 

If you want to generate an output file in fsdb format, use the 

following configuration command: 

set_print_format for=fsdb 

Vector Translation Utilities 

Vcd2e Utility 

The two vector translation utilities available in EPIC tools are 

vcd2e and VTRAN. The EPIC vcd2e utility reads a file in 

Verilog's Value Change Dump (VCD) format and produces a new 

file in EPIC vector format. The vcd2e utility is described in 

detail in the following sections. 

VTRAN is an OEM program. It loads the state/time information 

of logic stimulus, results, or other data sources contained in a 

file. It then processes this data, and formats it for a selected 

target simulator into a second file, called the Target Vector File 

(TVF). For information on VTRAN, see the VTRAN User Manual. 

Each of these utilities requires an additional license. 

The vcd2e utility can be executed in batch mode or interactively 

using a graphical user interface. In either case, you must 

generate a signal file that lists the signals to be converted as 

well as their directions. 

Even in batch mode, you can group or split buses and specify 

control information for bedirectional signals. The advantage of 

using the GUI is the ability it gives you to browse the VCD file 

hierarchy. 




vcd2e 


[-b] 

[-v Verilog_VCD_file] 

[-s filename] 

[-o prefix] 

[-t] 

[-r] 

[-h] 

[-x] 

The command-line options for the vcd2e command are: 

-b Invokes batch mode. If you run vcd2e in batch mode, the - 

v, -s, and -o options are required. 

NOTE: If you specify vcd2e without the -b option, the EPIC 

interface appears. 

-h Invokes help information. 

-v Verilog_VCD_file 

Specifies a Verilog VCD file. 

-r Restores the state time segment, in nanoseconds, to split a 

large VCD file. 

-s filename 

Specifies a vcd2e signal definition file. This file contains a 

list of the signals in the VCD file to be translated to EPIC 

format. 

-t Saves the state time segment, in nanoseconds, to split a 

large VCD file. 

-o 

prefix 

Specifies an output file prefix.


-x New bus notation, or bus expansion character. This option 

allows you to change the bus notation from the original 

Verilog VCD file or to expand the bus. 

For example, if the Verilog VCD file refers to a bus A[0:3], 

and you add -x “”, the resulting EPIC vector file will 

refer to the bus as A. 

The same option can be used to split a bus into single bits. 

If the argument does not specify parentheses-characterclose-parentheses, 

it is assumed to be a bus-splitting 

character. 

For example, if the Verilog VCD file refers to a bus A[0:3]; 

and you specify the -x _ option, the resulting EPIC vector 

file will refer to the bus as A_0_, A_1_, A_2_,A_3_. 

Vcd2e Window Layout 

The vcd2e window layout is divided into six areas: menu bar, 

current scope, design instance browser, signal in current scope, 



Menu bar 

Current scope 

Signal in current 

scope 

Design instance 

browser 

command buttons, and selected signals list. Figure 6 shows an 

example of the vcd2e window. 

Figure 6 vcd2e window 

Command 

buttons 

Selected 

signal list


Menu Bar 

The File menu is the only menu on the menu bar. Figure 2 shows 

the options on the File pulldown menu. 

Figure 7 File menu options 

The File menu options are: 

■ Load VCD file: Select a Verilog VCD file and load it into the 

vcd2e environment. 

■ Load Signal file: Select a signal definition file and load it 

into the vcd2e environment. You must follow the Signal file 

format syntax. (See “Signal Save File Format” on page 294.) 

■ Save Signal file: Save the current selected signals and their 

parameters to a file. You can load this file into the vcd2e 

environment in the next run by selecting the Load Signal 

file option from the File menu. 

■ Quit: Quit the vcd2e environment. 

NOTE: The VCD file must be loaded first, followed by the signal file. You 

can only do this once per session. 

Current Scope Message Area 

This area displays the hierarchical path of the selected instance. 



Design Instance Browser 

This area displays the instances in the current selected scope. 

You can browse the hierarchical design by double-clicking the 

instance in this area with the left mouse button. 

Signals in Current Scope 

This area shows the signals in the current selected scope. You 

are allowed to select signals from this area to build the EPIC 

vector. 

Command Buttons 

The following command buttons appear on the vcd2e window: 

■ Add: Adds the selected signals from the Signals in 

Current Scope list to the Selected Signals List. 

■ Add All: Adds all signals from the Signals in Current 

Scope list to the Selected Signal List. 

■ Delete: Deletes the selected signals from the Selected 

Signals List area. 

■ Delete All: Deletes all signals from the Selected Signals 

List area. 

■ Create Bus: Creates a bus for the signal selected in the 

Selected Signal List area. 

The vcd2e utility bus output is no longer exclusively written 

in single bits in the .vec/.vec_chk.cmd/.cmd_chk vector files. 

The type of bus output of the vcd2e utility depends on the 

following factors: 

◆ If you define your bus in single bits in the signal file, the 

output files list the bits individually, and they are 

assigned binary values 

◆ If you define your bus as a bus, which must be a multiple 

of four, the output files define the bus as a “single signal,” 

and the values are written out in hexadecimal


NOTE: If some of the bits of the buses are X or Z, the 

following rules apply: 

◆ If one of the bits is X, the hex value is X 

◆ If one of the bits is Z (and none of the other bits is X), the 

nex value is Z 

■ Direction: Specifies the signal directions: input, output, or 

biput. By default, all the selected signals are assumed to be 

inputs. The signal directionality is not contained in the VCD 

file, and must be assigned by you. 

■ Time Segment: Breaks the vectors into multiple files. Click 

this button to select one of the following options: Save State 

Time and Restore State Time. 

■ Upper Case: Changes the signals in the VCD file to 

uppercase. 

■ Lower Case: Changes the signals in the VCD file to 

lowercase. 

■ No Change: Specifies that the case of the signals in the VCD 

file is to remain unchanged. 

■ Expand Bus: Expands the bus for the signal selected in the 

Selected Signal List area. 

■ Build Stimulus: Builds the EPIC vector file with the 

information in the Selected Signals List. Figure 8 shows 

an example of the Bidirectional Signal Specification window. 



For further information about control signal expression, see 

the “Signal Save File Format” on page 294. 

Figure 8 Bidirectional Signal Specification window 

Selected Signal List 

This window displays the signals used to generate the EPIC 

vectors. 

Signal Save File Format 

Use the vcd2e signal file if you already know which signals are 

included, as well as their attributes. The syntax for the signal 

file is: 

signal_name signal_direction input_default output_default 

control_expression

These variables are: 


signal_name Signals in the VCD file. 

signal_direction Either I (input), O (output), or B 

(biput). 

input_default If signal_direction is B, when it is 

an output, an input_default is 

needed to find the input version 

value with the control information 

defined in control_expression. 

Values can be X, U, or Z. 

output_default If signal_direction is B, when it is 

an output, an output_default is 

needed to find the output version 

value with the control information 

in control_expression. Values can 

be X, U, or Z. 

control_expression If signal_direction is B, a 

control_expression is needed to 

separate input from output state on 

biput signals. And if a bidirectional 

control signal is not at the same 

level of hierarchy as the 

bidirectional signal, you must enter 

the full path to the control signal. 

EXAMPLE 1: 

in@(ctrl=1) 

This is an example of a control expression. It shows that 

signal_name contains input data because ctrl is logic 1. 

Otherwise, it contains output data. 

NOTE: You cannot have spaces in the expression, and you must enclose 

expressions within parentheses. 

EXAMPLE 2: 

r_wbI 

ram_enbI 

data[3:0]B Z X in@(r_wb) 



adr[2]I 

adr[1]I 

adr[0]I 

SEE ALSO: 

Batch Mode 

Translating a File 

The basic steps for translating a VCD file into EPIC vector 

format are: 

1 Select Load VCD file from the File menu and choose the 

name of the VCD file you want to translate. 

2 Select the signals required for the simulation. You can do 

this in either of two ways: 

◆ Select Load Signal file from the File menu, then select 

the required signals from the Signals in Current 

Scope list. Click the Add command button after 

selecting each signal, or click Add All or Delete. The 

names of the signals you selected will appear in the 

Selected Signals list. 

◆ Select Save Signal file from the File menu, and create 

a signal file containing all the selected signals and their 

attributes. This method works best if you are simulating 

a large design because you do not have to manually select 

a long series of signals from the Signals in Current 

Scope list. 

3 Make any necessary changes to the signals in the Selected 

Signal List. You can make these changes as follows: 

◆ Change signal directionality (Input/Output/ 

Bidirectional) by selecting the signal, clicking the 

Direction command button, and selecting the 

appropriate direction.


◆ Change the signal case by clicking the Case command 

button. The EPIC tools are case-sensitive, so it may be 

necessary to modify the case of the signals in the VCD file 

so that they match those in the netlist. 

◆ Create and split buses by clicking the Create Bus 

command button. This will make the buses compatible 

with the netlist you intend to use for the simulation. 

4 Click the Build Stimulus command button to generate the 

EPIC vector file. You need to specify the file prefix. If the 

VCD file contains bidirectional signals, you are prompted for 

the control logic expressions to determine when the signal is 

an input and when it is an output. 

The following EPIC vector files are generated: 

xxx.vec 

EPIC vector file that contains vectors for all inputs and 

bidirectional signals when they are inputs. 

xxx.cmd 

EPIC netlist file used to instantiate the xxx.vec file. 

xxx.vec_chk 

EPIC vector file that contains all the output signals, as 

well as bidirectionals when they are outputs. 

xxx.cmd_chk 

EPIC netlist file used to instantiate the xxx.vec_chk file. 

The vcd2e utility bus output is no longer exclusively written in 

single bits in the .vec/.vec_chk.cmd/.cmd_chk. 

The type of bus output of the vcd2e utility depends on the 

following factors: 

■ If you define your bus in single bits in the signal file, the 

output files list the bits individually, and they are assigned 

binary values. 



■ If you define your bus as a bus, which must be a multiple of 

four, the output files define the bus as a “single signal,” and 

the values are written out in hexadecimal. 

Batch Mode 

You can run vcd2e in batch mode. The syntax for running in 

batch mode is: 

vcd2e -b -v vcd_file -s signal_file -o epic_output_file_prefix 

In vcd2e batch mode, you can also specify strobes in the signal 

file. Specify the strobe cycle time, and two strobe points within 

that cycle time for any desired output and/or bidirectional pin. 

Strobing works only when running in batch mode. Even if you 

load a signal file that contains strobes graphically, they are 

ignored. There is no way to specify strobes from the EPIC user 

interface. Strobing only works if the signals you specify are 

output or bidirectional. If you specify strobes on input signals, 

those strobes will be ignored. 

SYNTAX: 

signal_name signal_direction [input_default] [output_default] 

cycle_time strobe1 strobe2 

EXAMPLE 1: 

out1 O 100 80 80 

NOTE: In the previous example, if you want to choose only 

one strobe point, you must enter the value twice. 

EXAMPLE 2: 

bidi1 B in@(out=0) 80 60 50

Appendix A 

Customization 

Customizing EPIC Tools 

The information in this appendix shows you how to set your 

environment to run a customized version of the tool. It also 

shows you how to customize EPIC tools by modifying some of the 

internal calculations they perform. 

You can customize EPIC tools to work in your environment, 

either for your own use or for all users at your site. 

The following steps show you how to customize the EPIC tools 

both for your own use and for use by others at your site. 

1 Copy the customize.c source code file from the release 

directory using the following command: 

cp $EPIC_HOME//lib/customize.c 

your_dir/customize.c

300 Customization 

If you use TimeMill or PowerMill, please see the example in 

$EPIC_HOME/examples/timemill_api/customize or 

$EPIC_HOME/examples/powermill_api/customize, and 

copy customize.c from the example directory. 

2 Edit the customize.c file as required. 

3 You can include the modified customize.c file by adding the 

following syntax to the .epicrc file in the run directory. 

toolname:user_obj_modules_force:customize.c 

A shared library, libCustom.so.1.0, is created in your current 

working directory during the simulation. When you are sure 

the customized version is correct, copy libCustom.so.1.0 to a 

permanent directory. 

4 If you want to use your customized version every time you 

run an EPIC tool, you can use one of the following methods: 

◆ Add the following line to your $HOME/.epicrc file: 

toolname:user_libraries:your_lib_path 

libCustom.so.1.0 

The toolname can be PathMill, PowerMill, RailMill, or 

TimeMill. If you want all users of this EPIC installation 

to use your customization, add the above line to 

$EPIC_HOME/PLATFORM_OS/lib/.epicrc. 

◆ Add the -U customize.c option to the command line 

when starting the simulator. 

This will create the libCustom library in your working 

directory. 

NOTE: After installing EPIC software updates, be sure to recompile the 

custom library libCustom.so.1.0. The exact name of the custom 

library varies from one platform to another.

Library names for supported platforms are: 

■ libCustom.so.1.0 (SUN SunOS) 

■ libCustom.s1 (HP HPUX) 

■ libCustom.o (IBM AIX) 

■ libCustom.so (DEC Alpha) 

■ libCustom.a (other platforms) 

Customizing EPIC Tools 301 

Three functions in the customize.c file need special attention for 

a pre-layout case. A pre-layout case is any case where you do not 

specify in your netlists any of the MOS geometry values ad, as, 

pd, ps, nrd, and nrs. The three functions are: 

■ calculateDiffArea() which returns ad or as 

■ calculateDiffPerimeter() which returns pd or ps 

■ calculateNRSH() which returns nrd or nrs 

These functions match the default geometry values of a prelayout 

case to your SPICE. You need to make sure they match 

your SPICE defaults; otherwise, an accuracy problem might 

arise when using EPIC Tools on a pre-layout netlist. 

NOTE: When compiling these functions on an HP machine, you must use 

the -z option to generate position independent code (PIC). This 

option is not supplied as part of the standard HP-UX operating 

system, but must be purchased as a separate product. If you try 

to compile without this option, you might get an error message, 

such as: 

cc: warning 422: Unknown option "c" ignored. 

Building libCustom.sl.... 

ld: DP-Relative Cide in file ./customize.o - Shared 

Library must be Position-Independent 

Each of the three functions has three leading arguments in its 

parameter list: acm, w, and l. 

The w argument is the effective width, Weff, which is calculated 

by and passed from EPIC tools as: 

Weff = Wdrawn * wmlt - 2 * wdiff 



The l argument is actually the effective diffusion extension 

length diffext, eff (or ds_length,eff), which is calculated by and 

passed from EPIC tools as: 

diffext,eff = diffext * wmlt 

The acm argument if the integer acm value in the technology file 

data line: 

acm value SPICE_name 

For HSPICE, the acm value is 0, 1, 2, or 3, which represents the 

physical Area Calculation Method. The three functions are 

already set up to return the correct default geometry values for 

HSPICE, so you don’t have to do anything for HSPICE. 

For other SPICE types, the acm value is used to distinguish its 

SPICE type, and the acm integer is borrowed for this purpose. A 

line of C code checks the SPICE type. 

EXAMPLE: 

if (acm == 22) 

Check the technology file for the acm value. If it is -1, your 

SPICE is not set up, and you should check and edit the three 

functions for a pre-layout circuit. If the acm value in the 

technology file is not -1 and the value appears in the three 

functions, the three functions are already set up for your SPICE. 

Customizing Wire Capacitance Estimate 

EPIC lets you modify the wire capacitance estimate, an internal 

TimeMill, PathMill, RailMill, and PowerMill calculation. The C 

source code containing the calculation is in the customize.c file. 

This module resides in the directory: 

$EPIC_HOME/ PLATFORM_OS/lib. 

To achieve a more accurate pre-layout timing analysis, you use 

the wire_cap_est command to automatically get estimated 

interconnect capacitances. When you specify the wire_cap_est

Customizing Wire Capacitance Estimate 303 

command in the configuration file, the 

estimateWireCapacitance function is called for each node in 

the design. 

The capacitance returned by the estimateWireCapacitance 

function is added to the capacitance already specified for each 

node. 



The C function is shown in Figure 1. 

double 

estimateWireCapacitance (node_name, number_channel, number_gate, 

number_input, number_output, number_biput, max_pwl, max_nwl, widths) 

char *node_name; 

int number_channel, number_gate; 

int number_input, number_output, number_biput; 

int max_pwl, max_nwl, widths; 

{ 

#define FANIN_CAP 2.0 

#define FANOUT_CAP 5.0 

return 

#undef FANIN_CAP 

#undef FANOUT_CAP 

} 

Figure 1 C function 

int fanin, fanout; 

float fanout_scale, cap; 

/* Treat channels as fanin’s and biputs as fanout’s */ 

fanin = number_channel + number_output; 

fanout = number_gate + number_input + number_biput; 

/* Select a scaling factor based on number of fanout’s*/ 

if (fanout >= 15) 

fanout_scale = 1.5; 

else if (fanout >= 5) 


else 


cap = fanin*FANIN_CAP+fanout*FANOUT_CAP*fanout_scale; 

The inputs are: 


node_name Name of the node 

number_channel Number of channel connected 

transistors connected to the node 

number_gate Number of gate connected 

transistors connected to the node 

number_input Number of functional model inputs 

connected to the node

Sample .err File 



number_output Number of functional model 

outputs connected to the node 

number_biput Number of functional model biputs 

connected to the node 

max_nwl Maximum N transistor W/L ratio 

driving the node 

max_pwl Maximum P transistor W/L ratio 

driving the node 

widths Sum of the total widths of the txs 

connected to this node (default unit 

is 0.01 μm) 

The output returns additional capacitance, in femtoFarads, to the 

node. 

The capacitance is given as a function of the fanins to a node and 

the fanouts from the node. The more fanins and fanouts that 

exist on a node, the higher the total interconnect capacitance is 

on the node. As well as adding this capacitance to each node, this 

example also prints the capacitance that was estimated for each 

node to a file called estimate.list. 

The following example shows a customized 

estimateWireCapacitance function. This example models 

interconnect capacitance prior to layout. 

/*for file access */ 

#include 

#define FAN_IN_CAP 2.0 /* This is the estimated Capacitance 

in FF per fan in */ 

#define FAN_OUT_CAP 5.0 /* This is the estimated Capacitance 

in FF per fan out */ 

#define BAND_LIMIT1 0 /* These 3 constants define the bands 

where we apply */ 

#define BAND_LIMIT2 5 /* a different fan out scaling factor 

depending on */ 

#define BAND_LIMIT3 15 /* the number of fan outs */ 

#define FAN_OUT_SCALE1 1.0 /* scale factor for the first band of 

fan outs */ 

#define FAN_OUT_SCALE2 1.2 /* scale factor for the second band of 



fan outs */ 

#define FAN_OUT_SCALE3 1.5 /* scale factor for the third band of 

fan outs */ 

double estimateWireCapacitance(node_name,number_channel, 

number_gate,number_input,number_output,number_biput, 

max_pwl,max_nwl) 

char *node_name; 

int number_channel, number_gate; 

int number_input, number_output, number_biput; 

int max_pwl, max_nwl; 

{ 

/* max_pwl is the maximum width/length of the drive P MOS */ 

/* max_nwl is the maximum width/length of the drive N MOS */ 

float c; /* variable to hold the estimated capacitance */ 

static FILE *cap_file = NULL; /* file ptr to file for writing 

capacitance estimates to */ 

static short first_time = 1; /* flag set true for the first time 

this function is called */ 

int fan_ins; /* Number of fan ins */ 

int fan_outs; /* Number of fan outs */ 

float fan_out_scale; /* Number used to scale the capacitance 

for fan outs */ 

/* This is the first time this function is called. Open the file for writing. */ 

if (first_time) 

if ((cap_file=fopen (”estimate.list”,”w”))==NULL) 

/* If unable to open file print an error message */ 

fprintf (stderr,”estimateWireCapacitance: Unable to" 

"open file’estimate.list’\n”); 

/* Set first time to false */ 

first_time = 0; 

/* The number of fanouts is given as the number of gate connects plus the number of 

inputs. Inputs are defined as ‘inputs’ to a gate i.e., fanouts to the node. In this 

example, biputs are 

treated as fanouts */ 

fan_outs = number_gate + number_input + number_biput; 

fan_ins = number_output + number_biput + number_channel; 

/* We scale the capacitance estimated for the fanouts based on the number of fanouts */ 

if ((fan_outs >= BAND_LIMIT1) && (fan_outs < BAND_LIMIT2)) 

fan_out_scale = FAN_OUT_SCALE1; 

else 

if ((fan_outs >= BAND_LIMIT2) && (fan_outs < BAND_LIMIT3)) 


else 

/* if (fan_outs >= BAND_LIMIT3) */ 


/* Capacitance estimate is based on fan ins and fan outs */ 

c = (fan_ins * FAN_IN_CAP) + (fan_outs * FAN_OUT_CAP * 

fan_out_scale); 

/* Print the estimates into a file for checking purposes */ 

/* The output format of this file is the same as accepted by all EPIC products. It 

could thus also be used by PathMill and PowerMill or TimeMill (when the wire estimator 

is turned off) */


if (cap_file != NULL) 

fprintf(cap_file,”node_capacitance %s %d\n”,node_name,(int)c); 

/* Return the estimated capacitance */ 

return(c); 

} 



epic_delay 

SYNTAX: 

double 

epic_delay (intrinsic, drive, slope_factor, slope, loading) 

int intrinsic, drive, slope, loading; 

double slope_factor; 

{ 

return (int) (intrinsic + (slope_factor * slope) + le-4 

* drive * loading); 

DESCRIPTION: 

This function returns a total delay that is a function of 1) the 

intrinsic delay, 2) the output loading times drive resistance, and 

3) the input slope times a slope effect coefficient. 


intrinsic Intrinsic delay of the gate in .01 ns 

units (int) 

drive Drive resistance of the output node 

in ohms (int) 

slope_factor Input slope coefficient (float) 

slope Input slope that is returned from 

fget_input_slope or 

fget_bi_slope in .01 ns (int) 

loading Output load that is returned from 

fget_out_load or fget_bi_load in 

fF (int) 

The input parameters are used in the following calculation to 

produce the delay: 

delay = int_d + (r*c_load)/10000 + 

(k_slope * slope + .05) 

The delay is returned as an int and is in units of 0.01 ns.

epic_slope 

SYNTAX: 


double 

epic_slope (intrinsic, drive, loading) 

int intrinsic, drive, loading; 

{ 

return intrinsic + le-4 * drive * loading); 

DESCRIPTION: 

This function returns the output slope as a function of 1) the 

intrinsic slope delay, and 2) the output loading times slope drive 

resistance. 


intrinsic Intrinsic slope of delay in .01 ns 

units (int). 

drive Slope drive resistance of the output 

node in ohms (int). 

loading Output load that is returned from 

fget_out_load or fget_bi_load in 

fF (int). 

The input parameters are used in the following calculation to 

produce the slope: 

slope = int_d + (r*c_load)/10000 

The slope is returned as an int in units of 0.01 nanoseconds. 


310 Customization

The .out File 

Appendix B 

Output Files 

This appendix contains information about files that result from 

dynamic simulation processing, including a sample file of each 

file type. The files types are: 

■ .out 

■ .act 

■ .nact 

■ .nodealias 

The .out file contains simulation output information for logic 

states, voltage, and current. The .out file format can be 

controlled using the set_print_format configuration command. 

The .out file is divided into three sections: 

■ Header section: This section contains the output format 

version number, copyright, and the time and date the file was 

generated.

312 Output Files 

Line Format 

Null 

■ Definition section: This section defines units used in the 

.out file, the mapping between signal index and signal name, 

bus notation, and so on. 

■ Data section: This final section in the .out file lists all the 

requested signal values. 

The output file uses line-oriented syntax. The lines can be 

classified according to the first character in the line: 

■ null (blank line) 

■ ; (semicolon) 

■ . (period) 

■ a number 

A blank line can appear anywhere and is ignored by the 

waveform display tools. It can contain spaces and tabs. 

Semicolon Lines 

A semicolon at the beginning of a line indicates that the line is a 

header, trailer, information, or comment line. Header and trailer 

lines are used by some waveform display tools to check file 

integrity. The first line in the file starts with a semicolon and 

specifies the output format version. 

The semicolon lines, except for comment lines, the end-of-file 

indicator, and the trailer line, can appear only in the header 

section. A comment line can appear anywhere. 

The voltage output of PowerMill and TimeMill is piecewiselinear. 

Two voltages in the same timestamp indicate a voltage 

transient that occurs too quickly to be resolved given the .out file 

time resolution.

Period Lines 

Keywords 

The .out File 313 

Lines that begin with a period (.) contain keywords followed by 

related values. 

All of the keywords, except for index, can be used only in the 

definition section. The index lines may appear in the data section 

in addition to the definition section. The keywords and 

associated values are defined in the following table: 

Keyword and Value Definition 

vdd vdd_value Specifies the power supply 

voltage. 

time_resolution time_unit Specifies the time unit 

(nanoseconds). 

current_resolution cur_unit Specifies the current unit 

(Amperes). 

voltage_resolution vol_unit Specifies the voltage unit 

(volts). 

math_resolution math_unit Used only in version 5.1 

output_format, which specifies 

the scaling factor for all math 

signals so that signal value 

times math_unit returns the 

real value for a math signal. 

In version 5.3 output_format, if 

the SPICE math expression is 

evaluated to a voltage value or a 

current value, the signal will be 

printed to the .out file as a 

voltage signal or a current 

signal, respectively. Otherwise, 

the MKS standard units will be 

used (for example, wattage will 

be in watts (volt*ampere). 

high_threshold vol_thresh Specifies the high threshold 

voltage. 




low_threshold vol_thresh Specifies the low threshold 

voltage. 

nnodes number_of_nodes Specifies the number of nodes. 

neems number_of_elems Specifies the number of 

elements. 

extra_nodes 

Total extra power node number. 

number_of_extra_nodes 

bus_notation o s c Specifies the bus name 

delimiters; o is the opening bus 

delimiter, s is the separator, and 

c is the closing delimiter. 



Specifies the hierarchical 

separation character. 

case case_symbol Specifies if the node or element 

names are case-sensitive (S), 

lowercase (L), or uppercase (U). 

index name_index_pair 

signal_attribute 

Specifies the index for a name, 

followed by the signal attribute. 

Note: The complete format for 

index immediately follows this 

table. 

bio new_name EPIC_name Replaces EPIC_name with 

new_name in ndisplay or other 

output display program. 

oct bus_name EPIC_name3 

EPIC_name2 EPIC_name1 

Specifies a bus name for a group 

of three signals. EPIC_name3 is 

the most significant bit, and 

EPIC_name1 is the least 

significant bit.


hex bus_name EPIC_name4 

EPIC_name3 EPIC_name2 

EPIC_name1 

big new_group_name 

EPIC_name1 

EPIC_name2 ... 


The following syntax shows the complete format for the keyword 

index. 

SYNTAX: 

Specifies a bus name for a group 

of four signals. EPIC_name4 is 

the most significant bit, and 

EPIC_name1 is the least 

significant bit. 

Prints a caption with 

new_group_name for the group 

of EPIC_name signals (used 

only in ndisplay output). 

name_index_pair ::= name index; 

index ::= integer; 

name ::= EPIC_name | 

v (EPIC_name) | 

i (EPIC_name) | 

I (EPIC_name) | 

I_rms (EPIC_name) | 

di/dt (EPIC_name) | 

i# (EPIC_name) | 

I# (EPIC_name) | 

I_rms# (EPIC_name)| 

di/dt# (EPIC_name) | 

m (EPIC_name) | 

EPIC_name::=EPIC valid element or node name 

#::= integer giving valid EPIC element branch index (1, 2, 3, 4, 

or 5). 



The signal attributes are defined as follows: 

Signal Attribute Definition 

v Analog voltage (PWL/voltage resolution). 

i Instantaneous current (PWC/current 

resolution). 

I Average current (PWL/current resolution). 

I_rms rms current (PWL//current resolution). 

di/dt Current change rate (PWC/current 

resolution). 

l Logic state number with a value between 0 

and 10. 

m Mathematical signal (PWL/math 

resolution). 

M Average mathematical signal (PWL / MKS 

resolution). 

M_rms RMS mathematical signal (PWL / MKS 

resolution). 

dm/dt Mathematical signal change rate (PWL / 

MKS resolution). 

NOTE: In the previous table, PWL is defined as piecewise linear, and 

PWC is defined as piecewise constant. 

Lines Beginning with Numbers 

Lines beginning with numbers represent either times or values. 

Single integer line: The number on this line represents a time. 

The unit of time is based on the resolution specified by the 

time_resolution keyword. When a time line appears, it defines a 

new time section in which all the value lines that appear after 

the time line but before the next time line give the signal values 

at the current time. Time lines must appear in ascending order. 

The last time line in the file is used by the display tool to 

determine the length of simulation time.


Double integer line: A line with two integers is a value line. 

The numbers represent index and value. 

For nodes whose logic states are printed, value is defined as: 

value ::= logic_state_number |signal_value 

signal_value ::= integer 

where integer is voltage/current/derived output. 

The logic state numbers and their corresponding characters are 

defined in the following table. (See “Logic States” on page 248.) 

Logic State 

Number 

Character Definition 

0 ‘0’ logic ZERO (strong drive) 

1 ‘1’ logic ONE (strong drive) 

2 ‘U’ logic UNDEF (strong drive) 

3 ‘L’ logic ZERO (high impedance drive) 

4 ‘H’ logic ONE (high impedance drive) 

5 “Z” logic UNDEF (high impedance drive) 

6 ‘N’ logic ZERO (biput driven by circuit) 

7 ‘T’ logic ONE (biput driven by circuit) 

8 ‘Y’ logic UNDEF (biput driven by circuit) 

9 ‘?’ logic UNSET (not initialized nor set during 

simulation) 

10 ‘X’ logic DON’T CARE (can be any state) 



Sample Output File for TimeMill 

;! output_format 5.3 

; header 306719985 

; -------------------------------------------------------- 

;| | 

;| TimeMill Version 5.4_Release | 

;| SN: P121598-SunOS_5 | 

;| Copyright (c) 2000 Synopsys Inc., All Rights Reserved. | 

;| | 

; -------------------------------------------------------- 

; 

; 

.vdd 3.3 

.time_resolution 0.1 

.current_resolution 1e-06 

.voltage_resolution 0.01 

;tentative simulation_time 50 

.high_threshold 2.31 

.low_threshold 0.99 

.nnodes 75 

.nelems 243 

.extra_nodes 0 

.bus_notation [ - ] 

.hier_separator . 

.case L 

.index v(g7) 1456 v 

.index g7 1457 l 

.index m(vfunc1) 1950 m 

.index M(vfunc2) 1976 M 

.index dm/dt(vfunc3) 2002 dm/dt 

.index M_rms(vfunc4) 2028 M_rms 

0 

1456 330 

1457 1 

2028 10.89 

2002 -200 

1976 0.00013464 

1950 0.00013464 

0 

2028 10.89 

2028 14.19 

5 

2028 14.19 

2028 3.3 

2002 -200 

2002 130 

1976 0.00013464 

1976 9.9e-07 

1950 0.00013464 

1950 0.00016896 

10 

2028 3.3 

2028 3.3 

1950 0.00016896 

1950 3.597e-05 

20 

2028 3.3 

2028 0 

25 

2028 0 

2028 -10.89

1976 9.9e-07 

1976 0.00013563 

1950 3.597e-05 

1950 3.762e-05 

29 

1456 330 

30 

1456 330 

2028 -10.89 

2028 3.3 

1976 0.00013563 

1976 9.9e-07 

1950 3.762e-05 

1950 3.597e-05 

31 

1456 313 

1456 274 

32 

1456 189 

1457 2 

33 

1456 81 

1456 0 

1457 0 

34 

1456 3 

35 

1456 2 

2028 3.3 

2028 3.3 

2002 130 

2002 -200 

1976 9.9e-07 

1976 0 

1950 3.597e-05 

1950 0 

39 

1456 0 

40 

2028 3.3 

2028 3.3 

1950 0 

1950 0.00013299 

49 

1456 0 

50 

1456 0 

1457 0 

2028 3.3 

2002 -200 

1976 0 

1950 0.00013299 

; file closed at 5.000000ns 

; trailer 823484657 




Sample Output File for PowerMill 

;! output_format 5.3 

; header 306529706 

; -------------------------------------------------------- 

;| | 

;| PowerMill Version 5.4_Release | 

;| SN: P121498-SunOS_5 | 


;| | 

; -------------------------------------------------------- 

; 

; 

.vdd 3.3 

.time_resolution 0.1 

.current_resolution 1e-06 

.voltage_resolution 0.01 

; tentative simulation_time 50 

.high_threshold 2.31 

.low_threshold 0.99 

.nnodes 75 

.nelems 243 

.extra_nodes 0 

.bus_notation [ - ] 

.hier_separator . 

.case L 

.index v(g7) 1456 v 

.index g7 1457 l 

.index i(g7) 1458 i 

.index I(g7) 1459 I 

.index I_rms(g7) 1460 I_rms 

.index di/dt(g7) 1461 di/dt 

.index m(power_flow) 1950 m 

.index M(power_flow) 1976 M 

.index dm/dt(power_flow) 2002 dm/dt 

.index M_rms(power_flow) 2028 M_rms 

.index i1(x11.xi9.xn8.mxn0) 2034 i 

.index I2(x11.xi9.xn8.mxn0) 2040 I 

.index I_rms3(x11.xi9.xn8.mxn0) 2046 I_rms 

.index di/dt4(x11.xi9.xn8.mxn0) 2052 di/dt 

.index di/dt5(x11.xi9.xn8.mxn0) 2053 di/dt 

0 

1456 330 

1457 1 

2052 0 

2053 0 

2034 0 

2046 0 

2040 0 

1458 0 

1461 0 

1459 0 

1460 0 

2028 0.00033 

2028 0.00033 

2002 -200 

2002 -200 

1976 0.00013464 

1976 0.00013464 

1950 0.00013464 

1950 0.00013464

0 

1950 0.00013464 

1950 0.00013464 

5 

2052 -53 

2034 268 

2028 0.00033 

2028 0.00088539 

2002 -200 

2002 130 

1976 0.00013464 

1976 9.9e-07 

1950 0.00013464 

1950 0.00016896 

6 

2052 214 

2034 54 

2028 0.00088539 

2028 0.00017919 

1976 9.9e-07 

1976 9.9e-07 

7 

2052 48 

2034 6 

2028 0.00017919 

2028 2.079e-05 

1976 9.9e-07 

1976 9.9e-07 

10 

2052 2 

2034 0 

2028 2.079e-05 

2028 9.9e-07 

1976 9.9e-07 

1976 9.9e-07 

1950 0.00016896 

1950 3.597e-05 

20 

1950 3.597e-05 

1950 3.597e-05 

25 

2053 10 

2046 0 

2052 5 

2034 175 

2028 9.9e-07 

2028 0.00033099 

1976 9.9e-07 

1976 0.00013563 

1950 3.597e-05 

1950 3.762e-05 

26 

2053 -239 

2046 49 

2052 -72 

2034 8 

2028 0.00033099 

2028 0.00033099 

1976 0.00013563 

1976 0.00013563 

27 

2053 -10 

2046 48 




2052 -3 

2034 0 

2028 0.00033099 

2028 0.00033099 

1976 0.00013563 

1976 0.00013563 

29 

1456 330 

2053 0 

2046 46 

1976 0.00013563 

1976 0.00013563 

30 

1456 330 

2052 -89 

2034 268 

1458 -394 

1461 -13 

1459 0 

1460 0 

2028 0.00033099 

2028 9.9e-07 

1976 0.00013563 

1976 9.9e-07 

1950 3.762e-05 

1950 3.597e-05 

31 

1456 313 

1456 274 

2052 214 

2034 54 

1458 -1430 

1461 -1036 

1459 -12 

1460 70 

2028 9.9e-07 

2028 9.9e-07 

1976 9.9e-07 

1976 9.9e-07 

32 

1456 189 

1457 2 

2052 48 

2034 6 

1458 -1587 

1461 -157 

1459 -57 

1460 262 

2028 9.9e-07 

2028 9.9e-07 

1976 9.9e-07 

1976 9.9e-07 

33 

1456 81 

1456 0 

1457 0 

1458 -141 

1461 1446 

1459 -103 

1460 378 

34 

1456 3 

1458 -84

1461 57 

1459 -104 

1460 373 

35 

1456 2 

2052 1 

2034 1 

1458 -26 

1461 58 

1459 -103 

1460 368 

2028 9.9e-07 

2028 0 

2002 130 

2002 -200 

1976 9.9e-07 

1976 0 

1950 3.597e-05 

1950 0 

39 

1456 0 

2052 0 

2034 0 

1458 0 

1461 6 

1459 -95 

1460 348 

2028 0 

2028 0 

1976 0 

1976 0 

40 

2028 0 

2028 0 

1976 0 

1976 0 

1950 0 

1950 0.00013299 

49 

1456 0 

50 

1456 0 

1457 0 

2028 0 

2002 -200 

1976 0 

1950 0.00013299 

51 

2053 0 

2052 0 

2046 35 

2040 0 

2034 0 

2028 -0 

2002 -0 

1976 -0 

1950 -0 

1458 0 

1461 0 

1459 -73 

1460 305 

; file closed at 5.000000ns 

; trailer 809437103 




The .act File 

The simulation tool reports active nodes whose voltage changes 

exceed the user-defined threshold to the .act file. The .act file 

uses the Arcadia netlist format so that it can be read directly by 

Arcadia. 

The .act file is divided into three main sections: 

■ Header section: This section displays the name of the 

program generating the file, the time and date the file was 

generated, the output format version number, and copyright. 

;! act_file_format version_number 

The version number is updated only when a new .nact file 

format is released with the software. 

■ Simulation information section: This section displays the 

information used by the tool to postprocess the file. See the 

next section for a detailed description of this section. 

■ Active node information section: This section displays 

the total number of active nodes reported in the file. 

Simulation Information Section 

This section of the .act file is divided into several subsections, 

which can be one or many lines long. For example, one line 

provides the RC time constant unit, which you can change using 

the set_sim_unit configuration command. 

EXAMPLE: 

; The unit for RC time constants is ns. 

The next subsection reports the interval of time during which 

the inactive nodes are monitored. 

EXAMPLE: 

; The checking starts at 10.600000ns and ends at 

13.400000ns

Sample .act File 

The .act File 325 

The next subsection lists active nodes using the following 

syntax: 

EXAMPLE: 

node_name [cap_model] [reduction_model] [RC_constant]; 

The possible values for cap_model and reduction_model are 

listed in the description of the report_node_active command. 

RC_constant is the RC time constant based on the node 

capacitance and the maximum resistance of the conducting path 

from the voltage source (or ground) to the node. 

This file lists active nodes reported by the report_node_active 

configuration command. 

;! act_file_format 5.3 

; -------------------------------------------------------- 

;| | 

;| PowerMill Version 5.4_Release | 

;| SN: P101598-SunOS_5 | 


;| | 

; -------------------------------------------------------- 

;; 

; Report active nodes in Arcadia netlist format. 

; The unit for RC time constants is ns. 

; 

; The checking starts at 10.600000ns and ends at 13.400000ns 

*schematic-net-name 

t1.C 21 awe ; 0.297 

t1.B 21 awe ; 0.252 

a 3 serial-parallel ; 0 

out 3 serial ; 0.126 

; number of active nodes reported in the file: 4 



The .nact File 

Inactive Node Information 

The simulation tool reports to the .nact file inactive nodes whose 

voltage changes exceed the user-defined threshold. 

The .nact file is divided into two main sections: 

■ Header section: This section contains the name of the 

program generating the file, the time and date the file was 

generated, the output format version number, and copyright. 

;! inact_file_format version_number 

The version number is updated only when a new .nact file 


■ Simulation information section: This section contains 

information used by various tools to do postprocessing on 

this file. See the next section for a detailed description of this 

section. 

■ Inactive node information section: This section displays 

a summary report of the inactive nodes detected. The report 

includes the total number of inactive nodes that were 

detected, and, of those, the number connected to an external 

source, and the number that were or were not in active 

stages. 

This section of the .nact file is divided into three subsections. 

The first subsection (a single line) reports the interval of time 

during which the inactive nodes are monitored. 

EXAMPLE: 

; The checking starts at 50.000000ns and ends at 

100.000000ns 

The second subsection lists inactive nodes that are not in active 

stages using the following syntax: 

config_cmd cmd_arguments_with_inactive_nodes

Sample .nact File 

The .nact File 327 

The third subsection lists inactive nodes that are in active stages 

using the following syntax: 

set_node_ic node_name ic_voltage 

This file reports inactive nodes with voltages that don’t change 

during the active node checking period. This file is generated by 

the inactive= option of the report_node_active configuration 

command. 

;! inact_file_format 5.3 

; -------------------------------------------------------- 

;| | 


;| SN: P110998-SunOS_5 | 


;| | 

; -------------------------------------------------------- 

;; 

; Report inactive nodes in EPIC configuration file format. 

; 

; The checking starts at 50.000000ns and ends at 100.000000ns 

;============================================================== 

; Section for inactive nodes not in active stages 

;============================================================== 

set_node_v v=0V no=CTR 

set_node_v v=0V no=CTR 

set_node_v v=0V no=XCNTR-XI2-XI0-XI25-NET9 

set_node_v v=0V no=N_378 

;============================================================== 

; Section for inactive nodes in active stages 

;============================================================== 

set_node_ic XCNTR-XI2-XI0-XI25-XI4-NET4 0V 

set_node_ic XCNTR-XI2-XI2-XI25-NET12 3V 

set_node_ic XCNTR-XI2-XI2-XI25-XI4-NET4 0V 

;============================================================== 

; Summary for inactive node report 

;============================================================== 

; number of inactive nodes detected: 11 

; number of inactive nodes connected to external src: 4 

; number of inactive nodes not in active stages reported: 4 

; number of inactive nodes in active stages reported: 3 



The .nodealias File 

Sample .nodelias File 

EPIC simulation tools report node alias names to the .nodealias 

file if the node names specified in the SPICE netlists, SPF files 

or configuration files are not the primary names. 

A node (net) in a circuit can have alias node names for any of the 

following reasons: 

■ There are hierarchical alias names from instances of 

subcircuits 

■ The very small resistors are shorted 

■ There are DC voltage sources of 0 volts connected to the node 

■ The node is replaced by the back-annonated RC network 

■ The RC network is reduced 

The .nodealias file has an EPIC file banner at the top that 

contains the name of the program generating the .nodealias file 

and time at which the file was generated. Starting with version 

5.3, the first line of the EPIC banner gives the file format version 

as: 

;! nodealias_format version_number 

The version number is updated only when a new .nodealias file 


Node alias names and primary names are listed using the 

following syntax: 

primary_node_name alias_node_name 

The alias_node_name is the name originally used in the SPICE 

netlists or configuration files. 

EPIC simulation tools report node alias names to the .nodealias 

file if the node names specified in the SPICE netlists, SPF files 

or configuration files are not the primary names.

The .nodealias File 329 

;! nodealias_format 5.3 

; -------------------------------------------------------- 

;| | 


;| SN: P111398-SunOS_5 | 


;| | 

; -------------------------------------------------------- 

; 

; 

; A node (net) in a circuit can have alias node names for any of the 

; following reasons: 

; * There are hierarchical alias names from instances of subcircuits 

; * The very small resistors are shorted 

; * There are DC voltage sources of 0 volts connected to the node 

; * The node is replaced by the back-annonated RC network 

; * The RC network is reduced 

; 

; The following node names specified in the SPICE netlists, SPF files, 

; or configuration commands are not primary names. Their primary names are 

; printed for reference using the following syntax: 

; 

; 

; 

; The primary_node_name is the node name chosen by the 

; netlist parser. The alias_node_name is the original node name used 

; in the SPICE netlists, SPF files or configuration commands. 

; 

; 

out t1.OUT 

vdd VSS 

PI x1.cell1.in 



Warning Messages and the .log File 

The following table defines terms you might find in the .log file 

or in warning messages: 

U A node is unconnected if it is not connected to 

any circuit element, except capacitors. A 

message is reported by the netlist compiler. The 

names of all unconnected nodes are listed in a 

.unc file. When an unconnected node is 

identified, a message will appear in the .dcu file. 

EXAMPLE: 

There are ten nodes that are set to U by the 

simulator before DC initialization. See the 

timemill.dcu file for the node names. 

dangling A node is dangling if: 

It is not connected to an input stimulus, 

including voltage/current source. 

It is not channel-connected to any circuit 

element. 

It is not connected to an output or biput of 

any functional models. 

The names of all dangling nodes are reported in 

a .dng file. When a dangling node is identified, 

a message is reported in a .dng file after the 

tool reads the configuration commands. 

EXAMPLE: 

There are eight dangling nodes. See the 

timemill.dng file for the node names. 

floating A node is defined as floating if there is no 

conducting path from a voltage source to the 

node.

The .err File 

Appendix C 

Error Output File 

All TimeMill and PowerMill timing, power, and logic errors are 

written to an error file. This appendix contains information 

about the .err file and the Viewerror utility that you can use to 

read the error file. 

EPIC simulation tools report warnings and errors to an error 

(.err) file, in addition to sending messages to the stdout and the 

.log file. The error file begins with an EPIC file banner that 

contains the name of the program generating the error file and 

the time the file is generated. 

The error file lists each error message as a number of fields of 

ASCII code on one line. These fields are error type code, error 

description code, related node names, element names, and 

simulation information. Each field on a line is separated by a 

blank. The number of fields on the line depends on the type of 

error.

332 Error Output File 

The first three fields are common to all error messages. They are 

described in the following table. 

Field Number Data Type Description 

1 float The simulation time when the 

error occurred. 

2 int Error/warning type code (T_code). 

3 int Error/warning description code 

(D_code). 

There are 10 different types of codes (T_codes), each of which has 

a set of description codes (D-codes). The D-codes provide detailed 

messages about the error. 

The T_codes (error/warning type codes in field 2) are described in 

the following table. 

T_Code Data Type 

1 Comparison error 

2 Timing error 

3 Bus contention error 

4 High Impedance condition 

5 Uncertain state condition 

6 Timing error with timing tolerance margin 

7 Block delay characterization error 

8 Power diagnosis 

9 Multiple toggle error 

10 Multiple pulse error

Type 1: Comparison Error 

Type 1: Comparison Error 

The .err File 333 

The description codes (D_Codes) describe the error in detail. The 

fields that follow the D-code field (field 3) vary. The following 

tables list the D_codes for all T_codes. 

D_code 1 The simulated result differs from the expected results. 

D_code 2 Node should have been in high impedance. 

D_code 3 Node should not have been in high impedance. 

D_code 4 Biput node should be driven by the circuit. 

D_code 5 Biput node should drive the circuit. 

D_code 6 Node should have been set during simulation. 

D_code 7 Node should not have been set during simulation. 

D-code 8 Node should be at X state. 

D-code 9 Node should be at a non-X state. 

Additional Fields: 


4 int Simulated value (state number). 

5 char Expected value. 

6 string Node name. 

D_code 10 The simulated result differs from the expected results during 

the strobe window. 

D_code 11 The simulated result differs from the expected results during 

the stimulus-triggered strobe window. 



4 int Simulated value (state number) 

5 char Expected value 



6 float Time when the strobe window starts. 

7 float Time when the strobe window ends. 


Type 2: Timing Errors and Type 6: Timing Errors with Tolerance Margin Specified 

D_Code 1 Setup time violation/tolerance 

D_Code 2 Hold time violation/tolerance 

D_Code 3 Edge-to-edge violation/tolerance 



4 string Node1 name. 

5 int direction (0: rising |1: falling | 

2: changing) 

6 float Occurred time of node1 

7 string Node2 name 

8 int direction (0: rising |1: falling | 

2: changing) 

9 float Occurred time of node2 

10 float Time diff (abs (field 9 - field 6)) 

11 string “Min/Max” 

12 float Time required. 

The following field is for Type 2 only: 

13 string Hierarchical name of the timing checking 

element or “-cfg” if the timing check element is 

specified in a configuration file. 

The following fields are for Type 6 only: 

13 float Tolerance margin. 


element or configuration filename if the timing 

check element is specified in a configuration file.



D_Code 4 Pulse width violation/tolerance 




5 int direction (0: rising |1: falling | 2: changing) 

6 float Occurred time 


8 float Occurred time 

9 float Pulse width. 

10 string “Min/Max” 

11 float Width required. 













D_Code 5 Edge to edge window violation/tolerance 



4 string Reference node name 





6 float Reference edge occurred time. 

7 string Checked node name. 


9 float Occurred time for the edge of the checked node. 

10 float Time diff by (field 9 - field 6) 

11 float Lower bound of time diff in nanoseconds. 

12 float Upper bound of time diff in nanoseconds. 






13 float Tolerance margin. 




Type 3: Bus Contention Error 

Timing checks can be specified by using a SETUP command in 

the netlist file or a timing check in a configuration file. A timing 

violation message is reported in the .err output file with element 

information if the error was found in a netlist. A timing violation 

message is reported without element information if the error was 

found from a timing violation check in the configuration file. The 

extension -cfg is appended to the message in the .err output file. 

D_Code 1 Bus contention error 



4 string Node name

Type 4: High Impedance Condition Generated by “report_node_z” 

D_Code 1 High Impedance Condition 




4 string Node name 

5 float At time 

6 int Internal state number for high impedance value 

(H/L/Z) 

7 float Maximum high-impedance state time without 

error reporting. 

Type 5: Unknown State 

D_Code 1 U-state (transition state) duration is too long. 




5 float U-state end time. 

6 int Internal state number for unknown state (U/Z/Y) 

7 float Maximum U-state time without error reporting 


D_Code 2 U- state (transition state) duration is too short. 







5 float U-state end time. 

6 int Internal state number for unknown state (U/Z/Y) 

Type 7: Block Delay Characterization Error 

D_Code 1 No transition on node 




Type 7: Block Delay Characterization Error 

D_Code 2 No delay path 



4 int 0|1|2 for rising|falling|changing 

5 int 0|1|2 for rising|falling|changing 


7 string Node name.

Type 8: Power Diagnosis 

D_Code 1 Static Partial-Swing Detection (NMOS) 

Syntax: 0 8 1 


Definition: Node is driven by PMOS transistors only, and it drives at least one 

NMOS fanout transistor. 

D_Code 2 Static Partial-Swing Detection (PMOS) 


Definition: Node is driven by NMOS transistors only, and it drives at least one 

PMOS fanout transistor. 

D_Code 3 Static VDD Path Problem 


Definition: No possible conducting path to VDD. 

D_Code 4 Static GND Path Problem 


Definition: No possible conducting path to GND. 

D_Code 5 Static DC Path to VDD 

Syntax: 0 8 5 () () ... () 

Definition: A static DC conducting path from to VDD detected. The 

path consists of elements ... and nodes , , ..., , 

and Vdd. 

D_Code 6 Static DC Path to GND 

Syntax: 0 8 6 () () ... () 

Definition: A static DC conducting path from to GND detected. The 

path consists of elements ... and nodes , , ..., , 

and Gnd. 

D_Code 7 Static DC Leakage Path between two power supply nodes 




Syntax: 0 8 7 () () ... ) () 

 

Definition: A static conducting path exists between supply nodes and 

of different voltages. The path consists of nodes through , 

and branches through . 

D_Code 8 Node Stuck at Logic 1 at All Times 

Syntax:0 8 8 () () ... () 

Definition: A static DC conducting path from to Vdd and no possible 

conducting path to Gnd. 

D_Code 9 Node Stuck at Logic 0 at All Times 

Syntax: 0 8 9 () () ... () 

Definition: A static DC conducting path from to Gnd and no possible 

conducting path to Vdd. 

D_Code 10 Static Excessive-Rise/Fall Time Problem 

Syntax: 0 8 10 

Definition: Node with an excessive rise/fall time "est_rf_time" by static estimation. 

D_Code 11 Static Excessive-Rise/Fall Time Problem 

Syntax: 8 11 

Definition: Node with an excessive rise/fall time by dynamic simulation. time_start 

and time_end are the times when node enters and exits the U-state, respectively. 

D_Code 12 Dynamic Floating Node (Hi-Z) Problem 

Syntax: 8 12 

Definition: Node staying at a floating state (L, H, Z) too long. time_start and 

time_end are the times when node enters the high impedance state. The 

is an internal state number for state (L, H, Z). 

D_Code 13 Excessive Branch Current


Syntax: 8 13 


Definition: Excessive branch current detected for from 

to . The average current between and 

is . 

D_Code 14 Partial off PMOS 

Syntax: 8 14 () ... () 

||| () ... () ||| () ... () 

Definition: A PMOS transistor has a possible channel-connect path 

to power supply , and its gate terminal has a possible path to another power 

supply node where the voltage of vddl is less than vddh. It is possible that 

will not turn off when its gate terminal is driven to logic 1, 

resulting in a dc leakage path between and the voltage source . 

D_Code 15 Partial off NMOS 

Syntax: 8 15 () ... () 

||| () ... () ||| () ... () 

 

Definition: A NMOS transistor has a possible channel-connect path 

to power supply , and its gate terminal has a possible path to another power 

supply node where the voltage of gndl is less than gndh. It is possible that 

will not turn off when its gate terminal is driven to logic 0, 

resulting in a dc leakage path between and the voltage source . 

D_Code 16 Forward bias PMOS 

Syntax: 8 16 () ... () 

||| 

Definition: A PMOS transistor has a possible channel-connect path 

to power supply , and its bulk terminal is connected to another power supply 

node where the voltage of vddl is less than vddh. It is possible to have a 

forward biased pn junction between the P-diffusion and the N-substrate, resulting 

in a dc leakage path between and . 

D_Code 17 Forward bias NMOS 




Syntax: 8 17 () ... () 

||| 

Definition: An NMOS transistor has a possible channel-connect 

path to power supply , and its bulk terminal is connected to another power 

supply node where the voltage of gndl is less than gndh. It is possible to 

have a forward biased pn junction between the N-diffusion and the P-substrate, 

resulting in a dc leakage path between and . 

D_Code 18 Instaneous Current/Power Exceeds Budget 

Syntax: 8 18 

Definition:The instaneous current/power for the report_block_power created probe 

has exceeded its current/power budget at . 

D_Code 19 Instaneous Current/Power Exceeds Budget at Least Once 

Syntax: 8 19 

The instantaneous current/power for the report_block_power created probe 

has exceeded its current/power budget of at least 

once during the dynamic simulation. The peak current observed was . 

D_Code 20 Average Current/Power Exceeds Budget 

Syntax: 8 20 

The average current/power for the report_block_power created probe 

exceeds its current/power budget of . 

D_Code 21 RMS Current/Power Exceeds Budget 

Syntax: 8 21 

The RMS current/power for the report_block_power created probe 

exceeds its current/power budget of . 

D_Code 22 Wasted Current Percentage Exceeds Budget 

Syntax: 8 21 

The wasted current percentage for the report_block_power created 

probe exceeds its budget of .

Type 9: Multiple-toggle Error 


This set of D-codes displays field names, as shown in the 

following table. 

Field Name Data Type 

string 

float 

est_rf_time float 

string 

string 

Integer number as .out to represent 

L|H|X state 

float 

float 

string 

D_Code 1 Node toggle more than once in a user-specified period of time 




5 float Last time node changed state 



Type 10: Multiple-pulse Error 

D_Code 1 Node has more than one pulse in a user-specified period of time. 




5 float Time the last pulse started 

6 int Pulse state (0: low; 1: high) 

7 float Period 

8 string Hierarchical name of the pulse detection element 

or configuration file name if the pulse detection 

is specified in a configuration file 


D_Code 2 Node has more than one pulse within the pulse of the reference 

node. 




5 float Time the last pulse started 



8 float Time the reference pulse started 

9 int Reference pulse state 0: low; 1: high) 



is specified in a configuration file



D_Code 3 Node has a single pulse inside the pulse of the reference node. 




5 float Time the single pulse started 




9 int Reference pulse state (0: low; 1: high) 





D_Code 4 Node doesn’t have a pulse inside the pulse of the reference node. 




5 float Time the reference pulse ended 




9 int Reference pulse state (0: low; 1: high) 







D_Code 5 Node has more than one pulse in a user-specified period of time. 



1 float Time when the multiple-pulse error is detected. 

It is also the time when the current period ends. 

2 int Error type code (10) 

3 int Error description code (5)) 


5 int Pulse state of the node (0: low; 1: high) 

6 float Time the current period started 





D_Code 6 Node has exactly one pulse in a user-specified period of time. 



1 float Time when the single-pulse error is detected 



3 int Error description code (6) 

4 string Node name








D_Code 7 Node does not have any pulse in a user-specified period of time. 



1 float Time when the no-pulse error is detected 



3 int Error description code (6) 









.err File Sample 

;! error_format 5.2 

; -------------------------------------------------------- 

;| | 

;| TimeMill Version 5.4 

;| SN: P042498-SunOS_5 | 


;| | 

; -------------------------------------------------------- 

; 

;Built by hmchen in " sun50504 " on Mon May 4 20:51:51 PDT 1998 

; Wed May 6 17:36:46 2000 

; 

;This is a comment 

11.00 1 1 1 0 n1 ;comparison error 

12.00 1 2 1 H n3 ;comparison error 

12.00 1 4 1 T n5 ;comparison error 



14.00 1 7 3 ? n6 ;comparison error 

30.00 2 1 n1 1 30.7 n2 0 30.8 0.1 Min 10-cfg ;setup violation 

30.00 6 1 n1 1 30.7 n2 0 30.8 0.1 Min 10 0.1 ;setup violation warning 

45.00 2 2 n3 0 40.7 n4 1 60.8 20.1 Max 10-cfg ;hold violation 

100.00 2 3 n2 0 40.7 n4 1 60.8 20.1 Max 10-cfg ;edge to edge 

145.00 2 4 n3 0 40.7 1 45.7 5.0 min 10 ;pulse violation 

150.00 3 1 n1 ;bus contention 

200.00 4 1 n2 202.00 4 ;high impedance condition 

200.00 5 1 n2 200.2 2 ;Unknown state 

;end 

; Total number of errors in this file: 14 

Figure 2 Sample .err file output

The Viewerror Utility 


The Viewerror Utility 349 

You use the Viewerror utility to view the output error file in 

several ways and generate multiple error reports. This utility 

can sort errors by the time or type associated with a node. You 

can also separate comparison errors from timing check errors. 

SYNTAX: 


viewerror [-i filename] 

[-m number_of_messages] 

[-n nodenames] 

[-o filename] 

[-p type] 

[-s] 

[-t t1 t2 ... tx,ty] 

The viewerror command line options are: 

-i filename 

This specifies the input file, for example, timemill.err. If 

you do not specify the filename, the program will search for 

timemill.err first, then powrmill.err. 

-m number_of_messages 

The number of error messages to print. The default number 

is 1000. This option can take up to 50 arguments. 

-n nodenames 

Prints all error messages associated with the given nodes. 

Signals with square brackets ([ ]) must be enclosed in 

quotation marks (“ ”). Buses (single or bit grouped) must 

also be enclosed in quotation marks. This option can take 

up to 50 arguments. 



-o filename 

Specifies the output file. The default is stdout. 

-p type 

Prints all the error messages with the given type, where 

type is an integer number of 1 through 10. When used with 

-n, it prints out all the error messages of the given type for 

the nodes specified in -n. The following list shows the 10 

different types of error messages. 

1 comparison error 

2 timing error 

3 bus contention error 

4 high impedance error 

5 uncertain state condition 

6 timing error with timing tolerance margin 

7 block delay characterization error 

8 power diagnosis 

9 multiple toggle error 

10 multiple pulse error 

-s Sorts error messages by error type. If not specified, the 

error messages are sorted by time. 

-t t1 t2 tx,ty 

Prints all error messages for a given simulation time or 

time range. Only one time range can be specified. 

Individual times must be separated by a space, and the 

time range separated by a comma. This option can take up 

to 50 arguments. 

EXAMPLE: 

-t time1 time2 timex,timey 

This example syntax prints all the errors between timex 

and timey, plus any errors at times time1 and time2. You 

can use this option together with -p and -n to print specific 

types of errors for specific nodes at given times.

Appendix D 

SPICE-independent 

Voltage Source Syntax 

This appendix provides the syntax and explanations of the 

SPICE-independent voltage sources supported by PowerMill, 

TimeMill and AMPS. 

SYNTAX: 

Vxxx n+ n- voltage_source_type parameters 

The voltage source types are: 

■ AM 

■ EXP 

■ PULSE, PU 

■ PWL 

■ SFFM 

■ SIN 

The syntax for these voltage source types is found on the 

following pages.

352 SPICE-independent Voltage Source Syntax 

AM 

SYNTAX: 

AM (sa oc fm fc td) 

EXAMPLE: 

v1 1 0 AM(10 1 100 1K 1M) 

DESCRIPTION: 


sa Signal amplitude. Default is 0.0. 

oc Offset constant. Default is 0.0. 

fm Modulation frequency. Default is 0.0. 

fc Carrier frequency. Default is 0.0. 

td Delay time. Default is 0.0

EXP 

SYNTAX: 

EXP [(]v1 v2 [td1 [τ1 [td2 [τ2]]]] [)] 

353 

EXAMPLE: 

VIN 3 0 EXP (-4 -1 2NS 30NS 60NS 40NS) 

This example describes an exponential transient source that is 

connected between nodes 3 and 0. It has an initial t=0 voltage of 

-4 V and a final voltage of -1 V. The waveform rises 

exponentially from -4 Vto-1 V with a time constant of 30 ns. At 

60 ns it starts dropping to -4 V again, with a time constant of 40 

ns. 

DESCRIPTION: 


v1 Initial value of voltage in volts. 

v2 Pulsed value of voltage in volts. 

td1 Rise delay time in seconds. Default is 0.0. 

td2 Fall delay time in seconds. Default is 0.0. 

τ1 

τ2 

Rise time constant in seconds. Default is 0.0. 

Fall time constant in seconds. Default is 0.0. 



PULSE 

PU 

SYNTAX: 

PULSE [([v1 v2 [td [tr [tf [pw [per]]]]] [)] 

PU [([v1 v2 [td [tr [tf [pw [per]]]]] [)] 

EXAMPLE: 

VIN 3 0 PULSE (-1 1 1NS 2NS 3NS 50NS 100NS) 

This example specifies a pulse source connected between node 3 

and node 0. The pulse has an output high voltage of 1 V, an 

output low voltage of -1 V, a delay of 1ns, a rise time of 2 and a 

fall of 3ns, a high pulse width of 50 ns, and a period of 100 ns. 

DESCRIPTION: 

This function is a trapezoidal pulse source function that starts 

with an initial delay from the beginning of the transient 

simulation interval to an onset ramp. During the onset ramp, the 

voltage or current changes linearly from its initial value to the 

pulse plateau value. After the pulse plateau, the voltage moves 

linearly along a recovery ramp, back to its initial value. The 

entire pulse repeats with a period per from onset to onset. 


v1 Initial value of the voltage before the pulse 

onset. 

v2 Pulse plateau value. 

td Delay time in seconds from the beginning of 

transient interval to the first onset ramp. 

Default is 0.0. 

tr Duration of the onset ramp, from the initial 

value to the pulse plateau value (reverse 

transit time). Default is 0.0. 

tf Duration of the recovery ramp, from the pulse 

plateau back to the initial value (forward 

transit time). Default is 0.0.


pw Pulse width (the width of the pulse plateau 

portion of the pulse). Default is 0.0. 

per Pulse repetition period in seconds. Default is 

0.0. 

V 2 

V 1 

0 ns 

t d 

pw 

t r tf 

Period 

Figure 3 Sample pulse waveform 

time 

355 



PWL 

PL 

SYNTAX: 

PWL [(] t1 v1 [t2 v2 t3 v3...] [r [=repeat]] [TD=delay] [)] 

PL [(] v1 t1 [v2 t2 v3 t3...] [r [=repeat]] [TD=delay] [)] 

EXAMPLE: 

V1 1 0 PWL 60N 0V, 120N, 130N 5V, 170N 5V, 180N 0V, 

R0N R1 1 0 1 

DESCRIPTION: 


v1 . . . Voltage values. 

t1 . . . Segment time values. 

r Causes the function to repeat. 

repeat Specifies the start point of the waveform which 

is to be repeated. 

delay Specifies the length of time to delay the 

piecewise linear function.

SFFM 

SYNTAX: 

SFFM [(] vo va [fc [mdi [fs]]] [)] 

EXAMPLE: 

V 1 0 SFFM (0, 1M, 20K. 10, 5K) 

DESCRIPTION: 


vo Output voltage in volts. 

va Output voltage in volts. 

fc Carrier frequency in Hz. Default is 0.0. 

mdi Modulation index. Default is 0.0. 

fs Signal frequency in Hz. Default is 0.0. 

357 



SIN 

SYNTAX: 

SIN [(] vo va [freq [td [θ[ϕ]]]] [)] 

EXAMPLE: 

VIN 3 0 SIN (0 1 100MEG 1NS 1e10) 

This example specifies a damped sinusoidal source connected 

between nodes 3 and 0. The waveform has a peak value of 1V, an 

offset of 0V, a 100 MHz frequency, a time delay of 1 ns, a 

damping factor of 1e10, and a phase delay of zero degrees. 

DESCRIPTION: 

This HSPICE function is a damped sinusoidal source that is the 

product of a dying exponential with a sine wave. Application of 

this waveform requires the specification of the sine wave 

frequency, the exponential decay constant, the beginning phase, 

and the beginning time of the waveform. 


vo Voltage in volts. 

va Voltage amplitude in volts. 

freq Frequency in Hz. Default is 0.0. 

td Delay in seconds. Default is 0.0. 

θ Damping factor in 1/seconds. Default is 0.0. 

ϕ Phase delay in degrees. Default is 0.0.

Symbols 

!append 275, 276 

%corner 195 

%diode 198 

%invoke 195 

%lib 158, 212 

%model 159 

%options 197 

%parameters 160 

*.err file 331 

*epic_tech command 141 

.act file 324 

.log file 330 

.measure statements 55 

.nact file 326 

.nodealias file 328 

.OPTIONS 197 

.out file 311 

Numerics 

3dtable command 149 

EPIC Tools Reference Guide 

Index 

A 

acm parameter command 168 

alias command 102 

alias file 99, 101 

attribute identifiers 10 

B 

batchfile 

batchrun command 259 

DATA command 262 

FILE command 261 

format 261 

RUN command 262 

binary command 142 

binary parameter command 162, 194 

body_bias command 143 

body_bias parameter command 160, 174 

BSIM1 139 

BSIM3 139 

bus_notation 46

360 Index 

C 

capacitance, minimum 110 

capacitor 55 

floating 111 

minimum value 56 

value, scaling 65 

case 47 

case parameter command 162, 191 

cell library path 52 

cg parameter command 161, 183 

cgbo parameter command 162, 188 

cgdo parameter command 162, 188 

cgso parameter command 162, 188 

circuit elements 

BJT 17 

capacitor 14 

CMOS transistor 21 

diode 18 

floating capacitor 15 

gate-level 37 

inductor 16 

net 35 

resistor 27 

subciruit 33 

voltage controlled voltage sources 32 

voltage source 27 

cja parameter command 161, 183 

cjgate parameter command 161, 182 

cjsw parameter command 161, 183 

clk 221 

clock stimulus 220, 221 

cnt 223 

counter stimulus 220, 223 

cov parameter command 161, 183 

cox parameter command 162, 188 

cspf_cap_select 47, 88 

cspf_disable_net 48 

cspf_name_map_proc 48 

cspf_net 49 

cspf_process_ccap 49 

customize.c file 300 

D 

D_codes description codes 333 

dangling node 330 

db_file 50, 99 

default file 99, 103 

delta_vt parameter command 162, 189 

device models 

BSIM1 139 

BSIM3 139 

MOS9 139 

device parameter file 

control option 97 

device parameter format file 96 

converting element names 51 

converting node names 51 

naming conventions 96 

diodes 103 

direct command 144 

dont_compress_db 50, 99 

dpf_name_map_proc 51, 97 

drain-to-source voltage 173 

ds_length parameter command 161, 176 

dynamic linked libraries, specifying 68 

E 

ecrypt utility 131 

edge-to-edge timing check 40 

EDIF netlist translator (edif2e) 118 

command syntax 120 

command-line options 120 

constructs 

supported 118 

unsupported 119 

design structure 121 

output, specifying from command line 52 

specifying from command line 51 

edif_out variable 123 

edif2e. See EDIF netlist translator 

edif2e_args 51 

edif2e_output_file 52

Edisplay utility 269 


control file 275 

syntax 269 

element identifiers 10 

encryption. See ecrypt utility 

EPIC binary file 50, 98 

control options 99 

file compression 50 

generation 50 

EPIC netlist 7 

attribute identifiers 10 

biput terminal (bt) 10 

biput value (bv) 11 

element name (en) 10 

input terminal (it) 10 

multiplier (m) 11 

node name (nn) 11 

number of states (st) 11 

optional (attr) 11 

output terminal (ot) 10 

output value (ov) 11 

state value (sv) 11 

buses 8 

circuit elements 14, 37 

element identifiers 10 

BJT (b) 10 

input signal (is) 10 

library function (ef) 10 

output signal (c) 10 

output signal (os) 10 

output signal (t) 10 

transistor-level subcircuit (ef) 10 

expressions 73 

functions 73 

global commands 42 

parameter passing 69 

syntax 7 

EPIC_CELL_LIB_PATH 81 

epic_cell_lib_path 52 

error limit, setting 60 

error messages 331 

error output file 331 

error_undefined_param 52 

Eview utility 276 




Edit menu 280 

File menu 279 

Options menu 283 

Search menu 281 

window layout 278 

F 

fall 244 

find_top_mod 53 

floating capacitor 111 

minimum value 57 

splitting 67 

floating nodes 53, 330 

floating_nodes_ok 53 

force_global_model 53 

G 

gate-to-source voltage 173 

Gentech utility 139, 153 




corner section 

temperature command 195 

voltage command 195 

diode models 198 

example 153 

invoke section 195 

lib section 158 

model section 159 

MOS models 159 

multiple-step mode 202 

parameter section command 

361 


362 Index 

acm 168 

binary 162, 194 

body_bias 160, 174 

case 162, 191 

cg 161, 183 

cgbo 162, 188 

cgdo 162, 188 

cgso 162, 188 

cja 161, 183 

cjgate 161, 182 

cjsw 161, 183 

cov 161, 183 

cox 162, 188 

delta_vt 162, 189 

ds_length 161, 176 

l_scale 160, 171 

ldiff 160, 169 

lmlt 160, 171 

mlt 160, 171 

model_alias 161, 175 

n_length 160, 164 

n_width 160, 164 

new_format 161, 181 

nl 160, 164 

no_nrd_nrs 161, 179 

nrd_nrs_caps 161, 180 

nw 160, 164 

p_length 160, 164 

p_width 160, 164 

pl 160, 164 

pn_ratio 160, 167 

pw 160, 164 

rsh 161, 178 

speed 162, 193 

tox 162, 188 

unit_adas 192 

unit_pdps 162, 192 

unit_wl 162, 192 

vds 160, 173 

vgs 160, 173 

vto 162, 190 

w_scale 160, 171 

wd 162 

wdiff 160, 169 

wl_scale 160, 171 

wmlt 160, 171 

single-step mode 201 

SPICE model files 158 

SPICE options 197 

starting SPICE 195 

gentech_parameter command 145 

global commands 

global nodes 42 

ground 44 

param 43 

parameters 43 

pgalias 44 

power 44 

global nodes 42, 53 

global_override_port 53 

H 

hier_separator 54 

hierarchical information, printing 62 

hierarchical separators 54 

high 240 

HOLD timing check 39 

HSPICE netlist syntax 83 

I 

ignore_excess_pin 54 

ignore_meas 54 

include statement 76 

inductors, minimum value 57 

initial condition, specifying 74 

internal calculations, customizing 302 

invoke command 146 

io 241

J 

junction diodes 56 

K 

keep_0v_dcvs 55 

keep_distinct_cap 55 

keep_junc_diode 20, 55 

keep_unc_node 56 

L 

l_scale parameter command 160, 171 

lateral diffusion 200 

ldiff parameter command 160, 169 

lmlt parameter command 160, 171 

logic constants 220, 228, 233, 238 

low 240 

lratio command 147 

LSIM netlist 82 

M 

max_res_value 56 

maximum resistance, specifying 56 

Meas utility 267 

message limit, setting 66 

min_cap_value 56 

min_fcap_value 57 

min_ind_value 57 

min_res_value 57 

mlt parameter command 160, 171 

model file 99 

model_alias parameter command 161, 175 

MOS devices 103 

SPICE 103 

MOS9 139 

multiple VDD and GND nodes 102 

N 

n_length parameter command 160, 164 

n_width parameter command 160, 164 

net flattening hierarchy 59 

netlist control options 45 

bus_notation 46 

case 47 

case specification 47 

cspf_cap_select 47, 88 

cspf_disable_net 48 

cspf_name_map_proc 48 

cspf_net 49 

cspf_process_ccap 49 

db_file 50 

dont_compress_db 50 

dpf_name_map_proc 51 

edif2e_args 51 

edif2e_output_file 52 

epic_cell_lib_path 52 

error_undefined_param 52 

find_top_mod 53 

floating_nodes_ok 53 

force_global_model 53 

global_override_port 53 

hier_separator 54 

ignore_excess_pin 54 

ignore_meas 54 

keep_0v_dcvs 55 

keep_distinct_cap 55 

keep_junc_diode 20, 55 

keep_unc_node 56 

max_res_value 56 

min_cap_value 56 

min_fcap_value 57 

min_ind_value 57 

min_res_value 57 

netlist_suffix 58 

nf_expand_inst 58 

nf_flatten_ins 59 

param_passing_rule 59 

parse_error_limit 60 

363 


364 Index 

prefer_model 60 

prefer_model_inst 61 

prefer_model_port_map 60 

prefer_model_port_map_inst 61 

rcr 62 

rcr_preserve_name 63 

report_missing_subckt 64 

report_unused_port 64 

scale_cap 64 

scale_cmos_length 65 

scale_cmos_width 65 

scale_res 65 

set_message_limit 66 

split_floating_cap 66 

syntax 46 

top_module 67 

user_lib 67 

vlog2e_args 68 

vlog2e_output_file 69 

netlist formats, supported 79 

netlist library 81 

netlist suffix 58 

netlist_suffix 58 

netlists 

filename extensions 80 

formats 80 

new_format parameter command 161, 181 

nf_expand_inst 58 

nf_flatten_inst 59 

nl parameter command 160, 164 

no_nrd_nrs parameter command 161, 179 

nodes 

dangling 330 

floating 330 

unconnected 56 

nrd_nrs_caps parameter command 161, 180 

nsvt 226 

nw parameter command 160, 164 

O 

one 228 

out 242 

output file 

active nodes 324 

current 311 

errors 331 

inactive nodes 326 

logic states 311 

node alias names 328 

voltage 311 

warning messages 330 

output file (.act) 324 

format 324 

sample file 325 

output file (.err) 331 

block delay characterization errors 338 

bus contention errrors 336 

comparison errors 333 

high impedance condition 337 

multiple-pulse errors 344 

multiple-toggle errors 343 

power diagnosis 339 


unknown state 337 

output file (.log) 330 

output file (.nact) 326 

format 326 


output file (.nodealias) 328 

format 328 


output file (.out) 

format 311 

keywords 313 

line format 312 

logic state numbers 317 

period lines 312, 313 

PowerMill sample file 320 

signal attributes 316 

TimeMill sample file 318 

output_resistance 242

P 

p_length parameter command 160, 164 

p_width parameter command 160, 164 

param_passing_rule 59 

parameter passing 43, 60, 69 

HSPICE 71 

HSPICE convention 69 

parameters 

defining 70 

undefined 52 

parse_error_limit 60 

pattern stimulus 220, 229 

period 243 

pins, excess 54 

pl parameter command 160, 164 

PMOS channel widths 167 

pn_ratio parameter command 160, 167 

port mapping 

name-based 12–13 

position-based 12–13 

ports, reporting 64 

power nodes 111 

prefer_model 60 

prefer_model_inst 61 

prefer_model_port_map 60 

prefer_model_port_map_inst 61 

ptn 229 

pulse width timing check 41 

pw parameter command 160, 164 

PWL mode 75 

R 

radix 243 

RC reduction 62 

preserving nodes 63 

rcr 62 

rcr_preserve_name 63 

report_missing_subckt 64 

report_unused_port 64 

resistance value, minimum 112 

resistance, scale factor 65 

resistor, minimum resistance 57 

rise 244 

rsh parameter command 161, 178 

runscript 

simulation 

runscript 152 

S 

scale factors, MOS devices 

length 65 

width 65 

scale_cap 64 

scale_cmos_length 65 

scale_cmos_width 65 

scale_res 65 

sense pair, specifying 76 

separate power reporting 102 

set_message_limit 66 

signal 244 

simulation 

running 152 

SimWave 286 

slope 244 

source-to-drain checking 92 

speed command 148 

speed parameter command 162, 193 

SPF file 

back-annotation 47, 48 

correcting mismatches 49 

coupling capacitors 49 

parasitic information 49 

SPF netlist 

control options 

name mapping 89 

net specification 90 

process coupling capacitors 91 

discard net 87 

limitations 92 

SPICE models 53 

SPICE netlist 82 

365 


366 Index 

.options statements 46 

characteristics 82 

syntax 46 

SPICE netlist translator (spice2e) 

alias file 99 

configuration file, generated by 102 

default file 99, 103 

ignored syntax 115 

model file 99 

spice2e.log file 115 

supported syntax 114 

syntax 109 

syntax to avoid 116 

spice2e. See SPICE netlist translator 

split_floating_cap 66 

stimulus functions 219 

clk 221 

cnt 223 

one 228 

ptn 229 

tgl 231 

udf 233 

vec 234, 236 

vec_chk 236 

zero 238 

subcircuit definition 53 

locating 64 

names 60 

substrate 

terminal 112 

terminal bias 117 

subthreshold currents 189 

T 

T_Code description codes 332 

technology files 140 

*epic_tech command 141 

automatic generation 140 

3dtable command 149 

binary command 142 

body_bias command 143 

direct command 144 

gentech_parameter command 145 

invoke command 146 

lratio command 147 

modifying netlists 141 

running a simulation 152 

speed command 148 

vds command 150 

vgs command 150 


wratio command 147 


runscript 152 

TechViewer utility 139, 209 

tgl 231 

time_scale 245 

timing checks 

edge-to-edge 40 

HOLD 38 

pulse width 41 

SETUP 37 

toggle stimulus 220, 231 

top module, specifying 67 

top_module 67 

tox parameter command 162, 188 

turboWave 286 

tutorials 

basic PowerMill simulation 133 

type 245 

U 

udf 233 

unit_adas parameter command 192 

unit_pdps parameter command 162, 192 

unit_wl parameter command 162, 192 

unused ports, reporting 64 

user_lib 67

V 

Vcd2e utility 

batch mode 298 


File menu 291 

signal file 294 

strobes 298 

syntax 288 

vds command 150 

vds parameter command 160, 173 

vec 234 

vec_chk 236 

vector file commands 

fall 244 

high 240 

io 241 

low 240 

out 242 

output_resistance 242 

period 243 

radix 243 

rise 244 

signal 244 

slope 244 

time_scale 245 

type 245 

vector stimulus 220, 234, 236 

vector translation utility. See Vcd2e utility 

Verilog netlist translator (vlog2e) 


specifying from command line 68 

syntax 129 

Veritech utility 

conventions 214 

vgs command 150 

vgs parameter command 160, 173 

Viewerror utility 349 


syntax 349 

vlog2e. See Verilog netlist translator 

vlog2e_args 68 

vlog2e_output_file 69 


vto parameter command 162, 190 

W 

w_scale parameter command 160, 171 

warning messages 330 

waveform display utilities 285 

wd parameter command 162 

wdiff parameter command 160, 169 

wire capacitance estimate 302 

wl_scale parameter command 160, 171 

wmlt parameter command 160, 171 

wratio command 147 

Z 

zero 238 

zero volt voltage source 55 

367 


368 Index

EPIC Tools Reference Guide

Create successful ePaper yourself

Delete template?

Save as template?