picture.iczhiku.com · 2019. 11. 28. · iii Contents Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi Related

NanoSim® User GuideVersion B-2008.09, September 2008

NanoSim® User Guide iB-2008.09

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

Right to Copy DocumentationThe license agreement with Synopsys permits licensee to make copies of the documentation for its internal use only. Each copy shall include all copyrights, trademarks, service marks, and proprietary rights notices, if any. Licensee must assign sequential numbers to all copies. These copies shall contain the following legend on the cover page:

“This document is duplicated with the permission of Synopsys, Inc., for the exclusive use of __________________________________________ and its employees. This is copy number __________.”

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

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

Registered Trademarks (®)Synopsys, AMPS, Astro, Cadabra, CATS, Design Compiler, DesignWare, Formality, HSPICE, iN-Phase, Leda, MAST, ModelTools, NanoSim, OpenVera, PathMill, Physical Compiler, PrimeTime, SiVL, SNUG, SolvNet, TetraMAX, VCS, Vera, and YIELDirector are registered trademarks of Synopsys, Inc.

Trademarks (™)AFGen, Apollo, Astro-Rail, Astro-Xtalk, Aurora, AvanWaves, Columbia, Columbia-CE, Cosmos, CosmosLE, CosmosScope, CRITIC, DC Expert, DC Professional, DC Ultra, Design Analyzer, DesignPower, Design Vision, DesignerHDL, Direct Silicon Access, Discovery, Eclypse, Encore, EPIC, Galaxy, HANEX, HDL Compiler, Hercules, Hierarchical Optimization Technology, HSIM, HSIMplus, in-Sync, iN-Tandem, i-Virtual Stepper, Jupiter, Jupiter-DP, JupiterXT, JupiterXT-ASIC, Liberty, Libra-Passport, Library Compiler, Magellan, Mars, Mars-Rail, Mars-Xtalk, Milkyway, ModelSource, Module Compiler, Planet, Planet-PL, Polaris, Power Compiler, Raphael, Saturn, Scirocco, Scirocco-i, Star-RCXT, Star-SimXT, System Compiler, Taurus, TSUPREM-4, VCS Express, VCSi, VHDL Compiler, VirSim, and VMC are trademarks of Synopsys, Inc.

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

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

Printed in the U.S.A.

NanoSim® User Guide, B-2008.09

ii NanoSim® User GuideB-2008.09

Contents

Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi

Related Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi

Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxii

Customer Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxii

Part I: Using the NanoSim GUI Workbench

1. Getting Started with the NanoSim GUI Workbench . . . . . . . . . . . . . . . . . . 3

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

Comparing the Command-line and the GUI Workbench . . . . . . . . . . . . . . . . . 3

Running a Demo Comparing the Command-line and the Workbench . . . 4

Organizing a NanoSim Command-line Session . . . . . . . . . . . . . . . . . . . 4

Organizing the NanoSim Workbench. . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Exploring the NanoSim Workbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Running a Demo Illustrating the Major Components of the Workbench . 6

Describing the Workbench Main Window . . . . . . . . . . . . . . . . . . . . . . . . 6

Displaying the Design Hierarchy—Hierarchy Explorer . . . . . . . . . . . . . . . 9

Viewing Usage Reports—Power Reports Window . . . . . . . . . . . . . . . . . 10

Getting Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Using the Workbench Icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Running a Demo Illustrating the Icons in Context . . . . . . . . . . . . . . . . . . 13

Setting the NanoSim GUI Default Preferences . . . . . . . . . . . . . . . . . . . . . . . . 14

Running a Demo Illustrating the NanoSim GUI-Preferences Setup. . . . . 14

NanoSim GUI Preference Default Categories . . . . . . . . . . . . . . . . . . . . . 14

General Category Defaults. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Netlist & Stimulus Category Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Simulation Setup Category Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Simulation Category Defaults. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Using Configuration Commands With and Without the Workbench . . . . . . . . 22

Encrypted Netlist and Model Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

iii

Contents

2. Running Basic GUI Simulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Starting the NanoSim Workbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Running a Demo Illustrating a Basic Workbench Session . . . . . . . . . . . . 24

Identifying Your Design Name and Simulation Type . . . . . . . . . . . . . . . . . . . . 24

File Browsing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Simulation Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Simulation Flow in the GUI Workbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Netlist & Stimulus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

AMS Setup (NanoSim-VCS only). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Simulation Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Running a Simulation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Viewing Your Run Script. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Viewing the Waveforms for Your Simulation. . . . . . . . . . . . . . . . . . . . . . . 33

Using Timing Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Running a Demo Illustrating Timing Diagnostics . . . . . . . . . . . . . . . . . . . 34

Using Power Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Running a Demo Illustrating Power Diagnostics . . . . . . . . . . . . . . . . . . . 35

Editing Netlist and Configuration Files within the Workbench . . . . . . . . . . . . . 35

Editing Netlist Files with the Default Editor . . . . . . . . . . . . . . . . . . . . . . . 35

Editing Configuration Files from the Manual Cmds Panel . . . . . . . . . . . . 35

Running a Demo Illustrating Netlist and Configuration File Editing . . . . . 36

Viewing Waveforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Running Demos Displaying Waveforms . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3. Running Advanced GUI Simulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Setting Up a Simulation for Discovery AMS: NanoSim-VCS . . . . . . . . . . . . . . 39

Running a Demo Using NanoSim-VCS . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Setting Up a Simulation to Use Hierarchical Array Reduction . . . . . . . . . . . . . 40

Running a Demo Using NanoSim with Hierarchical Array Reduction . . . 41

Running HAR from the NanoSim Workbench . . . . . . . . . . . . . . . . . . . . . 41HAR-Specific Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

iv

Contents

Setting Up Advanced Analog Simulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Running a Demo of Setting Up and Running an Advanced Analog Simulation 43

Using Remote Simulation Control (LSF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Setting the Workbench to Run Simulations Remotely by Default . . . . . . 43

Turning Remote Simulation On or Off Dynamically . . . . . . . . . . . . . . . . . 43

Running a Demo Setting up Remote Simulation Control . . . . . . . . . . . . . 44

Using ADFMI Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Running a Basic Demo Using ADFMI Models . . . . . . . . . . . . . . . . . . . . . 44

Using an ADFMI Model in Place of a Transistor-level Block. . . . . . . . . . . 45

Running a Demo Using an ADFMI Model in Place of a Transistor-level Block 46

Using Interactive Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Running a Demo Using Interactive Mode . . . . . . . . . . . . . . . . . . . . . . . . 46

Activating and Deactivating Interactive Mode . . . . . . . . . . . . . . . . . . . . . 46

Debugging in Interactive Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Part II: Controlling the Simulator

4. Getting Started at the Command-line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Invoking NanoSim at the Command-line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Using the NanoSim Unified CSHRC File . . . . . . . . . . . . . . . . . . . . . . . . . 53

Viewing the nanosim Man Page. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Choosing Between Batch Mode or Interactive Mode . . . . . . . . . . . . . . . . 53

Defining Parameters in the Environment File. . . . . . . . . . . . . . . . . . . . . . 54

Tailoring your Analysis with the Command-line Options . . . . . . . . . . . . . . . . . 54

Describing a Circuit with a Netlist File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Using HSPICE/SPICE Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Using Other Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Performing a Simulation Using a Configuration File . . . . . . . . . . . . . . . . . . . . 65

Configuration File Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Describing Basic Configuration Commands . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Describing Key Features with a Technology File . . . . . . . . . . . . . . . . . . . . . . . 69

Using Stimulus Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Creating the Environment File (.epicrc) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

v

Contents

Using NanoSim Command-line Options in .epicrc . . . . . . . . . . . . . . . . . . 70

Sample .epicrc File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Running a Basic Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Understanding Simulation Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Describing Return Codes After Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

5. Using Configuration and Interactive Commands . . . . . . . . . . . . . . . . . . . . 75

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76Configuration File Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

Describing the Interactive Mode Using the help Command . . . . . . . . . . . 77Finding Alias Command Information using the help Command . . . 78

Finding Index Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Specifying Command Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Argument Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79Unit Prefixes and Symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80Specifying a Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Changing the Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

Reducing Ambiguity with Argument Tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Controlling Conventions for Simulation Parameters. . . . . . . . . . . . . . . . . . . . . 83

Reporting Conventions for Node and Branch Currents . . . . . . . . . . . . . . . . . . 84

Mapping Element Branch Currents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

Reporting Node Currents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

Categorizing the Configuration Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Circuit Diagnosis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90Functional Detection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 Vector Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Circuit Modification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92MOSFETs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92Circuit State Modification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93Miscellaneous Circuit Modifications . . . . . . . . . . . . . . . . . . . . . . . . . 93

DC Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

Hierarchical Array Reduction (HAR). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

Message Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

Netlist Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

Circuit Applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

vi

Contents

Output Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95General Output Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96Current Reporting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

Partitioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97Cut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97Autodetection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

Simulation Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98Accuracy and Speed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99Device Modeling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99Behavioral Modeling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100Simulation Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100Unit Delay. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101Powernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101Simulation Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101Vector Stimulus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

Timing Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

BDC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

Back-annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

Categorizing the Interactive Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

Analysis and Trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

Circuit Modification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

Execution Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

Interactive Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

Simulation Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

Simulation Diagnostic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

Defining the Man Page Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

6. Applying Simulation Control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Controlling Accuracy and Performance Using the set_sim_eou Command . . 109

Using the sim and model Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110Assigning Values to the sim and model Options . . . . . . . . . . . . . . . 110Using the net Option. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112Applying set_sim_eou Globally and Locally . . . . . . . . . . . . . . . . . . . 113Command Option Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

Using a Single Command for Leakage Current Simulation . . . . . . . . . . . . . . . 119

Command Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

vii

Contents

Applying set_sim_leak Locally and Globally . . . . . . . . . . . . . . . . . . . . . . 120

Precedence Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120Single Commands Conflicting with set_sim_leak. . . . . . . . . . . . . . . 121Conflicting Usage of set_sim_leak and set_sim_eou. . . . . . . . . . . . 121

Usage Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

Creating a Balanced Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

Applying Multiple Autodetection Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . 124

Applying Multiple Time Steps (Multi-Rate Simulations) . . . . . . . . . . . . . . 125

Controlling Node Sensitivity and Time Step. . . . . . . . . . . . . . . . . . . . . . . . . . . 125

Event sensitivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126Speed control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

Controlling Waveform Print Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

Applying Multiple Simulation Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

Activating Double-Precision Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

Controlling Voltage and Current Resolution . . . . . . . . . . . . . . . . . . . . . . . 128

Simulating BJTs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

Supporting BJTs During Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

Simulating BJTs—The Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

7. Using the VCD and EVCD Direct-read Features . . . . . . . . . . . . . . . . . . . . . 131

Topics in this Chapter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

VCD Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

EVCD Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

Default EVCD Port Direction Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

EVCD Port Direction Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

Using the Signal Information File for VCD and EVCD . . . . . . . . . . . . . . . . . . . 137

Defining Bus Syntax with the #format Command. . . . . . . . . . . . . . . . . . . 138

Defining Signal Directions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

Defining Mapping Information with the #alias Command. . . . . . . . . . . . . 142

Defining Attributes for Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143The #edge_shift Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144The #idelay and #odelay Commands . . . . . . . . . . . . . . . . . . . . . . . . 144The #outz Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144The #scale Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144The #trise, #tfall, and #slope Commands. . . . . . . . . . . . . . . . . . . . . 145The #triz Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145The #vih and #vil Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

viii

Contents

The #voh and #vol Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146The #scope Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

VCD File Sample . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

EVCD File Sample . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150

Signal Information File Sample . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

Overriding with the set_vec_opt Configuration Command. . . . . . . . . . . . . . . . 154

8. Using Hierarchical Array Reduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

Understanding HAR Concepts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

HAR Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156

Describing HAR Analysis Phases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156Setup Phase. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157Simulation Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158Reduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

Using HAR - The Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

Sample .log File Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

Using HAR - The Usage Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

Simulating Pre-layout Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

Adding the -har Command-line Option. . . . . . . . . . . . . . . . . . . . . . . . . . . 161

Adding the define_har_corecell Configuation Command. . . . . . . . . . . . . 162

Using Additional Config Commands (Optional) . . . . . . . . . . . . . . . . . . . . 163HAR Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

Simulating Post-layout Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

HAR Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

9. Using Power Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

Analyzing Power Consumption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

Analyzing Power at Full-Chip Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

Analyzing Power Block-by-Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

Measuring Wasted Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170Consuming Current . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171Using the report_block_powr Command . . . . . . . . . . . . . . . . . . . . . 171

Measuring True Power in Watts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

Measuring Power Hierarchically. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

ix

Contents

Assigning Power Budgets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

Retrieving Power Information Interactively . . . . . . . . . . . . . . . . . . . . . . . . 176

Controlling Power Reporting Resolution and Accuracy . . . . . . . . . . . . . . 178

Printing and Reporting Branch Currents . . . . . . . . . . . . . . . . . . . . . . . . . 179

Printing and Reporting Internal Node Currents . . . . . . . . . . . . . . . . . . . . 181

Working with Probes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

Printing Current Histograms and Tracking Windows . . . . . . . . . . . . . . . . 182

Performing a Dynamic Power Consumption Analysis . . . . . . . . . . . . . . . . . . . 184

Checking Dynamic Rise and Fall Times (U-State Nodes) . . . . . . . . . . . . 184

Detecting Dynamic Floating Nodes (Z-State Nodes) . . . . . . . . . . . . . . . . 184

Detecting Excessive Branch Currents . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

Analyzing Hot-Spot Node Currents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

Detecting Dynamic DC Paths. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187

Performing a Static Power Consumption Diagnosis. . . . . . . . . . . . . . . . . . . . . 189

Detecting Static DC Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190

Detecting Static Excessive Rise/Fall Time . . . . . . . . . . . . . . . . . . . . . . . 191

Analyzing Power Using the RC and UD Simulation Modes . . . . . . . . . . . . . . . 192

Dissipating Power. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

Running a Simulation in RC or UD Mode. . . . . . . . . . . . . . . . . . . . . . . . . 194

Using Power Diagnosis Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194

10. Post-Layout and Back-Annotation Simulation . . . . . . . . . . . . . . . . . . . . . . 197

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

Processing Parasitics During the Post-Layout Simulation . . . . . . . . . . . . . . . . 198

Using the NanoSim Standard Post-Layout Flow . . . . . . . . . . . . . . . . . . . . . . . 199

Choosing Either the Schematic-based or Layout-based Flow . . . . . . . . . 199Flow 1 (schematic-based) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199Flow 2 (layout-based) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200

Setting up the Post-layout Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202

Setting Up Hercules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202

Setting Up Star-RC XT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203

Back-annotating the Layout Device Properties . . . . . . . . . . . . . . . . . . . . . . . . 204

Generating Device Properties for Schematic-based Back-annotation . . . . . . . 205

Required NanoSim Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205

Invoking the Post-layout Flow with NanoSim . . . . . . . . . . . . . . . . . . . . . . 206

x

Contents

Back-annotating the Device Parameter File (required only in the schematic-basedflow) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206

Using Hierarchical Back-annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207

Reporting Back-annotation Warnings . . . . . . . . . . . . . . . . . . . . . . . . . . . 207

Default Settings for NanoSim Post-layout Simulation . . . . . . . . . . . . . . . . . . . 207

Skipping Parasitics for Powernets and Back-annotation Nets Connected toStimulus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208

Splitting the Coupling Capacitors in the SPF/SPEF File to Ground Capacitors 208

Log File Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208

NanoSim Selective Net Back-annotation Flow. . . . . . . . . . . . . . . . . . . . . . . . . 209

Setting up the Selective Net Back-annotation Flow . . . . . . . . . . . . . . . . . 210

Invoking the Selective Net Back-annotation Flow . . . . . . . . . . . . . . . . . . . . . . 211

Default Settings for the NanoSim Selective Net Back-annotation Flow . . 212

NanoSim Selective Net Extraction Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213

Setting up the Selective Net Extraction Flow . . . . . . . . . . . . . . . . . . . . . . 213

Generating Active Nets—First NanoSim Run . . . . . . . . . . . . . . . . . . . . . 213

Generating the Active Net File Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 214

Setting Up Hercules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214

Setting Up Star-RC XT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214

Required NanoSim Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215

Invoking the Post-layout Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215

Back-annotating the Device Parameter File . . . . . . . . . . . . . . . . . . . . . . . 216

Processing Capacitors in NanoSim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216

Integrating the Post-layout Flow with Other NanoSim Features. . . . . . . . . . . . 218

Integrating the Post-layout Flow with LNS RC Reduction . . . . . . . . . . . . 218

Integrating the Post-layout Flow with Powernet Simulation . . . . . . . . . . . 218

Integrating the Post-layout Flow with HAR . . . . . . . . . . . . . . . . . . . . . . . . 219

Optimizing Accuracy and Speed for Post-layout Simulation . . . . . . . . . . . . . . 219

Generating Accurate Results for Post-layout Simulation . . . . . . . . . . . . . 220

Improving Speed for Post-layout Simulation. . . . . . . . . . . . . . . . . . . . . . . 221

NanoSim Post-layout Flow Warning Messages . . . . . . . . . . . . . . . . . . . . . . . . 222

DPF Warning Messages: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224

SPEF Triplet Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225

Error Back-annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225

Star-RC XT commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225

xi

Contents

11. Simulating Power Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229

Static Extracted Power Net Simulations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229

Internal Supplies or Ramping Supplies Circuit Simulations. . . . . . . . . . . . . . . 230

Simulating Power Nets Efficiently . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230

Partitioning Circuits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230

Improving Power Net Simulations with the mode=5 Argument . . . . . . . . . . . . 232

Identifying the Power Net . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232

Reducing the Power Net . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232

Cutting Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233Command Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233

The Recommended mode=5 Usage Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 238

Using the mode=5 Argument with LNS . . . . . . . . . . . . . . . . . . . . . . . . . . 239

Back-annotation Flow Using the mode=5 Argument . . . . . . . . . . . . . . . . . . . . 240

12. Extracting Timing Information with the BDC Option . . . . . . . . . . . . . . . . . 241

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241

Characterizing Circuits with BDC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242

Running a Pre-characterization Run . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243

Listing of the BDC Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244

Viewing BDC Command Man Pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244

Measuring Delays with the meas_n2n_delay Command. . . . . . . . . . . . . . . . . 245

Defining Parts of the Causality Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245

Measuring Node Capacitance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246

Measuring Node Transition Times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246

Determining the Setup Measurement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246

Determining the Hold Measurement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248

Measuring the Minimum Pulse Width . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250

Command Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251

Configuration and Model File Samples . . . . . . . . . . . . . . . . . . . . . . . . . . 253

Using the Batch Run Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254

sdfcombine. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255

Running a Sample BDC Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255

xii

Contents

Viewing BDC Output: Error and Measurement Reports . . . . . . . . . . . . . . . . . 256

Reporting Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256

Reporting Measurements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256

13. Understanding NanoSim’s Output Files . . . . . . . . . . . . . . . . . . . . . . . . . . . 261

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261

Understanding Output File Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261

nanosim.3to5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261

nanosim.cap. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262

nanosim.cnt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263

nanosim.cut.cfg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263

nanosim.dc. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264

nanosim.dcpath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264

nanosim.dcu. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265

nanosim.dng. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265

nanosim.err . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266

nanosim.fcap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266

nanosim.fsdb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266

nanosim.hist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266

nanosim.ic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267

nanosim.ignore. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267

nanosim.log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267

nanosim.meas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268

nanosim.mosalias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268

nanosim.nodealias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268

nanosim.out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268

nanosim.partition.Z . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269

nanosim.power. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269

nanosim.rcxt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269

nanosim.save.xxx.xx.Z . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269

nanosim.stat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270

nanosim.stg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270

nanosim.sum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271

nanosim.unc. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272

nanosim.xst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272

Displaying Simulation Results Logically. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273

Displaying Simulation Results Graphically. . . . . . . . . . . . . . . . . . . . . . . . . . . . 273

xiii

Contents

14. Using Utilities for Dynamic Synopsys Tools . . . . . . . . . . . . . . . . . . . . . . . . 275

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275

Using the Stand-alone Post-process meas Utility . . . . . . . . . . . . . . . . . . . . . . 275

Command Syntax and Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276

Controlling Formatting with the edisplay Utility . . . . . . . . . . . . . . . . . . . . 277Command Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278edisplay -m nanosim.err result . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279

Controlling Output Printing with edisplay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283

Piping Output Data to a Waveform Display Utility . . . . . . . . . . . . . . . . . . . . . . 286

CosmosScope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286

nWave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286

Converting Output Formats with the vfast Utility . . . . . . . . . . . . . . . . . . . . . . . 287

15. Using the batchrun Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291

Distributing Jobs for Concurrent Computing . . . . . . . . . . . . . . . . . . . . . . . . . . 292

Naming Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292Searching for the Host File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292

Formatting the Batchfile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293

FILE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293

RUN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294

DATA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294

Batchfile Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296

Part III: Using NanoSim-supported HSPICE Features

16. Encrypting with the metaencrypt Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . 301

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301

Encrypting with metaencrypt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301

Algorithm Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3028-byte Key Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3033DES Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304

Simulating with an Encrypted Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305

xiv

Contents

Algorithm Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306Encrypted Netlist Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306Simulation Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307Work-arounds. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308

Known Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308

17. Modeling with the HSPICE-compatible W-element Feature . . . . . . . . . . . . 311

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311

Using the W-element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312

Specifying the RLGC Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313

Using a .MODEL Statement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314

Using an RLGC External File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316

Specifying the Field-solver Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317

Defining Material Properties. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318

Creating Layer Stacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319Defining Shape. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320Defining Rectangles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320Defining Circles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321Defining Strips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322Defining Polygons. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322

Specifying Field-Solver Model Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323

Defining the Field-Solver Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324

18. Optimizing Timing with Bisection Functions . . . . . . . . . . . . . . . . . . . . . . . 329

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329

Bisection Methodology. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330

Detecting Output Transition Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332

Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332

Using Bisection In NanoSim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332

Required Values and Statements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332

Optional Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333

Statement Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334

.MODEL Statement Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334

Additionally Created Output Files for a Bisection Run . . . . . . . . . . . . . . . 336

Reading the NanoSim Log File Iteration Report . . . . . . . . . . . . . . . . . . 336

xv

Contents

.TRAN Statement Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337

.MEASURE Statement Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338

Guidelines for the NanoSim Bisection Method . . . . . . . . . . . . . . . . . . . . 339Using NanoSim to Optimize the Setup Time for D-FF . . . . . . . . . . . 340

Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344

19. Using the NanoSim-supported HSPICE Digital Vector Format . . . . . . . . . 347

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347

Using a Netlist Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348

Using Command-line Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348

Defining Vector Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348

The enable Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349

The io Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350

The period Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350

The radix Statement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351

The tskip Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351

The tunit Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352

The vname Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353

Defining Waveform Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353

The out or outz Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353

The tdelay, idelay, and odelay Statements . . . . . . . . . . . . . . . . . . . . . . . . 354

The trise, tfall, and slope Statements. . . . . . . . . . . . . . . . . . . . . . . . . . . . 355

The triz Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356

The vih and vil Statements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357

The voh and vol Statements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358

The vref Statement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358

The vth Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359

Using the cbc Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360

Overriding Parameters with the set_vec_opt Configuration Command . . . . . . 361

20. Defining Blocks with the .ALTER Statement . . . . . . . . . . . . . . . . . . . . . . . . 363

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363

Reviewing the .ALTER Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363

Altering the Design Variable and Subcircuits . . . . . . . . . . . . . . . . . . . . . . . . . . 365

Using Multiple .ALTER Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365

xvi

Contents

21. Generating New Stimuli with the .STIM Statement . . . . . . . . . . . . . . . . . . . 367

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367

Using .STIM Syntax Format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368

Using VEC Syntax Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369

Generating Stimuli Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371

NanoSim-generated VEC File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372

NanoSim-generated PWL File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374

Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374

22. Using Diverse NanoSim-Supported HSPICE Features. . . . . . . . . . . . . . . . 377

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377

Using the PAR() Function. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377

Using X() or ISUB () Functions to Probe Subcircuit Currents . . . . . . . . . . . . . 377

Part IV: Appendices

A. Output File Descriptions and Samples . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381

The .rcxt File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381

Sample .rcxt File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381

Sample .log File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382

Warning Messages and the .log File . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387

Dangling Nodes Detected . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387

Netlist Compilation Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388

Circuit Partitioning and Autodetection Results . . . . . . . . . . . . . . . . . . . . . 390

Simulation Times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391Reported Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392

The .out File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392

Sample .out File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393

Line Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397Null . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398Semicolon Lines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398Period Lines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398

Lines Beginning with Numbers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401

xvii

Contents

Sample .cnt File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402

The .nodealias File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405

Sample .nodealias File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406

The .stat File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407

Data Structure Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408

Simulation Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409

Sample .sum File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413

Sample Block Power Report in the .log File. . . . . . . . . . . . . . . . . . . . . . . . . . . 414

Sample .power File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418

Sample .dcpath File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422

Sample .hist File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424

B. Detailed Configuration Command Information . . . . . . . . . . . . . . . . . . . . . 425

Effects of set_node_thresh Command. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425

Effects of the tv_node_edge Command. . . . . . . . . . . . . . . . . . . . . . . . . . 428

Effects of tv_node_setup Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431

Positive Setup Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432

Negative Setup Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432

Effects of tv_node_hold Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432

Positive Hold Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433

Negative Hold Time without a Specified Window Size. . . . . . . . . . . . . . . 434

Negative Hold Time with Specified Window Size. . . . . . . . . . . . . . . . . . . 434

Applying Commands to Portions of a Circuit . . . . . . . . . . . . . . . . . . . . . . . . . . 434

Applying Configuration Commands Directly. . . . . . . . . . . . . . . . . . . . . . . 435

Applying Configuration Commands that Apply other Configuration Commands435Using the set_inst_cmd Configuration Command . . . . . . . . . . . . . . 436Using the set_ckt_cmd Configuration Command . . . . . . . . . . . . . . . 436Using the set_pattern_cmd Configuration Command . . . . . . . . . . . 436

Sample Circuits Detected with report_ckt_leak . . . . . . . . . . . . . . . . . . . . . . . . 437

Using report_node_exv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440

Counting Pulses within a Reference Pulse . . . . . . . . . . . . . . . . . . . . . . . . . . . 441

Understanding Keepers (search_mos_keeper) . . . . . . . . . . . . . . . . . . . . . . . . 443

Using set_err_window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443

Syntax 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444

xviii

Contents

Syntax 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444

Syntax 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445

Simulating Floating Capacitors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445

Model 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446

Model 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446

Model 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446

Defining a Steady-state Strobe Window with vchk_node_window . . . . . . . . . 448

Defining Causality Relationships between Nodes with define_n2n_cause (BDC) 453

Measuring Delay between Source and Sink Nodes (BDC) . . . . . . . . . . . . . . . 454

Using print_meas_path (BDC). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455

Using print_node_path (BDC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456

Setting Slope Threshholds (BDC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457

C. Tcl Command Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459

Setting Up Tcl Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459

Limitations of Tcl Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460

Tcl Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460

Tcl Command Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460

Configuration Commands that Work with Tcl. . . . . . . . . . . . . . . . . . . . . . . . . . 461

D. Error Output File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463

Reporting Warnings and Errors to the .err File . . . . . . . . . . . . . . . . . . . . . . . . 463

Description of Error Messages and Warnings . . . . . . . . . . . . . . . . . . . . . 463

Comparison Errors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464

Timing Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466

Bus Contention Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473

High Impedance Condition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473

Uncertain State Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474

Timing Error with Timing Tolerance Margin . . . . . . . . . . . . . . . . . . . . . . . 475

Block Delay Characterization Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477

Power Diagnosis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478

Multiple-Toggle Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483

Multiple-Pulse Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483

xix

Contents

Excessive Voltage Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488

The .err File Sample. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492

Viewing the Error File with the Viewerror Utility . . . . . . . . . . . . . . . . . . . . . . . . 492

Command Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493

Command-line Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493

E. Supporting SPICE Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497

SPICE Models Supported in NanoSim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501

xx

About This Manual

The NanoSim User Guide provides conceptual and usage information about the NanoSim simulator. It includes information about using both the NanoSim Workbench graphical user interface, and the NanoSim command-line interface. In addition, it describes the contents and format of the NanoSim-generated output files.

Audience

This manual is for integrated circuit engineers and designers performing power simulations to test and verify integrated circuit designs at the deep-submicron level.

This manual is written at a level that assumes you have knowledge of UNIX, high-level design techniques, and circuit description tools, such as SPICE.

Related Publications

For additional information about NanoSim, see■ The documentation installed with the NanoSim software and available

through the NanoSim Help menu■ The NanoSim Release Notes, available on SolvNet (see Accessing SolvNet

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

is available through SolvNet at http://solvnet.synopsys.com

You might also want to refer to the documentation for the following related Synopsys products:■ Enhanced NanoSim-VCS■ NanoSim-VCS-MX■ HSIM■ CosmosScope■ HSPICE

NanoSim® User Guide xxiB-2008.09

http://solvnet.synopsys.com

About This ManualConventions

Conventions

The following conventions are used in Synopsys documentation.

Customer Support

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

Convention Description

Courier Indicates command syntax.

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

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

[ ] Denotes optional parameters, such as:

write_file [-f filename]

... Indicates that parameters can be repeated as many times as necessary:

pin1 pin2 ... pinN

| Indicates a choice among alternatives, such as

low | medium | high

\ Indicates a continuation of a command line. NOTE: Ensure there are no spaces after this character before the next line.

/ Indicates levels of directory structure.

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

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

xxii NanoSim® User GuideB-2008.09

About This ManualCustomer Support

Accessing SolvNet

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

To access SolvNet:

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

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

If you need help using SolvNet, click SolvNet Help in the Support Resources section.

Contacting the Synopsys Technical Support Center

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

http://solvnet.synopsys.com (Synopsys user name and password required), then clicking “Enter a Call to the Support Center.”

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

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

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

■ Telephone your local support center.

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

• Call (650) 584-4200 from Canada.

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

NanoSim® User Guide xxiiiB-2008.09



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

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

About This ManualCustomer Support

xxiv NanoSim® User GuideB-2008.09

Part: 1 Using the NanoSim GUI Workbench

Part 1 of this guide contains information about using the NanoSim GUI Workbench.

NanoSim® User Guide 1B-2008.09

:

2 NanoSim® User GuideB-2008.09

11Getting Started with the NanoSim GUI Workbench

This chapter provides a brief comparison between the NanoSim GUI Workbench and the NanoSim command-line interface. It describes the basic organization of both a command-line session and the Workbench interface, and describes, in detail, the major components of the Workbench.

Overview

At several points in the chapter there are pointers to demonstration files that you can run to see an animated illustration of the features that are being discussed. See the /doc/ns/movies subdirectory of your NanoSim installation directory.

This chapter contains the following topics:■ Comparing the Command-line and the GUI Workbench■ Exploring the NanoSim Workbench■ Using the Workbench Icons■ Setting the NanoSim GUI Default Preferences■ Using Configuration Commands With and Without the Workbench■ Encrypted Netlist and Model Files

Comparing the Command-line and the GUI Workbench

You can run NanoSim simulations using the command-line interface or using the NanoSim Workbench graphical user interface (GUI)—the term Workbench and GUI are used interchangeably. Running a simulation from the command-line requires that you have a thorough knowledge of the simulator and its many configuration commands. The command-line interface is described in detail in


Chapter 1: Getting Started with the NanoSim GUI WorkbenchComparing the Command-line and the GUI Workbench

the latter part of this book but is generally not recommended except for expert NanoSim users.

In most cases, using the Workbench is an easier and more effective way to set up and run your simulation. It prompts you intuitively to make decisions about the details of your design, builds your configuration file behind the scenes, and runs your simulation based on the decisions you make. This eliminates much of the risk of error that comes with manually creating and maintaining configuration files and running simulations at the command-line.

The Workbench organizes your entire simulation process from setup to post-simulation analysis and enables you to reuse and modify existing simulations easily with minimal knowledge of the simulator.

Running a Demo Comparing the Command-line and the Workbench

You can execute a demonstration of the two methods for running NanoSim. See the NanoSim_installation_directory/doc/ns/movies directory for the appropriate files.

Organizing a NanoSim Command-line Session

Using a NanoSim command-line session to produce your simulation requires that you provide a number of files defining the various details of your design and the parameters you want NanoSim to use. These files vary depending on your simulation.

During your simulation run, various progress messages are displayed on screen. If all goes well, your output files will contain the results of your simulation when it is completed. NanoSim displays any requested power reports on screen. Any errors produced during the simulation are in an encoded file and must be decoded using the viewerror command.

After you complete the command-line session, you can view the waveforms represented by your simulation using one of three waveform viewers: ■ The WaveView viewer opens with the .wdf file generated by your simulation.■ The CosmosScope viewer opens with the .fsdb or .wdb file generated by

your simulation. ■ The nWave viewer opens with the .out or .fsdb file generated by your

simulation.


Chapter 1: Getting Started with the NanoSim GUI WorkbenchExploring the NanoSim Workbench

Organizing the NanoSim Workbench

With the Workbench, you do not need to know commands or manage configuration and control files or run scripts. You only need to understand the design tasks you want to accomplish.

The Workbench is made up of these major components: ■ Workbench main window■ Hierarchy Explorer■ Power Reports window

In addition to these major components, there is a Help system, a file browser, and several other minor components that assist you in completing your simulation design. Using these components, you make intuitive choices based on the design features you want in your simulation.

After your simulation is complete, you can view the results, including nWave or CosmosScope views of your waveforms, from within the Workbench. The remaining section of this chapter describes the major components of the Workbench in more detail.

Exploring the NanoSim Workbench

This section describes how you can become familiar with the major components of the NanoSim Workbench, thereby becoming more comfortable working in the environment:■ Running a Demo Illustrating the Major Components of the Workbench■ Describing the Workbench Main Window■ Displaying the Design Hierarchy—Hierarchy Explorer■ Viewing Usage Reports—Power Reports Window■ Getting Help



Running a Demo Illustrating the Major Components of the Workbench

You should run a demonstration that walks you through the major components of the NanoSim Workbench. See the NanoSim_installation_directory/doc/ns/movies directory.

Describing the Workbench Main Window

The main Workbench window consists of a main menu bar, several windows (you can invoke), and corresponding tabbed panels for managing various aspects of your simulation. The variety of tabbed panels depends on what type of simulation you choose.

Figure 1 is the initial window that appears when you invoke the NanoSim GUI. You can initiate a new simulation, or open an existing simulation.

Figure 1 Initial NanoSim GUI window

The second window that appears enables you to choose the simulation type best suited for your needs.



There are three types of simulations to choose from:

1. Standard NanoSim

2. NanoSim Memory Simulation Using HAR

3. Discovery AMS: NanoSim-VCS

For simulation types 1 and 2 (standard NanoSim), four windows are enabled by clicking on the following buttons: ■ Netlist & Stimulus■ Simulation Setup■ Simulation■ Analysis

Figure 2 shows the enabled windows for a standard NanoSim simulation.

Figure 2 NanoSim simulation windows

For simulation type 3 (Discovery AMS: NanoSim-VCS), five windows are enabled by clicking on the following buttons:■ Netlist & Stimulus■ Discovery AMS Setup (NS-VCS)■ NanoSim Setup

Enabledwindows (1-4)for standardNanoSim

correspondingtabbed panels



■ Simulation■ Analysis

Figure 3 shows the enabled windows for a Discovery AMS simulation.

Figure 3 Discovery AMS simulation window

For each of the enabled windows, there is a set of corresponding tabbed panels that you can use to modify the various tasks related to your simulation. In Figure 3 for example, the Netlist & Stimulus window is invoked—by selecting the Netlist & Stimulus button—enabling six tabbed panels for your specifications: Verilog, Pre-Layout, Post-Layout, Verilog Gate Level, Behavioral Modelling, and Netlist Options.

The Manual Cmds tabbed panel enables you to add additional NanoSim configuration commands. It provides you with a brief description of each command, and a text entry field within which you can enter a specific configuration command (see Figure 4).

tabbed panels



Figure 4 Manual Cmds tabbed panel

Displaying the Design Hierarchy—Hierarchy Explorer

The Hierarchy Explorer visually displays the design hierarchy as defined by the netlists. In the left pane, all the instances are hierarchically listed, which allows you to navigate through the hierarchy (see Figure 5). The nodes of a selected instance are displayed in a separate pane on the right.



Figure 5 NanoSim Hierarchy Explorer

Viewing Usage Reports—Power Reports Window

Initially, you must set up your power report settings before you can use the Power Reports feature. After you have run your simulation, you can use the Power Reports dialog box to view various types of reports on current usage in the simulation (see Figure 6). The content of the dialog box changes depending on the type of report you choose. In each case, there is a histogram report in the left pane and a table containing the data that is represented in the chart in the right pane.



Figure 6 Power Reports dialog box

Getting Help

You can always get a basic description of the function of the currently open window in the NanoSim Workbench. From the main menu, click the Help icon. Alternately, you can select the Help icon whenever it is visible for information about the area in which it appears.


Chapter 1: Getting Started with the NanoSim GUI WorkbenchUsing the Workbench Icons

Using the Workbench Icons

The graphical icons used in the NanoSim Workbench represent various common tasks and events, which are described in Table 1.

Table 1 NanoSim Workbench Icon Descriptions

Icon Definition

Browse Directory

icon. Enables you to select a directory.

Browse File

icon. Enables you to select a file.

Browse Hierarchy

icon. Enables you to browse and select an object.

Copy

icon. Copies the selected nodes or elements to the clipboard. This icon appears in the menu bar of the Hierarchy Explorer.

Decrease Font

icon. Decreases the font size of the selected text.

Increase Font

icon. Increases the font size of the selected text.

Hierarchy Explorer

icon. Opens the Hierarchy Explorer, which enables you to browse your netlist structure. You can do this only if you have specified a netlist.


Chapter 1: Getting Started with the NanoSim GUI WorkbenchUsing the Workbench Icons

Running a Demo Illustrating the Icons in Context

You can run a demonstration showing the icons in the contexts where they are used in the Workbench. See the NanoSim_installation_directory/doc/ns/movies directory.

Help

icon. Opens a dialog box displaying descriptive help for the area in which the Help icon is located.

Insert (Paste)

icon. Inserts the selected items (nodes, instance names, etc.) into the original text box from which the Hierarchy Explorer is invoked.

Power Reports

icon. Opens the Power Reports dialog box. This dialog box displays histogram bar graphs of your completed simulation. You must have initially specified power reports from the power diagnostic section under the Simulation Setup window.

Find

icon. Opens a search dialog box to locate a node or element in the hierarchy displayed in the Hierarchy Explorer.

Save simulation

icon. Saves the .wrk file for your simulation.

Table 1 NanoSim Workbench Icon Descriptions (Continued)

Icon Definition


Chapter 1: Getting Started with the NanoSim GUI WorkbenchSetting the NanoSim GUI Default Preferences

Setting the NanoSim GUI Default Preferences

From the main menu, you can view or change the settings contained in the NanoSim GUI-Preference dialog box. It is not necessary to start a simulation to change your preferences. Select the

View > Preferences

command from the Workbench menu bar and change the default values whether or not a simulation is running. When you change these settings, you are customizing the simulator default behavior for your environment.

Running a Demo Illustrating the NanoSim GUI-Preferences Setup

You can run a demonstration showing the NanoSim GUI-Preferences dialog box with the default values that are set when you first install the NanoSim Workbench. See the NanoSim_installation_directory/doc/ns/movies directory.

NanoSim GUI Preference Default Categories

The four categories listed in the NanoSim GUI-Preferences dialog box are as follows: ■ General Category Defaults

Defines defaults that apply throughout the NanoSim Workbench.■ Netlist & Stimulus Category Defaults

Defines defaults that apply specifically within the Netlist & Stimulus window in the NanoSim Workbench.

■ Simulation Setup Category Defaults Defines defaults that apply specifically within the Simulation Setup window in the NanoSim Workbench.

■ Simulation Category Defaults Defines defaults that apply specifically within the Simulation window in the NanoSim Workbench.



General Category Defaults

The settings that you can change in the General category are shown in Figure 7 and described in Table 2.

Figure 7 General category defaults

Table 2 General category default settings

Setting Description Default Value

Application file editor The default text editor that the simulator opens to view a file.

vi

Font name The name of the font that is used to display text in the NanoSim Workbench.

Application

Font size The size of the font that is used to display text in the NanoSim Workbench.

10 point

Use application color palate

Controls how color is used in your NanoSim Workbench session.

Checked



Netlist & Stimulus Category Defaults

The settings that you can change in the Netlist & Stimulus category are shown in Figure 8 and described in Table 3.

Figure 8 Netlist & Stimulus category defaults

Table 3 Netlist &Stimulus category default settings


Netlist directory Sets the default directory where you want the GUI to begin searching for netlist files. You can locate this directory using the Browse Directory icon at the far right of the text field.

Not specified

Model directory Sets the default directory where you want the GUI to begin searching for model files. You can locate this directory using the Browse Directory icon at the far right of the text field.

Not specified



Netlist file types & suffixes

A list of netlist file types and their suffixes that are allowable for your simulation.

ELDO, HSPICE, SPECTRE, CSPF, DPF, DSPF, HSPF, SPEF, SPF, vec

Netlist filtering This option keeps ground capacitors in the Hierarchy browser.

Unchecked

Pre-layout The default pre-layout netlist file type to use when the file suffix is not associated with a file type in the Netlist file types and suffixes field.You can change this value by selecting from the drop-down list containing valid alternatives.

HSPICE

Post-layout The default post-layout netlist file type to use when the file suffix is not associated with a file type in the Netlist file types and suffixes field.You can change this value by selecting from the drop-down list containing valid alternatives.

HSPICE

Vector Stimulus The default pre-layout netlist file type to use when the file suffix is not associated with a file type in the Netlist file types and suffixes field. You can change this value by selecting from the drop-down list containing valid alternatives.

vec

Table 3 Netlist &Stimulus category default settings (Continued)




Simulation Setup Category Defaults

The settings that you can change in the Simulation Setup category are shown in Figure 9 and described in Table 4.

Bus notation The default characters to use for bus notation. You can change this value by selecting from the drop-down list containing valid alternatives.

[-]

Hierarchy separator The default character to use as a separator in hierarchical netlists. You can change this value by selecting from the drop-down list containing valid alternatives.

.

Table 3 Netlist &Stimulus category default settings (Continued)




Figure 9 Simulation Setup category defaults

Table 4 Simulation Setup category default settings


Waveform output format The default waveform output format. You can choose other formats from the pull-down menu.

.out

Global resolutions This check box changes the global resolution automatically on changing global simulation accuracy

Checked (enabled)

Voltage resolution Waveform resolution for voltage. You can choose other voltages from the pull-down menu.

10 mv

Current resolution Waveform resolution for currents. You can choose other currents from the pull-down menu.

1 ua



Simulation Category Defaults

The settings that you can change in the Simulation category are shown in Figure 10 and described in Table 5.

Time resolution Waveform minimum timestep resolution. You can choose other times from the pull-down menu.

10 ps

Minimum time resolution Global simulator minimum timestep resolution. You can choose other minimum times from the pull-down menu.

10 ps

Tech files directory Specify the directory where you want the GUI to begin searching for the tech file. You can locate this directory using the Browse Directory icon at the far right of the text field.

Not specified

Proprietary SPICE *nanosim tech command for tech file generation

A command used at your installation to generate a tech file.

Not specified

Table 4 Simulation Setup category default settings (Continued)




Figure 10 Simulation category defaults

Table 5 Simulation category default settings


Run simulation (local or remote)

Choosing local determines your simulation will run locally in the current working directory.

Choosing remote determines your simulation will run remotely. The lsf or grid options are enabled. You enter the enviroment commands to enable remote simulations.

Local

Configuration file Generates the GUI-generated config file automatically.

Checked (enabled)


Chapter 1: Getting Started with the NanoSim GUI WorkbenchUsing Configuration Commands With and Without the Workbench

Using Configuration Commands With and Without the Workbench

Before the introduction of the NanoSim Workbench, it was necessary to set up a configuration for a simulation using a text editor to define all of the simulation parameters in a configuration file. This file usually contains a large number of configuration commands. Before the Workbench, you needed to know or look up these commands in order to properly define your configuration.

However, the NanoSim Workbench provides you with a more intuitive way to create your configuration file. As you make choices in the Workbench, they are reflected in the configuration of your simulation without the need for you to manually enter configuration commands into the configuration file.

Of course, you can still create or modify a configuration file manually, and the Workbench provides an easy way to do so. You can enter additional NanoSim config commands in the Manual Cmds tabbed panel, where you get a concise definition of each command and usage examples for each individual command.

You can view the config commands (generated in the NanoSim GUI) within the Simulation window. Click the Configuration button and view the Configuration file dialog box that contains a list of NanoSim configuration commands for a specific simulation.

You can also still use your favorite text editor to create your own configuration file manually, if you choose to run NanoSim from the command-line. In this case, you can view a man page for any NanoSim configuration command using the following command:

man command_name

Encrypted Netlist and Model Files

Take note of the following:■ If any netlist and/or model files are encrypted by the metaencrypt utility,

the Hierarchy Browser becomes disabled and a warning message displays.■ If model files are encrypted, the Cadence integration feature does not

display the corners information in the Model Setup field.■ If the netlist or model files are encrypted, the NS-VCS simulation errors

out—it is not currently supported.


22Running Basic GUI Simulations

This chapter describes how to run a basic NanoSim GUI Workbench simulation. It describes the interface features for starting, setting up, running, and analyzing simulations.

Overview

At several points in the chapter, there are pointers to demonstration files that you can run to see an animated illustration of the features that are being discussed. See the /doc/ns/movies subdirectory of the NanoSim installation directory.

This chapter contains the following topics:■ Starting the NanoSim Workbench■ Identifying Your Design Name and Simulation Type■ Simulation Flow in the GUI Workbench■ Running a Simulation■ Using Timing Diagnostics■ Using Power Diagnostics■ Editing Netlist and Configuration Files within the Workbench■ Viewing Waveforms

Starting the NanoSim Workbench

How you start the Workbench depends on whether you want to create a new simulation from the beginning or use and modify an existing simulation. In


Chapter 2: Running Basic GUI SimulationsIdentifying Your Design Name and Simulation Type

either case, you begin by typing the following command at the command prompt:

nanosimgui &

The NanoSim start-up screen displays a NanoSim banner with information about your simulator session. It also displays two icons for you to choose from to start your simulator session.

These icons are located at the lower center of the initial window and again in the intial window menu bar:■ Start a new simulation by clicking the new simulation icon:

This icon starts the simulation when you do not have an existing .wrk file to use as the basis of your simulation. A dialog box prompts you for information about some basic characteristics of your new simulation.

■ Start an existing simulation by clicking the existing simulation icon:

This icon starts the simulation when you have an existing .wrk file that contains setup information from a previous simulation. You can rerun the existing simulation as-is or modify its settings. A dialog box prompts you for the name and location of the .wrk file you want to use as the basis of your simulation.

Running a Demo Illustrating a Basic Workbench Session

You can run a demonstration that walks you through a basic Workbench session. See the NanoSim_installation_directory/doc/ns/movies directory.

Identifying Your Design Name and Simulation Type

When you start a new simulation, a window opens and prompts you to specify a name and location for the work file for the simulation that you want to create. You can click the Browse Directory icon


Chapter 2: Running Basic GUI SimulationsIdentifying Your Design Name and Simulation Type

to locate the directory where you will keep the file. The file type of a work file is termed.wrk. In addition to the name and location of your design, you must specify the type of simulation you want to create. The simulation types are described under the following section Simulation Types.

When you start an existing simulation, a window opens and prompts you to specify a name and location for the work file for the simulation that you want to use. You can click the Browse Directory icon to find the directory where the file is located. In this case, you are not prompted to specify the type of simulation since it has already been determined at the time when the .wrk file was originally created.

File Browsing

Whenever you see the Browse File icon

at the right side of a text box, you can open a File Browser dialog box and navigate the directory structure there to locate a directory or file. After you find the file you want, select it and click the Open button.

Simulation Types

There are three types of simulations available for running in the NanoSim Workbench.

The types are:■ Standard NanoSim Simulation

This is a basic NanoSim simulation, without hierarchical array reduction or Discovery AMS: NanoSim-VCS.

■ NanoSim Memory Simulation Using HAR

This is a basic NanoSim simulation, but with hierarchical array reduction (HAR). Hierarchical array reduction is only limited to memory simulations. See Setting Up a Simulation to Use Hierarchical Array Reduction in Chapter 3, “Running Advanced GUI Simulations.”

■ AMS Simulation

This is a simulation using the Discovery AMS environment, which includes NanoSim, HSPICE, and VCS.


Chapter 2: Running Basic GUI SimulationsSimulation Flow in the GUI Workbench

Simulation Flow in the GUI Workbench

This section describes the major components of the GUI Workbench and how they relate to your design simulation. The main sections of the Workbench are indicated by buttons across the main window, from left to right, in the order that you would normally use for setting up, running, and analyzing your simulation. When you click on one of these buttons, a new window displays. Within each window, there are corresponding tabbed panels that require your specifications of your design.

Netlist & Stimulus

The Netlist & Stimulus window of the Workbench contains tabbed panels in which you can specify netlist files containing Verilog (NS-VCS only), Pre-layout, Post-layout, Verilog Gate Level, Behavioral Modelling, and Netlist Options. You can also specify your configuration for netlist options. When you select a tab, the related panel displays.

There are default values in many of the fields (panes) in these panels. You can change the default values used here and throughout the Workbench using the Preferences dialog box. See the Setting the NanoSim GUI Default Preferences section in Chapter 1, “Getting Started with the NanoSim GUI Workbench.”

Table 6 describes each of the tabs in the Netlist and Stimulus window, and their basic functions.

Table 6 Netlist and Stimulus tabbed panels description

Tab name Function

Verilog Specify Verilog netlist files and details of library file setup for Verilog (Available only in NanoSim-VCS simulations).

Pre-Layout Specify a valid SPICE netlist file type and subcircuit library path for each netlist file.

Post-Layout Specify:



AMS Setup (NanoSim-VCS only)

The AMS Setup window of the Workbench contains tabbed panels that enable you to control VCS options, view selection and interface options for your NanoSim-VCS simulation. When you click a tab, the related panel displays.

■ RC reduction method■ Minimum resistance value■ Minimum grounded capacitor value■ Minimum coupling capacitance■ Valid netlist (SPICE and SPF/SPEF) types■ Valid SPICE subcircuit library path

Verilog Gate Level Specify:

■ Path to Verilog gate level library path■ Name of Verilog gate level netlist file

Behavioral Modelling Specify:

■ Behavioral modelling netlist file■ Modeling netlist file (Verilog-A and ADFMI)

Netlist Options Specify:

■ Identifiers for bus notation■ Case-sensitivity of netlist names■ Use of GUI-generated configuration file■ Main subcircuit name■ Hierarchy separator character■ Include additional configuration files

Vector Stimulus Specify:

■ Stimulus vector file type■ Verilog VCD stimulus file type

Save & Restore Specify parameters for Save or Restore simulations.

Table 6 Netlist and Stimulus tabbed panels description (Continued)

Tab name Function



Table 7 describes each of the tabs in the AMS Setup window, and their basic functions.

Simulation Setup

The Simulation Setup window of the Workbench contains tabbed panels that enable you to control simulation accuracy and performance, generate technology files, perform timing and power diagnostics, choose additional NanoSim config commands, and specify output waveforms.

There are default values in many of the fields in these panels. You can change the default values used here and throughout the Workbench using the Preferences window. See the NanoSim GUI Preference Default Categories section in Chapter 1, “Getting Started with the NanoSim GUI Workbench.”

Table 8 describes each of the tabbed panels in the Simulation Setup window, and their basic functions.

Table 7 AMS Setup tabbed panels description

Tab name Function

VCS Options Specify a simulation executable name (simv), additional run time, compile time options, and run time log file.

Circuit Partitioning Enables you to resolve duplicate views (subcircuit or module) in your simulation. Multiple views can be Verilog, SPICE, Verilog-A, or ADFMI.

Interface Options Enables you to control the design digital-to-analog (D2A) interface and the analog-to-digitial (A2D) interface. Interface nodes are handled by NS-VCS through a resistance map file.

Table 8 Simulation Setup tabbed panels description

Tab name Function

Accuracy/Performance

Specify accuracy and performance levels for global level settings, standard block level settings.

Tech Files Specify the method for generating a technology file.

Behavioral Specify settings for ADFMI and Verilog-A components.



Timing Diagnostics

Set up the following timing diagnostics: ■ Setup time chk■ Hold time chk ■ Edge-to-edge chk ■ Pulse width chk■ Slow edges ■ Report node toggle count ■ Report multi-toggling on nodes■ Undriven nodes ■ Chk for heavily loaded nodes/excessive rise-fall times ■ Chk for propagation of don't care X-states

Power Diagnostics Set up the following power diagnostics: ■ Static leakage check ■ DC path checks ■ Excessive current check■ Block power reports, power budgeting■ Node power report ■ Histogram

Manual Cmds Specify additional NanSim configuration commands.

Global Cmds Define the following global settings for your simulation:■ When to recompile customize.c■ Interactive mode■ Suppressing warnings■ Double precision mode■ Simulation end time■ Maximum number of warning messages reported■ Output prefix name■ Additional NanoSim command-line options

Table 8 Simulation Setup tabbed panels description (Continued)

Tab name Function



Simulation

You run your simulation from this window.

Table 9 describes each of the tabbed panels in the Simulation window, and their basic functions.

Waveform O/P Define the following waveform output and print settings for your simulation:■ Output format■ Print logic■ Print voltage■ Print node current■ Print branch current

Table 9 Simulation tabbed panels description

Component Function

Progress Display window

Displays information about the progress of your simulation: ■ Log tab displays a log of the activity in the simulation. ■ Errors tab displays any error messages generated during

the simulation. Warnings tab displays any warning messages that are generated during the simulation.

Simulation Script button

Displays a dialog box containing the GUI-generated run script.

AMS Setup File button

Displays a dialog box containing the partition file for a NanoSim-VCS simulation setup. It is not available for standard NanoSim simulations.

Configuration button

Displays a dialog box that shows the generated NanoSim config commands.

Table 8 Simulation Setup tabbed panels description (Continued)

Tab name Function



Analysis

This window contains a pull-down menu that contains various output file formats that you can choose from to evaluate the results of your simulation for VCS output and NanoSim output (depending on the simulation type you have chosen). The various output formats are described in Table 10 for VCS output and in Table 11 for NanoSim output.

Simulation Settings button

Displays the NanoSim GUI-Preferences dialog box where you select the Local or Remote radio button to specify how you want to run your simulation and the defaults specified. If you select Remote, specify the simulation command you want to run, with its options.

Simulate button Starts the simulation run.

Waveform button Opens nWave or CosmosScope with the output of your simulation.

Table 10 Analysis window VCS output file format descriptions

VCS Output Files Description

Compilation log files A log of the compiling progress of your simulation

Runtime log files A log of the runtime progress of your simulation

Table 11 Analysis window NanoSim output format descriptions

NanoSim Output Files

Description

.dng Dangling nodes

.dcu Dangling nodes (zero voltage)

.err Error

.fcap Floating cap

Table 9 Simulation tabbed panels description

Component Function


Chapter 2: Running Basic GUI SimulationsRunning a Simulation

Running a Simulation

Before you run your simulation, review the settings you have entered in the tabbed panels of the Netlist & Stimulus and Simulation Setup windows for accuracy. If you do not modify the settings in these panels, the Workbench runs your simulation using the settings you defined in the NanoSim GUI.

In the Simulation window, run your simulation by clicking the Simulate button. The .log file for your simulation is displayed in the Log tabbed panel.

.hist Histogram

.sum Hotspot

.ignore Ignore netlist line

.nact Inactive node

.ic Initial conditions

.log Log file

.meas Measurement

.mosalias MOS alias

.nodealias Node alias

.power Power budget

.stg Stage info

.stat Statistics

.unc Unconnected nodes

Table 11 Analysis window NanoSim output format descriptions

NanoSim Output Files

Description


Chapter 2: Running Basic GUI SimulationsUsing Timing Diagnostics

Viewing Your Run Script

In the Simulation window, click the Simulation Script button. The run script that the Workbench uses for your simulation is displayed in a message window, along with the path where the file is located in your system. Notice that several of the values you entered in various places in the Workbench appear in the run script. You can reuse this run script at the command-line.

Viewing the Waveforms for Your Simulation

After your simulation has completed, you can view the waveforms for your simulation by clicking the Waveform button in the Simulation window. ■ The WaveView viewer opens with the .wdf file generated by your simulation.■ The CosmosScope viewer opens with the .fsdb or .wdb file generated by

your simulation. ■ The nWave viewer opens with the .out or .fsdb file generated by your

simulation.

Using Timing Diagnostics

NanoSim enables you to use various timing diagnostic features. You can use the diagnostics to determine if your design meets the correct timing specifications.

Throughout these procedures, you can use the Hierarchy Explorer to locate and insert nodes in the appropriate fields, as follows:

1. Specify your vector stimulus netlist file type in the Vector Stimulus tabbed panel within the Netlist & Stimulus window.

2. Specify “Setup time checks” in the Diagnostic functions text box in the Timing Diagnostics tabbed panel within the Simulation Setup window. The Setup time checks table displays.

Specify the values you want to include in your timing checks, such as:

• Data nodes and clock node that you want to check

• Significant edge or edges for data

• Edge for clock nodes

Setup time


Chapter 2: Running Basic GUI SimulationsUsing Power Diagnostics

• Valid window. This setting prevents checking the wrong data edge outside a clock period.

• Skip timing violations. If you want to skip the timing violations, mark the checkbox of each respective entry.

3. Specify nodes in the Print logic table for which you want to display waveforms in the Waveform O/P tabbed panel within the Simulation Setup window.

Running a Demo Illustrating Timing Diagnostics

You can run a demonstration that walks you through how to use timing diagnostics. See the NanoSim_installation_directory/doc/ns/movies directory.

Using Power Diagnostics

NanoSim enables you to use various power diagnostic features. You can use the diagnostics to determine if your design meets the correct power specifications.

Throughout these procedures, you can use the Hierarchy Explorer to locate and insert nodes in the appropriate fields, as follows:

1. Define your power diagnostics settings in the Pwr Diagnostics tabbed panel within the Simulation Setup window. Select the functions you want to use from the Diagnostic functions drop-down list and specify the values you want to use with each one.

2. Open the Simulation window and click the Simulate button to run the simulation.

3. Select the Power Reports icon

to open the Power Reports dialog box and view power reports for your simulation. For each report generated by your simulation, you can display a histogram bar graph in the lower left pane. When you click on a bar in the graph, the details represented by that bar in the graph are highlighted in the pane at the right.


Chapter 2: Running Basic GUI SimulationsEditing Netlist and Configuration Files within the Workbench

Running a Demo Illustrating Power Diagnostics

You can run a demonstration that walks you through how to use power diagnostics. See the NanoSim_installation_directory/doc/ns/movies directory.

Editing Netlist and Configuration Files within the Workbench

You can edit netlist and configuration files during a Workbench session.

Editing Netlist Files with the Default Editor

To edit netlist files using the default editor, do the following:

1. Right-click in the space to the right of the file name, from a field that displays the name of a file (such as a netlist or vector stimulus file). Some of the places where you will find these file names are the Pre-Layout, Post-Layout, or Vector Stimulus tabbed panels within the Netlist & Stimulus window. A pop-up menu appears.

2. Choose Edit File. NanoSim opens the file for editing in the default editor specified in your GUI preferences default settings. See the NanoSim GUI Preference Default Categories section in Chapter 1, “Getting Started with the NanoSim GUI Workbench.” for more information.

Editing Configuration Files from the Manual Cmds Panel

The Manual Cmds tabbed panel within the Simulation Setup window is the appropriate place to add or remove commands in your simulation’s primary configuration file. If you edit this configuration file directly from another editor, the changes are overwritten by the information specified in the Workbench the next time the simulation is run.

The following steps describe how to insert and modify configuration commands:

1. Click the plus sign [+] to the left of a command category in the left pane to display the related commands. Click a command that you want to insert into the configuration file. A description of the selected command is displayed in the bottom pane with the command name highlighted in blue.


Chapter 2: Running Basic GUI SimulationsViewing Waveforms

2. Type, drag, or copy and paste (Ctrl-C, Ctrl-V) the command name into the right pane, then type the command parameters you need to use with it. Repeat this step for each command you want to add.

Explanation: For commands that require that you specify a node name or element name, click the Hierarchy Explorer icon

to open the Hierarchy Explorer and locate the node or instance name. When you locate the name, drag or copy and paste it from the Hierarchy Explorer to the position in the Manual Cmds tabbed panel where you are specifying your command.

3. Delete commands you want to remove from the configuration file, if any.

Running a Demo Illustrating Netlist and Configuration File Editing

You can run a demonstration that walks you through how to access files for editing during a Workbench session. See the NanoSim_installation_directory/doc/ns/movies directory.

Viewing Waveforms

The NanoSim Workbench uses nWave and CosmosScope to display waveforms generated by your simulation. For detailed information on how to use nWave and CosmosScope, see the respective user guides provided with these products.

To open nWave from the Workbench,

1. Click the Waveform button in the Simulation window of the main Workbench window after you have run your simulation to completion.

2. An nWave session opens with your simulation output as input.

Running Demos Displaying Waveforms

Most of the demonstrations of various Workbench functions include segments that demonstrate using nWave and CosmosScope to display waveforms from



your simulation. See the /doc/ns/movies subdirectory of your NanoSim installation directory.




33Running Advanced GUI Simulations

This chapter describes considerations for NanoSim GUI Workbench sessions using various advanced features. It describes details relevant to different types of simulations.

Overview

At several points in the chapter, there are pointers to demonstration files that you can run to see an animated illustration of the features that are being discussed. See the /doc/ns/movies subdirectory of your NanoSim installation directory.

This chapter contains the following topics:■ Setting Up a Simulation for Discovery AMS: NanoSim-VCS■ Setting Up a Simulation to Use Hierarchical Array Reduction■ Setting Up Advanced Analog Simulations■ Using Remote Simulation Control (LSF)■ Using ADFMI Models■ Using Interactive Mode

Setting Up a Simulation for Discovery AMS: NanoSim-VCS

There are five key steps to running a Discovery AMS: NanoSim-VCS simulation. In addition to these steps, you must also ensure that any other details that are not directly related to this type of advanced simulation have been properly defined in the Netlist & Stimulus and Simulation Setup windows. See Chapter 2, “Running Basic GUI Simulations.”


Chapter 3: Running Advanced GUI SimulationsSetting Up a Simulation to Use Hierarchical Array Reduction

The five steps are:

1. Specify the Verilog netlist files that you want to use in your simulation in the Verilog tabbed panel within the Netlist & Stimulus window. If there are order dependencies among the files, be sure to select them in the required order.

2. Specify the SPICE netlist files that you want to use in your simulation in the Pre-Layout tabbed panel within the Netlist & Stimulus window.

3. Ensure that the bus notation is set to match the netlists you have specified in the preceding steps in the Netlist Options tabbed panel within the Netlist & Stimulus window.

4. Navigate to the Partition Module tabbed panel—within the View Selection tabbed panel—to resolve your multiple views (Verilog, SPICE, Verilog-A, ADFMI) before simulation.

5. Select the _uod.out output format, and specify the nodes for which you want to output waveforms in the Waveform O/P panel within the NanoSim Setup window. You can specify nodes using the Hierarchy Explorer, or you can enter the node name directly.

Running a Demo Using NanoSim-VCS

You can run a demonstration that walks you through a Workbench session using NanoSim-VCS. See the NanoSim_installation_directory/doc/ns/movies directory.

Setting Up a Simulation to Use Hierarchical Array Reduction

Hierarchical Array Reduction (HAR) enables you to read-in a complete, hierarchical netlist for a large SRAM or DRAM memory and to simulate the memory with reasonable accuracy and speed. HAR automatically reduces the inactive parts of a memory based on stimulus, while preserving the loading effect of the reduced memory components.

This section describes how to use HAR from the Workbench. For information about how HAR works and the prerequisites for a design that can effectively use HAR, see Chapter 8, Using Hierarchical Array Reduction.


Chapter 3: Running Advanced GUI SimulationsSetting Up a Simulation to Use Hierarchical Array Reduction

Running a Demo Using NanoSim with Hierarchical Array Reduction

You can run a demonstration that walks you through a Workbench session using HAR. See the NanoSim_installation_directory/doc/ns/movies directory.

Running HAR from the NanoSim Workbench

If you have an existing HAR simulation saved in a .wrk file, you can click the Open an existing simulation icon on the initial Workbench window and then specify the name and location of your .wrk file when prompted. Otherwise, click the Set up a new simulation icon, and specify a unique name and a location for your new .wrk file when prompted. On the same window where you specify the file name, click the NanoSim Memory Simulation Using HAR radio button, and click the Next button.

HAR-Specific SettingsFollow these steps to run a simulation using HAR. In addition to these steps, you must also ensure that any other details that are not directly related to this type of advanced simulation have been properly defined in the Simulation Setup panel within the Netlist & Stimulus window. See Chapter 2, “Running Basic GUI Simulations,” for more information.

Throughout these procedures, you can use the Hierarchy Explorer to locate and insert nodes in the appropriate fields and:

1. Specify the details of your HAR simulation. This section focuses primarily on the HAR Setup tabbed panel within the Simulation Setup window.

2. Specify the core cells you want included in the reduction.

Explanation: When you click the Browse button at the right edge of a Core Cell column row, a cell list displays in the left side of the HAR Setup tabbed panel. This list is generated from the netlist that you specified in the Pre-Layout tabbed panel within the Netlist & Stimulus window. The controlling port for a core cell might or might not be specified. If it does not appear automatically in the Controlling Ports column, you will need to enter the controlling port in the column. If you have core cells that should be excluded, enter their names in the Exclude Core Cells column.


Chapter 3: Running Advanced GUI SimulationsSetting Up Advanced Analog Simulations

Setting Up Advanced Analog Simulations

There are several steps required to run advanced analog simulations. In addition to these steps, you must also ensure that any other details of your simulation that are not directly related to advanced analog have been properly defined in the Netlist & Stimulus and Simulation Setup windows. See Chapter 2, “Running Basic GUI Simulations,” for more information.

Throughout these procedures you can use the Hierarchy Explorer to locate and insert nodes in the appropriate fields. The following steps are merely a sample of what options you can use for your simulation:

1. Set the Simulation slide bar to position 4 and the Model slide bar to position 3 in the Global Level Settings sub-tabbed panel, located within the Accuracy/Performance tabbed panel, which is in the Simulation Setup window.

2. Choose to set accuracy and performance for instances, and specify the instance from your netlist that you want to use in the Standard Block Level Settings sub-tabbed panel, located within the Accuracy/Performance tabbed panel, which is in the Simulation Setup window. You can click in the Instance text box to activate the Browse Hierarchy icon and locate the instance with the Hierarchy Explorer.

3. Specify event-sensitivity settings using the set_node_spd and set_node_esv configuration commands in the Manual Cmds tabbed panel within the Simulation Setup window.

4. Expand the sim_ctrl section of the Configuration Commands pane—from within the Manual Cmds tabbed panel—and click on set_node_spd. A description of the command appears in the bottom pane.

5. Type the command and its parameters in the right pane, which displays the manually specified commands that the simulator inserts into its configuration file. Alternatively, you can drag-and-drop or cut-and-paste the command from its description and then type in your parameter values.

6. For example, you can repeat the process for set_node_esv. When you are done, the following two commands should be displayed in the right pane:set_node_spd x5.* 1mvset_node_exv x5.* 1mv

Note:

Using 1 mv is a very conservative setting for an analog circuit!


Chapter 3: Running Advanced GUI SimulationsUsing Remote Simulation Control (LSF)

In the preceding commands, x5.* represents the instances affected, and 1mv represents the spd and esv values, respectively.

Running a Demo of Setting Up and Running an Advanced Analog Simulation

You can run a demonstration that walks you through a Workbench session running an advanced analog OPAMP simulation. See the NanoSim_installation_directory/doc/ns/movies directory.

Using Remote Simulation Control (LSF)

You can set your default preferences to LSF remote simulation control, or you can override the default settings to use or disable remote control for individual simulations.

Setting the Workbench to Run Simulations Remotely by Default

To set the workbench to remotely run simulations (by default):

1. Choose the View > Preferences command from the main menu bar. The NanoSim GUI-Preferences dialog box appears.

2. Choose the Simulation category and click the Remote radio button in the NanoSim GUI-Preferences dialog box.

Explanation: If you have a default LSF command that runs at your installation, specify it in the field provided.

3. Click the OK button to close the NanoSim GUI-Preferences dialog box. The Workbench is now set to run your sessions remotely with LSF.

Turning Remote Simulation On or Off Dynamically

To dynamically invoke (or turn off) a remote simulation:

1. Open the Simulation window, and click the Simulation Settings button. The NanoSim GUI-Preferences dialog box displays.

2. Click either the Local or Remote radio button, as required, to reverse the default specified in the NanoSim GUI-Preference default settings.


Chapter 3: Running Advanced GUI SimulationsUsing ADFMI Models

Explanation: If you have an LSF command that you want to run for this simulation, specify it in the field provided.

3. Click the OK button to close the NanoSim GUI-Preferences dialog box. The Workbench is now set to run your current session remotely or locally as specified.

Running a Demo Setting up Remote Simulation Control

You can run a demonstration that walks you through setting up the Workbench defaults, or an individual session, to use remote simulation control. See the NanoSim_installation_directory/doc/ns/movies directory.

Using ADFMI Models

There are several key steps to using ADFMI models in your simulation, depending on whether you replace a transistor-level block with a model. In addition to these steps, you must also ensure that any other details of your simulation that are not directly related to ADFMI modeling have been properly defined in the Netlist & Stimulus and Simulation Setup windows. See Chapter 2, “Running Basic GUI Simulations,” for more information. Throughout these procedures, you can use the Hierarchy Explorer to locate and insert nodes in the appropriate fields.

If you want to substitute a model for a specific transistor-level block, see Using an ADFMI Model in Place of a Transistor-level Block as follows:

1. Specify your ADFMI model file in the Behavioral Modelling tabbed panel within the Netlist & Stimulus window. Later, if you display the run script from the Simulation window, you will see the ADFMI model file as an argument to the -FM command option.

2. Specify nodes in the Print logic pane and the Print voltage pane for which you want to display waveforms in the Waveform O/P tabbed panel within the Simulation Setup window.

Running a Basic Demo Using ADFMI Models

You can run a demonstration that walks you through a Workbench session using ADFMI models. See the NanoSim_installation_directory/doc/ns/movies directory.


Chapter 3: Running Advanced GUI SimulationsUsing ADFMI Models

Using an ADFMI Model in Place of a Transistor-level Block

To speed up your simulation, you can substitute an ADFMI model for a specific transistor-level block.

This process does not require you to modify your netlist. Instead, you select the subcircuits you want to replace:

1. Specify your ADFMI model file in the Behavioral Modelling tabbed panel within the Netlist & Stimulus window. Later, if you display the run script from the Simulation window, you will see the ADFMI model file as an argument to the -FM command option.

2. Specify the subcircuit name for which you want the substitution in the Behavioral tabbed panel within the Simulation Setup window.

3. Set the Simulation slide bar to position 3 and the Model slide bar to position 3 in theGlobal Level Settings sub-tabbed panel that is located within the Accuracy/Performance tabbed panel, which is in the Simulation Setup window. Leave the Netlisting slide bar at position 2 (default).

4. Set accuracy and performance for your subcircuit in the Standard Block Level Settings sub-tabbed panel that is located within the Accuracy/Performance tabbed panel, which is in the Simulation Setup window. This keeps the setting independent of subcircuit hierarchy and enables portability between designs using the same subcircuit.

5. Specify the subcircuit that you want to use. You can click in the Instance text box to activate the Browse Hierarchy icon and locate the subcircuit with the Hierarchy Explorer dialog box.

6. Set the Simulation slide bar to position 4 and the Model slide bar to position 4. Leave the Netlisting slide bar at position 2 (default).

7. Click the Insert button. The subcircuit is inserted in the hierarchy in the Block (Instance/Subckt) pane, with the simulation settings you have defined.

You must have a well-designed model for this process to be useful.

If there is a model that is instantiated in the netlist, but there is no transistor-level equivalent, the model is used automatically and you need not specify it here.


Chapter 3: Running Advanced GUI SimulationsUsing Interactive Mode

Running a Demo Using an ADFMI Model in Place of a Transistor-level Block

You can run a demonstration that walks you through a Workbench session using ADFMI models. See the NanoSim_installation_directory/doc/ns/movies directory.

Using Interactive Mode

You can run any type of simulation in the Workbench using interactive mode and the advanced debugging features.

Running a Demo Using Interactive Mode

You can run a demonstration that walks you through a simulation using interactive mode. See the NanoSim_installation_directory/doc/ns/movies directory.

Activating and Deactivating Interactive Mode

After you have configured your netlist usage and simulation setup, go to the Simulation window of the main Workbench panel, and click the Simulate button to start your simulation. The Interactive button is now enabled. When you click the Interactive button, the simulation pauses showing the simulator version number in the log. At this point, the text label on the Interactive button changes to Continue. If you click the button now, it resumes the simulation where it paused.

Debugging in Interactive Mode

While in interactive mode, you can access the NanoSim interactive debugging commands by doing the following:

1. Click the Adv Debug button to bring up the interactive debugging mode command entry panel. Two additional panes display across the bottom of the Simulation window. The left pane displays a list of the most commonly



used NanoSim interactive mode commands. The right pane changes dynamically to contain appropriate data entry fields for the command that is currently selected in the left pane.

2. Select the interactive command on the left that you want to use.

3. Specify the parameters for the comand you selected on the right. Where appropriate, you can use the Hierarchy Explorer to locate nodes that you want to debug.

4. Click the Submit button.

The simulator runs the command and displays the results in the Log panel at the top of the Simulation window.

Explanation: After you have run interactive mode, the simulator will not automatically close your simulation at the end of the run.

5. Repeat steps 2 - 4 for each interactive debugging command you want to use. When you have run all the commands you need, click the Continue button to exit interactive mode and finish the simulation.




Part: 2 Controlling the Simulator

Part 2 of this guide contains information about controlling the simulator.


:


44Getting Started at the Command-line

This chapter provides the basic information you need to start using the NanoSim simulator from the command-line. It lists the required and optional input files and provides a basic procedure for running a NanoSim simulation.

Overview

To control the power and versatility of the NanoSim analysis tool, you can use the nanosim command and its options in the command interface form. See the appropriate interface manual for details on using NanoSim in a specific interface, such as Cadence or Mentor.

For added flexibility, the NanoSim simulator lets you set up certain simulation environment parameters in the .epicrc file that are overridden by the command-line options described in Tailoring your Analysis with the Command-line Options.

NanoSim also allows you to customize your interactive simulation environment using the set_cmd_env and set_cmd_mode configuration commands.

This chapter contains the following topics:■ Invoking NanoSim at the Command-line■ Tailoring your Analysis with the Command-line Options■ Describing a Circuit with a Netlist File■ Performing a Simulation Using a Configuration File■ Describing Basic Configuration Commands■ Using Stimulus Files■ Creating the Environment File (.epicrc)■ Running a Basic Simulation


Chapter 4: Getting Started at the Command-lineInvoking NanoSim at the Command-line

■ Understanding Simulation Messages■ Describing Return Codes After Execution

Figure 11 graphically represents the NanoSim environment.

Figure 11 The NanoSim environment

Invoking NanoSim at the Command-line

The nanosim command starts NanoSim from the command-line.

The syntax is as follows:

nanosim [option]

The command-line options let you tailor your power or timing analysis to fit your specific needs, as described in Table 12. For example, you can select the mode (batch or interactive) and how long to run the simulation.

The -n command-line option is the only required option. The -p (to specify the technology file) and -c (to specify a configuration file) options are optional, but frequently used.

Model LibrariesNetlist Files

Configuration NanoSim

Vector/Stimulus Files

NanoSimOutput Files

Display

Files Simulator

Technology Files


Chapter 4: Getting Started at the Command-lineInvoking NanoSim at the Command-line

See the following in Example 1:

Example 1 The nanosim -n command-line optionnanosim -n netlist.spi -c cfg -o test -p typ_tech*

If no configuration file is specified and you use a SPICE or HSPICE netlist, the use_sim_case configuration command with the l (lowercase letter L) argument specified is set as the default. This is because HSPICE is case-insensitive and sets all characters to lowercase.

Using the NanoSim Unified CSHRC File

To use the NanoSim unified CSHRC file, you must first source the CSHRC_ns file, which enables the NanoSim wrapper script to automatically detect a platform. If 64-bit code is desired for that platform, the NanoSim 64-bit environment variable must be set before launching NanoSim. See Example 2 for a sample.

Example 2 NanoSim Unified CSHRC Filesetenv NANOSIM_64 1

Viewing the nanosim Man Page

You can view the man page for the NanoSim command by typing the following command in Example 3 from the UNIX command-line at the location where NanoSim is installed:

Example 3 The “man” nanosim commandman nanosim

Choosing Between Batch Mode or Interactive Mode

NanoSim can be run in batch mode or interactive mode. The default is batch mode. In this mode, NanoSim runs to completion without intervention. To use NanoSim interactively, you must specify the -i option or type Control-c while the simulation is running (that is, after netlist compilation).


Chapter 4: Getting Started at the Command-lineTailoring your Analysis with the Command-line Options

Defining Parameters in the Environment File

NanoSim lets you define certain simulation environment parameters in the .epicrc file. The NanoSim simulator uses these parameters, but they can be overridden with options on the command-line. The syntax, description, and an example of this file are included in Creating the Environment File (.epicrc).

Tailoring your Analysis with the Command-line Options

The nanosim command-line options tailor your analysis. The NanoSim simulator processes the -n, -p, and -c (-C) command-line options before any other command-line options.

This section includes a list of the NanoSim command-line options, as shown in Table 12. It provides a short description of each option’s function, and when you should use it.

Table 12 NanoSim Command-line Option Descriptions

Option Function/Description

--version Prints the simulator’s banner that contains version information.

-aa Specifies the PSF format for the simulation waveform output file. Alternatively, you can use the set_print_format configuration command.

-A Starts the double-precision version of the simulator. You often need to use this option to simulate analog circuits.

-c configuration_file(s)

Specifies the names of the configuration files for this NanoSim run. If you do not specify this option, NanoSim can be run using the default values for all parameters.

-C configuration_file(s)

Specifies exactly as the -c option, except that all commands in the configuration files specified with this option are logged in the .log file.



-CR command_file_list Restores NanoSim’s configuration settings and logs all executed commands from the specified configuration files in a .log file. The command files listed here can only contain commands that are valid during the restore phase.

-cr command_file_list Restores NanoSim’s configuration settings. In the following example, cmdfile1 and cmdfile2 can only contain commands that are valid during the restore phase.

EXAMPLE:nanosim -n net.spi -c cfg -cr cmdfile1 cmdfile2

-d timing_mode By default the simulator uses piecewise linear (PWL) mode. This option changes the timing mode in which the simulator runs.

Choose one of the following modes:■ t (or rc) = full-delay (rc) mode■ u (or ud) = unit-delay mode

NanoSim’s full-delay mode uses the RC model by default to channel connected stages except where determined by the automatic selection methods. You can also use the set_sim_mode rc configuration command setting to turn on full-delay mode.

NanoSim unit-delay mode simulates circuits using a uniform timing delay for all events. This mode requires no delay calculation; therefore, it can simulate a circuit at a speed of two to twenty times faster than the full-delay mode. You can also use the set_sim_mode ud configuration command setting to enable unit-delay mode.

You can also specify the simulation mode setting by using the delay_mode keyword in the .epicrc file.

Table 12 NanoSim Command-line Option Descriptions (Continued)




-DFM Enables the debugging mode for ADFMI modeling. Place it after the model names in the command line.

EXAMPLE:nanosim -n buf4.spi -c cfg -fm buf4.c -DFM

For more details on how to use the ADFMI-based C models, see the NanoSim Modeling Guide for ADFMI and Verilog-A.

-F Forces the simulator to use less rigorous setups for digital circuits to improve simulation speed. This option should not be applied to analog circuits.

-fm adfmi_file(s) Specifies files that contain ADFMI-based C models. You can use the full name of the model files, with the .c or .o extension, but it is not required. This option does not force a recompilation of the .c file if the .o file is newer. For details on how to use the ADFMI-based C models, see the NanoSim Modeling Guide for ADFMI and Verilog-A.

-FM adfmi_file(s) Specifies files that contain ADFMI-based C models. You can use the full name of the model files, with the .c or .o extension, but it is not required. This option forces a recompilation of the .c files. For details on how to use the ADFMI-based C models, see the NanoSim Modeling Guide for ADFMI and Verilog-A.





-fm_user_lib libFuncModel

Specifies the complete path to the global model library. You can specify any path name to be used as the libFuncModel.so or you can specify a list of pre-compiled shared libraries with user-defined global names as arguments. By specifying a list, you can have multiple RegisterUserModel() settings in different libraries. The shared libraries are loaded in the order they appear in your list. All models are loaded only once. NanoSim issues a warning if any shared library is found to be incompatible (for example, 32-bit versus 64-bit), and skips loading the incompatible library. Libraries without either RegisterUserModel or RegisterUserModel2 are also skipped.

-fm_user_lib libFuncModel (continued)

If the option is used along with -fm/FM, the libModel.so at the current directory is loaded before any shared libraries passed by -fm_user_lib. Note that you must build your own shared libraries and the suffixes might be different on different platforms.

EXAMPLE:nanosim -fm_user_lib /remote/cad/lib/ \libx3232.so

This option is equivalent to the user_libraries option in the .epicrc file.

-h Prints help information for all available command-line options.





-har [hilo_file_name] Starts Hierarchical Array Reduction (HAR). It takes one optional argument: the name of a hilo file.

There are several possible behaviors:■ If there is no argument to the -har command

then no hilo file is generated. The results from the setup phase of the run are overwritten by the results from the simulation phase.

■ If you put set_har_opt verbose in the configuration file, then the files from the setup phase are renamed with _har on the output suffix. For example, nanosim.out is renamed to nanosim_har.out.

■ If there is a hilo file name specified on the command line and the file does exist, the setup phase is skipped, and a note is printed to the .log file and to stdout stating that a hilo file was found and that the setup phase is skipped:

NOTE: NanoSim:0x50704407:No hilo file found. Running setup phase to generate the file.





-har [hilo_file_name](continued)

The verbose option has no impact in this case.■ If there is a hilo file name specified on the

command line and the file does not exist, the setup phase will be run to generate the hilo file.

■ If the name of the hilo file is not the same as the output file prefix plus .hl, the generated .hl file is given the name specified on the command line. A note is printed to the log file and stdout:

NOTE:NanoSim :0x50704407:Found hilo file junk.hl, proceeding to sim phase.

The verbose option has no impact in this case.

If no corecells have been defined with the define_har_corecell configuration command, an interactive session is launched that lists possible corecells.

-i

[time | config | partition]

Starts the interactive mode, which lets you control the NanoSim simulation interactively. If used, NanoSim enters the interactive mode after compilation and initialization at the specified simulation time, then prompts you for commands. The time at which interactive mode begins is one of the following:■ time—a specific length of time after the start

of simulation■ config—the start of reading the configuration

files■ partition—the start of the circuit

partitioning phaseThe default value is time=0ns. For more information on interactive commands, see Chapter 5, “Using Configuration and Interactive Commands.”

-include_path Specifies the search path for “include” statements.





-L library_paths Specifies the search order when a subcircuit cell (for example, inv) is encountered: (1) Reads the input file, including any .INC or .LIB files, for a subcircuit with the specified cell name; (2) Searches the directories, specified by the -L option, for cell_name.xxx, while .xxx could be any NanoSim-supported SPICE file extension such as .spi or .spec.

-L path1 path2 path3 ...

Specifies the search order for subcircuit cells for multiple paths.

NOTE: Do not use -L more than once

with the multiple path names.

-m main_circuit_name Specifies the top-level subcircuit to be simulated. It allows you to change the top cell for design simulation. All elements in the orginal top are ignored, other than stimulus and voltage source elements. This option is not necessary if your top-level circuit is not in a subcircuit definition.

-n [format] netlist(s)

Specifies the netlist format and the netlist file containing the input netlist and stimulus descriptions for NanoSim. The [format] argument can be any one of the following: cspf (Cadence SPF), eldo (Eldo), hspice (HSPICE), out (NanoSim), spectre (Spectre), vec (vector files), and vlog (Verilog).

EXAMPLE 1:-nhspice net -nvlog net1

This example instructs the netlist compiler to compile the net file using the HSPICE netlist format, and compile the net1 file using the Verilog netlist format.





-n [format] netlist(s) (continued)

EXAMPLE 2:-nvec file1

This example tells the netlist compiler that file1 is a vector file. The vector file must contain the type and signal commands. For details, see the Circuit Simulation and Analysis Tools Reference Guide.

If the use_sim_case command is not used, lowercase is the default for SPICE netlists except Spectre netlists. The default for all other netlists, such as Verilog, is case sensitive. If both SPICE and other netlist formats are used, the default will be case sensitive.

NOTE: HSPICE is the default netlist format, if the -n option is used without format specifications.

NOTE: NanoSim supports netlists in compressed format (.gz or .Z).

-neldo netlist(s) Specifies the standard Eldo syntax.

-neldoplus netlist(s) Specifies the extended Eldo syntax.

-o out_prefix_name Directs the simulation output files to be saved with the specified prefix.

EXAMPLE:-o myfile

This example sets the prefix name for output files to myfile.

The default prefix is nanosim.





-out out|fsdb|cou|wdb|wdf custom_format_name

Specifies the format of the simulation waveform output file. There are three ways to choose a waveform output format: ■ Use this command-line option■ Use the set_print_format configuration

command■ Use the print_format option in the .epicrc

file.

-outclname custom_library_name

Specifies the library name for your custom output API.

-outclpath custom_library_path

Specifies path and name of the shared library containing your custom waveform output API.

-outpostfix output_file_postfix

Specifies the postfix of the custom waveform output files.

-p techfile [techfile2]...

Specifies the name of the technology file for the simulation. The technology file describes the key features of the process technology that NanoSim uses to predict the transistor behavior in the circuit.

EXAMPLE:nanosim -n netlist -p tech.tt.25.5

This example instructs the simulator to use the tech.tt.25.5 file as the technology file for the current simulation. If the techfile file does not exist, but techfile.Z (a compressed technology file) does, NanoSim uses the techfile.Z file.

If you are using BSIM1, BSIM2, BSIM3 v3, BSIM4, MOS9 (HSPICE level 50), MESFET, or JFET models, you do not need to specify a technology file.

The contents of the technology file and its automatic generation from your SPICE models are described in the Circuit Simulation and Analysis Tools Reference Guide.





-Q Specifies ‘quiet mode’, which suppresses the printing of warning messages to stderr or the .log files.

-q Suppresses the printing of all warning messages to the stderr (to the screen).

-r always | never | compare | warning

Controls the process by which NanoSim automatically generates technology files for HSPICE netlists. It is not required for automatic technology file generation to work. Only one keyword can be specified.

Keyword Definition

always Generates a technology file for each simulation run, if necessary.

never Does not generate a new technology file if specified technology files already exist. This is the default.

compare Regenerates technology files only if the models in the netlist are different from the models in the technology file.

warning Issues a warning if the models in the netlist are different from the model in the technology file. The technology files are not automatically generated in this case.

For more details, see the Circuit Simulation and Analysis Tools Reference Guide.

-t time Specifies the simulation end time in nanoseconds. If not specified, the default is 1000 ns.





-u customize.c Specifies a customized source code file. This option does not force a recompilation of the .c file if the .o file is newer. For information on how to modify the default customize.c file that comes with the simulator, see the Circuit Simulation and Analysis Tools Reference Guide.

-U customize.c Specifies a customized source code file. This option forces a recompilation of the .c file if the .o file is newer. For information on how to modify the default customize.c file that comes with the simulator, see the Circuit Simulation and Analysis Tools Reference Guide.

-W max_messages Specifies the maximum number of warning messages to be printed. A per-message limit is not provided. For a per-message limit, use either the set_mesg_opt or limit_mesg_byidx configuration commands.

-w When specified, the simulator waits for you to respond to each warning message.

-y Turns on the warning message printing for unused netlist ports.

-z prefix Starts the automatic technology-file-generation feature for HSPICE netlists. It also names or designates the technology files to be used for a particular simulation run. Prior to the first simulation run, NanoSim automatically generates new technology files and names them using the specified prefix. In subsequent runs, the simulator reuses the specified technology files or, if necessary, regenerates a new technology file.

For details, see the Circuit Simulation and Analysis Tools Reference Guide.




Chapter 4: Getting Started at the Command-lineDescribing a Circuit with a Netlist File

Describing a Circuit with a Netlist File

The netlist file describes the system or circuit to be simulated, and is required to run a simulation. The following formats are accepted by NanoSim: HSPICE/SPICE, Verilog, and Cadence SPF. More than one netlist, with the same or different formats, can be specified simultaneously; for example, you can combine SPICE and Verilog in the same run. If a format is not specified, NanoSim uses the file extension to determine the format. For information on supported netlist formats and their corresponding extensions, see the Circuit Simulation and Analysis Tools Reference Guide.

Using HSPICE/SPICE Format

If a netlist file with an .sp or .spi extension is used, the parser assumes the netlist is in an HSPICE format and sets all nodes and elements to lowercase. Do not use case-sensitive node names and element names if you are going to use SPICE netlists.

If a SPICE netlist is not specified, the netlist input, by default, is case-sensitive. You can override this default setting with the use_sim_case configuration command.

NanoSim is capable of recognizing .measure commands in HSPICE netlists. For more information about HSPICE netlist commands, see the Circuit Simulation and Analysis Tools Reference Guide.

Using Other Formats

For information on supported netlist formats, see the Circuit Simulation and Analysis Tools Reference Guide.

Performing a Simulation Using a Configuration File

The configuration file contains information that tells NanoSim how to perform the simulation. Any number of configuration files, including none, can be used.

Configuration File Parameters

The configuration file contains run parameters data:


Chapter 4: Getting Started at the Command-lineDescribing Basic Configuration Commands

■ Nodes to display during simulation (analog or digital values)■ Power analysis to be performed■ Timing checks to be performed■ Circuit modification■ Simulation accuracy control

Describing Basic Configuration Commands

This section includes a list of the most commonly used NanoSim configuration commands, as shown in Table 13. It also provides a short description of the command’s function and when you should use it. You can view the man page for these commands by typing the following command from the UNIX command-line at the location where NanoSim is installed:

man command_name

Table 13 NanoSim Configuration Command Descriptions

Configuration Command Function/Description

add_node_cap Adds capacitance to a node. This command is intended for debugging purposes when you are doing a “what-if” test.

■ get_cmd_help■ help

Interactive commands used to get a detailed description of a command’s syntax and usage.

■ get_elem_i■ iget_elem_i

Prints the instantaneous element current to the screen during simulation, by specifying the element name or index, respectively.

■ get_elem_iavg■ iget_elem_iavg

Prints the average drain current, by element name or index, to the screen in interactive mode.

■ get_elem_irms■ iget_elem_irms

Prints the RMS drain current to the screen in interactive mode.

■ get_elem_ipeak■ iget_elem_ipeak

Prints the peak drain current to the screen in interactive mode.



■ get_node_i■ iget_node_i■ get_node_iavg

These node-based commands retrieve the same type of information as the previous eight element-based commands.

get_sim_time An interactive command that prints the present time when the simulation was stopped.

■ print_node_logic■ iprint_node_logic

Prints the logic waveforms of specified nodes by name or index, respectively. These commands can be used in the interactive mode.

print_node_v Prints the voltage waveforms of specified nodes.

print_branch_didt1 Prints the time derivative of the current for analysis of ground or power supply bounce issues for bondwire inductance.

■ print_branch_i1■ print_branch_i2■ print_branch_i3■ print_branch_i4

Print branch currents for drain, gate, source and bulk nodes of MOS transistors. These commands follow the HSPICE rules for nodes 1, 2, 3, 4.

■ quit_sim■ quit

Quits the simulation.

■ report_block_powr■ report_branch_i■ report_branch_powr■ report_ckt_dcpath■ report_ckt_leak■ report_node_i■ report_node_powr

Print reports to the .log file. You can use them for doing power diagnostics as well as obtaining power reports.

■ save_ckt_state■ restore_ckt_state

Saves the state of a circuit and restores it later. This avoids the simulation time to set up a circuit in a predetermined state such as a reset condition for subsequent simulations that start from that condition.

set_bus_nt Sets the correct bus notation characters for digital simulation vectors.

Table 13 NanoSim Configuration Command Descriptions (Continued)




set_dcpath_thresh Modifies the threshold for DC path checking.

■ set_node_atcut■ set_node_memcut■ set_node_vppcut

Cuts the partitioning of large partitions for circuits containing charge pumps, memories, and other large stages.

■ set_node_gnd■ set_node_vdd

Set nodes to vdd and gnd that have node names that are not the standard keywords “vdd” and “gnd”.

set_node_ic Sets a node to a given initial voltage if needed.

set_node_v Sets a node to a given voltage. Use this command when a SPICE-type DC source is not used to set a node to a voltage.

set_print_vres Changes the voltage printing resolution from the default of 10 mv.

set_print_tres Changes the minimum printing timestep from the default of 100 ps.

■ set_sim_spd■ set_sim_esv

Change the global spd (timestep estimation parameter) and the global esv (event sensitivity voltage) from the defaults. Changing these values affects the entire simulation.

set_sim_tres Changes the minimum allowable timestep for event generation.

set_sim_mode Forces the simulator into another simulation mode such as the RC mode or UD (unit delay) mode.

set_vec_opt Sets the voltage levels for digital vectors. Use this command when you have mixed power supply voltages.

■ tv_node_edge■ tv_node_setup■ tv_node_hold■ tv_node_pulsew

Use these commands to check for timing violations.




Chapter 4: Getting Started at the Command-lineDescribing Key Features with a Technology File

Describing Key Features with a Technology File

The technology file describes the key features of the process technology that NanoSim uses to predict the transistor behavior in the circuit. This technology file is created using a utility called Gentech. It can be created automatically or manually.

For information on how to automatically create a technology file, and manually running the Gentech utility, see the Circuit Simulation and Analysis Tools Reference Guide.

If you are using BTA HVMOS, BSIM1, BSIM2, BSIM3 v.3, MOS9 (HSPICE level 50), MESFET, or JFET models, you don’t need to specify a technology file. NanoSim creates the technology data lookup tables at run time.

Using Stimulus Files

Stimulus information can be placed inside the netlist or included on the command-line as a separate file. Types of stimulus include SPICE piecewise linear (PWL) or PULSE waveforms, clk or tgl patterns, and digital vector files.

To learn more about stimulus types, see the Circuit Simulation and Analysis Tools Reference Guide.

Creating the Environment File (.epicrc)

A file named .epicrc can be used to specify most of the command-line options for the nanosim command. Although not required, this environment file is recommended for specifying options that are used frequently.

NanoSim searches for the .epicrc file in three directories in the following order:

use_sim_case Changes the case sensitivity to lower or upper or retains the case sensitivity, as needed. You can also use one of the following aliases:case l or case u




Chapter 4: Getting Started at the Command-lineCreating the Environment File (.epicrc)

1. Your current working directory

2. Your home directory

3. The Synopsys installation directory, as defined by $EPIC_HOME

If there are multiple .epicrc files in these directories or command-line options to control the settings, the precedence in descending order is

1. Command-line option settings

2. The .epicrc file settings in your current working directory

3. The .epicrc file settings in your home directory

4. The .epicrc file settings in $EPIC_HOME

Caution!

If a file named .epicrc already exists in your home directory for a different simulator, a warning message is printed when NanoSim is run.

Using NanoSim Command-line Options in .epicrc

See Table 14 for the NanoSim command-line options and their corresponding keywords in the .epicrc file.

Table 14 NanoSim command-line option keywords in .epicrc

Command-Line Option Corresponding Keyword in the .epicrc File

-A analog_mode

-c config_filesdefault_config_files

-d delay_mode

-F no_ace

-fm user_adfm_obj_modules

-FM user_adfm_obj_modules_force

-L cell_lib_path

-m top_cell


Chapter 4: Getting Started at the Command-lineCreating the Environment File (.epicrc)

The -c command-line option does not override the default_config_files keyword, instead, they are concatenated.

You can use the user_libraries keyword, which does not have a corresponding command-line option, to specify the full path to the libFuncModel library, which is used with built-in ADFMI models. See the NanoSim Modeling Guide for ADFMI and Verilog-A for more information on the libFuncModel library.

-n netlist_files

-o output_prefix_name

-out print_format

-outclname output_custom_library_name

-outclpath output_custom_library_path

-outpostfix output_postfix

-p technology

-t running_time

-u user_obj_modules

-U user_obj_modules_forceuser_libraries

Table 14 NanoSim command-line option keywords in .epicrc (Continued)

Command-Line Option Corresponding Keyword in the .epicrc File


Chapter 4: Getting Started at the Command-lineRunning a Basic Simulation

Sample .epicrc File

A comment line begins with a semicolon (;) in the .epicrc file, as shown in Example 4:

Example 4 Comment line in .epicrc file example; This is a sample .epicrc file.nanosim:netlist_files:dram.netnanosim:config_files:cfgnanosim:running_time:1000nanosim:output_root_name:dramnanosim:technology:techfilenanosim:user_adfm_obj_modules:dram.onanosim:analog_mode

Running a Basic Simulation

This section describes the procedure for running a basic NanoSim simulation in batch mode:

1. Set up your environment so you can access the directory that contains the current NanoSim release.

2. Ensure that the following input files are in your current directory:

- An .epicrc file (optional)

- Netlist files in any supported format, including SPICE (xxx.spi), and HSPICE (xxx.spi)

- Technology files (optional)

- Configuration files (optional)

- Stimulus files (optional)

3. Create a run script for your simulation. This script should contain the nanosim command with the appropriate options specifying your input files: nanosim -n adder.spi -c cfg -p techfile -o adder

4. Give the script a meaningful name such as runns or runns.scr.

5. Run the simulation by entering the name of the run script: runns

These output files are generated: adder.log, adder.err, and adder.out.


Chapter 4: Getting Started at the Command-lineUnderstanding Simulation Messages

6. View the output files with the nWave waveform viewer. To do so, type in the name of the viewer followed by the name of the output file you want to view: nWave -f adder.out

Understanding Simulation Messages

Before and during a simulation run, NanoSim produces messages that scroll up the screen telling you what the simulator is doing during different phases of the simulation.

Describing Return Codes After Execution

The NanoSim simulator produces a return code after a simulation is complete. This code is found using a UNIX shell script, and appears as a number between 0 and 25.

Example 5 shows a script that is used to read the return codes:

Example 5 Script for return codesecho $status

See Table 15 for the NanoSim return codes and their corresponding definitions.

Table 15 NanoSim return codes

Return Code Definition

0 Normal exit after completing simulation.

1 Simulation halted due to assert() defined in the assert.h C header file. The name of the file and line number containing the errors are identified.

2 Simulation halted due to epic_assert( ). The file name and line number containing the error are identified.

3 Generic error. A message identifies the error.

4 Exit after calling on_error, which prints out program statistics.


Chapter 4: Getting Started at the Command-lineDescribing Return Codes After Execution

5 Unable to build an executable code.

6 Code used for debugging an internal error.

7 Environment file contains errors.

8 A required file cannot be opened normally.

9 Netlist compilation failed.

10 Required license is not available.

11 Not enough memory available.

12 Floating point arithmetic error.

13 Program interrupt signal received.

14 System signal could not be handled.

15 Unrecognized program name.

16 Vector file contains errors.

17 Configuration command parsing failed.

18 EM code execution failed.

19 Node capacitance calculation failed.

20 RC delay calculation failed.

21 Unit-delay code execution failed.

22 XL code execution failed.

23 Errors occurred while parsing command-line arguments.

24 Unauthorized products used.

25 Illegal error code passed to the exit function (Synopsys internal error).

Table 15 NanoSim return codes (Continued)

Return Code Definition


55Using Configuration and Interactive Commands

This chapter provides an overview of the NanoSim configuration and interactive commands, including the categories of the commands.

Overview

You may not know which command is best for you to use. For a complete description of each specific command, type

man command_name

at the NanoSim command line prompt.

NanoSim includes commands that are part of the built-in Analog Circuit Engine (ACE) feature, which allows you to perform accurate SPICE-like circuit simulation on much larger designs than those traditionally handled by SPICE. (The ACE feature is included in the NanoSim license—you do not need to purchase a special option license.)

The following design types benefit the most from simulation with the ACE feature:■ Analog and mixed-signal designs■ Different types of memories and associated circuitry■ Designs with cross-coupled capacitances, including layout extracted

capacitances■ Very low-power designs that require highly precise current and voltage

measurements


Chapter 5: Using Configuration and Interactive CommandsOverview

This chapter contains the following topics:■ Specifying Command Arguments■ Changing the Units■ Reducing Ambiguity with Argument Tags■ Controlling Conventions for Simulation Parameters■ Reporting Conventions for Node and Branch Currents■ Categorizing the Configuration Commands■ Categorizing the Interactive Commands■ Defining the Man Page Commands

Configuration Files

The configuration file contains information that tells the NanoSim simulator how to perform the simulation. Any number of configuration files (including none) can be used.

Important:

Configuration commands and parameters are case-sensitive!

The configuration file contains the following information:■ Nodes to display during simulation■ Power and timing analyses to be performed■ Circuit modification■ Simulation accuracy control

Configuration File SyntaxIn a configuration file, the following syntax and conventions apply:■ Comments are preceded by a semicolon (;).■ Commands are line-oriented.■ If there are more than 1024 characters and spaces in a configuration

command line, the line must be broken into smaller segments.■ Continue data on the next line by terminating the current line with a space

and a back slash ( \).



■ If the same command is used more than once in the same configuration file, the settings in the later command overwrite those in the earlier command.

■ Pattern matching for node and instance names in the configuration commands supports wild cards and regular expressions. By default, patterns are “glob” style patterns as used in the Bourne and C shells. A pattern enclosed by double quotes is treated as a regular expression. A pattern enclosed in single quotes is treated literally. You can use a full hierarchical pin name to match a node name in your design. The pin can be at any level of the hierarchy and can be a transistor port (gate, drain, or source).

Table 16 describes a set of identifiers used to show how a pattern matches these identifiers.

The identifier set: {bus1, bus[], bus[2], bus[163], bus*, bus9+}

Describing the Interactive Mode Using the help Command

The interactive mode is a powerful debugging environment that provides many commands for examining the dynamic response of a circuit during a simulation. For information on all of the commands available in the interactive mode, you can specify the get_cmd_help interactive command, or simply help, at the interactive mode prompt. The simulator will display a list of available

Table 16 Identifier Descriptions

Pattern Description

bus* * is a wild card, so bus* matches all identifiers in the set.

bus? ? is a wild card, so the pattern matches bus1 and bus*.

‘bus*’ This pattern is treated literally, therefore, it matches only bus*.

‘bus[*]’ This pattern is treated literally, therefore, does not match anything in the set.

bus\* In this case, * is treated literally, therefore, it matches only bus*.

“bus\[[0-9]+\]” This is a regular expression that matches bus[2] and bus[163].



commands. When the list appears, you can enter the name of a specific command to get a detailed description of that command. You can also use the print_cmd_help command to print a list of commands, with abridged or detailed descriptions, to a given output file.

The following list highlights some features of the interactive mode:■ Accessing the Interactive Mode

You can move from batch mode to interactive mode using three different methods:

■ Send the simulation an interrupt signal, usually Control-c.

This is useful if you start the simulation in batch mode and want to take a look at its status. You can use the set_cmd_env command to customize the interrupt signal.

■ Specify the -i command-line option with the nanosim command. You can use this method to enter the interactive mode at a specific simulation time.

■ Apply the breakpoint and error handling commands (set_time_break, set_node_break, set_elem_break, handle_ckt_error) to enter the interactive mode whenever specific conditions occur.

You can use the cont_sim command to return the simulation to batch mode:■ Using Aliases

You can assign an alias to any interactive commands (see the make_cmd_alias and delete_cmd_alias commands).

■ Using Node and Element Indexes

An internal index is associated with each node and element. You can use these node or element indexes, instead of a long hierarchical name, with any of the interactive commands that are prefixed with the letter i such as iget_node_conn or iforce_node_v.

■ Creating an Interactive Log File

The actions you perform while in the interactive mode are not logged to the .log file. You can open an interactive log file using the open_intr_log command to create a record of these actions.

Finding Alias Command Information using the help CommandFor many configuration commands, there are corresponding alias commands. You should avoid using these alias commands whenever possible, but in cases when you must, you can review the functionality and description of the alias


Chapter 5: Using Configuration and Interactive CommandsSpecifying Command Arguments

command by entering the get_cmd_help interactive help command at the command line.

To discover if a command is actually an alias, you enter

help command_name

The full description of the corresponding configuration command displays.

Finding Index Numbers

You can use the get_node_info and get_elem_info configuration commands to find the index numbers for nodes and elements, respectively.

Example 6 shows sample data reported by the get_elem_info command.

Example 6 Sample data produced by the get_elem_info commandVer 2001.06 > get_elem_info

x1.x1.x8.mn2

x1.x1.x8.mn2 (23:NMOS) (OFF) G = x1.x1.8(9): 0|D = gnd(1): 0|S = gnd(1): 0|B = gnd(1): 0 ratio=1.01 w=20u l=19.8u ad=100.00p as=100.00p pd=50.0u ps=50.0u m=1.00

Specifying Command Arguments

This section describes the way in which you should specify command arguments.

Argument Unit

You can specify an argument with or without a unit definition. This increases the readability and flexibility of argument specification. The set_print_tres configuration command is used in the following example to illustrate this feature:set_print_tres 0.01ns

In this example, the value 0.01ns is a time argument for the set_print_tres command.



It consists of three tokens:■ A numeric value: 0.01

■ A unit prefix: n, which means nano or (see Table 17 in this section)

■ A unit symbol: s, which means seconds(see Table 18 in this section)

Spaces are not allowed between the units.

Unit Prefixes and SymbolsTable 17 lists unit prefix symbols. These prefixes are case-insensitive.

Table 17 Unit prefix symbols

Unit Prefix Symbol Multiplier

atto a

femto f

pico p

nano n

micro u

milli m

centi c

deci d

hecto h

kilo k

109–

1018–

1015–

1012–

109–

106–

103–

102–

101

102

103



Table 18 lists the default interface (input) units based on the International System of Units (SI).

Specifying a UnitYou can specify a unit in two ways:■ Use a number without a unit prefix and unit symbol (for example, 1.6e-8 or

0.0032). The default unit (or the unit set by the set_sim_unit command) is applied to these numbers.

■ Use a number with a unit prefix, with a unit symbol, or with both a unit prefix and a unit symbol. The default unit (or the unit set by the set_sim_unit command) will not be applied to these numbers.

mega meg

giga g

tera t

Table 18 Default interface input units

Quantity SI Unit Symbol

capacitance farad F

current ampere A

inductance henry H

length meter m

resistance ohm O (Ω)

time second s

voltage volt V

Table 17 Unit prefix symbols

Unit Prefix Symbol Multiplier

106

109

1012


Chapter 5: Using Configuration and Interactive CommandsChanging the Units

For example, a voltage argument can be written as 16e-3uV (16 nanovolts), 16e-9V (16 nanovolts), 16n (16 nanovolts), as shown in Example 7:

Example 7 Voltage argument exampleset_print_tres 0.01nsset_print_tres 0.01nset_print_tres 0.00000000001set_print_tres 10e-12set_print_tres 1e-11

All of the preceding commands in Example 7 are equivalent. The third command, which uses the value 0.00000000001 without a unit prefix or unit symbol, uses the default unit of seconds.

Changing the Units

If you prefer to use units that differ from the default settings, use the set_sim_unit command to change them. This command can be used in a configuration file or in interactive mode and can be specified as often as you like:

set_sim_unit time=1ns

This example sets the default argument time unit to nanoseconds, instead of the default unit of seconds.

Consequently, all of the following commands in Example 8 are now interpreted as set_sim_tres 0.01ns:

Example 8 Setting the default argument timeset_print_tres 0.01set_print_tres 1e-2set_print_tres 0.00001usset_print_tres 0.01ns

You can reduce ambiguity and increase readability by using a unit prefix.

Note:

The set_sim_unit command affects only those numbers specified without a unit prefix (n, m, u, etc.). If a unit prefix is used with a number, the units are assumed to be the standard units (s, V, F, A, etc.). Unit prefix scale


Chapter 5: Using Configuration and Interactive CommandsReducing Ambiguity with Argument Tags

factors do not multiply the set_sim_unit scale factor. That is, if units for time = 1ns is set, then 1n = 10e-9s or 1=10e-9s; 1n is not equal to 10e-18s.

Reducing Ambiguity with Argument Tags

To reduce the ambiguity caused by optional arguments or various syntax formats, many arguments have tags. The following example command uses several argument tags:

set_print_window period=100ns start=25n end=238ns on_time=30ns

This example uses four arguments with argument tags. The first argument, period=100ns, consists of an argument tag period= and an argument value 100ns. The argument tag always ends with a special token “=”.

Controlling Conventions for Simulation Parameters

A (case-sensitive) simulation parameter can be adjusted by the interaction of configuration commands.

The following conditions might change parameters from their default value:■ Commands that explictly adjust the parameter (for example,

set_print_tres, set_print_ires, set_sim_spd)■ Macro-commands that are equivalent to a set of configuration commands

(for example, set_sim_ires) ■ Conditions that change parameters (for example, if supply voltage is less

than or equal to 3V, global spd is reduced from the default 0.5V to (0.1*(supply voltage))


Chapter 5: Using Configuration and Interactive CommandsReporting Conventions for Node and Branch Currents

Here are the conventions controlling when and how parameters are altered in NanoSim: ■ If B and C try to adjust a parameter at the same time, NanoSim picks up the

one that generates the result with the highest accuracy. For example, to measure delay (meas_n2n_delay) in a circuit with supply voltage less than 3 volts, spd is assigned as the smaller value of 0.1V and (0.1*supply_voltage).

■ If a command appears several times in the configuration file, the last one determines the parameter's value. For example, if there are two set_print_tres commands, the second one overwrites the first one.

Reporting Conventions for Node and Branch Currents

When printing and reporting branch currents, NanoSim uses a syntax similar to HSPICE and SPICE conventions for specifying the direction of current flow for MOS, JFET and BJT devices. For the other devices, refer to the following figures for the current direction conventions.

The arrows in the six following figures show the direction of positive current in both HSPICE and NanoSim.

Figure 12 Direction for positive current flow — Capacitor



Figure 13 Direction for positive current flow — Diode

Figure 14 Direction for positive current flow — Inductor

Figure 15 Direction for positive current flow — Resistor



Figure 16 Direction for positive current flow — MOS

Figure 17 Direction for positive current flow — BJT

Mapping Element Branch Currents

Element branch currents are specified using the HSPICE conventions for i1, i2, i3, and i4 currents. Table 19 shows branch current mapping for most elements supported by NanoSim.

Table 19 Branch Current Mapping

Current Element Type Branch

i1 MOS, JFET, and MESFET Drain

BJT Collector

Resistor, inductor, diode, and voltage source

Negative Terminal



For some devices (MOS, JFET, MESFET, BJT, and diode), NanoSim provides an additional current called idc or i5. This current is equivalent to i1 in the DC limit (or i1 without capacitive contributions). Figure 18 illustrates the relationship between i1 and idc for a MOSFET and diode.

Figure 18 Comparison of il and idc current

i2 MOS, JFET, and MESFET Gate

BJT Base

Resistor, inductor, diode, and voltage source

Positive Terminal

i3 MOS, JFET, and MESFET Source

BJT Emitter

i4 MOS Bulk

BJT Substrate

Table 19 Branch Current Mapping (Continued)

Current Element Type Branch

idc

icsicd

is = idc + icsid = idc -iIcd

idc

ic

i1 = -idc -ic i2 = idc + ic



Figure 18 also shows the MOS parasitic capacitances as simple lumped capacitances to ground, the actual details of the capacitance modeling depends on the capacitance model used for the device. See set_elem_acc and set_elem_sms.

To improve simulation performance, in some cases the capacitive contributions to the MOSFET currents might be ignored (see the set_powr_acc command). In this case,

i1 = idrain = idci3 = isource = -idci2 = igate = 0i4 = ibulk = 0

Reporting Node Currents

NanoSim reports node currents using one of two conventions, depending on whether the node is a source node or an internal node:■ Source Nodes

The current reported is the current supplied by the source. Positive current is defined as current flowing into the node. In this case, the node capacitance to ground is ignored when calculating the node current.

■ Internal Nodes

Kirchhoff’s laws require the sum of all currents into the node to equal zero. In this case, the reported current is the sum of all positive branch currents flowing into the node, including the current due to node capacitance to ground.

The two cases are illustrated as follows. The arrows, as shown in Figure 19, indicate the direction of current flow. The reported current for this node, using the applicable convention, is

source node: inode = i1 - i2internal node: inode = i1 + i3


Chapter 5: Using Configuration and Interactive CommandsCategorizing the Configuration Commands

Figure 19 Current flow for internal and source nodes

Categorizing the Configuration Commands

In this section, the (case-sensitive) configuration commands for the NanoSim simulator are grouped into the following categories and subcategories:■ Circuit Diagnosis■ Functional Detection■ Vector Checking■ Circuit Modification■ MOSFETs■ Nodes■ Circuit State Modification■ Miscellaneous Circuit Modifications■ DC Initialization■ Hierarchical Array Reduction (HAR)■ Message Control■ Netlist Compilation■ Circuit Applications■ Output Reporting■ General Output Reporting

i1

i3

i2



■ Current Reporting■ Partitioning■ Cut■ Autodetection■ Simulation Control■ Accuracy and Speed■ Capacity■ Device Modeling■ Behavioral Modeling■ Simulation Mode■ Unit Delay■ Powernet■ Simulation Algorithm■ Vector Stimulus■ Timing Verification■ BDC■ Back-annotation

Note:

Not every available configuration command is listed in the following categories. Use the NanoSim GUI and Help files for the latest information and complete listings of the commands.

This section describes the command categories and their corresponding commands.

Circuit Diagnosis

The circuit diagnosis category includes commands that detect design problems that can result in functionality or power problems, or commands that control vector checking.



Functional DetectionTo detect behavior in a design that could lead to functionality or power problems, use the commands in Table 20:

Vector CheckingTo control the way in which vector checking is performed, use the commands in Table 21:

Table 20 Functional Detection Configuration Commands

limit_dcpath_search report_node_exv report_node_u

report_ckt_dcpath report_node_hotspot report_node_x

report_ckt_leak report_node_maxrf report_node_z

report_elem_exi report_node_multitoggle report_stage_info

report_elem_exv report_node_pulse set_dcpath_hiz

report_node_active set_dcpath_thresh

report_node_dangle report_node_quick set_exi_thresh

report_node_toggle set_hotspot_factor

Table 21 Vector-Checking Configuration Commands

vchk_node_edge vchk_node_opt

vchk_node_ignore vchk_node_window



Circuit Modification

The circuit modification category includes commands that modify your circuit, based on nodes or MOSFETs (and some miscellaneous circuit modification functions), including node capacitance and the width and length of MOSFETS.

MOSFETsTo modify the physical parameters of a circuit, use the commands in Table 22:

NodesTo modify node capacitance and connectivity, use the commands in Table 23:

Table 22 MOSFETs-modifying Configuration Commands

merge_mos_parallel set_mos_length set_mos_off

scale_mos_length set_mos_minrdiff set_mos_pd

scale_mos_width set_mos_nrd set_mos_ps

set_mos_ad set_mos_nrs set_mos_width

set_mos_as

Table 23 Node-capacitance Modifying Configuration Commands

add_node_cap no_node_wirecap

add_node_wirecap set_node_cap

modify_node_conn set_node_mincap



Circuit State ModificationTo modify node states, use the commands in Table 24:

Miscellaneous Circuit ModificationsFor various functions related to circuit modification, use the commands in Table 25:

DC Initialization

To set DC initialization parameters, set nodes to ground and Vdd, and set a node’s initial voltage, use the commands in Table 26:

Table 24 Circuit State Modifying Configuration Commands

force_node_logic restore_ckt_state set_node_vsrc

force_node_v save_ckt_state

iforce_node_logic set_node_gnd

irel_node_logic set_node_thresh

rel_node_logic set_node_v

rel_node_v set_node_vdd

Table 25 Miscellaneous Circuit-modifying Configuration Commands

add_bjt_gmin set_sim_subgroup

set_ckt_ctrl set_vec_opt

set_resistor_value

Table 26 DC Initializing Configuration Commands



Hierarchical Array Reduction (HAR)

To perform hierarchical array reduction on a circuit, use the commands in Table 27:

Message Control

To control the way in which warnings and messages are printed during the simulation run, use the commands in Table 28. You can also use these in the interactive mode:

set_dc_bjtv set_node_ic

set_dc_noclamp set_node_icx

set_dc_opt set_node_vsrc

Table 27 HAR Configuration Commands

define_har_corecell

set_har_opt

Table 28 Message Control Configuration Commands

limit_mesg_byidx set_sim_unit

limit_mesg_byphase

set_mesg_opt

Table 26 DC Initializing Configuration Commands (Continued)



Netlist Compilation

To control netlist compilation, use the commands in Table 29:

Circuit Applications

To control the application of configuration commands (that is, to which parts of the circuit they are applied) and produce simulation status reports, use the commands in Table 30:

Output Reporting

The output reporting category includes commands that print (to a file) information about nodes, blocks, and currents.

Table 29 Netlist Compilation Configuration Commands

set_bus_nt set_sim_hierid

set_eldo_cpp use_sim_case

Table 30 Circuit Application Configuration Commands

set_ckt_cmd set_sim_tup

set_inst_cmd

set_pattern_cmd



General Output ReportingTo control general output reporting options and parameters, use the commands in Table 31:

Current ReportingFor various types of current reporting, use the commands in Table 32:

Table 31 General Output Reporting Configuration Commands

match_node_alias set_print_filter set_v3cmd_opt

print_node_cap set_print_flush split_print_file

print_node_logic set_print_format set_tv_window

print_node_v set_print_opt

set_err_window set_print_tres

set_node_thresh set_print_vres

set_print_compress set_print_window

Table 32 Current Reporting Configuration Commands

assign_branch_i print_branch_i3 report_block_powr

assign_node_i print_branch_i3avg report_branch_i

print_branch_didt1 print_branch_i3rms report_branch_powr

print_branch_didt2 print_branch_i4 report_ckt_phist

print_branch_didt3 print_branch_i4avg report_node_i

print_branch_didt4 print_branch_i4rms report_node_ic

print_branch_didtdc print_branch_idc report_node_padnum



Partitioning

For various tasks associated with circuit partitioning, use the commands in Table 33:

CutTo cut partitions (stages) into smaller stages, use the commands in Table 34:

print_branch_i1 print_branch_idcavg report_node_powr

print_branch_i1avg print_branch_idcrms report_probe_i

print_branch_i1rms print_node_didt set_block_budget

print_branch_i2 print_node_i set_powr_acc

print_branch_i2avg print_node_iavg set_print_ipeak

print_branch_i2rms print_node_irms set_print_ires

print_port_i set_print_iwindow

print_probe_i

Table 33 Partitioning Configuration Commands

keep_nmos_gndgate set_mos_off

keep_pmos_vddgate set_stage_size

search_mos_keeper

Table 34 Cutting Configuration Commands

set_node_atcut set_node_vppcut

Table 32 Current Reporting Configuration Commands (Continued)



AutodetectionTo apply different autodetection rules to a simulation, use the commands in Table 35:

Simulation Control

The simulation control category includes commands that control different conditions for a simulation run. These commands allow you to manipulate individual nodes and elements, as well as the circuit as a whole.

Accuracy and SpeedTo control the balance between the accuracy and speed of a simulation, use the commands in Table 36:

set_node_memcut

Table 35 Autodetection Configuration Commands

search_ckt_analog search_ckt_mem search_ckt_ud

search_ckt_cpump search_ckt_msx set_stage_type

search_ckt_logic search_ckt_rc

Table 36 Accuracy and Speed Configuration Commands

set_analogvds_min set_node_spd set_sim_spd

set_acc_limit set_node_ssc set_sim_spmode

set_bjt_iter set_pwl_limit set_sim_ssc

set_ckt_subi set_sim_aesv set_sim_tres

Table 34 Cutting Configuration Commands (Continued)



CapacityTo control the capacity of a simulation, use the commands in Table 37:

Device ModelingTo control how a device is modeled, use the commands in Table 38:

set_elem_subi set_sim_aspd set_source_esv

set_mos_width set_sim_esv set_vds_min

set_node_esv set_sine_evp use_g_step

set_node_noclamp

Table 37 Capacity Configuration Commands

free_ckt_db

set_ckt_lns

Table 38 Device Modeling Configuration Commands

add_bjt_gmin set_diode_model set_sim_moslevel

reduce_elem_gridsize set_elem_acc use_mos_accbulk

set_analogfcap_param set_elem_quadratic use_mos_analytic

set_analogrelfcap_param set_elem_sms use_mos_chrgconserve

set_ckt_nodiffcap set_fcap_model use_mos_dcdiode

set_ckt_nogatecap set_fcap_param use_mos_diode

Table 36 Accuracy and Speed Configuration Commands (Continued)



Behavioral ModelingTo incorporate an ADFMI model into a simulation, use the commands in Table 39:

Simulation ModeTo select or change the simulation mode, use the commands in Table 40:

set_ckt_lns set_model_capop use_mos_gleak

set_node_accbulk use_mos_simplecc

set_relfcap_param use_mos_wnflag

Table 39 Behavioral Modeling Configuration Commands

set_bsrc_version swap_model_adfmi

set_veriloga_opt use_model_adfmi

set_veriloga_prof

Table 40 Simulation Mode Configuration Commands

set_elem_acc set_node_acc set_node_rc

set_elem_sms set_node_hscap set_node_ud

set_elem_sync set_node_pwl set_sim_mode

Table 38 Device Modeling Configuration Commands



Unit DelayTo modify a simulation using the unit-delay mode, use the commands in Table 41:

PowernetTo modify parameters for the power network search mode, use the commands in Table 42:

Simulation AlgorithmTo select the simulation algorithm, use the commands in Table 43:

Table 41 Unit Delay Configuration Commands

search_ckt_ud set_ud_opt

set_node_ud

set_node_udd

Table 42 Powernet Configuration Commands

set_powernet_default

report_powernet_info

Table 43 Simulation Algorithm Configuration Commands

set_sim_imna set_sim_trap

set_sim_mna



Vector StimulusTo control how vectors are applied to a circuit, use the command in Table 44:

Timing Verification

To do timing verification checks, use the commands in Table 45:

BDC

To generate block delay calculations (BDC), use the commands in Table 46:

Table 44 Vector Stimulus Configuration Commands

set_evcd_alias set_evcd_opt

set_evcd_bus set_vec_opt

Table 45 Timing Verification Configuration Commands

tv_node_edge tv_node_recovery tv_node_width

tv_node_hold tv_node_setup

tv_node_period tv_node_setuphold

tv_node_pulsew tv_node_skew

Table 46 The BDC Commands

add_model_port set_meas_designname

build_model_bdc set_meas_instname

define_n2n_cause set_meas_load

meas_n2n_delay set_meas_partialswing


Chapter 5: Using Configuration and Interactive CommandsCategorizing the Interactive Commands

Back-annotation

To use the back-annotation feature for your simulation, use the commands in Table 47:

Categorizing the Interactive Commands

The NanoSim Interactive Commands are grouped into the following categories: ■ Analysis and Trace■ Circuit Modification■ Execution Control■ Interactive Environment■ Output

meas_n2n_hold set_meas_pulsew

meas_n2n_setup set_meas_slope

meas_node_cap set_meas_thresh

print_meas_cmt set_meas_watch

print_meas_path set_meas_window

print_node_path

Table 47 Analysis and Trace Interactive Commands

set_ba_mode

Table 46 The BDC Commands (Continued)



■ Simulation Control■ Simulation Diagnostic

Although most of the configuration commands listed in the previous section can be interactively used, the commands listed in this section are most often used in the interactive mode.

Analysis and Trace

At a breakpoint, you can use any of the diagnostic commands to probe system conditions, trace back signal-event propagations, display partial results, and review node transitions within a time window.

To display formatted information on the screen, use the commands in Table 48:

Table 48 Analysis and Trace Interactive Commands

get_elem_i iget_node_i get_probe_irms

iget_elem_i get_node_iavg get_probe_ipeak

get_elem_iavg iget_node_iavg get_probe_iavg

iget_elem_iavg get_node_irms itrace_node_aconn

get_elem_irms iget_node_irms itrace_node_conn

iget_elem_irms get_node_ipeak itrace_node_trig

get_elem_ipeak iget_node_ipeak itrace_stage_conn

iget_elem_ipeak iget_node_peak trace_node_aconn

get_netlist_param get_probe_i trace_node_conn

get_node_conn get_probe_iavg trace_node_trig

iget_node_conn trace_stage_conn

get_node_i



Circuit Modification

To modify your circuit, including node capacitance, and the width and length of MOSFETS, use these commands in Table 49:

Execution Control

To control the execution (that is, starting and stopping) of an interactive-mode simulation, use these commands in Table 50. (The *_break commands are useful for monitoring the progress of a simulation):

Interactive Environment

To perform a variety of functions related to the setup and control of the interactive environment, use the commands in Table 51:

Table 49 Circuit Modification Interactive Commands

iset_mos_width

iset_node_cap

iset_resistor_value

Table 50 Execution Control Interactive Commands

cont_sim iset_node_break set_node_break

delete_intr_break list_intr_break set_time_break

handle_ckt_error quit_sim

iset_elem_break set_elem_break

Table 51 Interactive Environment Commands



Output

To print information about the logic state or the node voltage by index number, use the commands in Table 52. This information is printed in the .log file:

Simulation Control

To manipulate node voltages using node index numbers, use the commands in Table 53:

close_intr_log open_intr_log set_cmd_mode

delete_cmd_alias print_cmd_help

get_cmd_help read_cmd_file

make_cmd_alias set_cmd_env

Table 52 Output Interactive Commands

iprint_node_logic

iprint_node_v

Table 53 Simulation Control Interactive Commands

iforce_node_v

irel_node_v

Table 51 Interactive Environment Commands


Chapter 5: Using Configuration and Interactive CommandsDefining the Man Page Commands

Simulation Diagnostic

To report stages with more nodes than the specified limit, use the command in Table 54:

Defining the Man Page Commands

The command definitions documented in the man pages for NanoSim include the following information:■ Command syntax.■ Descriptions of each argument, keyword, and value associated with the

command, including default values for all arguments.■ Command examples, including graphical representations, where needed.■ A list of related commands under the “SEE ALSO ” heading.

For a complete description of a specific command, type the following command at the NanoSim command line prompt:

man command_name

Note:

Configuration commands that require a BDC license are also documented in the man pages.

Table 54 Simulation Diagnostic Interactive Commands

report_stage_large


Chapter 5: Using Configuration and Interactive CommandsDefining the Man Page Commands


66Applying Simulation Control

This chapter describes a number of configuration commands for controlling simulation.

Overview

This chapter contains the following topics:■ Controlling Accuracy and Performance Using the set_sim_eou Command■ Using a Single Command for Leakage Current Simulation■ Creating a Balanced Simulation■ Controlling Node Sensitivity and Time Step■ Controlling Waveform Print Resolution■ Applying Multiple Simulation Modes■ Activating Double-Precision Mode■ Simulating BJTs

Controlling Accuracy and Performance Using the set_sim_eou Command

The set_sim_eou ease-of-use (EOU) command enables you to easily control the simulator and implement your specifications for accuracy and performance.

You can directly address issues of simulation accuracy and performance using the set_sim_eou sliding-scale type variable. This sliding-scale variable enables you to adjust the desired accuracy vs. performance simulation trade-off.


Chapter 6: Applying Simulation ControlControlling Accuracy and Performance Using the set_sim_eou Command

The syntax for set_sim_eou follows:

set_sim_eou sim=1|2|3|4|5|6|7 model=1|2|3|3.5|4|5|6|7 net=1|2|3|4|5|6|7

The sliding-scale trade-off is summarized in Table 55:

The set_sim_eou command controls NanoSim simulation engine accuracy (sim option) and NanoSim MOS modeling accuracy (model option) during circuit simulation. An additional EOU option is available that controls the NanoSim netlist commands (net option).

The model=7 option can only be used with direct-modeling. Direct modeling supports bsim3, bsim4, and MOS9 models.

Applying set_sim_eou sim=2 model=2 net=2 is equivalent to a default NanoSim simulation.

Using the sim and model Options

To increase accuracy, apply a higher number to the sim and model EOU options. To increase performance, use a lower number. You must decide which is more appropriate for your simulation—greater accuracy or greater performance. There is no requirement that the sim and model options be set to the same level, but they should not be set to extreme opposites. For example, sim=7 and model=1 would not produce reliable results. You should maintain the difference between the values of these two EOU options at less than (<), or equal (=) to 2.

Assigning Values to the sim and model OptionsThe most frequently used sim and model level options are level=2, level=3 and level=4. If you set a level to 5 or above, a large portion of your netlist simulation performance could be impacted.

Table 55 Sliding-scale of accuracy vs. performance

Setting Accuracy Performance

low (1) less more

high (6) more less



Table 56 provides guidelines for you to follow:

Table 56 sim and model level guidelines

Level Description

1 digital functionality only

2 ■ all digital functionality■ digital timing on designs > 2.5V supplies and 0.18μm

technologies■ some analog

3 ■ most digital timing■ digital timing for designs < 2.5V supplies or 0.18μm

technologies■ most analog

3.5 (valid only for the model= argument)

■ most digital timing■ digital timing for designs < 2.5V supplies or 0.18μm

technologies■ most analog■ circuit includes heavily loaded MOS

4 ■ standard cell characterization■ critical path timing■ detailed rise/fall time measurements■ small signal analog■ applied to large circuits (> 500,000 elements) in extreme

cases only

5 ■ characterization of small cells■ small signal analog■ should only be applied to small designs (< 10,000

elements) or a small section of a large design

6 ■ characterization of small cells■ very small signal analog■ should only be applied to small designs (< 10,000

elements) or a small section of a large design



Using the net OptionThe net option has no relationship with the sim and model options. The net option does not need to be set to the same, or similar, level as is used for sim and model. The set_sim_eou command is often used without applying the net option.

The net option allows you to control when (or if) NanoSim adjusts the netlist. By default, NanoSim can remove small resistors, split small coupling capacitors to ground, convert diodes to capacitors, in an effort to improve circuit partitioning and simulation performance.

By increasing the level of the net option, fewer changes are made to the netlist, which can potentially result in larger circuit partitions and reduced simulation performance.

See Table 57 for a description of the nets:

7 ■ characterization of small cells■ very small signal analog■ model=7 can only be used with direct modeling■ should only be applied to small designs (< 1,000 elements)

or a very small section of a large design

Table 57 Net level guidelines

Level Description

1 All coupling capacitors split-to-ground

2 ■ Should be used on most circuits■ Accounts for significant coupling capacitors and small

resistors

3 ■ Approximately twice (2x) as sensitive to small resistors and coupling capacitors as default

■ Some performance impact when small resistors or coupling capacitors are present

Table 56 sim and model level guidelines (Continued)

Level Description



Applying set_sim_eou Globally and LocallyThe set_sim_eoucommand can be applied to the entire netlist (globally) or to a specific block (locally) in the netlist by using the NanoSim set_ckt_cmd or set_inst_cmd configuration commands.

The set_sim_eou command is a macro command. A description of the NanoSim configuration commands that are applied to the sim, model, and net options follow. Several of the commands can only be applied to the entire netlist. These global commands are applied to the entire netlist, even if you use the set_sim_eou command only for a single block.

4 ■ Approximately four times (4x) as sensitive to small resistors and coupling capacitors as default

■ Significant performance impact when small resistors or coupling capacitors are present

5 ■ Very aggressive■ Very sensitive to small resistors■ All coupling capacitors SMS’d or kept ■ Major performance impact when small resistors or

coupling capacitors are present

6 ■ Extremely aggressive■ Extreme sensitivity to small resistors■ All coupling capacitors kept■ Extreme performance impact when small resistors or


7 ■ Extremely aggressive■ Extreme sensitivity to small resistors■ All coupling capacitors kept■ Includes MOS parasitic diodes in simulation■ Extreme performance impact when small resistors or


Table 57 Net level guidelines (Continued)

Level Description



Command Precedence Table 58 explains the priorities that are applied when you use the EOU commands:

The following are examples of precedence:

Example 9 applies level=3 simulator accuracy, level=3 MOS modeling accuracy, and level=3 netlisting options to the entire netlist.

Example 9 Level 3 accuracy to entire netlistset_sim_eou sim=3 model=3 net=3

Example 10 applies level=3 simulator accuracy, level=3 MOS modeling accuracy, and level=3 netlisting options to every instance of the VCO subcircuit. The global commands are applied to the entire netlist. The time resolution for the simulator and printing is based on sim=3. The print resolution for voltage and current is based on sim=2.

Example 10 Level 3 accuracy to every VCO subcircuit instanceset_ckt_cmd VCO set_sim_eou sim=3 model=3 net=3

Example 11 applies level=4 simulator accuracy, level=4 MOS modeling accuracy, and level=4 netlist options to each VCO instance. Applies level=3 simulator accuracy, level=3 MOS modeling accuracy, and level=3 netlist options to the remainder of the design. The print resolution for voltage and

Table 58 Command priorities

Command Priority level

Local EOU Takes priority over global EOU setting for a local block

Multiple EOU commands in the same netlist portion

The highest of the local EOU levels is used if overlap occurs

Stand-alone config command settings

Takes priority over any conflicting EOU setting.

Print and simulator resolutions

The highest EOU level applied in the config file determines the global settings for set_sim_tres and set_print_tres

The global EOU level applied in the config file determines the global settings for set_print_vres and set_print_ires



current is based on sim=3. All other global commands are based on sim=4, model=4, and net=4.

Example 11 Level 4 accuracy to each VCO instanceset_sim_eou sim=3 model=3 net=3set_ckt_cmd VCO set_sim_eou sim=4 model=4 net=4

Example 12 applies level=4 simulator accuracy and level=4 MOS modeling accuracy to the entire netlist. An event sensitivity (esv) of 10mV overrides the esv set by the EOU command.

Example 12 Level 4 accuracy to entire netlistset_sim_eou sim=4 model=4set_sim_esv 10m

Command Option LevelsThe following tables display the sim, model, and net options with their corresponding values and NanoSim configuration commands.

The sim Option For a description of the sim level options, see Table 59. Global commands are indicated by a (G). The * (asterisk) character indicates the percent of local supply.

Table 59 sim=1|2|3|4|5|6|7 option descriptions

Command sim=1 sim=2

default

sim=3 sim=4 sim=5 sim=6 sim=7

set_sim_tres (G)

10p 10p 10p 1p 1p 1p 0.1p

set_print_tres (G)

100p 10p 10p 1p 1p 1p 0.1p

set_print_vres (G)

10m 10m 1m 1m 100u 100u 10u

set_print_ires (G)

1u 1u 100n 100n 10n 10n 1n

set_node_ssc 100n 100n 50n 50n 10n 1n 100p

set_elem_subi 1m 1u 500n 500n 100n 10n 1n



The model Option For a description of the model level options and corresponding NanoSim configuration commands, see Table 60. Global commands are indicated by a (G). This option controls a set of configuration commands that are related to MOS modeling accuracy.

set_dc_opt dc_current(G)

1u 1u 500n 500n 100n 10n 10n

set_vds_min (G) 1m 1m 500u 500u 100u 10u 1u

set_analogvds_min (G)

10n 10n 5n 5n 1n 100p 10p

set_node_esv* pwl nodes

(analog nodes)

15%

(5% or 0.1)

10%

(5% or 0.1)

5%

(2%)

5%

(2%)

2.50%

(1%)

1.25%

(0.5%)

0.625%

(0.25%)

set_node_spd* pwl nodes

(analog nodes)

15%

(5%)

10%

(5% or 0.1)

5%

(2%)

5%

(2%)

2.50%

(1%)

1.25%

(0.5%)

0.625%

(0.25%)

Table 60 model=1|2|3|4|5|6|7 option description

model option Configuration Commands

model=1 ■ set_node_rc■ search_ckt_logic

model=2 search_ckt_msx (default)

model=3 set_sim_moslevel1 (G)

model=3.5 set_sim_moslevel1.5 (G)

model=4 set_sim_moslevel 2 (globally applies set_sim_moslevel 1)

Table 59 sim=1|2|3|4|5|6|7 option descriptions (Continued)

Command sim=1 sim=2

default

sim=3 sim=4 sim=5 sim=6 sim=7



The net Option For a description of the net level options and corresponding NanoSim configuration commands, see Table 61. Global commands are indicated by a (G). This option controls a set of configuration commands that are related to netlisting control options.

model=5 ■ set_elem_sms■ set_sim_moslevel 2 (globally applies

set_sim_moslevel 1)

model=6 ■ set_elem_acc■ set_sim_moslevel 2 (globally applies

set_sim_moslevel 1 )

model=7 use_mos_analytic

Table 61 net=1|2|3|4|5|6|7 option description

net option Configuration Commands

net=1 ■ set_fcap_model *0■ set_powernet_default r=10 (G)

net=2 none (default)

net=3 ■ keep_nmos_gndgate 1 (G)■ keep_pmos_vddgate 1 (G)■ set_ckt_ctrl min_res_value:0.05 (G)■ set_fcap_param 5f 70f (G)■ set_relfcap_param 0.0025 0.05 (G)■ set_analogfcap_param 0.5f 5f■ set_analogrelfcap_param 0.00005 0.0002

(G)■ set_powernet_default r=2.5 l=0.25n (G)

Table 60 model=1|2|3|4|5|6|7 option description (Continued)

model option Configuration Commands



net=4 ■ keep_nmos_gndgate 1 (G)■ keep_pmos_vddgate 1 (G)■ set_ckt_ctrl min_res_value:0.01 (G)■ set_fcap_param 2.5f 35f (G)■ set_relfcap_param 0.001 0.025 (G)■ set_analogfcap_param 0.25f 2.5f■ set_analogrelfcap_param 0.000025 0.0001

(G)■ set_powernet_default r=1 l=0.1n (G)

net=5 ■ keep_nmos_gndgate 1 (G)■ keep_pmos_vddgate 1 (G)■ set_ckt_ctrl min_res_value:0.001 (G)■ set_ckt_ctrl cspf_process_ccap:1 (G)■ set_ckt_ctrl keep_gndcap:”all” (G)■ set_fcap_param 0 35f (G)■ set_relfcap_param 0 0.025 (G)■ set_analogfcap_param 0 2.5f■ set_analogrelfcap_param 0 0.0001 (G)■ set_powernet_default r=0.1 l=0.01n (G)■ set_powr_acc keep_cap=2■ set_diode_model * 1

net=6 ■ keep_nmos_gndgate 1 (G)■ keep_pmos_vddgate 1 (G)■ set_ckt_ctrl min_res_value:1e-4 (G)■ set_ckt_ctrl cspf_process_ccap:1 (G)■ set_ckt_ctrl keep_gndcap:”all” (G)■ set_diode_model * 1■ set_fcap_model * 2■ set_powernet_default mode=0 (G)■ set_powr_acc keep_cap=2

Table 61 net=1|2|3|4|5|6|7 option description (Continued)



Chapter 6: Applying Simulation ControlUsing a Single Command for Leakage Current Simulation

Using a Single Command for Leakage Current Simulation

The set_sim_leak command simplifies NanoSim setup for static leakage current simulation. It is a macro command that groups together all needed configuration commands for an accurate simulation of standby leakage current.

Command Description

The syntax is:

set_sim_leak [ires=]current_resolution

Using set_sim_leak is equivalent to using the following set of configuration commands:

set_sim_ires [ires=]current_resolutionset_dc_opt use_newton=1use_mos_dcdiode * 1set_diode_model * 1use_mos_gleak

The ires argument is optional. Its default value is 1fA. It is the smallest individual device current the user expects to contribute to the total leakage current.

The following example applies the command globally to the whole circuit, and runs the configuration commands as shown above, without any further modification. The default leakage current resolution of 1fA is used.

net=7 ■ keep_nmos_gndgate 1 (G)■ keep_pmos_vddgate 1 (G)■ set_ckt_ctrl min_res_value:1e-4 (G)■ set_ckt_ctrl cspf_process_ccap:1 (G)■ set_ckt_ctrl keep_gndcap:”all” (G)■ set_diode_model * 1■ set_fcap_model * 2■ set_powernet_default mode=0 (G)■ set_powr_acc keep_cap=2■ use_mos_dcdiode

Table 61 net=1|2|3|4|5|6|7 option description (Continued)




set_sim_leak

The next example sets the leakage current resolution to le-16.

set_sim_leak 1e-16

The last example sets the leakage current resolution to 1pA.

set_sim_leak ires=1p

Applying set_sim_leak Locally and Globally

The set_sim_leak command can be applied globally to the whole circuit, or it can be applied locally to specific blocks. To apply the command globally, use set_sim_leak.

If more than one set_sim_leak command is specified in the configuration file(s), then the one with the smallest ires value will be applied to the whole circuit.

To apply the command locally, you can use any of the following commands:■ set_ckt_cmd subckt name set_sim_leak

■ set_inst_cmd instance name set_sim_leak

■ set_pattern_cmd pattern name set_sim_leak

When the set_sim_leak command is used locally, it will still apply the following commands globally:

set_sim_iresset_dc_opt use_newton=1use_mos_gleak

These are all global commands and they will be applied to the whole circuit even if the set_sim_leak command is specified locally.

Precedence Rules

When the set_sim_leak command is used both globally and locally, the command with the smallest ires value takes precedence.

The global set_sim_leak command in the following example sets an ires of 1fA, while the local command sets an ires of 1pA. The smallest ires value will win; 1fA will be used for the whole circuit.



set_sim_leakset_ckt_cmd digital_block set_sim_leak 1p

In the next example, the global set_sim_leak sets an ires of 1fA, while the local command sets an ires of 1aA (1e-18A). The smallest ires value will win, 1e-18A will be used for the whole circuit.

set_sim_leakset_ckt_cmd digital_block set_sim_leak ires=1a

In the final example, there is no conflict because both set_sim_leak commands set the ires value to the default 1fA.

set_sim_leakset_ckt_cmd digital_block set_sim_leak

Single Commands Conflicting with set_sim_leakThe set_sim_leak command is a macro command that sets five single commands. These single commands can appear in the configuration file and their settings can conflict with the macro command setting. In that case, the single command value always overrides the macro command (set_sim_leak) value.

There is one exception for the set_diode_model command; it cannot override the set_sim_leak setting.

The following example sets an ires value of 1fA using set_sim_leak, however this value is overwritten by the single set_sim_ires command. The ires value used for simulation is 1nA and not 1fA.

set_sim_leakset_sim_ires 1n

The set_diode_model in the next example cannot override the set_sim_leak command. That means all diodes are kept even if there is a 'set_diode_model * 0' command.

set_diode_model * 0set_sim_leak

Conflicting Usage of set_sim_leak and set_sim_eouThe set_sim_eou command is also a macro command that can set the same individual command(s) as the set_sim_leak command. This can lead to conflicting settings. In that case, the most conservative (most accurate) setting will take precedence.



In the following example, the values used for vds_min, ssc, subi and current resolution are determined by the set_sim_leak command because it is more conservative than the sim=3 in the set_sim_eou command.

set_sim_leakset_sim_eou sim=3

The set_sim_ires 1p command in the following example overrides both the set_sim_eou and the set_sim_leak setting for current resolution.

set_sim_leakset_sim_eou sim=3 net=5set_sim_ires 1p

Usage Recommendations

Following are some recommendations for using set_sim_leak.■ It is highly recommended to use the double precision mode. Use -A in your

NanoSim run script to invoke double precision. If you forget to use it when using set_sim_leak, a warning will be issued.

■ The set_sim_leak command is aimed at static leakage current simulation. It is not recommended for timing or behavioral simulation. Using set_sim_leak will slow down the simulation because it imposes a very small current resolution. The set_sim_leak command improves the static leakage current accuracy, but it is not designed to improve timing accuracy.

■ For small, dynamic current simulation, you will need other configuration commands (such as commands to keep all capacitors).

■ Decreasing the ires value in set_sim_leak leads to more accurate results but also slows down the simulation. The default 1fA has been chosen to accurately simulate leakage current with current technologies. Synopsys recommends that you do not decrease this value unless you know that the smallest branch current in MOS that contributes to total leakage is less than 1fA.

■ You can increase the ires value if you use older technologies with higher leakage current, the simulation performance will then be improved.

■ If you are a user of previous versions of NanoSim, you no longer have to change the *nanosim tech="delta_vt <val1> <val2>" value. Delta_vt is now automatically determined by NanoSim based on the


Chapter 6: Applying Simulation ControlCreating a Balanced Simulation

ires value, as well as on the maximum supply voltage when direct modeling is used. For techfiles generated with auto-gentech, delta_vt is set to -1 1.

Creating a Balanced Simulation

NanoSim provides a group of autodetection commands you can use to create a simulation that is balanced in terms of accuracy and performance. It includes a default set of rules as well as several sets of rules that can be applied as needed to improve either the accuracy or speed of a simulation.

The default autodetection rules, controlled by the search_ckt_msx command, provide acceptable accuracy and speed for most mixed-signal circuits such as PLLs, ADCs, DACs, switched-capacitors, etc. However, some circuits might require a more accurate simulation, in which case, you could apply the search_ckt_analog command. This command applies a more extensive set of rules and is more accurate. However, a simulation using search_ckt_analog command will run somewhat slower as compared to a simulation using the default search_ckt_msx rules. The actual effect on speed will depend on the type of circuit, the amount searched, and how much the search_ckt_analog rule changes settings from the search_ckt_msx rule.

You can use the following configuration commands to apply different sets of autodetection rules, as needed:■ search_ckt_msx (default)

Use this set of rules for mixed-signal circuits. This is the default rule setting, except when running in RC or UD simulation modes. It includes most rules used by search_ckt_analog, but is less conservative and runs faster.

■ search_ckt_analog

Use this set of rules for analog circuits. This command applies a more conservative autodetection algorithm.

■ search_ckt_mem

Use this set of rules for embedded DRAMs, PLDs, and ROMs. You can also use the default search_ckt_msx for these circuits, but the simulation will likely take longer to run.

■ search_ckt_cpump


Chapter 6: Applying Simulation ControlCreating a Balanced Simulation

Use this set of rules for charge-pump circuits, flash memory circuits, etc. Flash memory circuits can usually be simulated with the default search_ckt_msx set of detection rules; however, some circuits might require the more conservative search_ckt_cpump rules.

■ search_ckt_logic

Use this set of rules for digital circuits. This set of rules is more aggressive and can greatly improve the simulation speed for digital circuits.

■ search_ckt_rc

Use this set of rules for digital-only blocks. If you use the set_sim_mode rc command, this set of rules is applied to the entire circuit by default.

■ search_ckt_ud

Use this set of rules for digital-only blocks. If you use the set_sim_mode ud command, this set of rules is applied to the entire circuit by default.

Applying Multiple Autodetection Rules

NanoSim enables you to apply different autodetection rules to individual portions of a circuit. If you do not specify an autodetection command, by default, the search_ckt_msx rules are applied to the entire circuit. However, if you apply an autodetection command to a portion (a block) of the circuit, that portion is searched with rules set by that autodetection command (that is, the default search_ckt_msx is not applied to that portion of the circuit). If you apply more than one autodetection command to the same block in a circuit, the simulator combines the rules for both commands and applies them to the specified block.

Example 13 applies search_ckt_mem rules to the xdram block. The default search_ckt_msx is applied to the remainder of the circuit.

Example 13 search_ckt_mem xdram blocksearch_ckt_mem el=xdram.*

In Example 14, the simulator combines the rules for search_ckt_mem and search_ckt_msx and applies them to the xmemory.xsubcircuit block, while applying search_ckt_mem to the remainder of the circuit in xmemory. In


Chapter 6: Applying Simulation ControlControlling Node Sensitivity and Time Step

addition, the simulator applies the search_ckt_analog rule to the xanalog block and search_ckt_msx to the remaining portions of the circuit.

Example 14 xmemory.xsubcircuit blocksearch_ckt_mem el=xmemory.*search_ckt_msx el=xmemory.xsubcircuit.*search_ckt_analog el=xanalog.*

Applying Multiple Time Steps (Multi-Rate Simulations)

In mixed-speed systems, such as DSPs, or other discrete-sampled circuits with high clock-speed-sampling, low-frequency signals, it might be necessary to use the multi-rate simulation capability. Multi-rate simulations let you apply different time steps to different parts of the circuit. Using multiple time steps helps you to obtain the maximum simulation speed from each circuit block. The simulation will speed up two to three times for some circuits, depending on the actual configuration of the circuit, when doing a multi-rate simulation. Use the set_sim_subgroup configuration command to enable a multi-rate simulation. You can use this command only when running in SMS or synchronous mode.

Controlling Node Sensitivity and Time Step

Normally, you do not need to modify the default simulation time resolution (10 ps). However, when simulating low frequency audio applications, you might need to increase the time resolution (the minimum time step), perhaps to 1 ns. If all nodes move slowly, a simulation time resolution of 10 ns or even 100 ns could provide sufficient accuracy with a high simulation speed. You can use the set_sim_tres command to modify the simulation time resolution.

set_sim_tres 0.01ps

This example sets the minimum time resolution to 0.01 ps.

After you choose the appropriate time resolution, you can apply additional time step control commands to control the time step.


Chapter 6: Applying Simulation ControlControlling Node Sensitivity and Time Step

Event sensitivity

The event sensitivity can be applied to the entire circuit (either all digital or all analog nodes) using the set_sim_esv, set_sim_aesv, and set_node_esv commands.

set_sim_esv 0.01

This example sets the event resolution voltage of all digital nodes to be 0.01 V.

set_sim_aesv 0.01

This example sets the event resolution voltage of all analog nodes to 0.01 V. Any voltage change that is higher than 0.01 V from its last event voltage will schedule an event, provided there is no local esv setting.

In some cases, different parts of the circuit could have different sensitivity requirements. In this case, you can apply the set_node_esv command to individual nodes (local setting).

set_node_esv vco_in 0.01

This example sets the event resolution voltage at node vco_in to 0.01 V. Any voltage change that is higher than 0.01 V from its last event voltage, will schedule an event at node vco_in.

Speed controlThe speed control can be applied to the entire circuit using the set_sim_spd and set_sim_aspd commands.

set_sim_spd 0.3

This example sets the simulation step size parameter (spd) to 0.3V. With this setting, the maximum voltage change at each time step cannot exceed 0.3V.

For analog, you can use the set_node_spd command to change the size of the time step for a particular node.

set_sim_aspd 0.2

This example sets the simulation step size parameter (spd) to 0.2V for analog nodes only. With this setting, the maximum voltage change of all analog nodes at each time step cannot exceed 0.2V.

You can apply the set_node_spd command to individual nodes (local setting).


Chapter 6: Applying Simulation ControlControlling Waveform Print Resolution

set_node_spd VCO_IN 0.05

This command sets the time step size parameter (spd) at node VCO_IN to 0.05 V. With this setting, the maximum voltage change in each time step at node VCO_IN cannot exceed 0.05 V.

Controlling Waveform Print Resolution

The NanoSim simulator allows you to change the time, voltage, or current resolution to the output file. It is important to be able to alter the print resolution settings to get sufficient precision for post-processing functions such as .measure command processing or FFT processing.

You can use the following commands to change the output print resolution:■ set_print_tres

■ set_print_vres

■ set_print_ires

Applying Multiple Simulation Modes

You can apply different simulation modes on a local or block level using the following commands:■ set_elem_acc

Use this command to apply a more accurate model and algorithm to specified MOSFETs.

■ set_node_pwl

Use this command to force the channel-connected stage containing a specified node to be simulated using the PWL algorithm.

■ set_elem_sms


Chapter 6: Applying Simulation ControlActivating Double-Precision Mode

Use this command to apply the Synchronous Matrix Solver (SMS) model to specified elements.

■ set_elem_sync

Use this command to apply the synchronous simulation algorithm to specified elements.

Both the set_elem_sync command and the set_elem_sms command apply the synchronous mode. However, they use different models—the set_elem_sync command uses a simplified region-dependent gate-capacitance model for MOS transistors at linear, saturation, and cut-off regions, while the set_elem_sync command uses a voltage-dependent gate-capacitance model. In addition, the set_elem_sms command models the crosstalk-Miller effect between gate and drain or source terminals.

Usually, the autodetection algorithm applies these commands as needed. However, there are situations when you might want to apply them manually (for example, when you need precise accuracy in digital circuits). You could use this technique, for example, when simulating an inverter-ring oscillator.

Activating Double-Precision Mode

You can start the double-precision version of NanoSim for voltage and current using the -A command-line option. Under normal conditions, you do not need to use double precision. However, in some cases, double precision could be necessary. For example, highly damped PLLs with slow lock times, low static-phase error, and low jitter requirements usually need to be simulated in the double-precision mode. Very high gain amplifiers or analog-to-digital circuits and digital-to-analog circuits beyond 12 bits might also require double precision.

Using double-precision mode will slow down the simulation by approximately 10%, while increasing memory consumption by approximately 30%. Therefore, it is recommended that you do not use double-precision mode unless absolutely necessary.

Controlling Voltage and Current Resolution

There are no limits on the voltage and current resolution settings except those imposed by the floating-point (float) data type. The float data type is the default in single precision, which is an 8-bit mantissa and a 3-digit exponent. This


Chapter 6: Applying Simulation ControlSimulating BJTs

means that the lowest absolute resolution available depends on the absolute value of a stored number.

For small voltages and currents there are more significant digits available at lower values. For example, if you have 1.00000000 V and you need to maintain accuracy to 1 nV, the nanovolt-level will be lost, that is,

1.000000000 V + 0.000000001 V = 1.000000000 V

However, if you have 1 mV instead, the 1 nV can be retained, that is,

0.001000000 V + 0.000000001 V = 0.001000001 V

Therefore, if you have large signals that require nanovolt accuracy and precision, you will need to use the double-precision data storage.

Note:

The higher precision printing has a direct impact on the size of the output file. If you try to print every node voltage in the circuit at the microvolt or nanovolt resolution level, you could easily fill up your disk.

Simulating BJTs

NanoSim can simulate BiCMOS circuits with bipolar junction transistors (BJTs). The BJT model is an implementation of the Gummel-Poon model used in SPICE. Both NPN and PNP transistors are supported, as well as diodes and diode-connected bipolar transistors.

Supporting BJTs During Simulation

Both vertical and lateral BJTs are supported. NanoSim is best-suited for circuits containing sparse BJTs as drivers, or interface circuits. Simulation of circuits containing large blocks of BJTs is slow, since those BJTs are simulated as a whole subcircuit. The simulation speed of small to medium-sized pure BJT circuits is in the same order as SPICE. If the circuit does not have large blocks of BJTs, the overall speed is faster than SPICE.

Simulating BJTs—The Procedure

This section describes the process by which NanoSim simulates BJTs. This procedure includes several steps, some in pre-processing and some during run time.


Chapter 6: Applying Simulation ControlSimulating BJTs

NanoSim does the following:

1. Reads the model from the netlist.

2. Calculates some variables used during simulation and calculates the temperature effect, if the operating temperature is given.

3. Expands internal nodes and internal resistors if base, collector, and emitter resistors are specified.

The base, collector, and emitter resistors are important in achieving convergence both at DC initialization and transient simulation since they limit the current through BJTs when the pn junction is forward biased. However, expanding those resistors and internal nodes significantly slows down the simulation.

4. Performs circuit partitioning on the BJTs as it would with an accurate MOS transistor. This partitioning includes the gate, drain, and source in the same stage (channel-connected subcircuit).

The base of a BJT is included in the same stage with its collector and emitter. This partitioning scheme is necessary since base-emitter and base-collector junctions are strongly coupled. This effectively connects two channel-connected regions that would usually be separated when a normal MOS device is used. If a circuit contains only BJTs, all channel-connected and base terminal-connected BJTs will form a large stage, which makes the simulation very inefficient.

The BJTs are simulated in the accurate element mode, which uses a different time step control and error control to assure simulation accuracy and stability.


77Using the VCD and EVCD Direct-read Features

This chapter describes the Value Change Dump (VCD) and the Extended Value Change Dump (EVCD) Direct-read features—supported by NanoSim—which enable you to directly read-in a VCD or EVCD file for simulation. The VCD and EVCD file formats are ASCII file formats containing header information, variable definitions, and variable value changes generated by a Verilog simulator. VCD and EVCD are specified in the IEEE 1364 standard.

Topics in this Chapter

This chapter contains the following topics:■ VCD Overview■ EVCD Overview

• Default EVCD Port Direction Rule

• EVCD Port Direction Rule■ Using the Signal Information File for VCD and EVCD■ VCD File Sample■ EVCD File Sample■ Signal Information File Sample■ Overriding with the set_vec_opt Configuration Command

VCD Overview

A VCD file is an open industry standard ASCII format file, generated by a test pattern generator, RTL simulator, or other high-level simulator. A VCD file does not contain signal direction or waveform characteristics. Therefore, you are


Chapter 7: Using the VCD and EVCD Direct-read FeaturesVCD Overview

required to create a signal information file to map the signal names in the VCD file to the node names in the design netlist, and also to provide this signal information for each signal to NanoSim.

A VCD file contains three sections:■ The header information section describes the date, the version number of

the simulator, and the time-scale used.■ The variable definitions section contains the scope of the hierarchy, and type

of variables. A variable can be a scalar or a bus. Each variable is represented by a unique identifier character.

■ The value changes section contains the actual value changes for all variables specified at each simulation time increment. Only the variables, which change during a time increment, are listed. Each variable with a set of values forms a vector over time.

To read-in a VCD file into NanoSim, see the following syntax:

set_vec_opt file=vcd_file_name sig_file=sig_info_file

Note:

The set_vec_opt command can also be used to read-in a NanoSim vector file and an HSPICE vector file. The sig_file argument is only used when reading-in a VCD file.

The vcd_file_name option specifies the VCD file name. The sig_info_file option specifies the signal information file name that provides additional information for the vcd_file, and is also a required argument.

Note:

NanoSim does not support command-line commands to invoke VCD direct-read.

Example 15 sets projectA.vcd as the input file to NanoSim; projectA.sig provides additional information to the VCD file.

Example 15 set_vec_opt command exampleset_vec_opt file=projectA.vcd sig_file=projectA.sig

If multiple VCD files are used during a simulation, you should specify the files using multiples of the set_vec_opt configuration command.


Chapter 7: Using the VCD and EVCD Direct-read FeaturesEVCD Overview

To specify the simulation bus syntax, refer to the set_bus_nt command in the NanoSim Command Reference. The default bus character is [ - ], but you can set any valid symbol.

EVCD Overview

The Extended Value Change Dump (EVCD) file format is an ASCII file containing header information, variable definitions, and variable value changes that include directions and strengths. EVCD format is generated by any Verilog simulator.

The EVCD format contains direction and strength data, which the four-state VCD file does not contain. The EVCD signals are handled by the input stimulus or output results—signal strength is not an important factor.

To enable the most efficient environment in NanoSim, you should directly read the EVCD file into NanoSim. Since the EVCD file contains unknown directions and no information about waveform characteristics, you should provide the direction information of each individual signal. If you do not provide the signal information, NanoSim follows the EVCD port direction rule and the unknown direction is ignored.

If there is not an unknown direction port in the EVCD file, you do not need to write the signal information file. NanoSim provides the options for the waveform value, bus format, and alias, using the following three configuration commands:■ set_evcd_opt

■ set_evcd_bus

■ set_evcd_alias

To read-in an EVCD file into NanoSim, see the following syntax:

set_evcd_opt file=evcd_file_name [sig_file=signal_information_file_name]

See the NanoSim Command Reference for a complete description of each of the EVCD commands.



Default EVCD Port Direction Rule

For state characters: The following state information is listed in terms of input values from a test fixture (Table 62), the output values of the device under test (DUT) (Table 63), and the states representing unknown directions (Table 64):

Table 62 Input values from a test fixture

State character INPUT (TEST FIXTURE) values

D low

U high

N unknown

Z three-state

d low (two or more drivers active)

u high (two or more drivers active)

Table 63 Output values of the device under test (DUT)

State character OUTPUT Device Under Test (DUT) values

L low

H high

X unknown (don't care)

T three-state

l low (two or more drivers active)

h high (two or more drivers active)



EVCD Port Direction Rule

If you do not provide the signal information file, NanoSim follows the EVCD port direction rule: unknown direction ports are ignored. In this case, waveform information is required through the set_evcd_opt command.

The signal direction rule in NanoSim is as follows:

1. If you do not provide the signal direction information, NanoSim follows the EVCD direction rule: the unknown direction is ignored.

Table 64 States representing unknown directions

State character UNKNOWN DIRECTION

0 low (both input and output are active with 0 value)

1 high (both input and output are active with 1 value)

? unknown

F three-state (input and output unconnected)

A unknown (input 0 and output 1)

a unknown (input 0 and output X)

B unknown (input 1 and output 0)

b unknown (input 1 and output X)

C unknown (input X and output 0)

c unknown (input X and output 1)

f unknown (input and output three-stated)



2. If you provide the signal information for the vector direction, the signal information overrides the EVCD direction rule.

a. If a port is assigned as an input signal (or port): the value of the signal (or port) in the EVCD file is automatically translated to:

'D'->'0', 'U'->'1', 'n'->'X', 'N'->'X', 'd'->'0', 'u'->'1','L'->'0', 'H'->'1', 'l'->'0', 'h'->'1', 'T'->'Z', 'x'->'X','?'->'X', 'A'->'0', 'a'->'0', 'B'->'1', 'b'->'1', 'C'->'X','c'->'X', 'f'->'Z', 'F'->'Z';

b. If a port is assigned as an output signal—the value of the signal (or port) in the EVCD file is automatically translated to (0/1 changed to L/H):

’0’->’L’, ’1’->’H’, ’l’->’L’, ’h’->’H’, ’T’->’Z’, ’x’->’X’,’D’->’X’, ’U’->’X’, ’n’->’X’, ’N’->’X’, ’d’->’X’, ’u’->’X’,’?’->’X’, ’A’->’H’, ’a’->’X’, ’B’->’L’, ’b’->’X’, ’C’->’L’,’c’->’H’, ’f’->’Z’, ’F’->’X’;

c. If a port is assigned as a bidirectional port with an enable signal:

i. Rule 2.a applies if a port is assigned to an input signal during simulation time.

ii. Rule 2.b applies if a port is assigned to an output signal during simulation time.

d. If a port is assigned to a bidirectional port without an enable signal—the EVCD direction rule applies:

i. If a port is assigned to a bidirectional port without an enable signal, and if the direction is unknown, an error occurs.

ii. If a port is assigned to a bidirectional port without an enable signal, and if the direction is known, the CBC option is used for this port.

iii. The cbc option specifies the direction of a bidirectional port without an enable pin.

iv. An unknown direction port is assigned to a bidirectional port with the enable signal.

v. Rule 2.a applies if an unknown direction port is assigned to an input signal during the simulation time.

vi. Rule 2.b applies if an unknown direction port is assigned to an output signal during the simulation time.


Chapter 7: Using the VCD and EVCD Direct-read FeaturesUsing the Signal Information File for VCD and EVCD

e. If an unknown direction port is assigned to a bidirectional port with an enable signal:

i. Rule 2.a applies if an unknown direction port is assigned to an input signal during simulation time.

ii. Rule 2.b applies if an unknown direction port is assigned to an output signal during the simulation time.

Using the Signal Information File for VCD and EVCD

The following sections on the signal information file applies to both the VCD and EVCD file format. Although VCD is referenced throughout these sections, EVCD can be used interchangeably.

The signal information file provides information to map the variable names in the VCD file to the node names in the design netlist. All signal names in the signal information file are case-sensitive because Verilog variable names are case-sensitive. If multiple expressions match the same signal, the last match takes priority. To avoid mapping problems, always use unique matches.

The following procedures enable you to create the signal information file:

1. Define bus syntax in the design netlist.

See the Defining Bus Syntax with the #format Command section.

2. Define signal directions, such as input, output, or bi-directional.

See the Defining Signal Directions section.

3. Map the variable names in the VCD file to the node names in the design netlist.

See the Defining Mapping Information with the #alias Command section.

4. Define analog waveform characteristics, such as rise time and fall time.

See the Defining Attributes for Signals section.



Defining Bus Syntax with the #format Command

The #format command specifies the bus naming format for a VCD file. The default name format for #format is %[#]. For a character descriptions, see Table 65.

See the following syntax:

#format|#fo bus_naming_format

Only one #format command is allowed in a signal information file. Create another signal information file, if multiple formats are needed.

Example 16 displays the bus line format in a VCD file.

Example 16 Bus line format command example$var reg 3 k tA [2:0] $end

The #format command causes tA to expand to the following names in the VCD file.

For a description of the commands and corresponding mapping names, see Table 66.

Table 65 % and # character descriptions

Character Description

% Represents the variable names

# Represents the bus indexes

Table 66 #format command mapping names

Command Mapping name

#format %<#> tA<2> tA<1> tA<0>

#format %.# tA.2 tA.1 tA.0

#format %[#] TA[2] tA[1] tA[0]



Defining Signal Directions

You must define signal directions to the variable names in the VCD and EVCD files. Signal directions can be input signals, output signals, or bi-directional signals. NanoSim uses all input, output, and bi-directional signals specified in the VCD file for the simulation. NanoSim uses input signals as stimulus for the simulation. Simulation output signals are checked against simulation output signals for any mismatch. Bidirectional signals require enable signal(s) to control the direction, either as input signals or output signals. All other signals in the VCD file, which are not specified in the signal information file, are ignored.

NOTE: Bi-directional signals cannot be included within an enable_signal logic expression.

The #bi-directional enable_signal option (see Example 17) can be specified as a logic expression, as shown in Example 18.

Example 17 Bi-directional enable_signal#input | #in signal_name(s)#output | #out signal_name(s)#bidirectional | #bi signal_name(s) [in | out enable_signal(s)]

Example 18 Logic expression of bi-directional enable_signal#format %[#]#in cen oen#in a[[3:0]] #out c b*#bi io[[7:0]] (out cen & oen)

Example 18 declares the following (description of each line):■ bus format■ input signals cen and oen■ input bus signal a[[3:0]]

The outer bracket signifies bus notification, while the inner bracket signifies a wild card range.

■ output signal c and bus b

The asterisk character (*) is a wild card for any group of characters.



■ bi-directional signal bus io[[7:0]] is controlled by signals cen and oen■ bus io[[7:0]] is output when both oen and cen are logic-high;

otherwise bus io is input

Logic expression operators are supported to define enable signals. See Table 67 for definitions of the logic expression operators.

Important:

You must insert a space between a logical operator and the signal name. If there is no space, the signal name will not be recognized. For example:

#bi bi_driver (in ~ ctrl)

Note the space between the NOT operator (~) and the signal name (ctrl).

You can use wild cards to match node names, as described in Table 68.

Table 67 Logic expression operators

Operator Definition

~ NOT

! NOT

^ exclusive OR

& AND

&& AND

| inclusive OR

|| inclusive OR

Table 68 Wild card support

Wildcard Description

* Matches any group of characters

? Matches any single character

[ : ] Matches any range expression



You need to provide the full hierarchical name for the specified signal in the signal information file, based on the VCD file hierarchy. The period ( . ) character is used as the hierarchical delimiter in the signal information file. If you choose not to specify the full hierarchical name, see The #scope Command section. See the Signal Information File Sample section for a detailed sample.

NanoSim uses input signals as stimulus for the simulation. Each input signal is converted to a PWL voltage source, in series with a resistor. The rise and fall times are used to smoothly transition from one state to another.

Each output signal is converted to an expected output checking statement. During simulation, the actual voltages are converted to a digital value and compared to the expected output checking statement at the specified times. A warning is generated, if the states differ. NanoSim checks the output signals to the expected outputs at every time point specified in the VCD file.

See Example 19 for further details.

Example 19 Signal direction example...$var reg 4 " A [3:0] $end$var reg 4 % B [3:0] $end...$dumpvarsb0000 "b0000 %$end#10b0010 "#12b0001 %

Bus A is defined as input and bus B is defined as output in the signal information file. At time 0, bus A is initialized to 0000; at time 10, it changes state from 0000 to 0010; at time 12, there is no change in the state. Since bus B is specified as output, the simulation output of bus B is checked against the expected result specified in the VCD file. NanoSim performs vector-checking at every time point (0, 10, 12), even if bus B does not change state at time 10.

A delay usually occurs between the logic simulation and the transistor-level simulation. Therefore, NanoSim issues warning messages if the state in the actual simulation does not match the VCD expected output. You can use the #odelay command to delay the expected outputs in the VCD file, so accurate vector-checking is implemented during simulation without generating warning



messages. Refer to the #odelay command in the section The #idelay and #odelay Commands for further details.

Defining Mapping Information with the #alias Command

The #alias command maps the signal names in the VCD file into different names to match with the design netlist. You can use multiple aliases and regular expressions, but use only one specific alias for each signal name. If multiple patterns match the same name, the last pattern takes priority.

The following are situtations in which you must use the #alias command:■ Different names are detected in the VCD file and the design netlist.

For example, you want to map signal name A1 in the VCD file to node name B1 in the design netlist.

■ Different hierarchy in the VCD file and the design netlist.For example, you want to map the signal from top module top.A1 to the node name of the top hierarchy of the design netlist A1.


#alias | #al vcd_signal_name netlist_node_name

In Example 20, the #alias commands convert the following signal names in the VCD file to map with the signal names in the design netlist. The percent sign ( % ) represents the signal name, and the pound sign ( # ) represents the bus index. See Table 65.

Example 20 #alias command example#alias tX64 x_64 ! alias #1#alias t% % ! alias #2#alias tAP% Ap_% ! alias #3#alias tAPE% APE% ! alias #4

See Table 69 for the mapping description.

Table 69 #alias command converting signal names

From (VCD file) To (design netlist) #alias matched

tAPEND APEND 4

tL2CIB L2CIB 2



Defining Attributes for Signals

The signal information file supports commands that define various attributes for signals, such as rise time or fall time. Multiple specifications of each individual command is allowed in the signal information file. If more than one individual command is specified to a signal, the last command overrides the previous one. If the signal name is not specified, the value applies to all input or output signals.

See the following supported commands:■ The #edge_shift Command■ The #idelay and #odelay Commands■ The #outz Command■ The #scale Command■ The #trise, #tfall, and #slope Commands■ The #triz Command■ The #vih and #vil Commands■ The #voh and #vol Commands■ The #scope Command

tX64 x_64 1

tAPEB APEB 4

tGBLB GBLB 2

tAP0 Ap_0 3

tADD ADD 2

tAPDD1 Ap_DD1 3

Table 69 #alias command converting signal names (Continued)

From (VCD file) To (design netlist) #alias matched



The #edge_shift CommandThe #edge_shift command specifies the timing shift on the transitions for specified signals. The default values for all #edge_shift arguments are 0.0. See the following syntax, and descriptions of the command arguments:

#edge_shift time1 time2 time3 signal_name(s)

The #idelay and #odelay CommandsThe #idelay and #odelay commands specify the delay time of the specified input and output signals. The default values for #idelay and #odelay are 0.


#idelay value signal_name(s)#odelay value signal_name(s)

The #outz CommandThe #outz command specifies the drive resistance for specified input signals—for instance, the “H” and “L” state characters. State characters 1and 0 are considered to be strong logic and have infinite strength. The default value for #outz is 0.0.


#outz value signal_name(s)

The #scale CommandThe #scale command specifies the time multiplier—a global setting that applies to all signals. This command does not specify individual signals. The default value for #scale is 1.0. The #scale command applies to all time variables, such as #rise and #fall.

#edge_shift command argument descriptions

Argument Description

time1 Specifies the time shift to be applied to positive transitions (to 1or H)

time2 Specifies the time shift to be applied to negative transitions (to 0 or L)

time3 Specifies the time shift of all other transitions




#scale option

The #trise, #tfall, and #slope CommandsThe #trise and #tfall commands specify the rise time and fall time for specified signals, respectively. The #slope command applies to both rise time and fall time. The default values for #trise, #tfall, and #slope are 0.0.


#trise value signal_name(s)#tfall value signal_name(s)#slope value signal_name(s)

The first example in Example 21 assigns 10ps as the fall time for all the signals.

If multiple patterns match the same signal name, the last pattern takes priority. The second example in Example 21 assigns 10ps as the fall time for all signals, except c and bus io.

Example 21 #tfall command example#tfall 10ps#tfall 10ps *#tfall 1ps c io*

The #triz CommandThe #triz command specifies the output impedance for specified tri-state input signals. The default value for #triz is 1000Meg.


#triz value signal_name(s)

The #vih and #vil CommandsThe #vih and #vil commands specify the logic-high and logic-low input voltages of specified signals. By default, NanoSim detects the rail-to-rail voltage supply of the design and sets #vih to the maximum rail voltage, and #vil to the minimum rail voltage.


#vih value signal_name(s)#vil value signal_name(s)



Example 22 assigns 1.1V as logic-high, and 0.2V as logic-low for all input signals.

Example 22 #vih and #vil command examples#vih 1.1#vil 0.2

Example 23 overrides the logic-high of bus add as 3.3V, and logic-low of reset as 0.0V. You could override the global values of logic-high and logic-low for specific input signals.

Example 23 #vih and #vil command examples#vih 3.3 add*#vil 0.0 reset

The #voh and #vol CommandsThe #voh and #vol commands specify the output voltage logic-high and logic-low of specified output signals. The default value of #voh is set to vih; #vol is set to vil.


#voh value signal_name(s)#vol value signal_name(s)

Example 24 assigns 3.3V and 0.0V as the global logic-high and logic-low, respectively, for all output signals except bus out. The logic-high of bus out is overridden as 1.1V.

Example 24 #voh and #vol command examples#voh 3.3#vol 0.0#voh 1.1 out*

The #scope CommandThe #scope command specifies the name of the scope from which signals are used for matching. By default, if #scope is not specified, NanoSim processes the signals starting from the top level in the VCD file. Note that the signals must be selected using #in, #bi or #out to be used as stimuli. You must specify the corresponding scope, so that the correct signals are used for simulation. If #scope is not specified, NanoSim searches the signals starting from the top-level of the VCD file. This eliminates the use of the #alias command to map the signals in the specified scope to the top-level hierarchy in the design netlist.



Only one #scope command is allowed in a signal information file. Create another signal information file if multiple scopes are needed.

Use the following syntax:

#scope scope_name

The scope definition in the VCD file is shown in Example 25.

Example 25 Scope definition in a VCD file$var wire 1 A data_in $end$var wire 32 B data_out [31:0] $end

$scope module st $end$var wire 1 ` data_in $end$var wire 32 ^ data_out [31:0] $end$upscope $end

$scope module tpu $end$var wire 1 _ data_in $end$var wire 32 Y data_out [31:0] $end$upscope $end

The scope definition in an EVCD file is shown in Example 26.

Example 26 Scope definition in an EVCD file$scope module TEST $end$var port 1 ` add_in $end$var port [31:0] ^ out $end$upscope $end

Example 27 uses st as the top-level hierarchy in the VCD file, and searches the signals only in scope st.

Example 27 #scope st command example#scope st


Chapter 7: Using the VCD and EVCD Direct-read FeaturesVCD File Sample

VCD File Sample

See Example 28 for a sample VCD file:

Example 28 VCD file sample$date

Sun Oct 10 18:20:30$end$version

Synopsys VCS Version 7.0$end$timescale

lns$end

$scope module adder $end$var reg 1 ! CIN $end$var reg 4 “ A [3:0] $end$var reg 4 # B [3:0] $end$var wire 1 $ COUT $end$var wire 4% S [3:0] $end$upscope $end

$enddefinitions $end$dumpvars0! b0000 “b0000 #0$b0000 %$end#10b0000 #b0000 “0!#12b0000 %0$#20b0001 ##22b0001 %#30b0010 #


Chapter 7: Using the VCD and EVCD Direct-read FeaturesVCD File Sample

#32b0010 %#40b0011 ##42b0011 %#50b0100 ##52b0100 %#60b0101 ##62b0101 %#70b0110 ##72b0110 %#80b0111 ##82b0111 %#90b1000 ##92b1000 %#100b1001 #


Chapter 7: Using the VCD and EVCD Direct-read FeaturesEVCD File Sample

EVCD File Sample

See Example 29 for an EVCD file sample.

Example 29 EVCD file sample$date Mon Apr 4 14:03:50 2006$end$version Chronologic Simulation VCS Release 7.1.2 $dumpports(adder "dumpports.vcd")$end$timescale 10ps$end$comment Csum: 1 bb5bd2bdf9b304b7 $end

$scope module adder $end$var port 1 <0 ck $end$var port [3:0] <1 a $end$var port [3:0] <2 b $end$var port 1 <3 cin $end$var port [3:0] <4 s $end$var port 1 <5 cout $end$var port1 <6 d $end$var port1 <7 e $end$upscope $end

$enddefinitions $end

#0$dumpportspU 0 6 <0pXXXX6666 6666 <1pXXXX6666 6666 <2pX 6 6 <3pNNNN6666 6666 <4pN 6 6 <5pU 6 6 <6pU 6 6 <7$end#500pD 6 0 <0pLLLL6666 0000 <1pLLLH6660 0006 <2pL 6 0 <3pU 6 6 <6



pD 6 6 <7#1000pU 0 6 <0pLLLH6660 0006 <4pD 6 0 <5pU 6 6 <6pU 6 6 <7#1500pD 6 0 <0pH 0 6 <3pU 6 6 <6pD 6 6 <7#2000pU 0 6 <0pLLHL6606 0060 <4pU 6 6 <6pD 6 6 <7#2500pD 6 0 <0pLLLH6660 0006 <1pU 6 6 <6pD 6 6 <7#3000pU 0 6 <0pLLHH6600 0066 <4pU 0 6 <5pU 6 6 <6pU 6 6 <7#3500pD 6 0 <0pHHHH0000 6666 <1pHHHH0000 6666 <2pL 6 0 <3pU 6 6 <6pD 6 6 <7#4000pU 0 6 <0pHHHL0006 6660 <4pU 6 6 <6pU 6 6 <7#4500pD 6 0 <0pH 0 6 <3pU 6 6 <6pD 6 6 <7#5000pU 0 6 <0pHHHH0000 6666 <4



pU 6 6 <6pD 6 6 <7#5500pD 6 0 <0pU 6 6 <6pD 6 6 <7

$vcdclose #5500 $end


Chapter 7: Using the VCD and EVCD Direct-read FeaturesSignal Information File Sample

Signal Information File Sample

See Example 30 for a sample signal information file:

Example 30 Signal information file sample; Define bus syntax#format %[#]

; Define signal directions#in adder.CIN#in adder.A[[3:0]]#in adder.B[[3:0]]#out adder.COUT#out adder.S[[3:0]]

; Define mapping information#alias adder.CIN CIN#alias adder.A[3] A[3]#alias adder.A[2] A[2]#alias adder.A[1] A[1]#alias adder.A[0] A[0]#alias adder.B[3] B[3]#alias adder.B[2] B[2]#alias adder.B[1] B[1]#alias adder.B[0] B[0]#alias adder.COUT COUT#alias adder.S[3] S[3]#alias adder.S[2] S[2]#alias adder.S[1] S[1]#alias adder.S[0] S[0]

; Define analog waveform characteristics#vih 3.3#vil 0.0#voh 3.0#vol 0.3#slope 10ps


Chapter 7: Using the VCD and EVCD Direct-read FeaturesOverriding with the set_vec_opt Configuration Command

See Example 31 for a sample signal information file generated with the #scope command:

Example 31 Signal information file sample generated with the #scope command

; Define bus syntax#format %[#]

; Define scope#scope adder

; Define signal directions#input CIN#input A*#input B*#output COUT#output S*

; Define analog waveform characteristics#vih 3.3#vil 0.0#voh 3.0#vol 0.3#slope 10ps

Overriding with the set_vec_opt Configuration Command

All arguments in the set_vec_opt configuration command can also be applied to the VCD file. See the following syntax:

set_vec_opt [rise=<rise_time>][fall=<fall_time>] [slope=<input_slope>][fixed_rf=0|1][delay=<delay_time>][high=<high_voltage>][low=<low_voltage>] [x_state=0|1|2|3|4][x2v=0|1|2|3|4] [r=<resistance>]file=<file_name1> file=<file_name2> ... no=<node_name1> no=<node_name2> ... [sig_file=<sig_info_file>][gen_vec_file=0|1]

The delay=delay_time argument is the only argument that is added to the value specified in the VCD file. All other arguments override the values specified in the signal information file.


88Using Hierarchical Array Reduction

This chapter provides conceptual information about how HAR works and the prerequisites for a design that can effectively use HAR. Hierarchical Array Reduction (HAR) enables you to read-in a complete, hierarchical netlist for a large SRAM or DRAM memory and to simulate the memory with reasonable accuracy and speed.

Overview

HAR automatically reduces the inactive parts of a memory based on stimulus, while preserving the reduced memory components loading effect.

This chapter contains the following topics:■ Understanding HAR Concepts■ Using HAR - The Prerequisites■ Using HAR - The Usage Model■ Simulating Pre-layout Designs■ Simulating Post-layout Designs

Understanding HAR Concepts

See the following description of HAR terms and concepts:


Chapter 8: Using Hierarchical Array ReductionUnderstanding HAR Concepts

HAR Terminology

The following terms are used throughout the discussion of HAR in this chapter.■ Abstraction: The specific selection of the necessary details for a particular

circuit representation.■ Array: A highly repetitive circuit structure, like a standard memory bit cell

topology, where the repeated circuit is represented by a SPICE .subckt call as a separate element in the netlist hierarchy.

■ Controlling node: The port of a core cell subcircuit that is monitored for activity. Core cells with active controlling nodes are not abstracted.

■ Core cell: A subcircuit selected for reduction by HAR and identified to the simulator through the define_har_corecell configuration command.

■ Reduction: The act of reducing the memory required for circuit representation by reducing the circuit details in memory to only what is required for accurate simulation results.

Describing HAR Analysis Phases

HAR analysis proceeds in two automatic (seamless) phases:

1. During the setup phase, the stimulus is propagated through the design without any instantiated core cells.

2. During the simulation phase, only active core cells are instantiated at the transistor level. Inactive core cells are reduced.

Reduction is only used for bit cells. See Figure 20 for a graphic overview of the HAR flow.



Figure 20 HAR flow overview

Setup PhaseDuring the setup phase, only those core cells marked not to be deleted are instantiated. All core cell controlling nodes are monitored for activity. Information about controlling nodes without activity during the setup phase is listed in the .hl file. This information is used to decide which core cells are to be represented by an abstract model. In the case of reduced cells (for example, memory bit cells), the abstract model is the bulk diffusion and gate capacitances for the transmission gate devices (average capacitances to ground).



In some cases, you can save simulation time across process and temperature variations (with the same vector stimulus) by re-using an existing .hl file. This bypasses the setup phase; however, if you use this method, you must use caution as to not overlook changes in controlling node activity due to variations in process, temperature, or voltage. See Figure 21 for the HAR setup phase flow.

Figure 21 HAR setup phase flow

Simulation PhaseDuring the simulation phase, the non-active cells are reduced so that only the active portion of the memory uses transistor representations. Reduced cells are represented by the appropriate capacitance for those nodes as grounded average capacitance (bulk capacitance for drain and source nodes, gate capacitance for gate nodes).

Both core cells with active controlling nodes, and those specified with the except keyword, are kept. Core cells specified with the except keyword are kept, regardless of the activity on their controlling nodes.

Idle nodes are defined as those nodes that do not change the logic state after the initial settling period. The initial setting period is required to avoid false activities created by unstable operating points. Voltages associated with the logic states can be controlled by the set_vec_opt and set_node_thresh commands, and default to 30% and 70% of the supply voltage.

The settling period after which node activity is monitored can be adjusted using the set_har_opt command and defaults to 10 ns. See Figure 22 for the HAR simulation phase flow.


Chapter 8: Using Hierarchical Array ReductionUsing HAR - The Prerequisites

Figure 22 HAR simulation phase flow

ReductionHAR enables you to reduce the memory required for circuit representation by eliminating the circuit details in memory that are not required to obtain accurate simulation results. For example, a standard 6-transistor (6T) SRAM bit cell requires approximately 350 bytes per transistor (2100 bytes total) to simulate accurately when the word line for the cell is active. When the word line is inactive, this subcircuit can be accurately modeled as the the bulk capacitance loading of the N-channel transmission gates. Due to the simulator’s existing requirement for a nodal capacitance table, the additional memory needed to represent this circuit is reduced to zero.

Using HAR - The Prerequisites

To use HAR, you must first meet the following basic requirements:■ Use for SRAM and DRAM memory cells only■ Specify hierarchical SPICE netlist■ Specify core cell names (core cell must be a subcircuit structure)■ Identify any instances that must not be reduced■ Provide stimulus■ Ensure that circuit behavior (controlling node activity) is not dependent on

memory content ■ Support device type in core cell: NMOS, PMOS, R, C, Diode, BJT


Chapter 8: Using Hierarchical Array ReductionUsing HAR - The Prerequisites

There is no inherent limitation to using HAR on embedded memories. However, since core cells are removed during the setup phase of simulation, simulation of embedded memories that rely on the memory content for subsequent circuit activity might not correctly simulate the array.

Sample .log File Data

The number of core cells encountered, and the number instantiated, are reported to the .log

file. The .log file also shows element counts for the reduced netlist and the complete netlist prior to reduction.

Example 32 illustrates output from HAR to the log file.

Example 32 Sample data for hierarchical array reduction in the .log file (excerpt)

Before Hierarchical array reduction2949120 1port_bit instancesAfter Hierarchical array reduction160 1port_bit instances (100.0% reduced)Summary of HAR transformation:Number of CMOS transistors : 18027810 --> 334050 (98.1% reduced)Number of elements : 18028215 --> 334455 (98.1% reduced)...

Original After HAR % reduction# of CMOS element : 18027810 334050 98.1# of diodes : 402 402 0.0# of dc voltage sources : 2 2 0.0# of stimulus elements : 1 1 0.0# of elements : 18028215 334455 98.1# of used elements : 334045

Setup 1001.0 real 907.0 user 9.0 sysSim 998.0 real 943.0 user 9.0 sysTotal 1999.0 real 1850.0 user 18.0 sys


Chapter 8: Using Hierarchical Array ReductionUsing HAR - The Usage Model

Using HAR - The Usage Model

This section of the chapter describes how to use HAR for simulating pre-layout and post-layout designs.

Simulating Pre-layout Designs

Two steps are required for invoking HAR:

1. Adding the –har [hilo_filename] argument at the command-line.

See the Adding the -har Command-line Option section for further details.

2. Adding the define_har_corecell configuration command.

See the Adding the define_har_corecell Configuation Command section for further details.

Adding the -har Command-line Option

The -har command-line option activates the HAR process with one optional argument—the hilo file name. Note that if the -har option does not contain an argument, a hilo file is not generated.

Example 33 shows -har option usage.

Example 33nanosim –nspice sram.sp –C cfg –har

Example 34 shows that if a hilo file name is specified, and the file exists, the setup phase is skipped.

Example 34 With an existing hilo filenanosim -nspice sram.sp -C cfg -har setup.hl

Example 35 shows the setup.hl hilo file is generated (at the end of the setup phase), if a hilo file name is specified, and the file does not exist.

Example 35 Without an existing hilo filenanosim -nspice sram.sp -C cfg -har setup.hl

If the –har option is not added to the NanoSim command-line, and the core cell is defined in the configuration file, the HAR feature is not enabled and the


Chapter 8: Using Hierarchical Array ReductionSimulating Pre-layout Designs

following warning message is generated in the NanoSim .log file: WARNING:NanoSim:0x2110206d:define_har_corecell: Command define_har_corecell can only be used with hierarchical array reduction

Adding the define_har_corecell Configuation Command

The define_har_corecell configuration command informs NanoSim to apply the HAR feature to a specified core cell. To use HAR, you must specify the subcircuit name that contains the core cells, followed by the controlling nodes for those specified core cells. All specified controlling nodes are monitored for activity. If the controlling nodes are toggled from one state to another during the setup phase, those controlling nodes are active and all transistors are kept during the simulation phase; otherwise, all inactive node transistors are reduced to abstract models.

In Example 36, a DRAM cell is defined inside a dram_cell subcircuit, and this subcircuit is instantiated.

Example 36.subckt dram_cell bl wl

mcell bl wl s vdd nch l=”0.18u” w=”0.23u”ccell s gnd 30f.ends dram_cell

x0<0> blx wl0<0> dram_cellx0<1> blx wl0<1> dram_cell...

In Example 37, in the configuration file a core cell is defined using the define_har_corecell command.

Example 37define_har_corecell dram_cell wl

Note:

Some memory circuits use a row or column of dummy cells that are identical in every respect to the rest of the memory array for self-timed circuitry, and thus, use the same subcircuit name. For functional verification of the memory, it is important to exclude these cells from reduction using the define_har_corecell configuration command except keyword.


Chapter 8: Using Hierarchical Array ReductionSimulating Pre-layout Designs

When you include initial conditions for nodes that have been reduced (for example, the internal nodes for a bit cell), the simulator reports those nodes as not found and indicates that the reason might be that the cells have been reduced.

Using Additional Config Commands (Optional)

You can specify the start time for monitoring the controlling nodes using the start_monitor keyword. The time default value is 10ns. This feature is useful for global reset issues—you can ignore monitoring during the global reset cycle. Any toggle activity before the start time is ignored.

The syntax is as follows:

set_har_opt [start_monitor=time] [verbose] [progress]

All files from the setup phase are deleted from the HAR simulation.

For a detailed description of each keyword, refer to the NanoSim Command Reference or invoke the respective man pages.

HAR LimitationsThe following features are currently unsupported in the HAR flow:■ BDC ■ HSPICE .ALTER Statement ■ Bisection ■ Mode 5


verbose Saves the intermediate files from the setup phase. All files from the setup phase are renamed with _har appended to the output suffix.

progress Prints status messages about the progress of HAR during simulations. Most useful for long HAR simulations.


Chapter 8: Using Hierarchical Array ReductionSimulating Post-layout Designs

The following features are limitations in the HAR flow:■ Global net/powernet back-annotation■ No EOU model support (greater than 2) for an idle cell

Simulating Post-layout Designs

HAR can be used to simulate post-layout designs. No additional configuration command or command-line option is required to enable HAR to work with a post-layout design. The set up to run an HAR post-layout design is identical to a pre-layout design.

HAR automatically detects RC parasitics that are:■ Embedded in the netlist

When parasitics are embedded in the netlist, HAR performs RC reduction and uses an efficient RC network building algorithm to handle the RC network. The embedded RCs generate a larger partition compared to a pre-layout design, so some performance penalties are expected.

■ In the back-annotation file

When the parasitics are captured by-way-of back-annotation, you must initially ensure that back-annotation (BA) can be performed properly without naming mismatches.

For example, a design contains the instance X1.X2.MN1.DRN

The instance name appears in the BA file, usually denoted as *|I in the file. The exact full instance name must be used for BA to perform properly. If the instance name cannot be properly matched, the RCs on that net are discarded—without an RC effect on the interconnect. See Table 70 for a comparison of the design netlist and BA file.

Table 70 HAR with back-annotation

Design netlist Back-annotation file

Differences Match (Yes/No)

X1.X2.MN1.DRN X1/X2/MN1:DRN NO YES

XX1.X2.MN1.DRN X1/X2/MN1:DRN Extra leading X in design netlist

NO



Note:

In the standard NanoSim BA flow, all naming mismatches listed above can be easily processed. The auto-correction feature will be enhanced in a future NanoSim release.

Once you confirm there are no naming mismatches between the design netlist and the BA file, HAR proceeds with RC reduction and constructs an RC network for simulations.

HAR Limitations

Unsupported features and known limitations in the pre-layout HAR feature also exist in the post-layout HAR feature. The following are two additional limitations in HAR:■ No hierarchical BA on non-memory array blocks■ No auto-correction on naming mismatches between netlist and BA files

X1.X2.MN1.DRN XX1/X2/MN1:DRN

Extra leading X in BA file

NO

X1.X2.MN1.DRN X1/2/MN1:DRN Missing X in BA file

NO

X1.X2.MMN1.DRN X1/X2/MN1:DRN Extra M character in design netlist

NO

Table 70 HAR with back-annotation

Design netlist Back-annotation file

Differences Match (Yes/No)




99Using Power Analysis

This chapter addresses how to use the various features provided by NanoSim for the analysis and diagnosis of power use for your circuits.

Overview

In discussing NanoSim simulation results, the term power is synonymous with current.

This chapter contains the following topics:■ Analyzing Power Consumption■ Performing a Dynamic Power Consumption Analysis■ Performing a Static Power Consumption Diagnosis■ Analyzing Power Using the RC and UD Simulation Modes

Analyzing Power Consumption

This section provides an overview of the features and methods available in NanoSim for the analysis of power use in your circuits at the full-chip, block, and individual node or element levels.

This section includes information on the following subjects:■ Analyzing Power at Full-Chip Level■ Analyzing Power Block-by-Block■ Measuring Wasted Power■ Measuring True Power in Watts■ Measuring Power Hierarchically


Chapter 9: Using Power AnalysisAnalyzing Power Consumption

■ Assigning Power Budgets■ Retrieving Power Information Interactively■ Controlling Power Reporting Resolution and Accuracy■ Printing and Reporting Branch Currents■ Printing and Reporting Internal Node Currents■ Working with Probes■ Printing Current Histograms and Tracking Windows

Analyzing Power at Full-Chip Level

Full-chip power analysis is the simplest type of power analysis. At this level the power usage of the chip can be characterized by the current statistics and waveforms of the main power nodes, such as Vdd and Gnd.

These can be obtained by using the following node current printing and reporting configuration commands:■ print_node_i

■ print_node_iavg

■ print_node_irms

■ print_node_didt

■ report_node_i

■ report_node_powr

When used for any voltage source node, the current reported is the current being supplied by the source (see Printing and Reporting Internal Node Currents). This value can be positive or negative. If a node is connected to both an ADFMI current port an a VSRC element (non-floating VSRC element), the current sign for the node current correlates to the VSRC element—not the ADFMI current port. Current ports are treated as sources, and the node connected to the current port is a VSRC node.

Note:

When used for any voltage source node, the signal node is the current flowing through the node, obtained by summing the branch currents flowing into the node (a positive current) while ignoring branch currents flowing out of the node (a negative current). The final value is always displayed as a negative value.



The print_node_i* commands are used to print the instantaneous, average, RMS, and didt waveforms of the requested nodes to the .out file. The report_node_i command can be used to request the reporting of the average, RMS, or peak currents to the .log file at the conclusion of the simulation. You can also use it to request that a current histogram be generated for the specified nodes (see Printing Current Histograms and Tracking Windows). The report_node_powr command is a macro and can be used to request all of the above information (except the didt waveform and current histogram) with one command.

The simplest approach is to use the report_node_powr command without specifying any arguments. This automatically selects all the supply and ground nodes, as well as all current probes, for current reporting.

Example 38 shows a sample report generated by the report_node_powr command. This report is first printed to the screen and then printed in the

.log

file, at the end of the simulation. The instantaneous, average, and RMS current waveforms for these nodes are also recorded in the .out file.

Example 38 Sample power report (generated by report_node_powr)Current information calculated over the intervals:

0.00000e+00 - 6.00000e+03 nsNode: gnd Average current : 7.11217e+02 uA RMS current : 1.26582e+03 uA

Current peak #1 : 1.49260e+04 uA at 4.40180e+03 ns Current peak #2 : 1.40570e+04 uA at 4.20180e+03 ns Current peak #3 : 1.32660e+04 uA at 4.00180e+03 ns Current peak #4 : 1.32540e+04 uA at 3.80180e+03 ns Current peak #5 : 1.31900e+04 uA at 2.86860e+03 nsNode: vdd Average current : -7.09839e+02 uA RMS current : 1.26431e+03 uA Current peak #1 : -1.54890e+04 uA at 4.40181e+03 ns Current peak #2 : -1.46190e+04 uA at 4.20181e+03 ns Current peak #3 : -1.38260e+04 uA at 4.00181e+03 ns Current peak #4 : -1.38160e+04 uA at 3.80181e+03 ns Current peak #5 : -1.32800e+04 uA at 2.86860e+03 ns

If you prefer to monitor power consumption during the simulation, you can use the nWave waveform viewer to watch the power consumption during the simulation.



Analyzing Power Block-by-Block

Block-level power analysis allows you to find out where most of the power is being consumed within a circuit. With this information, you can optimize power within blocks that consume too much power. Using a hierarchical netlist (a flat netlist will not work) you can isolate power to portions of blocks, if necessary. This type of analysis should be done in the design phase, prior to finishing the layout.

A block-level power analysis is most easily done using the report_block_powr configuration command. For example:

report_block_powr my_block x1.x1.*

This example generates a block power report to the

.log

file for the subcircuit x1.x1 under the label my_block.

The block power report provides a statistical analysis of the block including the number of elements, internal nodes, source nodes, and biput nodes. By default, it also lists the average and RMS source, ground, input, output, and biput currents for the block.

See Appendix B, “Detailed Configuration Command Information,” for a sample block power report. This report is first printed to the screen and then reported in the .log file, at the end of the simulation. Using optional arguments, the report_block_powr command can report the average and RMS ground current, and produce a list of the current supplied by each individual supply, ground, input, output, and biput node.

You can also produce a block-level waveform and current histogram. For more details, see Working with Probes.

Measuring Wasted Power

NanoSim defines wasted power, also called short-circuit current, for a circuit block, as any DC current consumed by the circuit block that is not used to charge block capacitances or capacitances driven by the block. Specifically, NanoSim defines the total current consumed by the block as the sum of the total supply current and the current from the biputs that are acting as supplies. (The current from biputs acting as ground is not included):



consumed current = total supply + Σ biput currents (i < 0)

Consuming CurrentThe consumed current is comprised of two types of current: capacitive current and wasted current, as described below:■ Capacitive Current

Any current for which its conductive path terminates (or originates) at a circuit capacitance. This current is essential in carrying out the switching functions of the circuit.

■ Wasted Current

Any current for which both ends of the conducting path are voltage sources. This current does not contribute to the changing of circuit voltages and, therefore, is considered wasted.

Usually, wasted current consists of the DC current flowing from power to ground. This wasted power can come from crowbar or short-circuit current caused by both P-channel and N-channel devices being active during a transition. It can also come from floating inputs or from DC paths that are unintended such as device leakage currents. In addition, analog bias circuits and current mirrors in operational amplifiers that cannot be avoided are reported as wasted power.

The wasted current can be further divided into two categories: dynamic and static.

• Dynamic wasted current is the portion of wasted current that occurs while the circuit is actively switching. The crowbar or short-circuit current, previously mentioned, is an example of dynamic wasted current.

• Static wasted current is the portion of wasted current that occurs while the circuit is inactive or not switching. This typically consists of device leakage currents or other static DC paths.

Using the report_block_powr CommandYou can measure wasted power using the track_wasted= option of the report_block_powr command. For example:

report_block_powr my_block track_wasted=1 x1.x1.*



This command generates a power analysis report for the subcircuit x1.x1.* that includes both the standard block power report (see Analyzing Power Block-by-Block) and a wasted power report.

Example 39 shows a sample of the additional information provided by the track_wasted= option. This report provides the following information about the block:■ Average and RMS capacitive current

The total current expended in charging block capacitances■ Average and RMS wasted current

The total DC current consumed by the block and not used to charge the block capacitances

■ Leakage percentage

The fraction of current consumed by the block, from all sources, that is not used to charge block capacitances.

Example 39 Sample information provided by the track_wasted= option of the report_block_powr command

Average capacitive current: -39057.934468 uARMS capacitive current : 56567.265346 uAAverage wasted current : -6115.921641 uARMS wasted current : 9764.697468 uAWasted current percentage : 13.538631%

Example 40 shows a sample of the additional information provided by the split_wasted= option. The simulation reports the dynamic and static wasted power separately.

■ Average and RMS static wasted current

The portion of the wasted current occuring while the circuit is static (in a steady_state)

■ Average and RMS dynamic wasted current

The portion of the wasted current occuring while the circuit is active (switching)



Example 40 Sample information provided by the split_wasted= option of the report_block_powr command

Average static wasted current : -443.965409 uA RMS static wasted current : 1595.630437 uA Average dynamic wasted current : -5650.882784 uA RMS dynamic wasted current : 9084.230948 uA

You can also produce block-level waveforms and current histograms for the capacitive and wasted currents. For more details, see Working with Probes.

Measuring True Power in Watts

You can use NanoSim to obtain the true power consumption (in watts) for a given circuit block. To do this, you need to specify the track_power= option when using the report_block_powr command. For example:

report_block_powr my_block track_power=1 x1.x1.*

In addition to the basic current reports, this command reports the total power consumption of the block.

Example 41 shows a sample of the additional information provided by the track_power= option. The power reported includes contributions from all sources and biputs for the block.

Example 41 track_powr= option sampleAverage block power: 179937.712787 uΩRMS block power: 259344.959596 uΩ

You can also produce block-level waveforms and current histograms. For more details, see Working with Probes.

Measuring Power Hierarchically

The level= and at_level options of the report_block_powr command allow you to do an analysis of block-level power in a hierarchical netlist. You can use these options to request power reports for all hierarchical sub-blocks of the specified circuit block with a single command.

The level= option automatically generates power reports for all sub-blocks of the specified subcircuit down to the specified level.



report_block_powr top level=2 *

This example generates a power report for the entire circuit, and automatically generates reports for all sub-blocks down to level 2, such as x1.*, x2.*, x1.x1.* and, x1.x2.*.

The at_level= option generates power reports only for the sub-blocks at the specified level:

report_block_powr top at_level=2 *

This example generates power reports for the entire circuit and the second-level sub-blocks x1.x1.* and x1.x2.* but not the first level sub-blocks.

In each case, the specified level refers to the absolute level in the circuit hierarchy, and is not relative to the level of the specified pattern:

report_block_powr my_block at_level=4 x1.x2.*

This example generates a power report for the x1.x2.* sub-block and its fourth-level hierarchal sub-blocks, such as x1.x2.x3.x4.*.

For each sub-block generated using the level= or at_level= options, NanoSim writes a standard block power report to the .log file. In each case, the reporting options will be the same as the top-level block. In addition, when either option is used, the simulator writes a hierarchical power report for the specified block hierarchy to the .power file.

NanoSim generates a similar report for the ground, supply, biput, wasted currents, and the power if those quantities are being tracked.



The file sample in Example 42 shows a report for the total supply current as printed to the

.power

file:

Example 42 Supply current report from the .power fileBLOCK top: AVERAGE SUPPLY CURRENT.LEVEL CURRENT PERCENT OF PERCENT OF CHILD BLOCK NAME

(uA) PARENT TOP----------------------------------------------------------------------0 -1537.8 100.00 100.00 top1 -1537.8 100.00 100.00 xsr34x22.top2 -359.83 23.40 23.40 xsr34x22.x1161.top2 -322.71 20.98 20.98 xsr34x22.x1164.top2 -214.54 13.95 13.95 xsr34x22.x1166.top2 -207.33 13.48 13.48 xsr34x22.x1158.top2 -192.92 12.55 12.55 xsr34x22.x1162.top2 -81.777 5.32 5.32 xsr34x22.x1163.top2 -57.569 3.74 3.74 xsr34x22.x1157.top2 -52.966 3.44 3.44 xsr34x22.x1160.top2 -42.359 2.75 2.75 xsr34x22.x1169.top2 -5.8502 0.38 0.38 xsr34x22.x1167.top2 0.0086932 -0.00 -0.00 xsr34x22.x1170.top2 0 -0.00 -0.00 xsr34x22.x1165.top2 0 -0.00 -0.00 xsr34x22.x1168.top2 0 -0.00 -0.00 xsr34x22.x1159.top

In addition, you can generate a block-level waveform and current histogram for each of the sub-block reports. For details, see Working with Probes.

Assigning Power Budgets

You can use NanoSim to assign power/current budgets to blocks created with the report_block_powr command and monitor those blocks for violations.

You will need to use the set_block_budget command to do this:

report_block_powr top *set_block_budget max_avg_src=100uA max_inst_src=1uA top



This pair of commands creates a block labeled top that consists of the entire circuit and assigns current budgets of 100 μA for the average supply current, and 1 μA for the instantaneous supply current.

NanoSim reports violations of the assigned budgets in the .err file and in the .power file. See Appendix B, “Detailed Configuration Command Information.”

You can assign budgets to the instantaneous, average, and RMS values of the block supply current, ground current, biput current, wasted current, and power, as well as to the block’s leakage percent.

Ordinarily, NanoSim checks only for budget violations at the conclusion of the dynamic simulation. However, if you specify the run_time_check=1 option, NanoSim will monitor the instantaneous current and power values during the dynamic simulation. In this case, NanoSim writes a message to the .err file each time the budget is violated, and prints a summary of each violation in the .power file. You can use the handle_ckt_error command with the run_time_check= option to drop the simulation into the interactive mode whenever a budget violation occurs.

Finally, you can specify the check_dcpath=1 option to trigger a DC path check each time an instantaneous current/power budget violation occurs.

Retrieving Power Information Interactively

During the dynamic simulation, you can interactively retrieve most power information that is reported to the output files if you have previously instructed NanoSim to track that information.

You can use the following commands in Example 43 to obtain node current information:

Example 43 Node current information commandsget_node_iget_node_iavgget_node_irmsget_node_ipeak

These commands report the current value of the instantaneous, average, RMS, and peak currents, respectively. In each case, you must have requested the simulator to track the relevant information requested for the command to work (see Analyzing Power at Full-Chip Level and Printing and Reporting Internal Node Currents).



You can use the following commands to obtain element and current information:

get_elem_iget_elem_iavgget_elem_ipeak

These commands report the current value of the instantaneous, average, RMS, and peak currents, respectively. In each case, the simulator reports the values for all element branches being tracked. You can track the current for an element branch using the commands discussed in Printing and Reporting Branch Currents.

You can use the following commands to get interactive information on blocks created with the report_block_powr command:

get_block_infoget_block_iget_block_icont

The get_block_info command supplies a statistical description of the block, essentially identical to the header in the report_block_powr report, in the

.log

file. In addition, if the block was generated using the level= or at_level= options, it will show the block’s hierarchical parent block, as well the number and names of its children.

The get_block_i command reports the instantaneous, average, and RMS values of all quantities tracked by the block.

The get_block_icont command generates hierarchical power information for blocks created using the report_block_powr level= or at_level options. This consists of a sorted list of the block’s hierarchical children and their contributions to the specified currents:

get_block_icont current=src type=inst xsr34x22.top



Example 44 displays the contribution of each child block of the parent block 34x22 to the block’s total supply current.

Example 44 Output from the get_block_icont commandBlock: xsr34x22.topTotal instantaneous source current :-16054.265763 uAContributions from children -

xsr34x22.x1158.top : -7026.176334 uAxsr34x22.x1167.top : -3376.436160 uAxsr34x22.x1166.top : -2848.805135 uAxsr34x22.x1161.top : -2100.318100 uAxsr34x22.x1169.top : -691.675033 uAxsr34x22.x1164.top : -7.744000 uAxsr34x22.x1160.top : -5.689000 uAxsr34x22.x1163.top : 4.136000 uAxsr34x22.x1162.top : -2.858000 uAxsr34x22.x1170.top : 1.320000 uAxsr34x22.x1165.top : 0.000000 uAxsr34x22.x1168.top : 0.000000 uAxsr34x22.x1159.top : -0.000000 uAxsr34x22.x1157.top : -0.000000 uA

You can use the following interactive commands to get current information on individual probe nodes generated by the report_block_powr command, or the assign_node_i and assign_branch_i commands:

get_probe_iget_probe_iavgget_probe_irmsget_probe_ipeak

Controlling Power Reporting Resolution and Accuracy

The accuracy of the reported current and power values is dependent on the accuracy of the underlying simulation engine. Therefore, all commands that affect the accuracy of the timing or voltage also affect power. In addition, the following commands control different aspects of the simulation specific to power reporting:

set_sim_iresset_print_iresset_print_tresset_powr_acc



The set_sim_ires and set_print_ires commands control the current resolution of the current/power reporting. NanoSim ignores currents that are smaller than the values set by these commands.

The set_print_ires command affects only the current/power output and reporting—it does not affect the underlying simulation engine. In contrast, the set_sim_ires command does modify certain simulation parameters to ensure that the underlying simulation is done with sufficient accuracy to support the specified current resolution. In general, it is recommended that you use the set_sim_ires command instead of set_print_ires when you need to achieve a greater current resolution; otherwise, the reported current values might not be accurate. The default current resolution is 1 μA. The set_print_ires command typically does not impact performance, but does affect the size of the .out file. The set_sim_ires command can have a significant effect on the speed of the simulation.

The set_print_tres command controls the time resolution of all simulation output, printed to the .out file, as well as the time resolution used in calculating the reported average and RMS power numbers. The time resolution is set by default to be ten times the value of the simulation time resolution (see set_sim_tres). This setting should be adequate for most situations; however, if you want to get the maximum accuracy in the current calculation, you should set the print time resolution to be the same as the simulation time resolution. This setting will create a larger output file and possibly reduce the simulation performance since the output handles a larger number of points.

The set_powr_acc command allows you to set the level of detail used in the accounting of circuit capacitances when doing element and node current calculations. Typically, the simplified models provide a high level of accuracy, and a significant improvement in simulation performance, when used to calculate the average and RMS current values. However, you might want to use the more accurate models if you need to get the detailed shape of the instantaneous waveforms. Specifically, you should apply the most accurate settings when comparing instantaneous waveforms of small circuits with another simulator, such as a SPICE simulation. Results for large circuits typically are not very sensitive to the capacitance model. The default settings usually provide a reasonable balance of accuracy and performance.

Printing and Reporting Branch Currents

Using NanoSim, you can print many different types of branch currents. There are commands that print instantaneous, average, and RMS currents as



waveforms to the .out file. NanoSim also provides commands to report average, RMS, and peak current summaries to the .log file.

The branch current printing commands follow the HSPICE conventions for i1, i2, i3, and i4 currents. The following list shows the branch current mapping for MOS transistors:

il = drain currenti2 = gate currenti3 = source currenti4 = bulk current

NanoSim also provides commands for printing and reporting DC current for specified elements. Use the following commands to print all types of branch currents:■ print_branch_didt1

■ print_branch_didt2



■ print_branch_didtdc

■ print_branch_i1

■ print_branch_i1avg

■ print_branch_i1rms

■ print_branch_i2



■ print_branch_i3



■ print_branch_i4



■ print_branch_idcavg

■ print_branch_idcrms



■ report_branch_i

■ report_branch_powr

■ print_branch_idc

Printing and Reporting Internal Node Currents

It is sometimes useful to be able to measure the amount of current flowing through an internal (non-voltage source) node. Since, according to Kirchhoff’s Current Law, the algebraic sum of all currents at a node is zero, internal nodes must be treated differently from voltage source nodes. For this reason, NanoSim defines the internal node current to be the sum of the positive currents flowing into the node.

Use the following commands to print and report internal node currents (see Analyzing Power at Full-Chip Level):■ print_node_i

■ print_node_iavg

■ print_node_irms

■ print_node_didt

■ report_node_i

■ report_node_powr

Working with Probes

Under some circumstances, the standard block-level power reporting commands (see Analyzing Power Block-by-Block and Measuring Wasted Power) might not provide sufficient flexibility. For these cases, NanoSim provides the commands assign_node_i and assign_branch_i. Together these commands allow you to construct a completely arbitrary sum of element branch currents:

assign_branch_i drain d_sum mos1 mos2 mos3 mos4

This example constructs a sum of drain currents for several MOS transistors and assigns it to the d_sum probe:

assign_node_i any_node n_sum mos1 mos2 mos3 mos4



This example obtains the sum of all currents from these transistors into the node any_node.

The same probe name can be used in multiple assign statements to build up the desired sum.

After the probe is constructed, the commands print_probe_i and report_probe_i can be used to obtain .out file waveforms and .log file current summaries for the probe identical to those created for the node currents. In addition, the report_node_powr command requests current information for all probe nodes if used without specifying any nodes. These commands can also be used with the report_block_powr command to obtain waveform information from those commands.

Printing Current Histograms and Tracking Windows

NanoSim can generate a current histogram for each node, branch, and probe. The current histogram report consists of a report of the average, RMS, and peak currents over a set of user-defined intervals printed to the .hist file.

You can print a histogram using the report_node_i, report_elem_exi, and report_probe_i configuration commands. Alternatively, you can use the report_ckt_phist command, which automatically generates current histograms for each constant voltage source node, as well as all user-defined probe nodes. This automatically generates histograms for all power nodes including probes created by report_block_powr.



A sample current histogram report for nodes Vdd and Gnd is shown in Example 45.

Example 45 Sample current histogram reportNode: XGND Start (ns) Stop (ns) Avg (uA) RMS (uA) Peak (uA) Time (ns) 5.0000e+01 9.0000e+01 2.8779e+01 5.3431e+01 1.0100e+02 6.0400e+01 9.0000e+01 1.3000e+02 7.0781e+01 8.4014e+01 1.1700e+02 1.0245e+02 1.3000e+02 1.7000e+02 5.3766e+01 7.3174e+01 1.0100e+02 1.5040e+02 1.7000e+02 2.1000e+02 2.1036e+01 4.5936e+01 1.3500e+02 2.0232e+02 2.1000e+02 2.5000e+02 1.0000e+02 1.0000e+02 1.0000e+02 2.1000e+02 2.5000e+02 2.9000e+02 9.0790e+01 9.0970e+01 1.0100e+02 2.5040e+02 2.9000e+02 3.3000e+02 7.3625e+01 7.3732e+01 8.2000e+01 2.9000e+02 3.3000e+02 3.7000e+02 6.1875e+01 6.1934e+01 6.8000e+01 3.3000e+02 3.7000e+02 4.1000e+02 5.4000e+01 5.4032e+01 5.8000e+01 3.7000e+02 4.1000e+02 4.5000e+02 4.9000e+01 4.9015e+01 5.1000e+01 4.1000e+02Element: IOBUFF0.P1 Branch: 1 Start (ns) Stop (ns) Avg (uA) RMS (uA) Peak (uA) Time (ns) 5.0000e+01 9.0000e+01 1.0304e+03 4.9851e+03 3.3619e+04 6.2000e+01 9.0000e+01 1.3000e+02 1.4845e+03 7.0174e+03 5.1510e+04 1.0190e+02 1.3000e+02 1.7000e+02 1.0614e+03 4.9601e+03 3.3150e+04 1.5200e+02 1.7000e+02 2.1000e+02 8.5798e+02 5.1421e+03 4.3718e+04 2.0181e+02 2.1000e+02 2.5000e+02 1.2009e+02 1.2009e+02 1.2100e+02 2.1000e+02 2.5000e+02 2.9000e+02 2.9633e+01 5.0674e+01 3.2600e+02 2.5214e+02 2.9000e+02 3.3000e+02 1.1750e+01 1.1874e+01 1.5000e+01 2.9000e+02 3.3000e+02 3.7000e+02 7.2500e+00 7.3144e+00 9.0000e+00 3.3000e+02 3.7000e+02 4.1000e+02 4.6250e+00 4.6771e+00 6.0000e+00 3.7000e+02 4.1000e+02 4.5000e+02 2.7500e+00 2.7839e+00 4.0000e+00 4.1000e+02

You can specify the histogram intervals using the set_print_iwindow command:

set_print_iwindow period=100ns start=25ns end=238ns on_time=30ns

This example specifies the following current windows:

From 25 ns to 55 ns

From 125 ns to 155 ns

From 225 ns to 238 ns

When a set of current tracking intervals is created by the set_print_iwindow command, the simulation tracks current only during the


Chapter 9: Using Power AnalysisPerforming a Dynamic Power Consumption Analysis

specified intervals. Therefore, waveforms printed to the .out file are limited in time to the specified intervals. Also, the average, RMS, and peak currents and waveforms are only computed based on the periods when tracking is enabled. This can be useful when you want to ignore part of the simulation run, as when you are calculating the current statistics.

Performing a Dynamic Power Consumption Analysis

This section provides an overview of the NanoSim features that can be used during the dynamic simulation to identify and diagnose conditions in your circuits that could lead to excessive power consumption.

This section covers the following subjects:■ Checking Dynamic Rise and Fall Times (U-State Nodes)■ Detecting Dynamic Floating Nodes (Z-State Nodes)■ Detecting Excessive Branch Currents■ Analyzing Hot-Spot Node Currents■ Detecting Dynamic DC Paths

Checking Dynamic Rise and Fall Times (U-State Nodes)

There are a couple of reasons why a circuit could end up consuming an unexpectedly large amount of power. For example, if a node spends an excessive amount of time in a U-state, it could create a large short-circuit current.

The report_node_u and report_node_quick configuration commands provide a mechanism to check for excessively long and excessively short rise/fall times, respectively, during the dynamic simulation. Each command checks the time taken by the node to transition between its logic high and low threshold and reports violations to the .err file. By default, the logic high and low thresholds are set to 70% and 30% of the node’s high voltage, respectively. You can use the set_node_thresh command to adjust the default voltage.

Detecting Dynamic Floating Nodes (Z-State Nodes)

If a node is left floating (Z-state) for an excessive time, the node voltage could drift into an intermediate voltage level due to sub-threshold short-circuit



currents in the associated elements. This can lead to unexpected DC paths in logic blocks that are in the node fanout.

The report_node_z configuration command provides a mechanism for reporting any node that stays in the Z-state longer than a user-specified time during the dynamic simulation. Violations are reported to the .err file.

Detecting Excessive Branch Currents

When attempting to diagnose excessive power in a circuit, it is often helpful to determine which circuit elements might be carrying unexpectedly large currents. You can use the report_elem_exi command to monitor the currents of specified elements and report those elements that have currents exceeding a specified threshold for a specified time during the dynamic simulation. NanoSim reports violations to the .err file.

Analyzing Hot-Spot Node Currents

When you are redesigning for lower-power consumption, it’s helpful to know how each circuit node contributes to the total power consumption. The report_node_hotspot command lists the average current statistics for the specified nodes in the

.sum

file.



A sample hot spot report is shown in Example 46.

Example 46 Sample hot spot report ***************************

*** Hot Spot Statistics *** *************************** Node Name Cap(fF) Toggle Icin(uA) Icout(uA)______________________________________________________________________X1.4 4150.91 6 503.21 510.44X1.5 6150.91 6 455.08 496.35X1.9 4150.91 6 354.64 450.23X1.3 2150.91 6 279.99 270.87X1.8 650.91 6 81.96 81.85X1.1 650.91 6 81.80 81.77X1.2 150.91 6 18.96 19.00X1.7 150.91 6 18.88 18.90X1.6 150.91 6 18.16 18.091 69.23 6 8.66 7.96 Total non-input nodes : 10Total node toggles : 60Total charging current : 1821.34 uATotal discharging current : 1955.45 uA

The hot spot report provides the following information for each node:■ Average Node Capacitance—lumped from netlist, wiring, and transistor

gate and diffusion capacitances■ Toggle Count—total number of logic toggles for the node■ Average Charging Current—average current flowing into the capacitances

connected to the node■ Average Discharge Current—average current flowing out of the

capacitances connected to the node

If a node toggle count is as expected, the charge and discharge currents represent the mandatory current consumption to support the necessary circuit operation



Ideally, the product of the node capacitance, toggle count, and supply voltage will equal the sum of the charging and discharging current multiplied by the simulation period. Thus, if

(toggle count)*(node capacitance)*(Vdd) - (charge + discharge)*(simulation time)

is greater than 0, some toggles cross the logic threshold, but never reach the full-swing value (either Vdd or 0). Conversely, if the difference is less than 0, the node voltage waveform might show some glitches, either above or below the logic threshold voltage for which no toggle is counted.

A large circuit with a large number of nodes could produce a huge volume of data in the .sum file, which would be too complicated to analyze. You can use the set_hotspot_factor command to suppress those nodes for which the sum of the charging and discharging current is less than a specified factor multiplied by the sum for the node with the largest currents.

The report in Example 46 can be used to illustrate the effect of applying a hot spot factor of 0.5. The node with the largest currents is X1.4, which has a charging current of 503.21 uA and a discharging current of 510.44 uA. Applying the 0.5 hotspot factor, the sum of the charging and discharging currents multiplied by the hotspot factor equals 506.83 uA. The sum of any other node’s charging and discharging current would have to be greater than this number to be included in the individual node report. In this case, all nodes below X1.3 are excluded from the report.

The summation of charge currents for all nodes within a block represents the average charge current for the block. Conversely, the summation of discharge currents for all nodes within a block represents the average discharge current for the block. The difference between the total average block current and the charge current should be the average short-circuit current from DC short-circuit, or the short-circuit current, during the transition period when both NMOS and PMOS transistors were conducting. This is one way of estimating the circuit short-circuit current.

Detecting Dynamic DC Paths

In CMOS circuits, any DC current flowing in the circuit between power and ground is considered to be wasted power. Therefore, wasted power can come from “crowbar” or “short-circuit” current caused by both P-channel and N-channel devices being on during a transition. Wasted power can come from mismatched supply voltages, a failure to reach full swing, timing errors, or other



unintended sources. It can also come from unavoidable analog bias circuits and current mirrors in operational amplifiers.

The report_ckt_dcpath command provides a method of detecting DC paths that occur during the dynamic simulation. You can use the set_dcpath_thresh command to prevent the reporting of DC paths with small currents. A DC path is reported only if the DC current through each element in the path exceeds the threshold. You can use this to exclude paths for bias circuits from the report, if they are sufficiently small. Alternatively, you can use the limit_dcpath_search command to exclude certain blocks from the search or to limit the search to specific blocks.


Chapter 9: Using Power AnalysisPerforming a Static Power Consumption Diagnosis

The detected DC paths are reported to the screen and to the .dcpath file, as shown in Example 47.

Example 47 Sample DC path reportNonzero dc path(s) found at time 200 ns Path # 1---------------------------------------------------------------------- resistor IOBUFF0.R1 current = -0.02 uA from XGND voltage = 0.00 V to DATAOUT0 voltage = 0.00 V resistor IOBUFF0.R2 current = 79.98 uA from IOBUFF0.VR voltage = 4.00 V to DATAOUT0 voltage = 0.00 V---------------------------------------------------------------------- Path # 2---------------------------------------------------------------------- resistor IOBUFF0.R1 current = -99.97 uA from XGND voltage = 0.00 V to DATAOUT0 voltage = 5.00 V inductor IOBUFF0.OUTBOND current = -119.93 uA from DATAOUT0 voltage = 5.00 V to IOBUFF0.OUT1 voltage = 5.00 V transistor IOBUFF0.P1 (type PMOS) current = -119.91 uA gate IOBUFF0.INGATE voltage = 0.00 V drain IOBUFF0.OUT1 voltage = 5.00 V source IOBUFF0.DP1 voltage = 5.00 V transistor IOBUFF0.P2 (type PMOS) current = -119.93 uA gate IOBUFF0.PGATE voltage = 0.00 V drain IOBUFF0.DP1 voltage = 5.00 V source EVDD voltage = 5.00 V inductor IOBUFF0.L1 current = -119.93 uA from EVDD voltage = 5.00 V to VDD voltage = 5.00 V----------------------------------------------------------------------

Performing a Static Power Consumption Diagnosis

This section provides an overview of the static power diagnosis features available in NanoSim. You can use these features to analyze your circuit based on its topology and look for conditions that might lead to excessive power use. These features are intended to provide an alternative to the dynamic power



diagnosis when dynamic simulation requires too much simulation time and you want to scale down power consumption. These analyses are performed before the dynamic simulation begins and generally require significantly less simulation time than a full-dynamic simulation.

This section includes information on the following subjects:■ Detecting Static DC Paths■ Detecting Static Excessive Rise/Fall Time

Detecting Static DC Paths

A static DC short-circuit path exists if a node has a static conducting path to Vdd and a static conducting path to Gnd. Each node in both paths is in a fighting condition at all times. Use the report_ckt_leak command to flag such nodes.

However, a static DC short-circuit path, which is independent of the external stimulus, rarely exists in CMOS circuits. A dynamic short-circuit path is more likely, although it requires a specific input condition that might not occur. The report_ckt_leak command can find a static DC path, as well as detect several unusual topological conditions in regular CMOS designs. These conditions, although insufficient to confirm a definite DC short-circuit path, might uncover potential short-circuit paths.

The report_ckt_leak command searches for the following conditions:■ Partial Swing Detection—A node is driven only by NMOS (PMOS)

transistors and it drives at least one PMOS (NMOS) transistor’s gate.■ No Path to Vdd/Gnd—There is no possible conducting path to the node from

a supply (ground) node. ■ Static Path to Vdd/Gnd—A static conducting path exists from a supply

(ground) node to the node. ■ Node is Stuck at High/low Voltage—A static conducting path exists between

the node and a supply (ground) node. In addition, there is no possible conducting path between the node and any ground (supply) node.

■ Static DC Path—A static conducting path exists between two voltage source nodes.

For the conditions mentioned above, the report_ckt_leak command does not take into account difficulties due to multiple supplies or grounds with different voltages. All supplies (constant voltage sources with voltages above



the logic high threshold) and grounds (constant voltage sources below the logic high threshold) are assumed to be equivalent.

For circuits that have multiple supplies or grounds, report_ckt_leak also searches for the following conditions that can lead to unintended DC paths:■ Partial-off PMOS

A PMOS transistor with a source or drain that has a possible channel-connected path to a supply or input node with high voltage VDDH. In addition, its gate has a possible channel-connected path to a supply or input node with high voltage VDDL, where the voltage of VDDH is greater than VDDL.

■ Partial-off NMOS

An NMOS transistor with a source or drain that has a possible channel-connect path to a ground or input node with low voltage GNDL. In addition, its gate has a possible channel-connect path to ground or input node with low voltage GNDH, where the voltage of GNDH is greater than GNDL.

■ Forward-bias PMOS

A PMOS transistor with a source or drain terminal that has a possible channel-connected path to a supply or input node with high voltage VDDH. In addition, its substrate is connected to a voltage source of voltage VDDL, where VDDH is greater than Vdd.

■ Forward-bias NMOS

An NMOS transistor with a source or drain terminal that has a possible channel-connected path to a ground or input node with high voltage GNDL. In addition, its substrate is connected to a voltage source of voltage GNDH, where GNDH is greater than GNDL.

NanoSim reports any problems it detects to the .err file. For details on the syntax of these reports see the Circuit Simulation and Analysis Tools Reference Guide.

Detecting Static Excessive Rise/Fall Time

A large transient short-circuit current might occur if the voltage rise/fall transition time for a node is excessive. You can use the report_node_maxrf command to report nodes with worst-case transition times that exceed a specified threshold time.


Chapter 9: Using Power AnalysisAnalyzing Power Using the RC and UD Simulation Modes

The node rise/fall time is the time taken for the node to make the transition between its high and low logic thresholds. This time is estimated based on the lumped capacitance for the node and the maximum impedance driving it. By default, the logic high and low thresholds are set to 70% and 30%, respectively, of the node’s high voltage. You can adjust these default levels using the set_node_thresh command.

NanoSim reports any problems it detects to the .err file. For details on the syntax of these reports, see the Circuit Simulation and Analysis Tools Reference Guide.

Analyzing Power Using the RC and UD Simulation Modes

The RC and UD modes provide a fast power estimation for digital CMOS circuits. In most digital circuits, major power contributions come from switching activities. Therefore, the RC and UD modes—which use switch-level simulation techniques—produce a faster average power estimation with reasonable accuracy, when compared with any other NanoSim mode ( PWL, ACC, SMS). RC mode provides full-delay information for CMOS circuits, while UD mode provides only fixed unit-delay information.

Dissipating Power

Power dissipation in digital CMOS circuits is attributed to two major power sources: capacitive power and short-circuit power, as shown in Figure 23.



Figure 23 Short-circuit (sc) current calculation

Switching current usually plays a major role in most digital circuits. When running in RC or UD mode, the simulator calculates the average power based on the charging and discharging of node capacitances. That is, the charging or discharging current due to a voltage change (dV) at a node is C *(dV/dt), where C is the capacitance and dt is the transition time of the node. This calculation can accurately estimate the average switching power in circuits.

For CMOS circuits, short-circuit current estimation in the RC or UD mode is based on the input and output slopes and is less accurate than PWL mode. In RC or UD mode, the simulator estimates the short-circuit current ( ) using the

switching capacitive current ( ) and the ratio of the input slope and output

slope. There will always be some discrepancy between the estimated short-circuit current calculated in the RC and UD modes and the actual short-circuit current calculated in PWL mode. If the short-circuit current is small, this discrepancy is negligible. However, if a circuit contains a large short-circuit current (if the input slope is much slower than the output slope), the discrepancy between RC and UD mode results and PWL mode results could increase significantly. In this case, a power analysis using RC or UD mode would be inaccurate.

Another source of discrepancy of average power between PWL and RC (UD) modes is derived from the application of different timing models, which could cause new glitches or cause existing glitches to change width and height, or even disappear.

Itotal

Isc

Icap

I sc

I totalx 100

Icap Isc

percent short-circuit =

+=I total

Isc

Icap



Running a Simulation in RC or UD Mode

You can instruct the simulator to run in RC mode in two places. You can either use the -d RC command-line option when starting the simulator or you can use set_sim_mode RC in the configuration file. Likewise, you can use the -d UD command-line option or the set_sim_mode UD command to run in the UD power analysis mode.

Power analysis in RC and UD mode is based on switching capacitive power in each stage, which generally corresponds to a gate. Therefore, only the average power of a stage is meaningful and, as a result, the instantaneous power is displayed based on the average power. You can combine RC and UD stages with PWL stages to achieve a balance between speed and accuracy. NanoSim’s RC and UD modes apply a few basic circuit detection rules to the circuits and mark portions of the circuit to use the PWL mode.

Using Power Diagnosis Commands

You can apply the following power diagnosis commands to analyze RC and UD stages:■ report_block_powr

■ report_probe_i ■ print_probe_i

■ report_node_i

■ print_node_i

Use the report_block_powr command to analyze power use for specified stages. If the specified elements cover only a partial stage, this command forces the whole stage into PWL mode:

report_block_powr blk2 xadder.* blk1

This example reports the average power dissipation for a circuit block, in this case, an adder circuit.

Use the report_probe_i and print_probe_i commands to report or print current information for probes created by the report_block_powr command:



print_probe_i avg blk1_vddprint_probe_i avg total_src[blk2]

This example prints the average Vdd current waveform of the adder block specified in the first example.

Use the report_node_i and print_node_i commands to get the total power dissipation of RC and UD stages by applying them to power nodes (Vdd/Gnd) connected to these stages. Applying them to non-power nodes forces the stages into PWL mode.

report_node_i avg VDDreport_block_powr blk1 track_wasted=1 *report_block_powr blk2 *

These commands report the power dissipation for the whole circuit, assuming Vdd is the only power source.

Caution!

Applying the report_branch_i, print_branch_i*, print_node_v, report_elem_exi, assign_branch_i, or assign_node_i command causes the given elements to be PWL, which defeats the fast power estimation feature for elements intended to be RC or UD elements.




1010 Post-Layout and Back-Annotation Simulation

This chapter describes the seamless NanoSim post-layout flow. The post-layout flow product sequence is: Hercules > Star-RC XT > NanoSim.

Overview

This back-annotation post-layout flow enables you to do the following: ■ Control the simulation command hierarchically■ Apply analysis on the circuit■ Control the amount of back-annotation needed to meet your accuracy

requirements■ Remove the risk of errors attributed to manual (non-automated) intervention■ Speed-up the verification process and increases design cycle throughput

NanoSim enables three flows:

1. Standard Post-layout

2. Selective Net Back-annotation

3. Selective Net Extraction

This chapter contains the following topics:■ Processing Parasitics During the Post-Layout Simulation■ Using the NanoSim Standard Post-Layout Flow■ Setting up the Post-layout Flow■ Back-annotating the Layout Device Properties■ Generating Device Properties for Schematic-based Back-annotation■ Default Settings for NanoSim Post-layout Simulation


Chapter 10: Post-Layout and Back-Annotation SimulationProcessing Parasitics During the Post-Layout Simulation

■ NanoSim Selective Net Back-annotation Flow■ Processing Capacitors in NanoSim■ Integrating the Post-layout Flow with Other NanoSim Features■ Optimizing Accuracy and Speed for Post-layout Simulation■ NanoSim Post-layout Flow Warning Messages■ DPF Warning Messages:■ SPEF Triplet Values■ Error Back-annotation■ Star-RC XT commands

Processing Parasitics During the Post-Layout Simulation

In addition to the post-layout flow, NanoSim enables you to efficiently process parasitics. Features such as RC reduction and control of the capacitor’s interpretation enable simulation throughput. These features are an essential part of post-layout simulation.

The NanoSim post-layout flow is developed using Star-RC XT and Hercules. NanoSim also works with other extraction or LVS tools. If you use another extraction tool, such as Calibre, you must convert the Caliber setup to Hercules to enable a seamless flow.

See Table 71 for definitions of the post-layout terms used throughout this chapter.

Table 71 Post-layout terms

Term Definition

BA nets back-annotation nets

schematic netlist original schematic netlist

layout ideal netlist layout ideal netlist generated by Star-RC XT

* Instance section flatten transistor information inside the DSPF file

SPF Standard Parasitic Format generated by Star-RC XT


Chapter 10: Post-Layout and Back-Annotation SimulationUsing the NanoSim Standard Post-Layout Flow

Using the NanoSim Standard Post-Layout Flow

The standard post-layout flow is comprised of two flows: ■ Flow 1 (schematic-based)—flat parasitic back-annotation onto the

schematic netlist■ Flow 2 (layout-based)—flat parasitic back-annotation onto the layout ideal

netlist

Using the standard post-layout flow enables you to■ Control the simulation command—hierarchically■ Control the amount of needed back-annotation to meet accuracy

requirements■ Remove the risk of errors introduced by manual intervention■ Speed-up the verification process and increase the design cycle throughput

Choosing Either the Schematic-based or Layout-based Flow

To decide which flow is best suited for your needs, review the following requirements:

Flow 1 (schematic-based)A graphic representation of Flow 1 is displayed in Figure 24. If your requirements can be chosen from this list, you should choose this flow: ■ Prefer using schematic environment over a layout environment■ Capable of reusing a pre-layout analysis statement■ Require a simple plug-in setup to run a post-layout flow from a pre-layout

environment

SPEF Standard Parasitic Exchange Format generated by Star-RC XT

DPF Device Parameter Format generated by Star-RC XT

Table 71 Post-layout terms

Term Definition



Figure 24 Flow 1: Schematic back-annotation flow

Flow 2 (layout-based)A graphic representation of Flow 2 is displayed in Figure 25. If your requirements can be chosen from this list, you should choose this flow: ■ Require a detailed parasitic description and layout device parameter■ Want to generate superior real-design representation■ Want a guarantee of zero back-annotation errors



Figure 25 Flow 2: Layout back-annotation flow

See Table 72 for a summary of the main differences between Flows 1 and 2:

Table 72 Differences between Flow 1 and Flow 2

Flow 1- Schematic-based Flow 2 - Layout-based

Schematic device properties are chosen when merging is complex.

Pre-layout analysis (post-processing statement such as .meas, .print, or .probe) may not be re-used.


Chapter 10: Post-Layout and Back-Annotation SimulationSetting up the Post-layout Flow

Setting up the Post-layout Flow

The basic procedure for setting-up the NanoSim post-layout flow is

1. Use a hierarchical netlist

(Choose either the schematic netlist or the layout ideal netlist)

2. Obtain the parasitics in the form of either an SPF or SPEF file

3. Perform back-annotation

Setting Up Hercules

To obtain the appropriate Hercules runset file for the LVS run, you must include (and ensure) the following:■ Layout data (GDSII)■ Schematic netlist■ Equivalence file

(optional)—Hercules automatically creates the equivalence point, but usually requires some changes if it is a custom design. You should first use Hercules to generate the equivalence point, then modify the default equivalence point to match up the schematic and the layout.

■ Make sure the compare section is properly set for the LVS run.

Layout nets are considered “ideal” when the net is ■ part of the merge series/path■ connected to filtered devices■ connected to an unequal number of

schematic/layout pairs■ unmatched

Proprietary models/netlist might have compatibility issues.

Additional equivalence checking is required for the layout ideal netlist—for accuracy.

Table 72 Differences between Flow 1 and Flow 2 (Continued)

Flow 1- Schematic-based Flow 2 - Layout-based


Chapter 10: Post-Layout and Back-Annotation SimulationSetting up the Post-layout Flow

The WRITE_EXTRACT_VIEW section must be inserted in the Hercules runset to create a transistor view for Star-RC XT as the input database. (Please refer to the Hercules User Manual to create the EXTRACT_VIEW.)

Setting Up Star-RC XT

To obtain the appropriate Star-RC XT command file for extraction, you must include (and ensure) the following commands and files:■ XREF: COMPLETE/YES

(Depends if you want the post-layout flow to be schematic-based or layout-based)

■ SKIP_CELLS: !* (Required to perform transistor-level extraction)

■ NETLIST_IDEAL_SPICE_FILE: filename

■ NETLIST_IDEAL_SPICE_HIER: YES

(These two commands are used together to create the Star-RC XT Layout Ideal Netlist.) If you want to use the hierarchical “ideal” netlist created by Star-RC XT, both commands are required. If you want to use the schematic base flow for post-layout simulation, only the NETLIST_IDEAL_SPICE_FILE command is required.

■ NETLIST_FORMAT: SPF/SPEF

■ The Hercules EXTRACT_VIEW command must be used as the input layout database. Cross-reference information must be established first.

■ All Star-RC XT standalone files must first be obtained, which include the ■ MAPPING_FILE■ TCAD_GRD_FILE, BLOCK, and MILKYWAY_DATABASE files.


Chapter 10: Post-Layout and Back-Annotation SimulationBack-annotating the Layout Device Properties

See Example 48 for a sample Star-RC XT command file sample.

Example 48 Sample Star-RC XT command file*INPUT FILEBlock: BLOCK nameMILKYWAY_DATABASE: XTR_VIEWMILKYWAY_EXTRACT_VIEW: YESSTAR_DIRECTORY: STARTCAD_GRD_FILE: tsmc.nxtgrdMAPPING_FILE: tsmc.map

* Extraction CommandEXTRACTION: RCSKIP_CELLS: !*IGNORE_CAPACITANCE: ALLCOUPLE_TO_GROUND: NONETS: *XREF: COMPLETE* Netlisting CommandNETLIST_FORMAT: SPEFNETLIST_FILE: design.spefNETLIST_IDEAL_SPICE_FILE: ideal_layout.spNETLIST_IDEAL_SPICE_HIER: YES

Back-annotating the Layout Device Properties

To generate the layout device parameter, you should back-annotate the DPF file (device parameter) to NanoSim along with the parasitics for the schematic-based post-layout simulation. If you use the layout ideal netlist generated by Star-RC XT, it already contains all device properties information; therefore, DPF back-annotation is not required.


Chapter 10: Post-Layout and Back-Annotation SimulationGenerating Device Properties for Schematic-based Back-annotation

Generating Device Properties for Schematic-based Back-annotation

To generate device properties for schematic-based back-annotation, choose from one of these two methods:

1. Run the post-layout flow using the SPF file (which contains the devices and the device properties in the * Instance section).

Use the NanoSim set_ckt_ctrl BA_READ_DPF_SECTION command to back-annotate the device parameter information from the * Instance section. By default, the schematic device properties are chosen.

2. Run the post-layout flow using the SPEF file (which does not contain the devices and the device properties) along with the DPF file.

Use the Star RC XT NETLIST_IDEAL_SPICE_FILE:DPF_FILE command to generate the DPF file. Use the –ndpf NanoSim command-line option to back-annotate the layout device properties.

Required NanoSim Setup

If you use the schematic netlist, you must include the following items:■ Schematic netlist■ SPF/SPEF files■ DPF file■ Model file and Stimulus, and others that are required for a stand-alone

NanoSim simulation

If you use the Star-RC XT Layout Ideal Netlist, you must include the following items:■ Layout Ideal Netlist■ SPF/SPEF files■ Model file, Stimulus, and others that are required for a stand-alone NanoSim

simulation


Chapter 10: Post-Layout and Back-Annotation SimulationGenerating Device Properties for Schematic-based Back-annotation

Invoking the Post-layout Flow with NanoSim

There are three methods (using either a command-line, netlist option, or configuration command) to invoke the post-layout flow with NanoSim, as shown in Table 73.

Back-annotating the Device Parameter File (required only in the schematic-based flow)

To back-annotate the DPF, choose from one of the three methods (using either a command-line, configuration command, or netlist option) in Table 74.

Table 73 Methods for invoking the post-layout flow

Method Command-line / Netlist option / Config. cmd syntax

1 ■ -ncspf filename.spf ■ -nspef filename.spef

2 ■ .option cspf_file = “filename.spf “■ .option spef_file = “filename.spef“

3 ■ set_ckt_ctrl cspf_file: “filename.spf“■ set_ckt_ctrl spef_file: “filename.spef”

Table 74 Ways for back-annotating the DPF

Method Command-line / Config cmd / Netlist option syntax

1 –ndpf dpf_file

2 set_ckt_ctrl ba_read_dpf_section (if using SPF file)

3 .option ba_read_dpf_section (if using SPF file)


Chapter 10: Post-Layout and Back-Annotation SimulationDefault Settings for NanoSim Post-layout Simulation

Using Hierarchical Back-annotation

To invoke the hierarchical back-annotation flow, use one of the two methods (using either a command-line or configuration command) shown in Table 75.

DPF back-annotation is only supported for “flat” back-annotation.

Although Method #2 (configuration commands) is used throughout this chapter, you also have the option to use netlist options to describe the configuration command. You do this by removing the set_ckt_ctrl syntax and replacing it with the .option syntax. You must also change the colon (:) symbol to an equal sign ( = ).


set_ckt_ctrl cspf_file: filename.spf >.option cspf_file=filename.spf

Reporting Back-annotation Warnings

Pay close attention to the warning messages. From these messages, you can find a work-around or identify the issues. See the NanoSim Post-layout Flow Warning Messages section for more details.

Default Settings for NanoSim Post-layout Simulation

The following are NanoSim default setting descriptions for post-layout simulations:

Table 75 Two methods for using hierarchical back-annotation

Method Command-line / Config Cmd Syntax

1 ■ –nhspf subcircuit_file.spf ■ –nhspef subcircuit_file.spef

2 ■ set_ckt_ctrl cspf_file_with_cell_scope: ”scope subcircuit_file.spf”

■ set_ckt_ctrl spef_file_with_cell_scope: “scope subcircuit_file.spef”


Chapter 10: Post-Layout and Back-Annotation SimulationDefault Settings for NanoSim Post-layout Simulation

Skipping Parasitics for Powernets and Back-annotation Nets Connected to Stimulus

NanoSim skips reading-in parasitic nets in powernets and back-annotation (BA) nets connected to stimulus, by default. Simulation with powernets can slow your simulation. To simulate the powernet effect with parasitics, use the following configuration command:

set_ckt_ctrl ba_power_nets:”1”

(default value= “0”)

Splitting the Coupling Capacitors in the SPF/SPEF File to Ground Capacitors

To improve performance, NanoSim splits all coupling capacitors in the parasitic file to ground capacitors. Keeping all coupling capacitors in the parasitic file can create a large partition and slow the simulation. To simulate with a coupling effect, use the following configuration command:

set_ckt_ctrl split_fcap:”1 none”

(default value = “1 ba”)

Log File Changes

The .log file contains the detailed back-annotation statistics of your simulation. The sub-categories number should add up to the number of BA (back-annotation) nets in all files. This helps you to identify issues with back-annotation.

For a sample of a .log file, see Example 49.

Example 49 Log file sample# of ba nets in all files :867# of ba nets skipped :28# of ba nets with errors - discarded (see above) :1# of ba nets without errors :838


Chapter 10: Post-Layout and Back-Annotation SimulationNanoSim Selective Net Back-annotation Flow

NanoSim Selective Net Back-annotation Flow

The Selective Net Back-annotation Flow requires back-annotation of the flat parasitics onto the schematic netlist or the layout ideal netlist. Additionally, using this flow, NanoSim automatically detects active nets that are important to the design for back-annotation. The detection is based on the voltage threshold of the circuit activity. This flow can be very efficient in designs containing a large number of parasitics with high latency.

Using the Selective Net Back-annotation Flow enables you to■ Control the simulation command hierarchically■ Simulate designs efficiently that contain a large number of parasitics with

high latency■ Remove the risk of error introduced by manual intervention■ Speed-up the verification process and increase the throughput of the design

cycle

For a graphic representation of the Selective Net Back-annotation Flow, see Figure 26.


Chapter 10: Post-Layout and Back-Annotation SimulationNanoSim Selective Net Back-annotation Flow

Figure 26 Selective Net Back-annotation Flow

Setting up the Selective Net Back-annotation Flow

To set up the flow for NanoSim to run the Selective Net Back-annotation flow, see the Setting up the Post-layout Flow procedure. To run a Selective Net Back-annotation Flow, NanoSim additionally requires the set_ba_mode command.

For details on how to set up Hercules and Star-RC XT, see the previous Setting Up Hercules and Setting Up Star-RC XT sections.

For details on how to set up NanoSim, see the previous Required NanoSim Setup section. In addition to this setup, the set_ba_mode configuration command is required.


Chapter 10: Post-Layout and Back-Annotation SimulationInvoking the Selective Net Back-annotation Flow

Invoking the Selective Net Back-annotation Flow

NanoSim contains a post-layout command that can be used for both the Selective Extraction Flow and the Selective Net Back-annotation Flow. See the following set_ba_mode flow syntax and description of the arguments:

set_ba_mode flow=selective_ba | selective_extract [file=file_prefix] [max_iter=num] [rcxt_hierid=hier_id] [idle_net_ba=c|rc|none]

set_ba_mode flow command argument description


flow=selective_ba| selective_extract

Chooses either to run selective extraction or selective back-annotation flow.

An argument is required.

file=file_prefix Defines the output active file name. If file is not specified, it uses the NanoSim output prefix name.

max_iter=value Defines how many iterations are needed to obtain the active net information.

Default: max_iter=2

rcxt_hierid=hierid Defines the hierarchical divider that is set in the active net file. (You should not use this command when using the Selective Back-annotation Flow—this command is only used for the Selective Extraction Flow.)

Default: rcxt_hierid= .

idle_net_ba=<C| RC | NONE>

Defines NanoSim’s interaction with the idle nets that are coupled to the active nets.

Default: idle_net_ba=c


Chapter 10: Post-Layout and Back-Annotation SimulationInvoking the Selective Net Back-annotation Flow

Default Settings for the NanoSim Selective Net Back-annotation Flow

To set the default settings for the Selective Net Back-annotation Flow,

1. Skip the powernet and BA net back-annotation connected to the stimulus.

2. Split the coupling capacitors in SPF/SPEF file-to-ground capacitors.

The change is displayed in the log file.

When running the Selective Net Back-annotation Flow, there is an additional line that appears in the log file that indicates the flow is used, as shown in Example 50.

Example 50 Header banner file sampleSelective back-annotation flow running...

There is circuit activity information at the end of the log file. This gives you an indication if using the Selective Back-annotation is beneficial. Typically, Selective Net Back-annotation is useful when circuit activity is less than 20%. If the circuit shows a great deal of activity, you should run a standard post-layout flow. The reason you should choose the standard flow is because running the selective back-annotation flow requires overhead in run time. This is due to NanoSim performing a setup run on the ideal netlist to obtain the active net.

See Example 51 for a file sample.

Example 51 Activeness measurement file sampleProcessing measurements ....Measurement results are saved in nanosim.meas

Total: 196.0 real 188.8 user 6.1 sys

No errors reported in the .err file (nanosim_file_hierid.err)

... Selective back-annotation flow complete ... maximum iteration reached

# of pre-layout active nodes from previous run : 489# of pre-layout active nodes at end of this run : 498 (27%)# of idle nodes back-annotated due to fcap-coupling to active nodes: 154


Chapter 10: Post-Layout and Back-Annotation SimulationNanoSim Selective Net Extraction Flow

An additional advantage of using the Selective Net Back-Annotation flow is that you can simply point to the file and skip the first setup run—if you have already created the active net file. It helps to decrease the simulation run time.

See Example 52 for a file sample.

Example 52 Active net discover file sampleSelective back-annotation flow running...

Found active net file 'active.rcxt', skipping pre-layout run...Reading active nodes from 'active.rcxt'...

NanoSim Selective Net Extraction Flow

The Selective Net Extraction Flow is used to alleviate the capacity limitations imposed on the tools. In this flow, NanoSim■ identifies the “active nets”■ feeds the active nets back into Star-RC XT■ reads the “active parasitics file” output from Star-RC XT and simulates

(You should use this flow if the parasitic file size causes issues)

Using this flow, you can ■ create a smaller parasitics file that is easy to simulate■ control the simulation command hierarchically■ remove the risk of error introduced by manual intervention

Setting up the Selective Net Extraction Flow

Use the set_ba_mode command to generate the active nets file. This command feeds the active nets to Star-RC XT to produce a parasitics file that only contains active nets. Use NanoSim to simulate the active nets parasitics.

Generating Active Nets—First NanoSim Run

The set_ba_mode command is used either with the Selective Extraction Flow or the Selective Net Back-annotation flow. You are required to choose one of the two flows. For a description of the set_ba_mode flow command syntax



and command arguments, see the Invoking the Selective Net Back-annotation Flow section.

Generating the Active Net File Format

The format of the active net in the active_list.rcxt file is as follows:


NETS: hierarchical_name

See Example 53:

Example 53 Nets exampleNETS: XI1/NET23NETS: IN

Be aware of Star-RC XT case-sensitivity issues. Use the CASE_SENSITIVE: NO command to turn off case-sensitivity. NanoSim and Star-RC XT must have identical and concurrent case-sensitivity.

Setting Up Hercules

To set up Hercules, see the previous Setting up the Selective Net Back-annotation Flow section.

Setting Up Star-RC XT

To set up Star-RC XT, obtain the appropriate Star-RC XT command file for extraction and include (and ensure) the following commands and files:■ NET_TYPE: SCHEMATIC

■ CASE_SENSITIVE: NO

■ NETS_FILE: active_list.rcxt (NanoSim creates this active file)■ XREF: COMPLETE/YES

■ SKIP_CELLS: !* (Required to perform transistor-level extraction)■ NETLIST_IDEAL_SPICE_FILE: filename

■ NETLIST_IDEAL_SPICE_HIER: YES



(These two commands are used together to create the layout ideal netlist from Star-RC XT.) If you want to use the hierarchical ideal netlist created by Star-RC XT, both commands are required. If you want to use the schematic base flow for post-layout simulation, only the NETLIST_IDEAL_SPICE_FILE command is required.

■ NETLIST_FORMAT: SPF/SPEF

■ Use the EXTRACT_VIEW command created by Hercules as the input layout database. It is required because cross-referencing must be established.

■ All Star-RC XT standalone required files must first be obtained. This includes the MAPPING_FILE, TCAD_GRD_FILE, and BLOCK, MILKYWAY_DATABASE files.

Required NanoSim Setup

If you are setting up NanoSim, you must include the following items:■ Schematic netlist■ SPF/SPEF files■ DPF file■ Model file and Stimulus, and others that are required for a stand-alone

NanoSim simulation

Invoking the Post-layout Flow

There are two methods you can use (using either a command-line or configuration command) to invoke the post-layout flow, as shown in Table 76.

Table 76 Two methods for invoking the post-layout flow

Method Command-line/Config Cmd Syntax

1 ■ -ncspf filename.spf ■ -nspef filename.spef

2 ■ set_ckt_ctrl cspf_file:spf_file■ set_ckt_ctrl spef_file:spef_file


Chapter 10: Post-Layout and Back-Annotation SimulationProcessing Capacitors in NanoSim

Back-annotating the Device Parameter File

There are two methods to choose from (using either a command-line or configuration command) to back-annotate the DPF, as shown in Table 77.

Processing Capacitors in NanoSim

NanoSim contains many processing commands. A complete list of the NanoSim capacitor-related commands is shown in Table 78.

Table 77 Two methods for back-annotating the DPF

Method Command-line/Config Cmd Syntax

1 -ndpf dpf_file

2 set_ckt_ctrl ba_read_dpf_section

Table 78 Capacitor-processing command descriptions

Command Netlist Option or Config Cmd

Sche-matic fcap

BA fcap

Sche-matic gnd, supply cap

BA gnd, supply cap

Default

ba_err_as_lumpc Netlist No No No Yes 0

ba_process_fcap=

”all | none”(previously called cspf_process_fcap)

Netlist No Yes No No all

ba_select_gndcap=

[ba_cap_use_sum | ba_cap_use_net]

Netlist No No No Yes ba_

cap_

use_

sum

keep_gnd_cap =

"none | vsrc_cap | all"

Netlist No No Yes No None


Chapter 10: Post-Layout and Back-Annotation SimulationProcessing Capacitors in NanoSim

For a detailed description of the netlist control options, see the Circuit Simulation and Analysis Tools Reference Guide.

min_gndcap_value (previously min_cap_value)

Netlist No No Yes Yes 0

min_fcap_value Netlist Yes Yes No No -1

scale_cap Netlist Yes Yes Yes Yes 1

split_fcap=

’<split ratio> all |

ba | none’

Netlist Yes Yes No No 1.0 all

set_ba_mode flow=

selective_ba selective_extract

Config No Yes No Yes N/A

set_fcap_model Config Yes Yes No Yes N/A

set_fcap_param Config Yes Yes No Yes N/A

set_relfcap_param Config Yes Yes No Yes N/A

set_analogfcap_param Config Yes Yes No Yes N/A

set_analogrelfcap_

param

Config Yes Yes No Yes N/A

set_powr_acc keep_cap=0 | 1 | 2

Config Yes Yes No Yes 0

Table 78 Capacitor-processing command descriptions (Continued)

Command Netlist Option or Config Cmd

Sche-matic fcap

BA fcap

Sche-matic gnd, supply cap

BA gnd, supply cap

Default


Chapter 10: Post-Layout and Back-Annotation SimulationIntegrating the Post-layout Flow with Other NanoSim Features

Integrating the Post-layout Flow with Other NanoSim Features

The majority of NanoSim features are integrated with the post-layout flow. The two most prominent features for the post-layout flow are ■ Linear Network Solver (LNS)■ HAR

Integrating the Post-layout Flow with LNS RC Reduction

Post-layout simulation introduces many new elements (resistors and capacitors). The presence of these elements can slow the simulation. It is important to try to maintain a reasonable simulation speed. LNS is an algorithm that reduces the RC network. LNS reduces the network to a smaller network that matches the frequency behavior of the original network over a given frequency range with good accuracy.

To enable LNS, enter this command:

set_ckt_lns [freq=cutoff frequency] [except_no=nodes that must not be reduced] [except_el=elements that must not be reduced]

The cutoff frequency is automatically detected by LNS. The default cutoff frequency is equal to 0.1/(simulator time resolution). Any cutoff frequency specified in the set_ckt_lns command overrides the default value.

In the Selective Net Back-annotation Flow, under certain circumstances, an active node may not be annotated. For example, when LNS is used together with the Selective Net Back-Annotation Flow (using command set_ba_mode flow=selective_ba), LNS reduces the RC network from the active transistor netlist. This net is not back-annotated.

Note:

This is a very rare occurrence and should not generate a loss of accuracy.

Integrating the Post-layout Flow with Powernet Simulation

Generally, you should not keep RC back-annotation on the powernets. Powernets with resistors and capacitors slow the simulation because partitioning is affected. NanoSim’s partitioning is based on ideal supplies. The supply nets are boundaries of the partitions. If the supply nets are no longer


Chapter 10: Post-Layout and Back-Annotation SimulationOptimizing Accuracy and Speed for Post-layout Simulation

ideal DC supplies, they are no longer partitioned boundaries; therefore, larger partitions are created.

If the parasitic file comprises the powernet back-annotation, parasitics in powernet back-annotation is ignored. Use the following configuration command to simulate the powernet effect:

set_ckt_ctrl ba_power_nets:“1”

You may be interested in simulating powernet back-annotation to see the effect of IR drop on circuit behavior and timing. In that case, all powernet back-annotation information must be maintained. You should, however, use reduction methods to speed up the simulation. Please refer to the set_powernet_default command man page.

Integrating the Post-layout Flow with HAR

Hierarchical Array Reduction (HAR) can be used in the post-layout flow. The prerequisite for HAR is hierarchical netlists—this prerequisite must also be respected in the post-layout flow.

HAR can be used with a SPICE netlist—including the parasitic resistors and capacitors—but it can also be used in the post-layout flow using an ideal transistor netlist and SPF/SPEF back-annotation files. In the case of the Selective Back-Annotation Flow, the list of active nets is generated during the HAP setup phase.

Note:

You should use a tcl.tk script if name mismatches are detected between the schematic netlist and the parasitic file.

Optimizing Accuracy and Speed for Post-layout Simulation

A post-layout simulation may be slower than a pre-layout simulation. The slow-down is due to the presence of many parasitic elements (resistors and capacitors).



Why are resistors and capacitors slowing the simulation?■ If you look at the element list in the nanosim.log file, you can see that the

number of resistors is equal to the number of active elements (MOS). Post-layout simulation is running twice the number of elements compared to pre-layout netlists.

■ Coupling capacitors are connecting nets together, forcing elements to go in the same stage. This creates bigger stages than in pre-layout simulation.

■ Resistors in the power supply create large stages.■ Commands are available in NanoSim to help you find the best tradeoff

between accuracy and speed.

Generating Accurate Results for Post-layout Simulation

The best accuracy is obtained when reduction is not implemented on the post-layout data (parasitic resistors and capacitors). However, you must keep in mind that maintaining all parasitic elements has a dramatic effect on tool performance.

You should do the following:■ Keep all coupling capacitors from the DSPF/SPEF files.

By default all DSPF/SPEF coupling capacitors are read-in and split to ground. To avoid splitting them to ground, use the set_ckt_ctrl split_fcap:“1 none” configuration command.

■ Keep all coupling capacitors in the schematic netlist.

By default, NanoSim screens all coupling capacitors, and some are split to ground or simulated with the SMS algorithm. It is possible to keep all the capacitors “floating” using the “set_fcap_model * 2” configuration command.

The asterisk ( * ) wild card means that all capacitors from both the transistor netlist and the DSPF/SPEF file are floating.

■ Keep all resistors.



By default, all resistors smaller than 0.1 ohm (or 0.01 ohm if LNS is used) are shorted. This threshold can be changed to a smaller value, or to 0 ohm, using the set_ckt_ctrl min_res_value:“min_value” control option.

■ Improve the accuracy of powernet reduction.

The power nets are reduced using the set_powernet_default mode=1 command, by default. All resistors in the powernets with a value smaller than 5 ohms are shorted. To get a more accurate reduction, you should use the set_powernet_default mode=5 configuration command. You can also use the set_powernet_default mode=0 command to prevent NanoSim from reducing, but it is not recommended due to a much slower simulation time.

Improving Speed for Post-layout Simulation

To speed-up the simulation, you must reduce all post-layout data. The more reduction—the faster the simulation. However, reducing the data too much can lead to inaccuracies, so reduction must be used with caution. You should do the following:■ Use LNS.

The LNS algorithm finds an equivalent reduced RC network that generates a result similar to the original RC network. The configuration command is set_ckt_lns.

■ Remove small resistors.

It is possible to remove resistors smaller than a minimum value. To improve the accuracy, decrease the minimum value. To improve the speed, it is possible to increase this minimum value.

■ Remove small capacitors.


Chapter 10: Post-Layout and Back-Annotation SimulationNanoSim Post-layout Flow Warning Messages

As for resistors, the small capacitors can be removed from the netlist for the simulation. Both floating capacitors and ground capacitors smaller than a minimum value can be removed:set_ckt_ctrl min_gndcap_value:“min_gndcap_value”set_ckt_ctrl min_fcap_value:“min_fcap_value”

■ Ignore DSPF/SPEF floating capacitors.

All floating capacitors from the DSPF/SPEF netlists can be ignored using the set_ckt_ctrl ba_process_fcap:“none” configuration command.

NanoSim Post-layout Flow Warning Messages

See the following SPF/SPEF warning messages in Example 54 to Example 60:

The parasitics in powernets and BA nets connected to stimuli are skipped in Example 54.

Example 54 Parasitics connected to stimuliWARNING:NanoSim:0x202080ed:SPEF vdd net was skipped because it is either a powernet or connected to stimuli.

Use the set_ckt_ctrl ba_power_nets:”1” command to back-annotate those parasitics in powernets or BA nets connected to stimuli.

The parasitic coupling capacitors are split-to-ground capacitors in Example 55.

Example 55 Parasitic coupling capacitors split to groundWARNING:NanoSim:0x2020803f.All parasitic coupling capacitors from CSPF/DSPF/RSPF/SPEF format netlists are split to ground caps. Refer to netlist control option SPLIT_FCAP for details.

Use the set_ckt_ctrl split_fcap:”1 none” command to keep the parasitic coupling capacitors.

The BA net name cannot be located in the main circuit database in Example 56.

Example 56 The BA net name cannot be locatedWARNING:NanoSim:0x20208071:spf net ‘net_name’ is discarded because that net could not be found in the netlist.


Chapter 10: Post-Layout and Back-Annotation SimulationNanoSim Post-layout Flow Warning Messages

When you encounter this message in the log file, check if the BA net actually exists in the main circuit netlist. If you cannot find the name in the main circuit netlist, the warning message is valid.

If you can find the net name in the main circuit netlist, check the following:

1. Does the BA net name and the main circuit hierarchy match up correctly?

Sometimes you may create a pseudo top, so the main circuit netlist always has one extra hierarchy than the parasitic file. If this is the case, remove the pseudo top to make sure the hierarchy matches properly.

2. Check to see if the *|DIVIDER setting is correct in the parasitics file.

The divider defines the hierarchy in the parasitics file.

During back-annotation, the simulator detects that the node name in the schematic netlist matches the BA net in Example 57. However, the BA net has a broken connection.

Example 57 The simulator finds the node name during BAWARNING:NanoSim:0x2020807e:SPF connectivity error on node ‘sum0’Spf net ‘sum0” is discarded because it contains 2 disconnected components:- component # 0 contains the following pins: x6/x33/m2/src- component # 1 contains the following pints: x7/x33/m1/src

If this message appears in the NanoSim log file, most likely it is a real error. You can use the NanoSim set_ckt_ctrl BA_ERR_AS_LUMPC configuration command. Using this command adds lump net capacitance to that node.

When you specify the ba_disable_net netlist control command, the net name that was generated cannot be found in the parasitics file; therefore, it cannot be disabled. See Example 58.

Example 58 ba_disable_net messageWARNING:NanoSim:0x2020806e:ba_disable_net name net_name did not match any back-annotation nets

Make sure if you want to disable certain items, such as VDD or GND, that the name appears in the parasitics file. Sometimes, the name might be interpreted differently, such as VCC, VSS. Go into the parasitics file and identify the net that you want to disable, and copy and paste the net that you want to disable into the ba_disable_net command.


Chapter 10: Post-Layout and Back-Annotation SimulationDPF Warning Messages:

When back-annotating a BA net, the BA net must have an instance pin to cover all paths to the devices that are connected in the schematic netlist. If any path to the devices is not covered by an instance pin, the message describes the connectivity recovery. See Example 59.

Example 59 The BA net name must have an instance pinWARNING:0x2020807:SPF connectivity error on node ‘VDD’spf net ‘VDD’ has the following missing instance pins:-x3.m1:g (connecting back to x1:i)-x3.m0:g (connecting back to x2:i)

The message in Example 60 is caused by the mismatch between the schematic netlist and the parasitics file. Check on terminal names to match NS recognizable terminal name.

Example 60 Instance pin cannot be located in the schematic netlistWARNING:NanoSim:0x20208073:SPF connectivity error on node’pdb[55]’Spf net ‘pdb[55] is discarded because:-xmem:xsme_gio:xsem_rip1:dpd1:cathode does not exist in the netlist

DPF Warning Messages:

See the following DPF warning messages in Example 61 and Example 62:

Example 61 Instance name is not in the DPF fileWARNING:NanoSim:0x2020806F:no matching rule for element name is foundWARNING:NanoSim:0x202080a2:unsupported back-annotation element type x0/x33/M1

The instance name in the DPF file does not exist in the schematic netlist.

Identify the instance path of the MOS device. Use a TCL script to modify the input DPF content to match the instance name.

Unsupported element types. Only the MOS devices are supported in the DPF file, as shown in Example 62.

Example 62 DPF file warningWARNING:NanoSim:0x20208051:File “dpf_file”, line 16, column 0, format SPICE BACK-ANNOTATION: device back-annotate failed


Chapter 10: Post-Layout and Back-Annotation SimulationSPEF Triplet Values

SPEF Triplet Values

SPEF files can have a triplet of capacitance and resistance values: minimum, typical, and maximum values. NanoSim can only back-annotate one value. By default, the typical value is chosen, but you can change the default value with the set_ckt_ctrl command.


set_ckt_ctrl spef_par_value:”min | typ | max” (default = “typ”)

Error Back-annotation

By default, if a net is discarded when a net exists in the database, it cannot be back-annotated due to connectivity errors. It is now possible to back-annotate the lumped net capacitance on this net using the following command:

set_ckt_ctrl ba_err_as_lumpc

Star-RC XT commands

To develop a post-layout flow, you must obtain a set of proper extraction commands. Table 79 displays the recommended commands to be set in the Star-RC XT command file:

Table 79 Star-RC XT commands for the post-layout flow

Star RC-XT Command Standard Post-layout Flow

Selective Net Extraction Flow

Selective Net Back-annotation Flow

CASE_SENSITIVE NO NO NO

COUPLE_TO_GROUND

NO (if you want coupling effect)



COMPARE_DIRECTORY

YES YES YES

EVACCESS_DIRECTORY

YES YES YES


Chapter 10: Post-Layout and Back-Annotation SimulationStar-RC XT commands

See the Star-RC XT Reference Manual for a description of these commands.

MILKYWAY_EXTRACT_VIEW

YES YES YES

XREF COMPLETE/YES COMPLETE/YES

COMPLETE/YES

NETLIST_FILE Optional Optional Optional

NETLIST_FORMAT: SPF/SPEF

YES YES YES

NETLIST_NAME_MAP

YES YES YES

NETLIST_IDEAL_SPICE_FILE

YES YES YES

NETLIST_IDEAL_SPICE_HIER

Mandatory if using the layout netlist



NETS_FILE NO YES NO

NET_TYPE NO YES NO

POWER_EXTRACT NO NO NO

SKIP_CELL: !* Mandatory if using the layout netlist



Table 79 Star-RC XT commands for the post-layout flow (Continued)

Star RC-XT Command Standard Post-layout Flow

Selective Net Extraction Flow

Selective Net Back-annotation Flow



For an example of a Star-RC XT command file for post-layout simulation, see Example 63.

Example 63 Star_RC XT control file sample************************************* Star-RC XT Control File for Database ************************************* Header Options* BLOCK:top design name* MILKYWAY_DATABASE: name of <library_name> in LVS runset* NETS: <list of nets> List of nets to be extracted* POWER_EXTRACT: <YES|NO>. Whether to extract power nets

BLOCK: sram_12x2048_block* Name of the block to be extractedMILKYWAY_DATABASE: SRAM * The name of the databaseMILKYWAY_EXTRACT_VIEW:YESPOWER_NETS: VSS GND VDD VCC* Define what is the name of the power netsNETS: *POWER_EXTRACT: NO

* Text Name OptionHIERARCHICAL_SEPARATOR:/ * Define the hierarchy separatorCASE_SENSITIVE: NO * Important for selective extraction flow

* Process Technology FilesTCAD_GRID_FILE: /home/design/sram.nxtgrdMAPPING_FILE: /home/design/sram.mapping

* Extraction OptionsEXTRACTION: RCANALYSIS: TimingCOUPLE_TO_GROUND: NOIGNORE_CAPACITANCE: ALL

* NETLIST FormatNETLIST_FORMAT: SPEF * This command decide the parasitic formatREDUCTION: YESNETLIST_MAX_LINE: 80NETLIST_NODE_SECTION:YES * Need this command if using SPF fileNETLIST_SUBCKT: NONETLIST_FILE: sram.spef * This control the filename of the parasitic file

* Command for Cross-Referenced Extraction



*

XREF: COMPLETECOMPARE_DIRECTORY: ./compare * Contain the cross-referencing informationEVACCESS_DIRECTORY: ./evaccess * Contain the cross-referencing informationNET_TYPE: Schematic * Important for selective extraction flowNETLIST_IDEAL_SPICE_FILE:layout.sp * This control the filename of the layout netlistNETLIST_IDEAL_SPICE_HIER:YES * This control the hierarchy of the layout netlist

* If using the schematic netlist, set this to NO

* If using the layout netlist, set this to YES


1111Simulating Power Networks

This chapter describes how you can efficiently simulate your power network using the set_powernet_default command with the mode=5 argument.

Overview

There are two types of power network (power net) simulations:■ Static Extracted Power Net Simulations■ Internal Supplies or Ramping Supplies Circuit Simulations

This chapter describes these two types of powernet simulations, and also contains the following topics:■ Simulating Power Nets Efficiently■ Improving Power Net Simulations with the mode=5 Argument■ The Recommended mode=5 Usage Model■ Back-annotation Flow Using the mode=5 Argument

Static Extracted Power Net Simulations

When running post-layout simulations, you might want to simulate the effect of parasitic resistors and capacitors on the power nets. For example, if there are not enough pads in the circuit, or if the vias or contacts are too small, there will be many (or extremely large) resistors in the power nets. Also, the voltage at the device ports will be smaller than the DC supply voltage. This smaller-than-expected voltage can change the timing (or the behavior) of the circuit.

For these reasons, you should extract the power nets and simulate the circuit using RC back-annotation on the power nets.


Chapter 11: Simulating Power NetworksInternal Supplies or Ramping Supplies Circuit Simulations

Internal Supplies or Ramping Supplies Circuit Simulations

In certain designs, internal voltages are generated in the circuit (such as charge pumps), or the main power supply is ramped to its final value to mimic the circuit switch-on phase.

By default, NanoSim behaves as if these internal power supplies, or ramped power supplies, are normal signal nets.

Simulating Power Nets Efficiently

By default, NanoSim can generate less-than-superior results when simulating extracted power nets or internal supply nets. The two main reasons are:

1. Small resistors in the extracted power nets slow the simulation.

2. Partitioning of extracted power nets and internal supplies is prohibitive and greatly impacts the performance.

Note:

NanoSim is fast, compared to SPICE, because of partitioning. HSPICE (and other SPICE products) create a single partition (stage). NanoSim partitions the circuit into multiple stages that consist of channel-connected elements. NanoSim cuts stages at DC supplies.

Partitioning Circuits

See Figure 27 for an example of partitioning with a non-extracted power net:


Chapter 11: Simulating Power NetworksSimulating Power Nets Efficiently

Figure 27 Non-extracted power net

Three partitions are created—each partition contains two MOS models.

See Figure 28 for an example of partitioning with an extracted power net:

Figure 28 Extracted power net

One partition is created—the single partition contains MOS, resistors, and coupling capacitors.

vdd DC

vdd DC


Chapter 11: Simulating Power NetworksImproving Power Net Simulations with the mode=5 Argument

Improving Power Net Simulations with the mode=5 Argument

NanoSim enables you to improve your power net simulations, because the set_powernet_default mode=5 command

1. Identifies the power nets (including internal and ramping supplies)

2. Reduces the power net RLC elements

3. Uses the cut algorithm with a special time step control

Identifying the Power Net

The mode=5 argument has been implemented in NanoSim to identify the power nets. All internal or ramped supply nets are recognized as power nets. The auto-detection algorithm identifies internal or ramping supplies as nodes or resistive networks, which have a large number of connections to sources, drains, or bulks of MOS transistors.

Reducing the Power Net

The mode=5 RLC reduction technique is optimized for power nets. To reduce the power net, NanoSim

1. Performs parallel-serial reduction of all RLC elements.

2. Lumps small resistors.

Resistor lumping transforms an RC line with many resistors and capacitors to an equivalent line with fewer elements. This step is controlled by the r_lump value.

3. Shorts all resistors with a value less than r.

4. Shorts all inductors with a value less than l (default is 0.5nH).



The result of the reduction is reported in the .log file, as shown in Example 64:

Example 64 RLC-reduction reporting in the .log filePerforming Powernet search... Powernet lumping threshold : 16.837477 Ohm Powernet shorting threshold : 1.237333 Ohm Powernet inductance threshold : 0.500000 nH

Number of resistors : 4963 --> 2326 Number of floating capacitors : 2906 --> 796 Number of inductors : 12 --> 9 Number of RLC elements : 7881 --> 3131 (60.3% reduced) Number of nodes : 204537 --> 202092 (1.2% reduced)Powernet search took 230.150 s

Cutting Algorithm

Once the power network has been identified and reduced, it will be cut at its perimeter nodes. In order to maintain a good performance/accuracy trade-off, a special time step algorithm has been implemented.

Command SyntaxFor the set_powernet_default mode=5 command syntax and argument descriptions, see the following:

set_powernet_default mode=5 [level=0|1|2|3|4|5|6|7]

[acc_dc=0|1] [r=resistance] [l=inductance] [r_lump=resistance] [esv=voltage] [spd=voltage] [do_lns=0|1] [power_no=node_name] [no=node_name] [el=elem_name] [subckt=subckt_name] [version=1|2] [model=model_name] [except_no=node_name] [except_el=elem_name] [except_subckt=subckt_name] [except_model=model_name] [except_cut_no=node_name] [except_power_no=node_name]


level=[0|1|2|3|4|5|6|7] Specifies an accuracy/performance trade-off. Default value is 3. RLC reduction becomes less robust, i.e., more accurate, with the level increasing from 0 to 7.



level=0 Deletes almost all resistors in the powernet.

level=1|2|3 Uses a vppcut method for cut, and changes esv at the cut nodes (level=1 esv is greater than level=3 esv).

level=4 Uses a more accurate mem_cut method for cut.

level=5 Does not use cut—only RLC reduction.

level=6 Does not use cut—only RLC reduction—and is more conservative than level=5.

level=7 Does not use cut—only RLC reduction—and is more conservative than level=6. This level is the most accurate no-cut no-reduction level, i.e., set_powernet_default mode=0

acc_dc=0|1 The default value is 1. By default, a true DC initialization is applied on the cut nodes of the power supply network. This ensures correct DC values are set at time 0. However, in some cases, this DC initialization can be slow. Setting the acc_dc argument to 0 speeds up the DC initialization, but there is a risk of incorrect DC values at time=0.

r=resistance The resistor-shorting threshold. All resistors below resistance are shorted in the power net. Default value of resistance is automatically determined by the program and is printed in the .log file.




r_lump=resistance The resistor-lumping threshold. Small adjacent resistors in the power net are lumped until the resistance threshold is reached. Default value of resistance is automatically determined by the program and is printed in the .log file.

l=inductance The inductor-shorting threshold. All inductors below inductance are shorted in the power net. Default value of inductance is 0.5 nH.

esv=voltage Specifies esv for the cut nodes generated by the mode=5 cutting algorithm.

The default esv value for vpp cut nodes is 0.02V, and the default esv value for memcut nodes is 0.1V.

spd=voltage Specifies spd for the cut nodes generated by the mode=5 cutting algorithm. The default spd value is the same as for normal nodes, i.e., it is determined by the type of the node.

Reminder of the general rules:

- For digital nodes the default spd is 0.1*Vsupply, if Vsupply<=3V; otherwise, it is 0.5V.

- For analog nodes the default spd is 0.05*Vsupply, if Vsupply<=2V; otherwise, it is 0.1V.

do_lns=[0|1] 0 - Does not apply LNS reduction in power nets (default with version=1)

1 - Applies LNS reduction to power nets in addition to the mode=5 reduction (default with version=2)




power_no=node_name Enables manual specification of resistive networks that must be treated as power nets, but are not recognized by the code. You must specify one node_name (wild cards permitted), and an entire resistive network containing this node is reduced and cut using power net rules. Multiple power_no= arguments can be used. To get information about large resistive networks (power net and others) and associated node names, use the report_powernet_info command.

no=node_name Enables RLC reduction of the specified node (wild cards permitted).

el=elem_name Enables RLC reduction of the specified element (wild cards permitted).

subckt=subckt_name Enables RLC reduction of the specified subcircuit.

version=1|2 1 - Turns on powernet RC-reduction from releases previous to Y-2006.06 (default).

2 - Powernet RC-reduction implemented in Y-2006.06 (and later) releases.

model=model_name Reduces elements described by model= model_name.

except_no=node_name Prevents RLC-reduction of the specified node (wild cards permitted).

except_el=elem_name Prevents RLC-reduction of the specified element (wild cards permitted).

except_subckt=subckt_name Prevents RLC reduction of the specified subcircuit.

except_model=model_name Prevents RLC-reduction of the specified RLC elements.




For a sample configuration file using the mode=5 argument, see Example 65.

Example 65 mode=5 command exampleset_powernet_default mode=5report_powernet_info

For a graphic that displays the accuracy trade-off (version=2), see Figure 29:

Figure 29 Accuracy trade-off (version=2) with various level settings

In Figure 30, the supply value is set to 1.2V; the default level setting is selected (level=3, 10% accuracy). You should expect an accuracy level of 10%, which results in an IR drop absolute error of 120mV (1.2 * 10% = 120mV)—Figure 30

except_cut_no=node_name Prevents placing a cut on the specified node (wild cards permitted).

except_power_no=node_name The entire resistive network containing node_name will not be treated as a powernet (wild cards permitted). Neither RLC-reduction, nor cut, will be applied to this resistive network. This is a reverse of the power_no= option.



Chapter 11: Simulating Power NetworksThe Recommended mode=5 Usage Model

is a graphical representation of how the Mode 5 feature reacts to these settings.

Figure 30 Voltage drop detection

The Recommended mode=5 Usage Model

Use the set_powernet_default mode=5 command when ■ you want to simulate IR drops or extracted power supplies■ the power supplies are ramping or switched■ there are internal supplies in the circuit, such as a

• circuit with charge pumps

• circuit with internal regulators

• circuit comprising any net acting as a power supply in the netlist and not connected to a DC source

For most circuits, the default values of reduction (r=, r_lump, l=) and simulation (esv=, spd=) parameters are sufficient for achieving fast simulation with reasonalbe accuracy. If you are not satisfied with the speed or accuracy, you can use the level= argument to shift the balance.

For performance and accuracy fine-tuning, you can use individual argument values that override the default level settings. For example, if you use the


Chapter 11: Simulating Power NetworksThe Recommended mode=5 Usage Model

set_powernet_default level=1 esv=0.1m command, the esv value set by level=1 is overridden by the specified esv=0.1m value.

Using the mode=5 Argument with LNS

The default operation of set_powernet_default mode=5 does not run LNS reduction on the reduced power net: ■ LNS reduction is forced, besides the mode=5 reduction, if you use the

following configuration command:

set_powernet_default mode=5 do_lns=1

■ LNS reduction is forced, by default, if you use the following configuration command:

set_powernet_default mode=5 version=2

■ LNS is applied on the power nets and the signal nets, if you use the following configuration commands:

set_powernet_default mode=5 do_lns=1set_ckt_lns

■ LNS is applied only on the signal nets, if you use following configuration commands:

set_powernet_default mode=5 set_ckt_lns

■ LNS is globally applied and the default reduction (mode=1) is applied to power nets, if you use the following configuration command:

set_ckt_lns

Note:

The set_ckt_lns command arguments level=, no=, el=, except_no=, except_el=, subckt=, except_subckt=, model=, and except_model= generate the same effect as corresponding arguments in the set_powernet_default mode=5 command. If your configuration file


Chapter 11: Simulating Power NetworksBack-annotation Flow Using the mode=5 Argument

contains both of these commands, the previously described arguments should be attached to only one of these two commands. These arguments automatically apply to the other command.

Back-annotation Flow Using the mode=5 Argument

The default NanoSim SPF/SPEF back-annotation flow does not back-annotate power nets. However, if the mode=5 argument is used, the default changes, and all power nets are back-annotated.

When you use the set_powernet_default mode=5 command, you do not need to use the set_ckt_ctrl ba_power_nets:1 command.

For example, if the run is set without using the set_powernet_default mode=5 command, you will see the warning message that is displayed in Example 66:

Example 66 Mode 5 argument not usedWARNING:NanoSim:0x202080ed: SPF VDD net was skipped because it is either a powernet or connected to stimuli.

If you add the set_powernet_default mode=5 command to the configuration file, the warning disappears and VDD is back-annotated.

Note:

It is not possible to back-annotate power nets with the selective back-annotation flow.


1212Extracting Timing Information with the BDC Option

This chapter describes the Block Delay Calculator (BDC) option that extracts timing information which is needed to characterize a library block. Using NanoSim with the BDC option enables large digital blocks to be easily characterized in less time than that required by a SPICE simulation.

Overview

To be able to use any of the BDC configuration commands, you need a NanoSim BDC feature license.

When you use a BDC command in a NanoSim configuration file, all transistors in the block are simulated using the piece-wise linear (PWL) model, by default, with the internal step size (set_sim_spd) set to 0.1. If the supply voltage is less than or equal to 3 volts, and you do not use the set_sim_spd command to set the global spd, the spd value is set as the lesser value of (vsupply * 0.1) and 0.1. This ensures that NanoSim is simulating in its very accurate mode. The delay measurements are typically very close to SPICE.

If you do not include a BDC command in a NanoSim configuration file, the internal step size (set by set_sim_spd) is 0.5 if the supply is greater than (>) 3V. Refer to the NanoSim Command Reference for more information on set_sim_spd.

The BDC feature also enables you to characterize block (or small circuit) timing. Timing characterization measures the ■ delay from a source node (for example, input) to a target node (for example,

output)■ setup and hold times


Chapter 12: Extracting Timing Information with the BDC OptionCharacterizing Circuits with BDC

■ transition time (or slope)■ minimum pulse width

Timing characterization is applied to several input slopes and output loads.

The BDC commands generate timing models. These models contain timing characterization information. There are three different types of models: Each of the three models contains the same information, but the format differs.

BDC generates the following models:■ liberty format (.lib)■ black box model (.ascii)

The liberty format should be used in combination with a Synthesis tool (Design Compiler) or a Static Timing Analysis tool (PrimeTime). The black box format is focused primarily for a PathMill analysis.

This chapter contains the following topics:■ Characterizing Circuits with BDC■ Listing of the BDC Commands■ Measuring Delays with the meas_n2n_delay Command■ Measuring Node Capacitance■ Determining the Setup Measurement■ Determining the Hold Measurement■ Measuring the Minimum Pulse Width■ Using the Batch Run Program■ Running a Sample BDC Procedure■ Viewing BDC Output: Error and Measurement Reports

Characterizing Circuits with BDC

The general rules for characterizing circuits are as follows: ■ NanoSim/BDC is recommended for digital circuits, memory cross-sections,

or small memories■ NanoSim/BDC is not recommended for complex analog circuitry, large

memories, and large mixed-signal circuits.


Chapter 12: Extracting Timing Information with the BDC OptionCharacterizing Circuits with BDC

For delay measurements, NanoSim traces the causality path from the output node to the input node. For large circuits, this can take a long while. For analog circuits, this may not be possible.

For setup and hold measurements, the causality path is not traced. Three signals are required: (1) an input signal, (2) a reference signal, and (3) a target (output) signal whose value changes with the reference signal active edge.

Any type of circuit can be characterized for setup and hold times, as long as these three signals can be defined with digital states; the simulator can use a bisection algorithm to determine if the target node should pass or fail.

Running a Pre-characterization Run

Before running NanoSim, you should run a regular run; specifically, a run without any BDC commands. A run without any BDC commands is referred to as a pre-characterization run.

In this pre-characterization run, the set_sim_spd command must be set to match the value that is used by BDC. If set_sim_spd is not specified in the configuration file, NanoSim BDC forces spd to 0.1 if the power supply voltage is larger than 3.0V, or to vsupply*0.1, if vsupply <= 3.0.

You should also implement a pre-characterization run with the largest slope and load values that are used for BDC characterization. This simulation is important for verifying that the signals are valid when large slopes and loads are applied.

Note:

You do not need to change your netlist and stimuli to apply a new slope and a new load:

- To apply a new slope on an input signal, use the set_vec_opt configuration command:

set_vec_opt slope=1ns no=D[0]

- To apply a new load on an output signal, use the add_node_cap configuration command:


Chapter 12: Extracting Timing Information with the BDC OptionListing of the BDC Commands

add_node_cap Q 500f

Listing of the BDC Commands

For a listing of the current BDC commands, see Table 80:

Viewing BDC Command Man Pages

You can view the man page for each of the BDC commands by typing man plus one of the BDC commands from Table 80 at the command line (where NanoSim is installed). The following is an example:

Table 80 The BDC Commands

add_model_port set_meas_designname

define_n2n_cause set_meas_instname

build_model_bdc set_meas_load

meas_n2n_delay set_meas_partialswing

meas_n2n_hold set_meas_pulsew

meas_n2n_setup set_meas_slope

meas_node_cap set_meas_thresh

meas_pulse_width set_meas_watch

print_meas_cmt set_meas_window

print_meas_path

print_node_path


Chapter 12: Extracting Timing Information with the BDC OptionMeasuring Delays with the meas_n2n_delay Command

man meas_node_cap

Measuring Delays with the meas_n2n_delay Command

The key feature of BDC is its ability to measure delays using the meas_n2n_delay configuration command. You can measure the delay from any input node (source_node_name) in the circuit to any other node (sink_node_name). Typically, the measurement will be from an input pin to either an internal latch node, or an output pin.

Delays are measured from the time the input transition reaches (Vhigh + Vlow)/2 until the output transition reaches (Vhigh + Vlow)/2. BDC records both minimum and maximum delays. You can also measure delays from a group of nodes to a specified end node. Measurements are recorded for the source node to the sink node for the minimum and maximum delay.

The simulation time for each delay measurement is recorded as the time each end node made a transition. You can also record the logic state of specific control nodes at the time of each measurement.

When measuring delays, BDC will measure a delay only from specified source nodes to specified sink nodes if the transition on the sink node is caused by a transition on the source node. You can use the set_meas_pulsew configuration command to set the simulator to ignore very short pulses or glitches on sink nodes when measuring the delays.

You are responsible for providing the input vectors to the blocks that cause the best and worst case delays.

The NanoSim BDC command does not support Hi-Z measurements—only measurements that fall between high/low logic levels are supported.

Defining Parts of the Causality Path

Sometimes, in complex digital circuitry, NanoSim cannot trace the whole causality path between the source and sink nodes. This might happen, for example, when tracing the path between the input and output of a sense amplifier in memory circuits, because the voltage swings are very limited. In this case, you can use the define_n2n_cause command to specify parts of the causality path.


Chapter 12: Extracting Timing Information with the BDC OptionMeasuring Node Capacitance

Measuring Node Capacitance

You can measure the total capacitance on any node using the meas_node_cap configuration command. Typically, you would request total capacitance on input pins. Total capacitance includes any interconnect, gate, and diffusion capacitance for the node. The capacitance is measured in femtofarads.

Measuring Node Transition Times

BDC automatically measures transition times for all nodes specified with the meas_n2n_delay command, but only prints them when you specify the print_meas_cmt command. The transition time is measured between low_threshold and high_threshold (specified with the set_meas_thresh command), which defaults to 0.3 Vdd and 0.7 Vdd.

Determining the Setup Measurement

The syntax of the meas_n2n_setup measurement command is:

meas_n2n_setup data=data signal ti_data=data edge of interest ref=reference signal ti_ref=ref time tar=target signal ti_tar_chk=target check time st_tar=target signal value accuracy=measurement accuracy start=schmooing window start time end=schmooing window stop time

To determine the setup time, the data edge is schmooed (moved) until a failure occurs. The failure occurs when the target value (st_tar) is incorrect (different from the expected target signal value) at time ti_tar_chk.


Chapter 12: Extracting Timing Information with the BDC OptionDetermining the Setup Measurement

The schmooing window is from time=ti_data+start to time=ti_data+end. See Figure 31.■ An initial measurement is implemented for data toggling at

ti_data+start—failure should not occur. ■ An additional measurement is implemented for data toggling at

ti_data+end—failure should occur.■ The following measurement is implemented for data toggling at ti=half

window time, that is ((ti_data+end)+(ti_data+start))/2,

If it fails, ti signifies more than setup time. The ti is now the lower boundary of the new schmoo window. The next measurement is implemented for data toggling at (ti +( ti_data+start))/2.

If it does not fail, ti signifies less than setup time. The ti is now the upper boundary of the new schmoo window. The next measurement is implemented for data toggling at ((ti_data+end)+ti)/2.

The measurements continue until the measurement does not fail, and is less than or equal to the requested accuracy:■ ti_data+start must then be less than ti_ref to ensure the data edge

occurs before the clock active edge.■ ti_data+end must then be more than ti_ref to make sure the setup

time is not respected at time=ti_data+end; a failure must occur at that time.


Chapter 12: Extracting Timing Information with the BDC OptionDetermining the Hold Measurement

Figure 31 Setup time measurement

The meas_n2n_setup command can also be used with a reduced number of arguments. Instead of using 10 arguments, you can specify 4 arguments: meas_n2n_setup data=data_node ti_data=data_time ref=ref_node tar=tar_node

The previously specified 10 arguments are still supported and recommended when NanoSim is not able to locate setup time using the four EoU (ease-of-use) arguments.

Determining the Hold Measurement

The syntax of the meas_n2n_hold measurement command is:

meas_n2n_hold data=data signal ti_data=data edge of interest ref=reference signal ti_ref=ref time tar=target signal ti_tar_chk=target check time st_tar=target signal value accuracy=measurement accuracy start=schmooing window start time end=schmooing window stop time

ref (active on rising edge)

st_tar=1data Data edge is “schmooed”

“schmoo” window (from “ti_data+start” to “ti_data+end”)

ti_ref

ti_data

tar

ti_tar_chk (can be any time where it is sure the target signal has reached the st tar value)



Chapter 12: Extracting Timing Information with the BDC OptionDetermining the Hold Measurement

To determine the hold time, the data edge is schmooed until a failure occurs. The failure occurs when the target value (st_tar) is incorrect (different from the expected target signal value) at time ti_tar_chk.

The schmooing window is from time=ti_data+start to time=ti_data+end. Schmooing is identically implemented as it was for setup measurement, as shown in Figure 32:■ ti_data+start must be less than ti_ref to ensure the hold time is not

respected at time=ti_data+start—failure must occur at that time■ ti_data+end must be more than ti_ref to ensure hold time is respected

Figure 32 Hold time measurement

The meas_n2n_hold command can also be used with a reduced number of arguments. Instead of using 10 arguments, you can specify 4 arguments: meas_n2n_hold data=data_node ref=ref_node ti_ref=ref_time tar=tar_node

tar

st_tar=1

ti_tar_chk can be any time where it is sure the target signal has reached the st_tar value.

ref (active on rising edge)

data Data edge is “schmooed”

ti_ref

ti_data



Chapter 12: Extracting Timing Information with the BDC OptionMeasuring the Minimum Pulse Width

The previously specified 10 arguments are still supported and recommended when NanoSim is not able to locate hold time using the four EoU (ease-of-use) arguments.

Measuring the Minimum Pulse Width

The meas_pulse_width command measures the minimum pulse width of a signal by moving one edge of the pulse. For every new pulse width, NanoSim checks the target signal value. If the target value equals the expected value, the test passes and the edge is moved again to narrow the pulse width. When the test fails (target signal differs from the expected value) the edge moves again to widen the pulse width. The binary search continues until the determined accuracy falls within the specified accuracy. The minimum pulse width is determined by the latest pulse value—specifically, when the output signal accepts the expected value.

The meas_pulse_width command should be used on clock signals or signals with identical frequency pulses. The output signal is required to accept the correct expected value with the original stimuli, and must also achieve an incorrect value for an extremely small (unacceptable) pulse width.

The Liberty format accepts two values for the minimum pulse width: high value and low value. If you want to measure the minimum pulse width for high and low pulses, you must specify two commands in the config file: one command for high value and one command for low value.

Like most BDC commands, the meas_pulse_width command cannot be used alone. It must be used together with the usual BDC commands:■ add_model_port

■ build_model_bdc

A new option has been added to the build_model_bdc command to report the minimum pulse width:

build_model_bdc pulsew=data_node



Command Description

The meas_pulse_width command measures the minimum pulse width for an input signal to maintain the expected state of target node at the specified time. See the following syntax, arguments, and examples:

meas_pulse_width node_state=high|low data=data_node ti_data=data_time tar=target_signal_name ti_tar_chk=target_time tar=tar_nodest_tar=target_state [accuracy=dt]

The minimum pulse width is measured for signal CLK, as shown in Example 67. Only the high pulse is measured. The CLK high pulse width is measured for a


node_state=high|low Specifies if the pulse to be measured is high or low.

data=data_node Specifies the node name for which the minimum pulse width is measured.

ti_data= data_time Specifies the data_node edge time.

tar=target_signal_name Specifies the target signal’s name.

ti_tar_chk=target_time Specifies the time the tar_node must be checked.

tar=tar_node Specifies the output signal name to be checked.

st_tar=target_state Specifies the expected state of the tar_node. The target_state value can be 0 or 1.

accuracy=dt Specifies the required accuracy.



rising edge at 30ns. In addition, there is a condition that Q[0] must be at state 1 at time 42ns for the CLK minimum pulse width.

See Example 68, Example 69, and Example 70 for different file types.

Example 67 Minimum pulse widthmeas_pulse_width node_state=high data=CLK ti_data=30n tar=Q[0] ti_tar_chk=42n st_tar=1add_model_port no=CLK no_dir=in attrib=source add_model_port no=Q[0] no_dir=out attrib=sink build_model_bdc pulsew=CLK name=ff

The meas_pulse_width node_state=high command generates the following lines:

Example 68 .lib filepin (clk) {direction: input ;min_pulse_width_high : <value> ;…}

Example 69 .mod fileCLK_CLK_pwh : WIDTH (POSEDGE) CLK;

Example 70 .data fileARCDATACLK_CLK_pwh :RISE_CONSTRAINT( scalar ){ VALUES ( "<value>");}ENDARCDATA



Configuration and Model File Samples

To run NanoSim/BDC, see Example 71, a configuration file sample:

Example 71 NanoSim/BDC file sampleset_meas_designname FLIPFLOPprint_meas_pathset_meas_thresh 0.2 0.8

set_meas_slope 0.1000ns 0.150ns 0.200nsset_meas_load mode=delay 0.0084pF 0.0196pf 0.05pf 0.1pf

meas_n2n_setup data=d0 ti_data=14ns ref=clkin tar=q

meas_n2n_hold data=d0 ref=clkin ti_ref=60ns tar=qmeas_n2n_delay clkin rise q -

add_model_port no=clkin no_dir=in attrib=source,clkadd_model_port no=d0 no_dir=in attrib=sourceadd_model_port no=q no_dir=out attrib=sink

build_model_bdc setup=d0,clkin delay=clkin,q name=dff1 cap_unit=pf

Using the configuration commands in Example 71, NanoSim generates the following model files:■ a ■ dff1.lib■ Liberty model, comprising new capacitive units and thresholds as shown in

Example 72:

Example 72 dff1.lib Liberty model filecapacitive_load_unit (1.000000, pf);slew_lower_threshold_pct_rise : 20.00 ;slew_lower_threshold_pct_fall : 20.00 ;slew_upper_threshold_pct_rise : 80.00 ;slew_upper_threshold_pct_fall : 80.00 ;

■ a delay from clkin rising to q, as shown in Example 73:


Chapter 12: Extracting Timing Information with the BDC OptionUsing the Batch Run Program

Example 73 delay samplepin(q) { direction : output ; capacitance : 0.099012 ; timing () { related_pin : "clkin" ; timing_type : rising_edge ; cell_rise( f_itrans_ocap ){ ... }}

■ setup and hold times, as shown in Example 74:

Example 74 setup and hold time samplepin(d0) { direction : input ; capacitance : 0.006451 ; timing () { related_pin : "clkin" ; timing_type : setup_rising ... } timing () { related_pin : "clkin" ; timing_type : hold_rising ; ... }}

■ a blackbox model, comprised of the ■ dff1.ascii file

Using the Batch Run Program

A script program called batchrun is included with the NanoSim simulator. It is designed to run the NanoSim BDC option using different parameters to characterize a block. The following parameters can be specified: vector rise/fall times, loading capacitances, temperatures, voltages, and technology process. You can use any combination of parameters in the specified batchfile.

See Chapter 15, “Using the batchrun Program,” for more information.


Chapter 12: Extracting Timing Information with the BDC OptionRunning a Sample BDC Procedure

A program called sdfcombine can be used to generate a single SDF file that includes minimum, typical, and maximum delays corresponding to different temperatures, voltages, and processes.

sdfcombine

See the following syntax for sdfcombine, as well as the command argument descriptions:

sdfcombine sdf_min sdf_typ sdf_max [sdf_combine]

Running a Sample BDC Procedure

This sample procedure shows you how to run NanoSim BDC with three technology files:

1. Run the batchrun program:

batchrun nanosim batchfile

Result: The contents of the batchfile called from the RUN -n net1 -p $TECH -c config -t 600 -o $OUTFILE command are as follows: DATA TECH OUTFILE

tech.best.0_5.5v out1tech.typ 25_5v out2

tech.worst.85_4.5 out3

END

sdfcombine command argument description


sdf_min The SDF file corresponding to minimum delays.

sdf_typ The SDF file corresponding to typical delays.

sdf_max The SDF file corresponding to maximum delays.

sdf_combine The SDF file which contains the combination of delays. The default is nanosim.sdf.


Chapter 12: Extracting Timing Information with the BDC OptionViewing BDC Output: Error and Measurement Reports

2. Run the sdfcombine program:

sdfcombine out1 out2 out3 output

Result: The resulting output.sdf file contains the combination of minimum, typical, and maximum delays.

Viewing BDC Output: Error and Measurement Reports

The NanoSim BDC output format is in Standard Delay Format (SDF), which can be used for back-annotating delay to the Verilog simulation.

Reporting Errors

There are two types of errors reported by BDC. The first occurs if there are no transitions on the nodes being measured.The second occurs when the transitions on the end nodes are not caused by any of the input nodes. Both of these types of errors are recorded in the

.err

file. You can view the errors with the viewerror utility:

viewerror -i nanosim.err

Example 75 shows what you would see when you run this sample command.

Example 75 viewerror utility file sample#1 BDC Error: no delay path from E(rising) to out1(changing)#2 BDC Error: no transition on node M

Reporting Measurements

BDC results are reported in an output file with the default name of nanosim.sdf. If you use the -o or -f command-line options, you can specify your own prefix name for this file.

The SDF construct IOPATH is used to specify the pin-to-pin delays. Comments (preceded by //) are used for information that SDF does not support directly, such as the times for the delay measurements.



Example 76 is a sample

nanosim.sdf

output file. This sample file does not include any comment lines because it was produced without using the print_meas_cmt command in the configuration file. Using this command will cause BDC comments to be printed to the

.sdf

file.

Example 76 Sample nanosim.sdf file(DELAYFILE (DESIGN “alu4.amd”) (DATE “Tue Apr 22 12:49:59 1997 “) (VENDOR “Synopsys, Inc.”) (PROGRAM “PTG ENGINE”) (VERSION “ 5.0s “) (DIVIDER .) (VOLTAGE 5.0:5.0:5.0) (PROCESS “typical”) (TEMPERATURE 25.0:25.0:25.0) (TIMESCALE 1ns) (CELL (CELLTYPE “alu4.amd”) (INSTANCE *) (DELAY (ABSOLUTE (IOPATH (posedge B) out1 (0:0:0) (1.770:1.770:1.770)) (IOPATH (posedge C) out2 (0:0:0) (1.210:1.210:1.210)) (IOPATH (posedge D) out2 (1.030:1.030:1.030) (0:0:0)) (IOPATH n1 n2 (0.290:0.290:0.290) (0.310:0.310:0.310)) (IOPATH A out3 (1.210:1.210:1.210) (1.310:1.310:1.310)) (IOPATH B out3 (1.890:1.890:1.890) (2.650:2.650:2.650)) (IOPATH (posedge A) out3 (0:0:0) (1.310:1.310:1.310)) (IOPATH (negedge A) out3 (1.210:1.210:1.210) (0:0:0))

Table 81 describes the SDF and comment constructs used in the output report. Some of the constructs described in this table are not used in the sample file.

Table 81 SDF and Comment Constructs Descriptions

Sample Lines Description

(DELAYFILE) Start of SDF file indicator.



(DESIGN “alu4.amd”) The design name, set by the measure_block_name command. Default is nanosim.

(DATE “Tue Apr 22 12:49:59 1997 “)

The date and time the file was created.

(VENDOR “Synopsys, Inc.”)

(PROGRAM “PTG ENGINE”)

(VERSION “ 5.0s “)

Vendor, program, and version information.

(DIVIDER .) The character used as a separator in hierarchical names. NanoSim uses a period (.).

(VOLTAGE 5.0:5.0:5.0) The supply voltage specified in the technology file.

(PROCESS “typical”) The process. The default is typical.

(TEMPERATURE 25.0:25.0:25.0)

The temperature specified in the technology file.

(TIMESCALE 1ns) The time scale in which the delays are reported.

//(TECHNOLOGY “/test/default/test/tech/pwtech.new”)

The NanoSim technology file used for the measurements.

(CELL

(CELLTYPE “alu4.amd”)

(INSTANCE *)

(DELAY (ABSOLUTE

Indicates the start of the delay information specific for this block (or cell). The CELLTYPE name is the name set with the set_meas_designname command. The delays are given as absolute (that is, not relative) delays.

Table 81 SDF and Comment Constructs Descriptions (Continued)




//(NODE_CAP A 163.291) This comment stores the input pin capacitance for a node requested through the meas_node_cap and print_meas_cmt BDC configuration commands. The value is in femtofarads.

//(TRANS B (0.600:0.600:0.600) (0.000:0.000:0.000))

This is the rising and falling transition time of node B requested by the meas_n2n_delay and print_meas_cmt commands. If the node is an output node, the transition time is measured at the time AT_TIME is stored.

(IOPATH (posedge B) out1 (0:0:0)(1.770:1.770:1.770))

This is the pin-to-pin delay from B rising to out1. The posedge field indicates that B is rising; negedge would indicate B was falling.

The two triples following out1 are for the rising and falling delays. The first number in each triple is the minimum delay, the middle number is the nominal delay, and the third number is the maximum delay. The delays measured by NanoSim use only the minimum and maximum numbers.

//(AT_TIME out2 (::) (381.960:381.960:381.960))

This is used to store the time the measurements of the min/max rise and fall delays took place at the output node. The first pair of values (::) are for the time at which the min and max rising transitions at out2 were calculated. In the above example no measurements for out1 rising were recorded. The second pair of values (381.960:381.960:381.960) shows the time the minimum and maximum falling delay was measured. In this case, the minimum and maximum delays were both measured at simulation time 381.960 ns.





Example 77 contains the configuration commands used to produce the sample

.sdf file in Example 76.

Example 77 BDC commands specified in a configuration fileset_meas_designname alu4.amdset_meas_window 50nmeas_node_cap A B C D out1 out2meas_n2n_delay A C D rise out1 -meas_n2n_delay B E rise out1 -meas_n2n_delay M - N -meas_n2n_delay A - N -set_meas_watch A Cmeas_n2n_delay A B C D E rise out2 -set_meas_watch A B E Cmeas_n2n_delay n1 - n2 -set_meas_watch A Bset_meas_watch E Cmeas_n2n_delay A B F - out3 -meas_n2n_delay A rise out3 fallmeas_n2n_delay A fall out3 risemeas_n2n_delay A - out3 -

//(WATCH_STATES out2 A 0:0:0) (1:0:0) B (::) (0:0:0)))

This stores the logic states of the nodes being watched during the previous measurements. The first pair of values after A show the logic state of A when the rising delays on out2 were measured (that is, A was at a logic 0 when both the minimum and maximum delay for out2 was measured).

Node B was undefined for both these measurements. Node A was at logic 1 when the minimum falling delay was measured, while node B was at logic 0. Also, nodes A and B were at logic 0 when the maximum falling delay was measured.




1313Understanding NanoSim’s Output Files

This chapter describes the output files that are generated from two general sources: netlist compilation and actual simulation. Included in this chapter is information on the different means of viewing output files.

Overview

This chapter contains the following topics:■ Understanding Output File Contents■ Displaying Simulation Results Logically■ Displaying Simulation Results Graphically

Understanding Output File Contents

Files generated at the end of a NanoSim simulation typically include a simulation output file, an error report file, an interactive log file (if requested using open_intr_log), a simulation log file, and files generated by configuration commands. As a general rule, you should always review the contents of the following files: nanosim.err, nanosim.sum, nanosim.int, and nanosim .log.

Use the -o command-line option to control the output prefix name (the default is nanosim).

nanosim.3to5

This file is produced by the set_v3cmd_opt command. This file contains a conversion table between 3.x release commands and their 5.x release equivalents.


Chapter 13: Understanding NanoSim’s Output FilesUnderstanding Output File Contents

nanosim.cap

Example 78 lists capacitance information for nodes specified using the print_node_cap or iprint_node_cap commands:

Example 78 Capacitance info for nodes sample---------------------------------------------------Node 0:Diff cap CBS or CBD 8.5611fFConnect mn1 CGDO (Overlap cap.) 0.727316fFNetlist Capacitance : 0.00fFGate Capacitance : 0.00fFOverlap Capacitance : 0.73fFDiffusion Capacitance : 8.56fFWire (Interconnect) Capacitance: 0.00fF---------------------------------------------------Total Capacitance : 9.29fF---------------------------------------------------Node vdd:Connect mp1 CBD (Diffusion cap.) 3.09604fFConnect mp1 CGDO (Overlap cap.) 0.216915fFNetlist Capacitance : 0.00fFGate Capacitance : 0.00fFOverlap Capacitance : 0.22fFDiffusion Capacitance : 3.10fFWire (Interconnect) Capacitance: 0.00fF---------------------------------------------------Total capacitance : 3.31fF-------------------------------------------------Node in:Fanout mp1 Overlap cap. 0.43383fF Gate cap. 1.71101fFFanout mn1 Overlap cap. 1.45463fF Gate cap. 1.09106fFNetlist Capacitance : 0.00fFGate Capacitance : 2.80fFOverlap Capacitance : 1.89fFDiffusion Capacitance : 0.00fFWire (Interconnect) Capacitance: 0.00fF------------------------------------------------------Total Capacitance : 4.69fF------------------------------------------------------Node test:Connect mn1 CBS (Diffusion cap.) 2.36902fFConnect mn1 CGDO (Overlap cap.) 0.727316fFConnect mp1 CBS (Diffusion cap.) 3.09604fF



Connect mp1 CGDO (Overlap cap.) 0.216915fFNetlist Capacitance : 0.00fFGate Capacitance : 0.00fFOverlap Capacitance : 0.94fFDiffusion Capacitance : 5.47fFWire (Interconnect) Capacitance: 0.00fF------------------------------------------------------Total Capacitance : 6.41fF

nanosim.cnt

This file lists the state toggling numbers of nodes specified using the report_node_toggle configuration command.

The node toggling information listed in this file has the following syntax:

node_name (node_index): toggle_count

The toggle_count is the total toggle number for the node within the specified counting window. At the end of the individual counting window, the total number of toggles that occurred during the counting window for all specified nodes is reported.

The counting windows are reported in ascending order of the window ending times. If the ending times are the same, the starting times are used to determine the reporting order.

See Appendix B, “Detailed Configuration Command Information,” for a sample nanosim .cnt file.

The output in Example 79 was generated using the following three commands (for a small test circuit):

Example 79 report_node_toggle output filereport_node_toggle start=3n end=199n start=199ns

end=255ns a ctlreport_node_toggle start=256ns end=333ns start=333ns areport_node_toggle start=8.5ns end=199ns start=199ns out

nanosim.cut.cfg

This is a configuration file generated by the set_node_atcut command. This file contains set_node_vppcut and set_node_memcut commands. These commands normally produce the same partitioning as that produced by set_node_atcut.



nanosim.dc

This file lists the nodes that became unsettled during DC initialization. They are scheduled to be re-evaluated during transient analysis.

nanosim.dcpath

This file lists the output of the report_ckt_dcpath configuration command. Example 80 shows some examples of the entries.

Example 80 report_ckt_dcpath output sampleNonzero dc path(s) found at time 200 nsPath # 1---------------------------------------------------------------------- resistor IOBUFF0.R1 current = -0.02 uA from XGND voltage = 0.00 V to DATAOUT0 voltage = 0.00 V resistor IOBUFF0.R2 current = 79.98 uA from IOBUFF0.VR voltage = 4.00 V to DATAOUT0 voltage = 0.00 V--------------------------------------------------------------------------------------------------------------------------------------------Path # 2 resistor IOBUFF0.R1 current = -99.97 uA from XGND voltage = 0.00 V to DATAOUT0 voltage = 5.00 V inductor IOBUFF0.OUTBOND current = -119.93 uA from DATAOUT0 voltage = 5.00 V to IOBUFF0.OUT1 voltage = 5.00 V transistor IOBUFF0.P1 (type PMOS) current = -119.91 uA gate IOBUFF0.INGATE voltage = 0.00 V drain IOBUFF0.OUT1 voltage = 5.00 V source IOBUFF0.DP1 voltage = 5.00 V transistor IOBUFF0.P2 (type PMOS) current = -119.93 uA gate IOBUFF0.PGATE voltage = 0.00 V drain IOBUFF0.DP1 voltage = 5.00 V source EVDD voltage = 5.00 V inductor IOBUFF0.L1 current = -119.93 uA from EVDD voltage = 5.00 V to VDD voltage = 5.00 V--------------------------------------------------------------------------------------------------------------------------------------------



Notice that each path entry is preceded by a line specifying the time at which the DC paths were found: Nonzero dc path(s) found at time 200 ns

This is followed by a numbered list of paths for that time. In Example 80, there were two paths at 200 ns. This line can be followed by additional entries for later times.

Each path entry reports a conducting path from one voltage source through a list of elements to a second voltage source. For example, Path 2, in Example 80, starts at the voltage source XGND and goes through the elements IOBUFF0.R1, IOBUFF0.OUTBOND, IOBUFF0.P1, IOBUFF0.P2, and VDDBOND. It terminates at the voltage source Vdd. The connected nodes for each element are listed so that the path can be traced through the intermediate nodes.

The right column in the report shows the DC current through the device and voltage of each of the connected nodes.

nanosim.dcu

This file reports all dangling nodes that are set to 0 V by the simulator before DC initialization. These nodes are identified because they are dangling nodes and not initialized by any configuration commands or input stimuli. See the following nanosim.dng section for information on dangling nodes.

nanosim.dng

This file identifies all dangling nodes in a simulation run. By default, a node is considered dangling when it fits the following criteria:■ Not connected to an input stimulus

(including voltage/current source)■ Not channel-connected to any circuit element■ Not connected to an output/biput of any functional models

You can apply an optional algorithm for identifying dangling nodes using the report_node_dangle command.



nanosim.err

This output file contains warning and errors from the timing or power simulation, if any. This file begins with a file banner containing the name of the program (NanoSim) and the time at which the file was generated.

Following the banner, the .err file lists errors as fields in a single line of ASCII code. These fields correspond to the following information, in the following order:

1. Error type code

2. Error description code

3. Related node names

4. Element names and some simulation information

You can use the viewerror utility to process this file and produce more readable reports. For information about using the viewerror utility, see the Circuit Simulation and Analysis Tools Reference Guide.

nanosim.fcap

This file contains information about floating capacitances. The simulator will discard small floating capacitances and convert some of them into SMS capacitors (see the descriptions of the set_fcap_param and set_relfcap_param configuration commands). This file contains a list of capacitors (or MOS capacitors) that have been kept as real floating capacitors.

nanosim.fsdb

This file is generated if the FSDB output format is chosen for printing simulation output. Use nWave or CosmosScope to view the simulation output from this file.

nanosim.hist

This file contains current information used for the creation of graphical histograms (see Example 81). This file is generated by the report_ckt_phist, report_node_i, report_probe_i, and report_branch_i configuration commands.



Example 81 Sample nanosim.hist fileNode: gnd

Start (ns) Stop (ns) Avg (uA) RMS (uA) Peak (uA) Time (ns) 0.0000e+00 1.0000e+02 1.0154e+03 3.2430e+03 2.8715e+04 5.0100e+01 1.0000e+02 2.0000e+02 1.1140e+03 3.1151e+03 2.1588e+04 1.6010e+02 2.0000e+02 3.0000e+02 1.2632e+03 3.2377e+03 2.6071e+04 2.5020e+02 3.0000e+02 4.0000e+02 9.2633e+02 2.7052e+03 2.6349e+04 3.7010e+02 4.0000e+02 5.0000e+02 1.1303e+03 3.2997e+03 2.8571e+04 4.9010e+02 5.0000e+02 6.0000e+02 1.4595e+03 4.0364e+03 2.8571e+04 5.3010e+02 6.0000e+02 7.0000e+02 1.0462e+03 3.3605e+03 2.9873e+04 6.9010e+02 7.0000e+02 8.0000e+02 7.4903e+02 2.8783e+03 2.6349e+04 7.1010e+02

Node: vdd

Start (ns) Stop (ns) Avg (uA) RMS (uA) Peak (uA) Time (ns) 0.0000e+00 1.0000e+02 -1.0172e+03 3.2458e+03 -2.8715e+04 5.0100e+01 1.0000e+02 2.0000e+02 -1.1349e+03 3.1344e+03 -2.1588e+04 1.6010e+02 2.0000e+02 3.0000e+02 -1.3084e+03 3.2743e+03 -2.6071e+04 2.5020e+02 3.0000e+02 4.0000e+02 -9.5453e+02 2.7270e+03 -2.6349e+04 3.7010e+02 4.0000e+02 5.0000e+02 -1.1601e+03 3.3144e+03 -2.8571e+04 4.9010e+02 5.0000e+02 6.0000e+02 -1.4618e+03 4.0404e+03 -2.8571e+04 5.3010e+02 6.0000e+02 7.0000e+02 -1.0831e+03 3.3849e+03 -2.9873e+04 6.9010e+02 7.0000e+02 8.0000e+02 -7.5635e+02 2.8863e+03 -2.6349e+04 7.1010e+02

nanosim.ic

This file created by the report_node_ic configuration command lists the initial voltage of all nodes except inputs and voltages source nodes.

nanosim.ignore

This file reports netlist statements that are ignored.

nanosim.log

This output file contains a log of the netlist compilation and simulation activity that includes the output of error messages and warnings, the circuit node and element numbers, event statistics (see the report_node_toggle configuration command), execution time, memory use information, and I/O



statistics. See Appendix B, “Detailed Configuration Command Information,” for a complete description of the .log file.

nanosim.meas

If the simulation uses a SPICE or HSPICE netlist containing any .meas (.measure) statements, this file will contain the results of processing those measurements. The measurements will be processed only if you chose the output format for printing simulation output. The simulator accepts the following measurement commands: trig-targ, cross, rise, fall, TD, from-to, AT, average, RMS, MIN, MAX, Peak-to-Peak, and find-when. These are supported only for transient analysis.

nanosim.mosalias

This output file contains a list of parallel transistors that were merged using the merge_mos_parallel command.

nanosim.nodealias

Whenever a node is aliased to another node (due to shorted resistors, a DC voltage source of 0 V, or net statements) and the aliased node name is referenced in a configuration command, the primary node name and alias node name are written to this file. This information tells you when a configuration command is applied to a different node than the one given when it was executed.

nanosim.out

This is the default output file that stores NanoSim simulation output information for logic states, voltages, and currents. This file contains information generated by the Output Reporting configuration commands.

It also contains data generated by the following output functions: big, bio, hex, oct, and spa. See the Circuit Simulation and Analysis Tools Reference Guide for more information.



This file is divided into three segments, which appear in the following order:

1. Header

This segment contains the output format version number, copyright, time, and date the file was generated.

2. Definition

This segment defines the units used in this file, the mapping between signal index and signal name, bus notation, and so forth.

3. Data

This segment contains all the requested signal values.

You can use edisplay to process this file and produce logic transition tables in text form. nWave, among others, can be used to produce graphical waveforms.

See the Circuit Simulation and Analysis Tools Reference Guide for more information on data formats and graphical utilities.

nanosim.partition.Z

This file contains partition information saved using the partition=1 option of the save_ckt_state command.

nanosim.power

This file contains power budget violation errors and hierarchical power reports generated by the report_block_powr command.

nanosim.rcxt

This file contains the names of nodes found to be active as reported by the report_node_active configuration command. See Appendix B, “Detailed Configuration Command Information,” for a sample .rcxt file.

nanosim.save.xxx.xx.Z

This is a UNIX compressed file that contains the intermediate simulation state at the simulation time xxx.xx nanoseconds specified by the save_ckt_state command in the configuration file.



nanosim.stat

This file reports memory and runtime statistics. The first table in this file lists the simulation time and dynamic and core memory use for each phase during the simulation. There are two types of memory listed: allocated memory and core memory. The allocated memory is the dynamic memory (malloc, calloc) used by the simulator. This memory is allocated and freed by the simulator as necessary. (Allocation and freeing might not happen in the same phase of simulation.) Core memory is the space being used to store the netlist, and technology files, all available data, allocated data and the simulator itself.

There are four columns in this table. The first column is the phase name while the rest of the columns are simulation time, dynamic memory use, and core memory use, in that order.

For some processes such as post_read_netlist_tasks, you might see a negative number for the allocated memory. The minus sign signals the release of some dynamic memory. Negative numbers on the core memory usage are not common because it is just a “water-mark” level. But, sometimes the OS can reduce the code and data size for a process and you might see a negative number. The value in parentheses on the core memory column is the up-to-date maximum memory used. See Appendix B, “Detailed Configuration Command Information,” for a sample .stat file (and a more extensive explanation).

To minimize the disk swapping and I/O time, run the simulation on a platform configured with a larger memory than the peak core memory size.

nanosim.stg

This is the stage dump file. This file is the output of the circuit diagnostic configuration command, report_stage_info. For the stages listed in the file, the settings on some stage flags are reported, in addition to the nodes and the elements in the stage.



nanosim.sum

This summary file contains output from the report_node_hotspot configuration command. This hot spot report contains the following information (by columns):■ The first column (Node) contains the node names. ■ The second column (Cap) contains the total lumped node capacitance from

all sources (netlist capacitance and the capacitance of connected device terminals).

■ The third column (Toggle) is the number of toggles for that node during the simulation.

■ The final two columns (Icin and Icout) contain the node average charging and discharging current, respectively. The charging current is defined as: Total amount of charge that has flown into the node during the simulation divided by the simulation time.



Example 82 is a sample hot spot report as it would be printed in the nanosim .sum file.

Example 82 Sample hot spot results in the nanosim.sum file****************************** Hot Spot Statistics ******************************

Node Cap(fF) Toggle Icin(uA) Icout(uA)_________________________________________________X1.4 4150.91 6 503.21 510.44X1.5 6150.91 6 455.08 496.35X1.9 4150.91 6 354.64 450.23X1.3 2150.91 6 279.99 270.87X1.8 650.91 6 81.96 81.85X1.1 650.91 6 81.80 81.77X1.2 150.91 6 18.96 19.00X1.7 150.91 6 18.88 18.90X1.6 150.91 6 18.16 18.091 69.23 6 8.66 7.96 Total non-input nodes : 10Total node toggles : 60Total charging current : 1821.34 uATotal discharging current : 1955.45 uA

Read in this file every time you run a simulation.

nanosim.unc

This file lists all unconnected nodes found during the netlist compilation. A node is considered unconnected if it is not connected to any elements other than capacitors.

nanosim.xst

This file contains nodes found to be in an X-state (“don’t care” state) at a given time. It is generated by the report_node_x configuration command.


Chapter 13: Understanding NanoSim’s Output FilesDisplaying Simulation Results Logically

Displaying Simulation Results Logically

NanoSim simulation results can be conveniently displayed in a logical form using the edisplay utility. The edisplay command, options, and example are provided in the Circuit Simulation and Analysis Tools Reference Guide.

Displaying Simulation Results Graphically

The NanoSim simulation results can be displayed in graphical form using the nWave waveform viewer.

Use the .out files generated by NanoSim as input to this viewer.

See the nWave Manual for more details.


Chapter 13: Understanding NanoSim’s Output FilesDisplaying Simulation Results Graphically


1414Using Utilities for Dynamic Synopsys Tools

This chapter describes the various utilities you can use to specify the type of information you want to obtain from simulation results.

Overview

The available utilities are as follows:■ Meas: computes the results of .measure statements in SPICE or HSPICE

netlists■ Edisplay: controls the formation of simulation results■ nWave: enables you to view analog and digital waveforms

This chapter contains the following topics:■ Using the Stand-alone Post-process meas Utility■ Controlling Formatting with the edisplay Utility■ Piping Output Data to a Waveform Display Utility■ Converting Output Formats with the vfast Utility

Using the Stand-alone Post-process meas Utility

meas 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 based on the output waveform file and measure statements, without running the 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.


Chapter 14: Using Utilities for Dynamic Synopsys ToolsUsing the Stand-alone Post-process meas Utility

To run the meas utility, you must have an .out or .fsdb output file and a SPICE netlist containing .meas statements (including all other netlists that may contain parameters referred to by the .measure 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 fails.

Command Syntax and Options

The command syntax for the meas utility is

meas [-p] [-n netlist_file] [-s out_file][-o meas_out_file]


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

Under the following two conditions, using the -p option could prevent .meas from generating 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

Use the .spi extension or the .sp extension for the netlist file. These extensions are required.

In addition, use the -nspice option if the netlist has any extension other than an .spi or .sp extension.

-s Specifies the .out, fsdb, or .wdf output file to be used as input for the meas utility; for example, nanosim.out



Controlling Formatting with the edisplay Utility

edisplay is a program that controls the 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 Table 82. The output file numbers are defined in the section describing the double integer line in Appendix B, “Detailed Configuration Command Information.”

-o Specifies the name of the output file generated by the.meas utility. The default file name is meas.meas

Table 82 Translation of logic state values to edisplay output

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




Command SyntaxThe command syntax for the edisplay utility is

edisplay [-i in_file_name] [-b begin_time] [-e end_time][-f control_file] [-h] [-m error_file] [-I] [-o out_file_name] [-p caption_step] [-r] [-s interval_step] [-t] [-d delay_measure_file] [-g time_tolerance] [-w sp_pwl_inode] [-v sp_pwl_file] [-l ]


-i in_file_name Specifies the input file to display, such as nanosim.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 to use. This file lets you specify which signals to display and their formats (that is, binary, hex, and so on). See the Controlling Output Printing with edisplay section.

-h Command-line help

-m error_file Merges the comparison errors with the output. An asterisk (*) is used to mark the lines that have errors. If a comparison error appears in the nanosim.err file, then edisplay -m nanosim.err produces the result shown in Example 83.



edisplay -m nanosim.err resultFor a sample result, see Example 83:

Example 83 -m nanosim.err edisplay resultT ......I n.nnnOM nInnnUE 1N234T

0.00 0110104.00 *U-----5.00 *-----110.00 10010120.00 10010123.00 *-----030.00 10010135.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.


-I Instructs edisplay to read the input from the standard input device. This is useful when running NanoSim 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_file_name 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, as shown in Example 84.



For a sample result, see Example 84:

Example 84 -o standard output......O......U

T ..d...TI ppa...PM hht...UE 12aABCT

0.00 000UUUU

10.00 100UUUU10.25 1001UUU20.00 1011UUU20.82 1010UUU30.00 0010UUU35.00 0110UUU35.01 01100UU35.02 011001U35.03 011001040.00 010001055.00 000001060.00 100001061.47 100101080.00 000101085.00 010101085.01 010111085.49 010110086.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.



See Example 85 for a -p caption_step sample.

Example 85 -p caption_step sampleSCEDDDDLLLLC

EKN01231111LR..........KI......BCAN.A........._.

T L.........1.I _ ...........M I...........E N...........

0.00 1U1UUUUUUUUU0.01 1U1UUUUUUUUU

SCEDDDDLLLLCEKN01231111L

R..........KI......BCAN.A........._.

T L.........1.I _...........M I...........E N...........

0.08 1U1UUUUUUUUU0.19 1U1UUUUUUUU00.291U11UUUUUUU00.431U11UUU0U0U00.43 1U11UUU0U0U00.54 1U111UU010UU


-r Changes the bottom-justified signal caption header to top-justified. Table 83 shows the effect of using the -r option.

Table 83 Using the edisplay -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 with 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: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.

Table 83 Using the edisplay -r option

With the -r option Without the -r option


Chapter 14: Using Utilities for Dynamic Synopsys ToolsControlling Output Printing with edisplay

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.

Controlling Output Printing with edisplay

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 NanoSim 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:

-I Instructs edisplay to display only digital logic values, and to ignore all analog voltage or current values.

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.




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 NanoSim output to be displayed after any other signal specified in the control file. Otherwise, only signals defined in the control file are displayed.

!append print_node n1^ n1 n2 n3spa 1 print_node_current i(a1) print_node_voltage v(b1) spa 3 print_node n0 print_node n1 print_node n2 bio bn3 n3hex 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.

■ The high impedance bus can 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 output file, instead of the default symbol T.


Chapter 14: Using Utilities for Dynamic Synopsys ToolsPiping Output Data to a Waveform Display Utility

Piping Output Data to a Waveform Display Utility

While the simulation output is generating, the output data can be piped to the waveform display utility using the set_print_filter configuration command. Synopsys offers three stand-alone waveform display utilities:■ WaveView

WaveView is a Synopsys tool and is packaged with NanoSim. WaveView processes .wdf files.

■ CosmosScope

CosmosScope is a Synopsys tool and is packaged with NanoSim. CosmosScope processes .fsdb and .wdb files.

■ nWave

nWave is a third-party utility that has been integrated with NanoSim so you can view analog and digital waveforms. nWave can be used as a stand-alone tool to view either NanoSim .out files or simulation results while a simulation runs.

Note:

An additional license is required for nWave.

CosmosScope

This section briefly describes how to use CosmosScope. See the CosmosScope manuals or access Help in CosmosScope for more information.

To use CosmosScope, do the following:

1. Source the NanoSim .CSHRC_platform file.

2. Type cscope.

The NanoSim .cshrc_platform file sets up all required paths to run NanoSim and CosmosScope.

nWave

This section briefly describes how to use nWave. See the nWave Manual or access Help in nWave for more information.


Chapter 14: Using Utilities for Dynamic Synopsys ToolsConverting Output Formats with the vfast Utility

To use nWave as a stand-alone utility, do the following:

1. Type % nWave & at the prompt.

2. Click on File, then choose Open from the slider menu to load the simulation result file(s).

3. Click Add, then Apply or OK in the signal browser to display waveforms.

Use the browser to add and apply signals.

To display waveforms while running a simulation, add the following line in Example 86 to your Synopsys configuration file:

Example 86 To display waveformsset_print_filter nWave -i

If you want to generate an output file in .fsdb format, use the following configuration command: set_print_format for=fsdb

Converting Output Formats with the vfast Utility

The vfast conversion utility that is installed with NanoSim (and provided by Novas, Inc.,) is used to convert accepted output formats (for example, VCD files) to FSDB files in binary format. No additional license is required for the vfast utility. See the following vfast utility syntax and command argument description—note that arguments can be entered before or after dump_file :

vfast dump_file [argument] OR vfast [argument] dump_file[-del delimiter] [dump_file] [-fileType or -ft][-h or -help] [-hier_scopename] [-hier_varname][-inc] [-lcase] [-o fsdb_file] [-outDir or -outdir][-orig_scopename] [-orig_varname]



[-orig_esc_varname or -esc] [-seq_num] [-ucase][-vcdIDstring or -idstr] [dump_file]

vfast Command Arguments


-del delimeter The delimeter for separating a full path signal name. Specify the scope delimiter for parsing the full path signal name; for example, if a full path signal name is /top/system/alu/dbus [15:0], you should specify the scope delimiter as slash (/).

dump_file The name of the dump file.

-fileType or -ft Specifies the type of dump file to be converted to an FSDB file. The type can be nanosim, verilog, spice, xp, rawfile or wfm. The default is verilog.

-h or -help Shows the usage.

-hier_scopename Parses the hierarchical scope name and creates the corresponding scope(s).

-hier_varname Parses the hierarchical var name and creates the corresponding scope(s).

-idstr idcode scheme.

-inc Parses the file by incremental mode. It enables incremental parsing when the file is still growing.

-lcase Converts all signal definitions to lowercase.

-o fsdb_file The name of the output fast file. The default is dump_file.fsdb.

-outdir or _outDir Specifies the directory that holds the output fast file.

-orig_scopename Keeps the original scope name. It will not perform any conversion on scope name.



Table 84 displays vhdl2vcd value change mapping.

-orig_varname Keeps the original var name. It will not perform conversions on var name.

-orig_esc_varname or -esc

Keeps the original escape var name. It will not perform conversions on var name.

-seq_num Enables sequence number dumping.

-ucase Converts all signal definitions to uppercase.

-vcdlDstring or -idstr

Parses VCD ID string by handle scheme. The default is idcode scheme.

Table 84 Value Change Mapping

Value Result

u or U x

x or X x

0 0

1 1

z or Z z

w or W x

I or L 0

h or H 1

dash x

vfast Command Arguments (Continued)





1515Using the batchrun Program

This chapter describes the batchrun program, in which multiple jobs can be run concurrently on multiple computers. The batchrun script runs NanoSim in batch mode using various parameters.

Overview

The batchrun program distributes jobs to multiple computers that can be executed concurrently. The information required is in a host file that specifies the host names of available computers.

The batchrun command runs a script you have written. For the batchrun command syntax, see the following, as well as the command argument descriptions:

batchrun product_name batch_file

This chapter contains the following topics:■ Distributing Jobs for Concurrent Computing■ Formatting the Batchfile■ Batchfile Example

batchrun command arguments


product_name nanosim

batch_file Specifies the name of the batch script you wrote


Chapter 15: Using the batchrun ProgramDistributing Jobs for Concurrent Computing

Distributing Jobs for Concurrent Computing

You can run the batchrun program after following a few requirements:

Naming Conventions

To perform distributed computing, all file names 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 path name 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. Because multiple jobs are run simultaneously 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 be used to execute different jobs.

The format of this batchrun file is one host name per line, as shown in Example 87.

Example 87 Batchun file host namesmauioahulanaimaui

In Example 87, 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. After a computer completes a job, batchrun assigns a new one to it.

Searching for the Host FileThe batchrun program 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.


Chapter 15: Using the batchrun ProgramFormatting the Batchfile

- Uses only the local host to run jobs (if steps 1 and 2 fail).

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 directory where the batchrun command is executed.

The batchrun program uses remote shell, rsh, to invoke remote processes for running a job on a remote computer. The path name 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. Depending on the network file system setup, PWD might not be a network full path. You should set EPIC_BATCHRUN_DIR before starting the batchrun program. EPIC_BATCHRUN_DIR must be a network full path.

If you encounter permission problems while using rsh, see your system administrator. Also, see the UNIX manual page on rsh for details.

Formatting the Batchfile

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.

FILE

The syntax for the FILE statement is

FILE file_name<contents><contents><contents>

...

END



See Example 88 for a FILE statement example.

Example 88 FILE statement exampleFILE temp.config

add_node_cap N1 $CLOAD1add_node_cap N2 $CLOAD1

END

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 a dollar sign ($). The parameter values are specified in the DATA statement.

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.

RUN

The syntax for the RUN statement is

RUN arguments

See Example 89 for a syntax example.

Example 89 RUN statement syntax exampleRUN -n NET -p $TECH

This syntax runs the Synopsys tool on the NET netlist and uses the technology files specified by the TECH parameter in the DATA statement.

The RUN statement specifies the command-line options for NanoSim. 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 ($).

DATA

The syntax for the DATA statement is

DATA param1 param2 param3 ...<data><data><data>



<data>...END

See Example 90 for a DATA statement example.

Example 90 DATA statement exampleDATA CLOAD1 TECH OUTFILE

10 best_5v.tech best_5v_c10 20 best_5v.tech best_5v_c20 100 best_5v.tech best_5v_c10010 worst_4.5v.tech worst_4.5v_c10 20 worst_4.5v.tech worst_4.5v_c20 100 worst_4.5v.tech worst_4.5v_c100

END

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. (This is 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.


Chapter 15: Using the batchrun ProgramBatchfile Example

Batchfile Example

Example 91 shows a sample batchfile for running NanoSim with different loading capacitances and technology files.

Example 91 Sample batchfile with differing capacitances and tech filesbatchrun nanosim batchfile batchfile: --------------------------------- # to specify capacitances for nodes N1 and N2

FILE temp.configadd_node_cap N1 $CLOAD1

add_node_cap N2 $CLOAD1 END

RUN -n net -p $TECH -c config1 temp.config -t 100 -o $OUTFILE

DATA CLOAD1 TECH OUTFILE 10 best_5v.tech best_5v_c10 20 best_5v.tech best_5v_c20 100 best_5v.tech best_5v_c100 10 worst_4.5v.tech worst_4.5v_c10 20 worst_4.5v.tech worst_4.5v_c20 100 worst_4.5v.tech worst_4.5v_c100 END

Six simulations will be run for this NanoSim batchrun. The output file best_5v_c10 will contain the results of a simulation performed using best_5v.tech as the technology file, including a load of 10 fF on nodes N1 and N2.

Table 85 displays what the other runs use:

Table 85 Simulation Parameters

Load on N1 & N2 Technology File Output

20 fF best_5v.tech best_5v_c20.out

100 fF best_5v.tech best_5v_c100.out

10 fF worst_4.5v.tech worst_4.5v_c10.out





Table 85 Simulation Parameters

Load on N1 & N2 Technology File Output




Part: 3 Using NanoSim-supported HSPICEFeatures

NanoSim supports many HSPICE features. Part 3 of this guide describes several of these features.


:


1616Encrypting with the metaencrypt Utility

This chapter describes the metaencrypt utility.

Overview

NanoSim has the capability to protect your intellectual property (from reverse engineering) using the HSPICE encryption utility that parses encrypted files.

This chapter contains the following topics:■ Encrypting with metaencrypt■ Simulating with an Encrypted Netlist■ Known Limitations

Encrypting with metaencrypt

NanoSim supports files encrypted by the metaencrypt utility—not other encryption programs.


metaencrypt –i input_file –o encrypte_netlist –t algorithm –r tools_name:access_code

The key words for the -r tools_name option of metaencrypt are■ synopsys

(default) that enables all Synopsys tools (including HSPICE, NanoSim, and HSIM)

■ hspice


Chapter 16: Encrypting with the metaencrypt UtilityEncrypting with metaencrypt

■ nanosim

■ hsim

HSPICE can read any encrypted netlist, if encrypted by the metaencrypt utility. See Table 86 for more details about NanoSim and HSIM.

See Table 87 for a description of the three basic algorithms for metaencrypt:

Algorithm Examples

See the following examples:

Table 86 Encrypted netlists

Product Encrypted netlist read by

hspice HSPICE

nanosim NanoSim, HSPICE

hsim HSIM, HSPICE

Table 87 Three algorithms for the metaencrypt utility

Algorithm Description

freelib ■ Basic algorithm of metaencrypt■ Keyword: freelib

8-byte key ■ Advanced algorithm of metaencrypt. Use DES algorithm.

■ Keyword: 8 ASCII characters■ ex> -t 12345678 or –t lkaskdi3

3DES ■ The latest algorithm of metaencrypt. Use 3DES algorithm.

■ Keywords: 3DES algorithm enables two encryption methods.

■ randkey: 3DES algorithm without key file.■ private key: 48 ASCII characters are needed,

and metaencrypt generates the key file.



8-byte Key ExamplesIn Example 92, without the -r option, all Synopsys tools can read the encrypted netlist.

Example 92metaencrypt –i design_ckt.sp –o enc_design_ckt.sp –t 7fG4WeP8

In Example 93, with the -r option, only HSPICE can read the encrypted netlist.

Example 93metaencrypt –i design_ckt.sp –o enc_design_ckt.sp –t 7fG4WeP8 -r hspice

In Example 94, the access control level and the level are optional. The default level is 0, which is the most secure level.

Example 94metaencrypt –i design_ckt.sp –o enc_design_ckt.sp –t 7fG4WeP8 -r nanosim:0

3DES ExamplesExample 95 encrypts design_ckt.sp with an HSPICE 192-bit random key encryption feature, based on a 3DES algorithm. The encrypted file enc_design_ckt.sp can be parsed by HSPICE, NanoSim and HSIM. The access control level is 0 for all simulators. Note that HSPICE can parse the encrypted file, even though -r hspice is not explicitly stated.

Example 95metaencrypt –i design_ckt.sp –o enc_design_ckt.sp –t randkey -r hspice -r nanosim -r hsim

Example 96 encrypts design_ckt.sp with the HSPICE 3DES encryption feature. The encrypted file enc_design_ckt.sp can be parsed by HSPICE, NanoSim and HSIM. The access control level is 0 for both HSPICE and HSIM, and 1 for NanoSim. You can access the NanoSim interactive debugging features to debug the encrypted netlist.

Example 96metaencrypt –i design_ckt.sp –o enc_design_ckt.sp –t randkey -r nanosim:1 -r hsim

Example 97 encrypts design_ckt.sp with an HSPICE 256-bit public key 3DES encryption feature. The encrypted file enc_design_ckt.sp can only



be parsed by HSPICE and HSIM with a 256-bit public key, which is generated during encryption based on the 192-bit private key. The access control level for both HSPICE and HSIM is set to 0.

Example 97metaencrypt –i design_ckt.sp –o enc_design_ckt.sp –t privkey <48 ASCII character for encrypt key> -r hsim

Example 98 encrypts design_ckt.sp with the HSPICE 3DES encryption feature. The encrypted file enc_design_ckt.sp can be parsed by all Synopsys tools with the access control level set to 0.

Example 98metaencrypt –i design_ckt.sp –o enc_design_ckt.sp –t randkey -r synopsys

SyntaxSee the following syntax:

metaencrypt –i input_file –o encrypted_output_file –t encrypt_type -r synopsys_tool[:access_control] -r synopsys_tool[:access_control] -r …

See the following argument descriptions:


synopsys_tool Specifies the Synopsys tool enabled to parse an encrypted file. The value can be hspice, hsim, nanosim, or synopsys. The value is case-insensitive.

hspice Only allows HSPICE for parsing. Other Synopsys tools not specified with an -r option abort with a message. A default value for the -r option, if not specified in the metaencrypt command line.

hsim Only allows HSPICE and HSIM for parsing. Other Synopsys tools not specified with an -r option abort with a message.

nanosim Only allows HSPICE and NanoSim for parsing. Other Synopsys tools not specified with an -r option abort with a message.


Chapter 16: Encrypting with the metaencrypt UtilitySimulating with an Encrypted Netlist

Simulating with an Encrypted Netlist

This HSPICE encrypted netlist feature supports transistor-level netlists and device model files specified in the HSPICE netlist format. Other transistor-level netlist formats encrypted by the metaencrypt utility are not parsed. See Table 88.

synopsys Default. All Synopsys tools are allowed for parsing.

access_control Specifies how much information from the encrypted netlist section Nanosim is allowed to provide to you. This value is optional. If it is not provided, the default is 0, which is the most secure mode.

0 The default setting, designed to suppress netlist data printing for an encrypted circuit. In addition, such functions as interactive mode simulations, SimIF, NS-GUI, and circuit diagnostic and waveform printing/displaying are all disabled during simulation.

The encrypted circuit is like a black box where only the interface nodes that connect to any unprotected circuits can be viewed during simulation. If the encrypted file/block has model cards (all kinds of device models, not limited to BSIM4), the parsing information for these model cards is suppressed.

1 In NanoSim, all simulator features are supported, as the netlist is not encrypted. You can see the parsing messages for encrypted netlist files.

If multiple encrypted files are provided for simulation, and one or more files does not contain an access_control option in the encrypted file, the value 0 default condition is assumed.

Table 88 License feature

Algorithm metaencrypt (netlist) nanosim (netlist)

encryption decryption




Algorithm Descriptions

See the following details:■ freelib

encrypt — metaencrypt encrypts the netlist between .prot and .unprot. The remaining netlist displays in normal text.

nanosim — handled as a normal netlist. Proceed with the simulation as a normal netlist simulation.

■ 8-byte

encrypt — DES algorithm encrypts the netlist by file base.

nanosim — must be included by the top netlist file. NanoSim cannot directly read in the DES encrypted netlist with the -n command line option. You must use the include statement .inc encrypted_netlist.spi in the top netlist, and proceed with the NanoSim simulation of the top netlist.

■ 3DES

encrypt — 3DES algorithm encrypts the netlist by file base.■ nanosim — must be included by the top netlist file. NanoSim cannot directly

read in the 3DES encrypted netlist with the -n command line option. You must use the include statement .inc encrypted_netlist.spi in the top netlist, and proceed with the NanoSim simulation of the top netlist.

Encrypted Netlist ExamplesSee Figure 33 for sample encrypted netlists.

freelib encrypt nanosim

8-byte encrypt nanosim

3DES encrypt + metaencrypt3des

nanosim + hspice3des

Table 88 License feature

Algorithm metaencrypt (netlist) nanosim (netlist)



Figure 33 Encrypted netlists

Simulation LimitationsThe following are simulation limitations:■ Non-HSPICE netlists (Verilog/Verilog-A/ADFMI/Spectre/Eldo etc.) are not

supported.■ NanoSim features not supported: HAR flow, Co-simulation (including NS-

VCS and AMS), Selective extraction/back-annotation flow


Chapter 16: Encrypting with the metaencrypt UtilityKnown Limitations

Work-aroundsThe following are work-arounds for ADFMI and Verilog-A:■ Verilog-A

Encryption syntax is not allowed inside the Verilog-A module. However, you can convert the Verilog-A module to binary code using the vamc stand-alone utility.

Example:

vamc –f file.va –ocx (this will convert *.va file to *.ocx file)

NanoSim can directly read-in the *.ocx file (the *.ocx file is only readable by NanoSim).

■ ADFMI

Use object file (*.o).

Example:

nanosim –n input_netlist –C config_file –fm adfmi.o –o out/test

Known Limitations

The following are known limitations:■ Case-sensitivity

When using the freelib encryption method, all letters are converted into lower-case—other encryption methods maintain their original case. This limitation restricts the .include file names (.include filename) to lower-case.

■ Forward compatibility

The 3DES algorithm of the metaencrypt utility changes its encryption key in every major release of the HSPICE product. Therefore, a file encrypted by 3DES in a newer version of metaencrypt cannot be parsed by an older version of HSPICE. This limitation also applies to NanoSim and HSIM. See Figure 34 for a graphical illustration of version compatibility.



Figure 34 Version compatibility




1717Modeling with the HSPICE-compatible W-element Feature

This chapter describes the W-element, which is an efficient and accurate versatile transmission line model that can be simulated from a simple lossless line to a complex frequency-dependent lossy-coupled HSPICE-compatible line.

Overview

The W-element does not require optional parameter fine-tuning for simulation. However, transmission line simulation is challenging since physical geometry parameter extraction can require a significant effort.

The W-element multi-conductor lossy frequency-dependent transmission line provides advanced modeling capabilities for transmission lines.

The W-element enables:■ A limitless number of coupled conductors■ Structural freedom for RLGC matrices—all matrices can be full

This chapter contains the following topics:■ Using the W-element■ Specifying the RLGC Model■ Using an RLGC External File■ Specifying the Field-solver Model■ Specifying Field-Solver Model Options■ Defining the Field-Solver Model


Chapter 17: Modeling with the HSPICE-compatible W-element FeatureUsing the W-element

Using the W-element

The W-element supports two formats for inputting transmission line properties:■ RLGC Model■ Field-solver Model

NanoSim does not support the U model, nor the frequency-dependent tabular model that HSPICE supports.

The W-element syntax is as follows:

Wxxx il i2 ... iN iR o1 o2 ... oN oR N=val L=val+[RLGCMODEL=name or RLGCFILE=name or FSMODEL=name]+[INCLUDERSIMAG=YES|NO FGD=val ]

For a description of the arguments, see Table 89.

Table 89 W-element argument descriptions


N Specifies the number of signal conductors (excluding the reference conductor).

i1 ... iN Specifies the nodes for the near-end signal-conductor terminal.

iR Specifies the node for the near-end reference-conductor terminal.

o1 ... oN Specifies the nodes for the far-end signal-conductor terminal.

oR Specifies the node for the far-end reference-conductor terminal.

L Specifies the transmission line length.

RLGCMODEL Specifies the RLGC model name.

Note: You can only specify one in a single W-element card.

RLGCFILE Specifies the external RLGC file name.



Chapter 17: Modeling with the HSPICE-compatible W-element FeatureSpecifying the RLGC Model

For a graphic representation of the terminal node numbering, see Figure 35.

Figure 35 Terminal node numbering

Specifying the RLGC Model

You can specify the RCLG model in two ways:■ Internally in a .MODEL statement■ Externally in a different file

FSMODEL Specifies the field-solver model name.


INCLUDERSIMAG Specifies the skin effect imaginary term to be considered. The default is YES.

FGD Specifies the cut-off frequency of dielectric loss.

Table 89 W-element argument descriptions (Continued)




Using a .MODEL Statement

The syntax of a W-element RLGC model is as follows:

.MODEL name W MODELTYPE=RLGC N=val Lo=matrix_entries+ Co=matrix_entries+ [Ro=matrix_entries] [Go=matrix_entries]+ [Rs=matrix_entries]+ [Gd=matrix_entries]+ [Rgnd=val] [Rsgnd=val] [Lgnd=val]


Table 90 .MODEL statement argument descriptions


name Specifies the RLGC model name.

N Specifies the number of signal conductors.

Lo Specifies the DC inductance matrix per unit length. [H/m]

Co Specifies the DC capacitance matrix per unit length. [F/m]

Ro Specifies the DC resistance matrix per unit length. [Ω/m]

Go Specifies the DC shunt conductance matrix per unit length. [S/m]

Rs Specifies the skin effect resistance matrix per unit length. [Ω/m√ Hz]

Gd Specifies the dielectric-loss conductance matrix per unit length. [S/m.Hz]

Rognd Specifies the DC resistance matrix per unit length for ground. Ω[/m]

Rsgnd Specifies the skin effect resistance matrix per unit length for ground. [Ω/m√ Hz]



Only the lower-triangle sections of the matrices are specified in the RLGC model, since RLGC matrices are symmetric.

Example 99 is an example of an input netlist file, showing the RLGC model as input usage for the W-element.

Example 99 RLGC model input netlist file for the W-element* W-element - RLGC Modelw1 n=3 1 3 5 0 2 4 6 0 rlgcmodel=example_rlc l=0.97v1 1 0 pulse(4.82v 0v 5ns 0.1ns 0.1ns 25ns).tran 0.1ns 200ns

* RLGC matrices for a four-conductor lossy.model example_rlc w modeltype=rlgc n=3+ Lo=+ 2.311e-6+ 4.14e-7 2.988e-6+ 8.42e-8 5.27e-7 2.813e-6+ Co=+ 2.392e-11+ -5.41e-12 2.123e-11+ -1.08e-12 -5.72e-12 2.447e-11+ Ro=+ 42.5+ 0 41.0+ 0 0 33.5+ Rs=+ 0.00135+ 0 0.001303+ 0 0 0.001064+ Gd=+ 5.242e-13+ -1.221e-13 5.164e-13+ -1.999e-14 -7.747e-14 4.321e-13.end

Lgnd Specifies the DC inductance matrix per unit length for ground. [H/m]

Table 90 .MODEL statement argument descriptions (Continued)



Chapter 17: Modeling with the HSPICE-compatible W-element FeatureUsing an RLGC External File

Using an RLGC External File

RLGC matrices can also be specified in an external file. This external file format is more restricted than the RLGC model. For example, the RLGC file

does not support scale suffixes such as n( ) or p( ) which is HSPICE-compatible.

Similar to the RLGC model, only the lower-triangle sections of the matrices are specified in the RLGC file. The RLGC file is order-dependent.

A line beginning with an asterisk ( * ) is considered to be a comment line. It comments-out everything until the end of the line. You can separate numbers using any of the following characters: space , tab, newline, commas, and semicolon.

These graphically represented characters are as follows:

, ;

The RLGC file parameters are in the following (descending) order:■ N (Number of signal conductors)■ Lo (DC inductance matrix per unit length [H/m])■ Co (DC capacitance matrix per unit length [F/m])

The RLGC file optional parameters are in the following (descending) order:■ Ro (DC resistance matrix per unit length [Ω /m])■ Go (DC shunt conductance matrix per unit length [S/m])■ Rs (Skin effect resistance matrix per unit length [Ω /m√ Hz])■ Gd (Dielectric-loss conductance matrix per unit length [S/m.Hz])

Example 100 is an example of an input netlist file, calling the RLGC file as input usage for the W-element.

Example 100 Input netlist file calling RLGC* W-element - RLGC Filew1 n=3 1 3 5 0 2 4 6 0 rlgcfile=example.rlc l=0.97v1 1 0 pulse(4.82v 0v 5ns 0.1ns 0.1ns 25ns).tran 0.1ns 200ns.end

109–

1012–


Chapter 17: Modeling with the HSPICE-compatible W-element FeatureSpecifying the Field-solver Model

This example calls the following example.rlc RLGC file, as shown in Example 101.

Example 101 Calling the example.rlc RLGC file* RLGC parameters for a four-conductor lossy frequency-dependent line* N (number of signal conductors)3* Lo2.311e-64.14e-7 2.988e-68.42e-8 5.27e-7 2.813e-6Co2.392e-11-5.41e-12 2.123e-11-1.08e-12 -5.72e-12 2.447e-11* Ro42.50 41.00 0 33.5* Rs0.001350 0.0013030 0 0.001064* Gd5.242e-13-1.221e-13 5.164e-13-1.999e-14 -7.747e-14 4.321e-13

Specifying the Field-solver Model

The netlist input syntax contains five statements that specifically relate to the field-solver model, as shown in Table 91.

Table 91 Field-solver model statement definitions

Statement Definition

.MATERIAL Material properties. See the Defining Material Properties section.

.LAYERSTACK Material stacks. See the Creating Layer Stacks section.



Defining Material Properties

The syntax of a .MATERIAL statement to define the properties of a material is as follows:

.MATERIAL mname METAL|DIELECTRIC [ER=val]+ [UR=val] [CONDUCTIVITY=val]+ [LOSSTANGENT=val]


.SHAPE Conductor shapes. See the Defining Shape, Defining Rectangles, Defining Circles, Defining Strips, and Defining Polygons sections.

.FSOPTIONS Field-solver model options. See the Specifying Field-Solver Model Options section.

.MODEL W MODELTYPE= FieldSOLVER

Transmission model type. See the Defining the Field-Solver Model section.

Table 92 .MATERIAL statement argument descriptions


mname Specifies the material name.

METAL|DIELECTRIC Specifies the material type: METAL or DIELECTRIC.

ER Specifies the dielectric constant. See Table 93 for the default value for a different material type.

UR Specifies the relative permeability. See Table 93 for the default value for a different material type.

CONDUCTIVITY Specifies the static-field conductivity of conductor or lossy dielectric (S/m). See Table 93 for the default value for a different material type.

Table 91 Field-solver model statement definitions (Continued)

Statement Definition



For a description of the default values, see Table 93.

Creating Layer Stacks

A layer stack defines a stack of dielectric and/or metal layers. Each transmission line system is associated with exactly one layer stack; however, a single-layer stack can be associated with many transmission line systems.

The syntax of a .LAYERSTACK statement to create the layer stack is as follows:

.LAYERSTACK sname [BACKGROUND=mname]+ [LAYER=(mname, thickness . . . )]


LOSSTANGENT Specifies the alternating field loss tangent of dielectric (tan d). See Table 93 for the default value for a different material type.

Table 93 Default values for different parameters for different material types

Parameter Metals Dielectrics

CONDUCTIVITY -1 (perfect conductor) 0 (lossless dielectric)

ER 1 1

UR 1 1

LOSSTANGENT N/A 0 (lossless dielectric)

Pre-defined names PEC AIR

Table 94 .LAYERSTACK statement argument descriptions


sname Specifies the layer stack name.

mname Specifies the material name.

Table 92 .MATERIAL statement argument descriptions




In the layer stack,■ metal layers (ground planes) are located only at the bottom, top, or both top

and bottom■ layers are stacked in a y-direction■ the bottom of the layer stack is at y=0■ all conductors must be located above y=0■ background material must be dielectric

Defining ShapeThe syntax of a .SHAPE statement that defines the shape of a conductor is as follows:

.SHAPE sname shape_descriptor


Defining Rectangles(shape_descriptor)

BACKGROUND Specifies the background dielectric material name. Default is AIR for the background.

thickness Specifies the layer thickness.

Table 95 .SHAPE statement argument descriptions


sname Specifies the shape name.

shape_descriptor See Defining Rectangles, Defining Circles, Defining Strips, and Defining Polygons.

Table 94 .LAYERSTACK statement argument descriptions




The syntax of a RECTANGLE statement, which is a shape_descriptor option, is as follows:

RECTANGLE WIDTH=val HEIGHT=val [NW=val] [NH=val]


You do not need to specify NW and NH values. The field-solver model automatically sets these values, depending on the accuracy mode. You can specify both values, or specify only one of these values, since the solver determines the other.

Defining Circles(shape_descriptor)

The syntax of a CIRCLE statement, which is a shape_descriptor option, is as follows:

CIRCLE RADIUS=val [N=val]


Table 96 RECTANGLE statement argument descriptions


WIDTH Specifies the width of a rectangle (length in x-direction).

HEIGHT Specifies the height of a rectangle (length in y-direction).

NW Specifies the number of segments for the width discretization.

HW Specifies the number of segments for the height discretization.

Table 97 CIRCLE RADIUS statement argument descriptions


RADIUS Specifies the radius of a circle.



The field-solver model approximates a circle as an inscribed circular polygon with N edges. The more edges, the more accurate the circle approximation. Do not use the CIRCLE descriptor to model actual polygons—use the POLYGON descriptor. You normally do not set the N value, because the field-solver model automatically sets the value (depending on the accuracy mode). But, you can specify the value if you need to.

Defining Strips(shape_descriptor)

The syntax of a STRIP statement, which is a shape_descriptor option, is as follows:

STRIP WIDTH=val [N=val]


Defining Polygons(shape_descriptor)

The syntax of a POLYGON statement, which is a shape_descriptor option, is as follows:

POLYGON VERTEX=(x1 y1 x2 y2 ...) [N=(n1, n2, ...)]

N Specifies the number of segments for discretization.

Table 98 STRIP WIDTH statement argument descriptions


WIDTH Specifies the width of a strip (length in x-direction).

N Specifies the number of segments for discretization.

Table 97 CIRCLE RADIUS statement argument descriptions



Chapter 17: Modeling with the HSPICE-compatible W-element FeatureSpecifying Field-Solver Model Options


Specifying Field-Solver Model Options

The syntax of a .FSOPTIONS statement to set various options for the solver is as follows:

.FSOPTIONS name [ACCURACY=LOW|MEDIUM|HIGH]+ GRIDFACTOR=val+[PRINTDATA=YES|NO] [COMPUTEGO=YES|NO]+[COMPUTEGD=YES|NO]+[COMPUTERO=YES|NO] [COMPUTERS=YES|NO]


Table 99 POLYGON VERTEX statement argument descriptions


VERTEX Specifies the (x,y ) coordinates of vertices. Listed either in clockwise or counter-clockwise direction.

N Specifies the number of segments for each edge. If only one value is specified, this value is used for all edges.

Table 100 .FSOPTIONS statement argument descriptions


name Specifies the option name.

ACCURACY Sets the solver accuracy to either LOW, MEDIUM, or HIGH. Default is HIGH. For each accuracy mode, the field-solver model uses either the predefined number of segments, or the number of segments you specified. It then multiplies on the value of the GRIDFACTOR to obtain the final number of segments. If the predefined accuracy level is not enough, you can increase the value of the GRIDFACTOR or the N/NH/NW to increase the mesh density.


Chapter 17: Modeling with the HSPICE-compatible W-element FeatureDefining the Field-Solver Model

The L and C matrices are always computed.

Defining the Field-Solver Model

The field-solver model is used to specify the W-element transmission line geometry model. In the field-solver model:■ The list of conductors must appear last.■ Conductors cannot overlap.■ Floating conductors are assumed to be electrically disconnected, and non-

zero fixed charge is not supported.■ Metal layers in the layer stack are treated as the reference node.

GRIDFACTOR Specifies the multiplication factor to determine the final number of segments used in discretization. Default value is 1.

PRINTDATA Specifies that the solver prints output matrices. Default is NO.

COMPUTEGO Specifies that the solver computes the static conductance matrix. Default is YES.

COMPUTEGD Specifies that the solver computes the dielectric loss matrix. Default is NO.

COMPUTERO Specifies that the solver computes the DC resistance matrix. Default is YES.

COMPUTERS Specifies that the solver computes the skin effect resistance matrix. Default is NO.

Table 100 .FSOPTIONS statement argument descriptions (Continued)




■ Conductors defined as references are all electrically connected and correspond to the reference node in the W-element.

■ Signal conductors must be ordered according to the terminal list in the W-element statement. For instance, the i th signal conductor, counting without reference and floating conductors, is associated with the ith input and output terminals specified in the corresponding W-element. Floating and reference conductors can appear in any order.

The syntax of a field-solver model is as follows:

.MODEL mname W MODELTYPE=FieldSolver+ LAYERSTACK=name+[FSOPTIONS=name] [RLGCFILE=name]+[OUTPUTFORMAT=RLGC|RLGCFILE]+[CONDUCTOR=(SHARE=name) [MATERIAL=name]+[ORIGIN=(x,y)] ]+[TYPE=SIGNAL|REFERENCE|FLOATING]


Table 101 .MODEL statement argument descriptions


mname Specifies the model name.

LAYERSTACK Specifies the associated layer stack name.

FSOPTIONS Specifies the associated option name.

RLGCFILE Specifies the output file for RLGC matrices instead of the standard error output device. In case the specified file already exists, the output is simply appended. PRINTDATA in .FSOPTIONS statement must be set to YES.

OUTPUTFORMAT Specifies the W-element model syntax format for RLGC matrices in RLGCFILE. The default format is RLGC model.

SHAPE Specifies the shape name.

x, y Specifies the coordinate of the local origin.

MATERIAL Specifies the conductor material name. PEC is assumed, if not specified.



For an example showing three traces immersed in stratified dielectric media, see Figure 36.

Figure 36 Three traces immersed in stratified dielectric media

TYPE Sets the conductor type to one of the following: ■ SIGNAL is a signal node in W-element, which is

also the default. ■ REFERENCE is the reference node in W-element.■ FLOATING is the floating conductor, no reference

to W-element.

Table 101 .MODEL statement argument descriptions (Continued)




For an example of an input netlist file, showing the field-solver model as input for the W-element, see Example 102:

Example 102 Field-solver model as input for the W-elementW-element - Field-Solvervimpulse in1 gnd pulse 4.82v 0v 5ns 0.5ns 0.5ns 25nsw1 in1 in2 in3 gnd out1 out2 out3 gnd fsmodel=cond3_sys n=3 l=0.5

* Materials.material diel_1 dielectric er=4.3.material diel_2 dielectric er=3.2

* Shape.shape rect_1 rectangle width=0.35mm height=0.07mm

* Layer Stacks.layerstack stack_1 layer=(pec,1um), layer=(diel_1,0.2mm), +layer=(diel_2,0.1mm)

* Field-Solver Options.fsoptions opt1 printdata=yes

* Field-Solver Model.model cond3_sys w modeltype=fieldsolver, layerstack=stack_1, +fsoptions=opt1, rlgcfile=ex.rlgc,+ conductor=(shape=rect_1,origin=(0,0.201mm)), + conductor=(shape=rect_1,origin=(0.5mm,0.301mm)),+ conductor=(shape=rect_1,origin=(1mm,0.301mm))

* Analysis.options post.tran 0.5n 100n.end




1818Optimizing Timing with Bisection Functions

This chapter describes bisection optimization, which is an efficient cell-characterization method that NanoSim supports. Bisection methodology saves you time in three ways: (1) reducing multiple jobs to a single characterization; (2) reducing the complication of post-processing measurements; and (3) using accuracy-driven iterations.

Overview

To analyze circuit timing violations, a typical methodology generates a set of operational parameters that produces circuit behavior failures. When a circuit timing failure occurs, you can identify a timing constraint that can lead to a design guideline. You must perform an iterative analysis to define the violation specification.

Timing constraint violations that you typically encounter include:■ data setup time—before the clock■ data hold time—after the clock

This chapter describes how to use NanoSim’s bisection function for timing optimization and contains the following topics:■ Bisection Methodology■ Detecting Output Transition Status■ Optimization■ Using Bisection In NanoSim■ Results


Chapter 18: Optimizing Timing with Bisection FunctionsBisection Methodology

Bisection Methodology

To find the value of an input variable (target value), bisection is used as an optimization method—a binary search method. This variable is associated with a goal value of an output variable.

NanoSim supports timing variables (input and output variables). To find the variable value,

1. Use a binary search to locate the goal value of the output variable, within a search range of the input variable.

2. Halve that range iteratively, to rapidly converge on the target value.

At each iteration, NanoSim compares the measured value of the output variable with the goal value.

Figure 37 shows a typical analysis of setup-time constraints. Clock and data input waveforms drive a cell. Two input transitions occur at times T1 and T2. The result is an output transition, when V(out) changes from low to high. The following relationship between the T1(data) and T2(clock) times must be true, for the V(out) transition to occur:


Chapter 18: Optimizing Timing with Bisection FunctionsBisection Methodology

T2 > (T1 + setup time)

Figure 37 Determining Setup Time with Bisection Violation Analysis

Characterization, or violation analysis, determines the setup time. NanoSim initially keeps T2 fixed, and repeats the simulation with different T1 values. Secondly, NanoSim observes which T1 values produce—or do not produce—an output transition.


Chapter 18: Optimizing Timing with Bisection FunctionsDetecting Output Transition Status

Detecting Output Transition Status

Common measurement function, such as MAX and MIN, are used to detect the success or failure of an output transition. For a low-to-high output transition, a MAX measurement produces zero on failure, or approximately the Vdd supply voltage on success. This measurement, using a goal of Vdd (minus a suitable small value to ensure a solution), is sufficient to drive the optimization. You have the flexibility of defining other types of measurement functions to drive the optimization.

Optimization

For the input parameter, you must specify a single measurement with a goal, and known upper and lower boundary values.

Using Bisection In NanoSim

Before you can use the bisection feature, you must specify the following:

Required Values and Statements

The following values and statements are required:■ The optimization parameter name.■ The optimization parameter value domain (that is, the upper and the lower

parameter values).■ A measure statement with the optional goal value (called “optimization root”)

such that the measurement result is a monotonic function of the optimization parameter on the domain specified in the parameter value domain. The optimization root may or may not contain the optimization parameter.

The optimization root fails, if one of the following occurs:■ The measurement failed.■ The measurement type is MIN and the measurement result is greater than

or equal to ( > or =) the goal.■ The measurement type is MAX and the measurement result is less than or

equal to (< or = ) the goal.


Chapter 18: Optimizing Timing with Bisection FunctionsUsing Bisection In NanoSim

If the goal is not specified, only the former condition is applicable.■ The lower and upper optimization parameter values must be selected in a

way that the optimization root measurement passes for one of the two conditions, and fails for another.

Optional Parameter

The following parameters are optional:■ Maximum number of iterations■ Optimization parameter value error tolerance■ Optimization root measurement results error tolerance

Note: If an optional parameter's value is not specified, the default value is used.

The bisection process stops either when the difference between two successive root/parameter values is less than the corresponding error tolerance, or when the maximum number of iterations is exceeded—whichever occurs first.

NanoSim includes the error tolerance in a relation, and is used as a process-termination criterion.

Figure 37 shows an example of the binary search process, which the bisection algorithm uses. This example is appropriate for a setup-time analysis that tests for the presence of an output transition.

In this figure,■ A long setup time TS (= T2 - T1) results in a V(out) transition (a pass).■ A very short setup time (where the latch has not stabilized the input data,

before the clock transition) results in a fail value.■ The target value is a setup time that produces the V(out) value of 4.5 V

(0.9 * VDD). Finding the exact value is impractical, if not impossible, so specify an error tolerance to calculate a solution arbitrarily close to the target value.

■ The bisection algorithm performs tests for each specified boundary value, to determine the direction in which to pursue the target value after the first bisection. The lower boundary has a pass value, and the upper boundary has a fail value.



■ To start the binary search, specify the lower and upper boundaries. The program tests the point midway between the lower and upper boundaries.

If the initial value passes the test, the target value must be less than the tested value. The bisection algorithm moves the upper search limit to the value that it previously tested.

If the test fails, the target value must be greater than the tested value. Bisection moves the lower limit to the value that it previously tested.

■ The algorithm tests a value midway between the new limits.■ The search continues in this manner, moving one limit or the other to the last

midpoint, and testing the value midway between the new limits.■ The process stops when the difference between the latest test values is less

than or equal to the error tolerance that you specified. To normalize this value, multiply by the initial boundary range. The iteration process also stops when it reaches the maximum iteration number (the default value is 20).

Statement Syntax

See the syntax for the following:■ .MODEL Statement Syntax■ .TRAN Statement Syntax■ .MEASURE Statement Syntax

.MODEL Statement Syntax


.MODEL OptModelName OPT METHOD=BISECTION+[RELIN=value] [RELOUT=value] [ITROPT=value]


Table 102 .MODEL argument description


OptModelName Specifies the model. Refer to the HSPICE Simulation and Analysis User Guide for name information about specifying optimization models.



In HSPICE, the iteration process only terminates if one of the following conditions is satisfied:■ The maximum number of iterations reaches the ITROPT value■ Both the RELIN and the RELOUT condition are satisfied

The termination criterion is different from NanoSim’s approach. In NanoSim, the iteration process terminates if one of the following conditions is satisfied:■ The maximum number of iterations reaches the ITROPT value■ Either the RELIN or RELOUT condition is satisfied. The definition of satisfied

is if only the RELIN condition or the RELOUT condition is satisfied, and the iteration process stops and yields the optimized parameter.

METHOD Specifies the keyword to indicate the optimization method. For bisection, the method can only be BISECTION. NanoSim does not support the PASSFAIL optimization method.

OPT Specifies the keyword for performing optimization.

ITROPT Sets the maximum number of iterations. Typically, you need no more than 20 iterations to find a solution. Too many iterations can imply that the RELIN or RELOUT values are too small. Default=20.

RELIN Sets the relative input parameter (delta_par_val / MAX(par_val,1e-6)) for convergence. If all optimizing input parameters vary by no more than RELIN between iterations, the solution converges. RELIN is a relative variance test, so a value of 0.001 implies that optimizing parameters vary by less than 0.1% from one iteration to the next. Default=0.001.

RELOUT Sets the relative tolerance to finish optimization. For RELOUT=0.001, if the relative difference in the RESULTS functions (from one iteration to the next) is less than 0.001, optimization is finished. Default=0.001

Table 102 .MODEL argument description (Continued)




The syntax for a normal optimization specification to pass the parameters is as follows:

.PARAM ParamName=OptParFun (Initial, Lower, Upper)

With the bisection feature, the measure results for the Lower and Upper limits of the ParamName must be on the opposite side of the goal value in the .MEASURE statement. For the bisection method, the two initial measurements must pass for one limit and fail for the other limit. Bisection ignores the Initial value. The bisectional search applies to only one parameter.

Additionally Created Output Files for a Bisection Run

When using the NanoSim bisection feature, two files are additionally created. These two files are created only if the bisection feature is used:■ OPT_HSPICE_BISECTION.out (or OPT_HSPICE_BISECTION.fsdb)

contains the waveform created by the final bisection optimized parameter ■ *.mt0 contains the optimized value and all the post-processing

measurement statements

Reading the NanoSim Log File Iteration Report

The log file presents valuable information for debugging the bisection. The iteration process tells you at which point the NanoSim result begins diverging from the golden result. The log file in Figure 38 contains the same information that HSPICE generates when using the .option OPTLST=1 statement.



Figure 38 NanoSim bisection log file report

.TRAN Statement Syntax


.TRAN TranStep TranTime SWEEP OPTIMIZE=OptParFun+RESULTS=MeasureName MODEL=OptModelName


Table 103 TRAN argument description


OptParFun Specifies for the simulator which transfer function to use. This name must be identical to the name you specify in the .PARAM statement.



.MEASURE Statement Syntax


.MEASURE TRAN [MeasureName] [MeasureClause]+GOAL=GoalValue


MeasureName Specifies for the simulator which measurement statement is used to drive the bisection optimization. This name must be identical to the output MeasureName name.

OptModelName Specifies for the simulator which model to use. This name must be identical to the name given to the .MODEL statement.

Table 104 MEASURE argument description


MeasureName Specifies the name given to the measurement statement.

MeasureClause Specifies any measurement statement that is NanoSim-supported.

GoalValue Specifies the desired .MEASURE value. The error is calculated by ERRfun = (GOAL – result)/GOAL

Table 103 TRAN argument description (Continued)




Guidelines for the NanoSim Bisection Method

In order to use the bisection method, follow these guidelines:■ Bisection is an optimization using a binary search algorithm.

In order to iterate to the correct optimize values, NanoSim must simulate with high accuracy. Without accuracy the iteration continues, but yields the incorrect optimized values because the output starts to diverge with the true output transitions.

■ To use NanoSim for bisection optimization, more accurate settings are required than for a default NanoSim run.

The following is the suggested setting to run NanoSim using the bisection feature:

set_sim_eou sim=4 model=4

or, if you already know the instance from the input to the output, specify as follows:

set_sim_eou sim=3 model=3set_inst_cmd instance_from_input_to_output sim=6 model=4

■ NanoSim usually takes fewer iterations to converge to the optimized result than HSPICE, because it only requires either a RELIN or RELOUT condition to be satisfied (instead of both conditions).

You should use a smaller RELIN value than the HSPICE default setting to make sure the iteration process is accurate. The recommended value for RELIN is 0.0001 (1/10 of the HSPICE default setting). You should not need to modify RELOUT. The iteration process usually terminates with only the RELIN condition with good accuracy.

■ If the NanoSim bisection feature does not generate good accuracy, it is important to check the *.log file for the individual iteration process.

If the iteration process is different than HSPICE in the first five iterations, it is probably due to a bisection error. However, if the result diverges from HSPICE after 10 iterations, most probably it is because NanoSim is not accurate enough; therefore, you must apply more conservative settings to maintain the accuracy. Usually, when running the bisection feature, the



output transition is localized. It is very easy to detect the path from the input to the output—you can locally apply a high accuracy setting using the set_inst_cmd command.

Using NanoSim to Optimize the Setup Time for D-FFExample 103 illustrates a bisectional search to find the minimum setup time for a D flip-flop. The files in Example 104 show the results of this search. In this example NanoSim does not directly optimize the setup time, but extracts it from its relationship with the DelayTime parameter (the time before the data signal), which is the parameter to optimize.



Example 103 Input Listing******************************************** D Flip Flop Bisection Search for Setup Time ********************************************

***************** PWL Stimulus *****************vdata data gnd PWL+ 0ns 5v + '1ns+DelayTime' 5v + '1.5ns+DelayTime' 0v

************ CLOCK ************vclk clock gnd PWL+ 0s 0v + 3n 0v + 3.5n 5v

********************************************************** Specify DelayTime as the search parameter and provide ** the lower and upper limits. **********************************************************.Param DelayTime = Opt1 ( 0.0n, 0.0n, 4.0n )

***************************************************** Transient simulation with Bisection Optimization *****************************************************.Tran 1n 10n Sweep Optimize = Opt1+ Result = MaxVout $ Look at measure+ Model = OptMod

************************************** This measure finds the transition **************************************.Tran 1n 10n Sweep Optimize = Opt1+ Result = MaxVout $ Look at measure+ Model = OptMod

************************************** This measure finds the transition **************************************



param vih=5vMeasure Tran MaxVout Max v(D_Output) Goal = '0.9*vih'+ from=5ns to=10ns

************************************************* This measure calculates the setup time value *************************************************.Measure Tran SetupTime Trig v(Data) Val = 'vih/2' cross=1+ Targ v(Clock) Val = 'vih/2' cross=1

*********************** Optimization Model ***********************.Model OptMod Opt Method = Bisection relin=0.0001 relout=0.001 .lib './log013x.l' ss.lib './log013x.l' ss_2v.lib './log013x.l' mid_dio.lib './log013x.l' mid_res

.Global vdd gnd *---------------------------------------------------------* Main Circuit Netlist:*---------------------------------------------------------

v14 vdd gnd dc=5c10 vdd gnd c=35.96fc15 d_output gnd c=21.52fc12 dff_nq gnd c=11.73fc11 net31 gnd c=42.01f

c14 net27 gnd c=34.49fc13 net25 gnd c=41.73fc8 clock gnd c=5.94fc7 data gnd c=7.93fXi3 net25 net31 net27 dff_nq DFF l=0.13u wn=0.34u wp=0.3uXi6 data net31 INVXi5 net25 net27 INVXi4 clock net25 INVXi2 dff_nq d_output INV wp=0.3u wn=0.34u

*---------------------------------------------------------* Subcircuit definition*---------------------------------------------------------.subckt XGATE control in n_control out



m0 in n_control out vdd TP l=0.13u w=0.3um1 in control out gnd TN l=0.13u w=0.34u.ends.subckt INV in out wp=0.3u wn=0.34u l=0.13umb2 out in gnd gnd TN l=l w=wnmb1 out in vdd vdd TP l=l w=wp.ends.subckt DFF c d nc nq Xi64 nc net46 c net36 XGATEXi66 nc net38 c net39 XGATEXi65 c nq nc net36 XGATEXi62 c d nc net39 XGATEXi60 net722 nq INVXi61 net46 net38 INVXi59 net36 net722 INVXi58 net39 net46 INVc20 net36 gnd c=17.09fc15 net39 gnd c=15.51fc12 net46 gnd c=25.78fc4 nq gnd c=25.28fc3 net722 gnd c=19.48fc16 net38 gnd c=16.48f.ends

.end

See Figure 39 for a bisection example for three iterations.


Chapter 18: Optimizing Timing with Bisection FunctionsResults

Figure 39 Bisection example for three iterations

Results

The top plot in Figure 40 shows the relationship between the clock and the data pulses that determine the setup time. The bottom plot is the output transition.



Figure 40 Transition at minimum setup time

NanoSim reports the optimized parameter result in the *.mt0 file. The *.meas file contains all the measurement results and is fully backward-compatible with a NanoSim run without using the bisection feature. There is only one difference between the *.mt0 and *.meas file: the *.mt0 file contains one extra result that is the final value for the optimized parameter. This is consistent with the HSPICE method for reporting the optimized parameter.

Example 104 contains a sample of the *.mt0 file.

(The delaytime = 1.767639E-09 line is the optimized parameter.)

Example 104 NanoSim measurement file (.mt0) delaytime = 1.767639E-09 maxvout = 5.000000E+00 at = 5.000000E-09 from = 5.000000E-09

to = 1.000000E-08setuptime = 2.323600E-10 TARG = 3.250000E-09 TRIG = 3.017640E-09

NanoSim *.out and *.fsdb files contain all the waveform iterations. A new output file is created: OPT_HSPICE_BISECTION.out or OPT_HSPICE_BISECTION.fsdb. This *.out file contains only the final run with the optimized parameter.



The top plot in Figure 41 shows examples of early and late data transitions, and the transition at the minimum setup time. The bottom plot shows how the timing of the data transition affects the output transition. The following analysis statement produces these results:

Figure 41 Early and late data transition

This analysis produces the following results in Example 105:

Example 105 Analysis results*** parameter DelayTime = .000E+00 *** $ Early

setuptime= 2.0000E-09 targ= 3.5000E-09 trig= 1.5000E-09*** parameter DelayTime = 1.766E-09 *** $ Optimal

setuptime= 2.8120E-10 targ= 3.5000E-09 trig= 3.2188E-09*** parameter DelayTime = 5.000E-09 *** $ Late

setuptime= -3.0000E-09 targ= 3.5000E-09 trig= 6.5000E-09


1919Using the NanoSim-supported HSPICE Digital Vector

Format

This chapter describes how NanoSim uses the same run-set as HSPICE for simulation. HSPICE supports one digital vector format as the stimulus that differs from NanoSim’s digital vector format.

Overview

The HSPICE digital vector file consists of three parts:■ Vector Pattern Definition■ Waveform Characteristics■ Tabular Data

There are two methods to enable NanoSim to read-in an HSPICE digital vector file:

1. Using a Netlist Statement (HSPICE-compatible)

2. Using Command-line Options

This chapter contains the following topics:■ Using a Netlist Statement■ Using Command-line Options■ Defining Vector Patterns■ Defining Waveform Characteristics■ Using the cbc Option■ Overriding Parameters with the set_vec_opt Configuration Command


Chapter 19: Using the NanoSim-supported HSPICE Digital Vector FormatUsing a Netlist Statement

Using a Netlist Statement

For compatibility reasons, NanoSim supports the same netlist statement as HSPICE. This enables you to use the same run-set as HSPICE.


.vec ‘digital_vector_file’

The .vec statement can only be used with the HSPICE digital vector format. It does not support the NanoSim digital vector format.

Example 106 calls projectA.vec as the stimulus to NanoSim.

Example 106 .vec stimulus.vec ‘projectA.vec’

Using Command-line Options

NanoSim automatically checks the digital vector file format—either the NanoSim or HSPICE digital vector format.


-nvec digital_vector_file

Example 107 calls projectB.vec as the stimulus to NanoSim.

Example 107 -nvec stimulusnanosim -nvec projectB.vec . . .

Defining Vector Patterns

The Vector Pattern Definition defines the sequence (or order) of each vector stimulus, as well as individual characteristics. The following statements, which are described in the following sections (except the radix statement), can appear in any order. All keywords are case-sensitive:■ The enable Statement■ The io Statement■ The period Statement■ The radix Statement


Chapter 19: Using the NanoSim-supported HSPICE Digital Vector FormatDefining Vector Patterns

■ The tskip Statement■ The tunit Statement■ The vname Statement

The enable Statement

The enable statement specifies the controlling signal(s) of the bi-directional signal. The controlling signal(s) controls the direction of the bi-directional signal. This is required for all bi-directional signals.


enable signal_name(s) [mask]

Example 108 declares x and y are bi-directional signals. The first enable statement indicates that bi-directional signal x (as defined by the position of F) becomes output when signala is logic high. The second enable statement specifies that bi-directional bus y becomes output when signala is logic-low.

Example 108 enable exampleradix 144io ibbvname a x[3:0] y[3:0]enable a 0 F 0enable ~a 0 0 F


Table 105 enable statement argument descriptions


signal_name Specifies the name(s) of the controlling signal(s).

mask Defines the bi-directional signal(s) for which the enable statement applies. If it is not specified, the enable statement globally applies to all bi-directional signals.



The io Statement

The io statement defines the type of each signal. See Table 106 for keywords defining the signal type.

Example 109 defines rst and enb as the input signals, and a<0>, a<1>, a<2>, a<3> as the output signals:

Example 109 input signalsradix 11 4 vname rst enb a<[0:3]> io ii o

The period Statement

The period statement defines the time interval for the tabular data so that specifying the absolute time at every time point is not necessary. Thus, if a period statement is specified, the tabular data contains only signal values—not absolute times.

Table 106 io statement keywords

Keyword Definition

i Input used to simulate the circuit.

o Expected output used to compare with the simulated results.

b Bi-directional signal. Input signal is used to simulate the circuit; output signal is checked against the simulation results.



Example 110 defines the tabular data time interval as 10ps. The first row of tabular data (11 0000) is 0ps. The second row of the tabular data (10 1000) is 10ps:

Example 110 tabular data time intervalradix 11 4vname rst enb a<[0:3]>io ii otunit psperiod 10

11 000010 1000

The radix Statement

The radix statement specifies the number of bits associated with each vector. Valid values for the number of bits range from 1 to 4. Only one radix statement is allowed in one HSPICE digital vector file, and it must be the first non-comment line. See Table 107 for more details.

The following example illustrates two 1-bit signals followed by a 4-bit signal:

radix 11 4

The tskip Statement

The tskip statement specifies the absolute time field in the tabular data is skipped (ignored). In this way, the absolute time field of each row can be kept in the tabular data (ignored) when using the period statement.

Table 107 Valid value range for the number of bits

Radix Number of bits Number System Valid Digits

1 2 binary 0 - 1

2 4 -- 0 - 3

3 8 octal 0 - 7

4 16 hexadecimal 0 - F



Example 111 skips the absolute time (first column) specified in the tabular data:

Example 111 Skipping absolute timeradix 11 4vname rst enb a<[0:3]>io ii otunit psperiod 10tskip

0.0 11 00005.0 10 1000

The tunit Statement

The tunit statement defines the time unit in the digital vector file for period, tdelay, slope, trise, tfall, and absolute time. See Table 108 for acceptable time units. The default time unit is ns.

Example 112 specifies the time unit as a picosecond:

Example 112 picosecond time unitradix 11 4vname rst enb a<[0:3]>io ii otunit ps

Table 108 Keywords for tunit

Keyword Definition

fs femtosecond

ps picosecond

ns nanosecond

us microsecond

ms millisecond


Chapter 19: Using the NanoSim-supported HSPICE Digital Vector FormatDefining Waveform Characteristics

The vname Statement

The vname statement defines the name of each signal. If you define more than one vname statement, the last value overrides the previous value. There is no default name for a vname statement.

If vname is not specified, HSPICE uses V1, V2, V3, and so on, as the default signal names. This is not the case with NanoSim.

The vname name is required for each bit, and a single name may be associated with multiple bits (such as bus notation).

Example 113 shows the two 1-bit signal names are rst and enb, respectively. The one 4-bit signal name is a<0>, a<1>, a<2>, a<3>:

Example 113 vname 1-bit and 4-bit exampleradix 11 4vname rst enb a<[0:3]>

Defining Waveform Characteristics

The waveform characteristic defines various attributes for signals, such as rise time, fall time, and threshold for logic-high and logic-low. See the following statements that define these attributes:■ The out or outz Statement■ The tdelay, idelay, and odelay Statements■ The trise, tfall, and slope Statements■ The triz Statement■ The vih and vil Statements■ The voh and vol Statements■ The vref Statement■ The vth Statement

The out or outz Statement

The out or outz statement specifies the output resistance of each input signal for which the mask applies. Characters H and L are driven by a resistor with



the value specified with the outz or out statement. Numerals 1 and 0 are considered strong logic, and are not driven by a resistor. If you specify more than one out or outz statement to a signal, the last value overrides the previous value. The default value for the out or outz statement is 0.0.


out | outz output_resistance [mask]


The tdelay, idelay, and odelay Statements

The tdelay, idelay, and odelay statements define the delay time of the signal relative to the absolute time of each row in the tabular data. The idelay statement applies to the input signals, while the odelay statement applies to the output signals—the tdelay statement applies to both input and output signals. The tunit statement defines the time unit of these statements. You can specify more than one individual tdelay, idelay, or odelay statement. If more than one value applies to the same signal, the last value overrides the previous values. The default value is 0.


tdelay delay_time [mask]idelay delay_time [mask]odelay delay_time [mask]

Table 109 out | outz statement argument descriptions


output_resistance

Specifies the output resistance for the specified input signals.

mask Defines the signal(s) to which out or outz applies. If it is not specified, the output_resistance option globally applies to all input signals.



Example 114 defines the time delay for input signal rst as-10.0 ps, and the time delay for output bus a as 2.5 ps. Time delay for input signal enb defaults to 0.0 ps.

Example 114 Time delay inputradix 11 4vname rst enb a<[0:3]>io ii otunit psperiod 10idelay -10.0 10 0odelay 2.5 00 1

11 000010 1000


The trise, tfall, and slope Statements

The trise, tfall, and slope statements specify input signal rise time and fall time with the time unit defined by the tunit statement. The trise statement applies to the input signal rise time; the tfall statement applies to the input signal fall time; and the slope statement applies to both input signal rise time and fall time. You can use a mask to specify the signals to which the statement applies. If more than one value is specified for rise time or fall time to a signal, the last value overrides the previous value. The trise and tfall statements take precedence over the slope statement. The default value of the NanoSim rise time and fall time is 0.0.

HSPICE uses 0.1 ns as the default value for the trise, tfall, and slope statements.

Table 110 tdelay/idelay/odelay statement argument descriptions


delay_time Specifies the time delay for specified signals.

mask Defines the signal(s) to which tdelay, idelay, or odelay applies. If it is not specified, the delay_time option globally applies to all signals.




trise rise_time [mask]tfall fall_time [mask]slope slope [mask]


The triz Statement

The triz statement specifies the output impedance when the input signal (for which the mask applies) is in tri-state. The triz statement only applies to input signals. The default value for the triz statement is 1000 Meg. If you apply more than one triz statement to a signal, the last value overrides the previous value. The triz statement has no effect on the output signals.


triz output_impedance [mask]


Table 111 trise/tfall/slope statement argument descriptions


rise_time Specifies the rise time for specified signals.

fall_time Specifies the fall time for specified signals.

slope Specifies the rise time and fall time for specified signals.

mask Defines the signal(s) to which trise, tfall, or slope applies. If it is not specified, the rise_time, fall_time, or slope option globally applies to all input and output signals, respectively.

Table 112 triz statement argument descriptions


output_impedance

Specifies the output impedance for the specified input signals.



The vih and vil Statements

The vih statement specifies the logic-high voltage of each input signal to which the mask applies. The vil statement specifies the logic-low voltage of each signal to which the mask applies. Both vih and vil statements have no effect on the output signals. NanoSim detects the rail-to-rail design voltage supply. NanoSim sets vih to the maximum rail voltage and vil to the minimum rail voltage. Multiple voltage supplies are allowed. If you apply more than one individual vih or vil statement to a signal, the last value overrides the previous value.

HSPICE uses 3.3 as the vih default value and 0.0 as the vil default value.


vih logic_high_voltage [mask]vil logic_low_voltage [mask]


mask Defines the signal(s) to which triz applies. If it is not specified, the output_impedance option globally applies to all input signals.

Table 113 vih | vil statement argument descriptions


logic_high_voltage Specifies the logic-high voltage for specified input signals.

logic_low_voltage Specifies the logic-low voltage for the specified input signals.

mask Defines the signal(s) to which vih and vil applies. If it is not specified, the logic_high_voltage or logic_low_voltage options globally apply to all input signals.

Table 112 triz statement argument descriptions (Continued)




The voh and vol Statements

The voh and vol statements specify the logic-high and logic-low voltages of each output signal to which the mask applies. If both voh and vol are not defined, NanoSim uses vth as the threshold voltage to determine the logic-high and logic-low state. The default value of voh is set to vih. The default value of vol is set to vil. If you apply more than one logic threshold to a signal, the last value overrides the previous value.

HSPICE uses fixed values for voh and vol, which are 3.3 and 0.0 respectively.


voh logic_high_voltage [mask]vol logic_low_voltage [mask]


The vref Statement

The vref statement specifies the reference voltage name for each input signal to which the mask applies. The vref statement applies only to the input signals. The default name for the vref statement is 0.


vref ref_name [mask]

Table 114 voh/vol statement argument descriptions


logic_high_voltage Specifies the voltage of logic-high for the specified output signals.

logic_low_voltage Specifies the voltage of logic-low for the specified output signals.

mask Defines the signal(s) to which voh or vol applies. If it is not specified, logic_high_voltage or logic_low_voltage globally applies to all output signals.



Example 115 defines the reference voltage for input signal rst as 0, and the reference voltage for input signal enb as vss.

Example 115 Reference voltage for inputradix 11 4vname rst enb a<[0:3]>io ii otunit psperiod 10idelay -10.0 10 0odelay 2.5 00 1vref 0 10 0vref vss 01 0

When reading into the netlist, the voltage source for input signals rst and enb are

Vrst rst 0 pwl . . . Venb enb vss pwl . . .


The vth Statement

The vth statement specifies the logic threshold voltage of each signal to which the mask applies. The threshold voltage is used to decide the logic state of NanoSim’s simulation output signals for comparison against the expected output signals. The default value for vth is (vil + (vih - vil) * 0.5). If you apply more than one vth statement to a signal, the last value overrides the previous value.

Table 115 vref statement argument descriptions


ref_name Specifies the reference voltage name for the specified input signals.

mask Defines the signal(s) to which vref applies. If it is not specified, the reference voltage name globally applies to all input signals.


Chapter 19: Using the NanoSim-supported HSPICE Digital Vector FormatUsing the cbc Option

HSPICE uses 1.65 as the default value for vth.


vth threshold_vol [mask]


Using the cbc Option

The context-based control (CBC) option specifies that signal values specify bi-directional signal directions. If the vector is 0, 1, or Z, the bi-directional signal behaves as an input signal. If the vector is specified with L, H, or X, the bi-directional signal behaves as an output signal, as shown in Table 117.


option cbc

Table 116 vth statement argument descriptions


threshold_vol Specifies the threshold voltage for the specified output signals.

mask Defines the signal(s) to which vth applies. If it is not specified, threshold_vol globally applies to all output signals.

Table 117 Specifications for bi-directional signals using the cbc option

Input Output

0 L

1 H

Z X


Chapter 19: Using the NanoSim-supported HSPICE Digital Vector FormatOverriding Parameters with the set_vec_opt Configuration Command

Example 116 defines a, z, and b as the bi-directional signals. At 0 ns, signal a behaves as output, and signals z and b behave as input. At 10 ns, signal a behaves as input, and signals z and b behave as output.

Example 116 bi-directional signalsradix 1 1 1io b b bvname a z boption cbctunit nsperiod 10

L 1 10 L H

Overriding Parameters with the set_vec_opt Configuration Command

Stimulus parameters are defined in the HSPICE digital vector file. The NanoSim set_vec_opt configuration command can be used to override the parameters for the specified input nodes using the no= option. The set_vec_opt configuration command can be used to override the parameters for the specified input, output, and bi-directional nodes in the specified HSPICE digital vector files using the file= option. The specified value overrides any global value set in the HSPICE digital vector file.

For more details about this command, see the section Overriding with the set_vec_opt Configuration Command in Chapter 7, Using the VCD and EVCD Direct-read Features, or see the NanoSim Command Reference.


Chapter 19: Using the NanoSim-supported HSPICE Digital Vector FormatOverriding Parameters with the set_vec_opt Configuration Command


2020Defining Blocks with the .ALTER Statement

This chapter describes the .ALTER statement, which is supported by NanoSim to improve NanoSim and HSPICE compatibility. With .ALTER statement support, NanoSim reads HSPICE-supported .ALTER statements without any modifications. The implementation of the .ALTER statement in NanoSim is compatible to the HSPICE-supported .ALTER statement.

Overview

HSPICE supports the .ALTER statement to define blocks within the netlist that can be used to re-run the simulation with different parameters. Using .ALTER in NanoSim, the simulation no longer requires the creation of an additional run directory. This process is commonly used in cell and memory characterization flows.

This chapter contains the following topics:■ Reviewing the .ALTER Flow■ Altering the Design Variable and Subcircuits■ Using Multiple .ALTER Statements

Reviewing the .ALTER Flow

NanoSim reads the input file until the initial .ALTER statement and performs the analysis up to that .ALTER statement.

After the first simulation completes, NanoSim reads the input in one of the following ways:■ between the first .ALTER statement and the following .ALTER statement■ between the first .ALTER statement and the .END statement


Chapter 20: Defining Blocks with the .ALTER StatementReviewing the .ALTER Flow

These statements modify the input netlist file. NanoSim then simulates the circuit one more time. See Figure 42 for a graphic representation of the .ALTER flow.

Figure 42 The .ALTER flow

The .ALTER sequence (or block) can contain the following statements:■ Element (except source)■ .MODEL ■ .PARAM

■ .LIB and .DEL LIB ■ .INCLUDE

■ .IC and .NODESET■ .OPTIONS

■ .TEMP


Chapter 20: Defining Blocks with the .ALTER StatementAltering the Design Variable and Subcircuits

■ .alias

■ .TRAN

Altering the Design Variable and Subcircuits

When you alter design variables and subcircuits, the following rules apply:■ A new statement replaces an old statement if the name of a new element,

.MODEL statement, or subcircuit definition is identical to the name of an original statement of the same type.

■ Element and .MODEL statements within a subcircuit definition can be changed, and a new element or .MODEL statement can be added to a subcircuit definition. Topology modifications to subcircuit definitions should be placed into libraries and added with a .LIB statement and deleted using a .DEL LIB statement.

■ If a new .PARAM statement name in the .ALTER module is identical to a previous parameter name, the newly assigned value replaces the old value.

■ If element or model parameter values are parameterized with an .ALTER statement, these parameter values must be changed through the .PARAM statement. Do not use numerical values to describe the elements or model parameter.

■ .LIB statements within a file called with an .INCLUDE statement cannot be revised by .ALTER processing. But, an .INCLUDE statement within a file called with a .LIB statement can be accepted by .ALTER processing.

■ In the .IC or .NODESET statements, if the new node name is identical to the original node name of the same type, the value assigned to that node replaces the old value.

Using Multiple .ALTER Statements

When using multiple .ALTER statements, the following procedure occurs:

1. NanoSim reads the input file and performs the analysis until the initial .ALTER statement, for the first simulation run.


Chapter 20: Defining Blocks with the .ALTER StatementUsing Multiple .ALTER Statements

2. NanoSim reads the input between one of the following, after the initial simulation completes: - the initial .ALTER statement and the following .ALTER statement- the initial .ALTER statement and the .END statement

Explanation: NanoSim uses these statements to modify the input netlist file.

3. NanoSim simulates the circuit again.

Explanation: For each additional .ALTER statement, NanoSim performs the simulation that precedes the previous .ALTER statement.

4. NanoSim again simulates using the input between one of the following: - the current .ALTER statement and the following .ALTER statement- the current .ALTER statement and the .END statement


2121Generating New Stimuli with the .STIM Statement

This chapter describes the .STIM statement, which enables you to “reuse simulation output as input stimuli” (see further details in the HSPICE Simulation and Analysis User Guide).

Overview

When you want to generate new stimuli from your simulation output results, you can use the simulation output values that become new stimuli for an additional (subsequent) simulation. The new stimuli can be used for either a NanoSim simulation or an HSPICE simulation. The new stimuli is displayed in one of two formats: HSPICE VEC or HSPICE PWL.

The .STIM statement generates two types of output files: ■ PWL Source (.pwl$_tr#)■ Digital Vector (.vec$_tr#)

This chapter contains the following topics:■ Using .STIM Syntax Format■ Using VEC Syntax Format■ Generating Stimuli Files■ NanoSim-generated VEC File■ NanoSim-generated PWL File


Chapter 21: Generating New Stimuli with the .STIM StatementUsing .STIM Syntax Format

Using .STIM Syntax Format

The .STIM syntax format is identical to the HSPICE syntax format. See the following PWL syntax:

.stim [tran] PWL [filename=output_filename]+ [name1 = ] signal1 [node1 =positive_term_name]+ [node2 = negative_term_name]+ [[name2 = ] signal2 [node1 = positive_term_name] + [node2 = negative_term_name] ..]+ [ [[from = val] [to = val] [npoints = val]]|indepvar =+ [(]t1 [t2 ..[)]] ]


tran Transient simulation.

filename Keyword: output file name. If you do not specify a filename, NanoSim uses the netlist file prefix.

name<i> PWL source name that you specify. The name must start with V (for a voltage source) or I (for a current source).

signal<i> Output variable that you specify. The signal can be:

- Node voltage

- Element current

- Parameter string. If you use a parameter string, you must specify name1 For example: v(1), i(r1), v(2,1), par('v(1)+v(2)')

node1 Keyword: positive terminal node name. If omitted, the node/element name is used.

node2 Keyword: negative terminal node name. If omitted, "0" is used.

from Keyword: specifies the simulation result time-to-start output into stimulus. The default value is the start time in the waveform file. The default time unit is seconds.


Chapter 21: Generating New Stimuli with the .STIM StatementUsing VEC Syntax Format

Using VEC Syntax Format

See the following VEC syntax:

.stim [tran] VEC [filename=output_filename] vth= val+ vtl= val [voh= val] [vol= val]+ [name1 = ] signal1 [[name2 = ] signal2 ..] + [[[from = val] [to = val] [npoints = val]] |+ indepvar = [(]t1 [t2 ..[)]]]

to Keyword: specifies the simulation result time-to-end output into stimulus. The default value is the end time in the waveform file. The default time unit is seconds.

If the from value is greater than the to value (from > to), the two values are swapped and a warning message is generated. For example, If from=10ns to=0ns, then from=0ns to=10ns

npoints Keyword: the number of output time points. The default value is (stimulus time interval)/(waveform file time resolution).

indepvar Keyword: specifies dispersed (independent-variable) time points.

You must specify dispersed time points in increasing order.


name<i> Signal name that you specify. The name must start with V (for a voltage source).

filename Keyword: output file name. If you do not specify a filename, NanoSim uses the netlist file prefix.



Chapter 21: Generating New Stimuli with the .STIM StatementUsing VEC Syntax Format

signal<i> Output variable that you specify. The signal must be a node voltage.

from Keyword: specifies the simulation result time-to-start output into stimulus. The default value is the start time in the waveform file. The default time unit is seconds.

to Keyword: specifies the simulation result time-to-end output into stimulus. The default value is the end time in the waveform file. The default time unit is seconds.

If the from value is greater than the to value (from > to), the two values are swapped and a warning message is generated.

For example, If from=10ns to=0ns, then from=0ns to=10ns

npoints Keyword: the number of output time points. The default value is (stimulus time interval)/(waveform file time resolution).

indepvar Keyword: specifies dispersed (independent-variable) time points.

You must specify dispersed time points in increasing order.

vth Keyword: high-voltage threshold.

vtl Keyword: low-voltage threshold.

voh High voltage for the output vectors. The value is not used for stimuli generation. If voh is specified, the voh statement appears in the vector file.

vol Low voltage for the output vectors. The value is not used for stimuli generation. If vol is specified, the vol statement appears in the vector file.



Chapter 21: Generating New Stimuli with the .STIM StatementGenerating Stimuli Files

Generating Stimuli Files

For each .STIM statement in the netlist, an ASCII file is generated. (Note that the HSPICE convention is followed for file name generation.) See the following stimuli file examples:

Example 117 generates the mystim.pwl0_tr0 stimuli file:

Example 117 The mystim.pwl0_tr0 stimuli file.STIM tran PWL filename=mystim V(cout) V(s_0_) from=10n to=600n

Example 118 generates the mystim.pwl1_tr0 stimuli file:

Example 118 The mystim.pwl1_tr0 stimuli file.STIM tran PWL filename=mystim V(n1) V(n2) from=0n to=800n + npoints=81

Example 119 generates the newstim.vec0_tr0 stimuli file:

Example 119 The newstim.vec0_tr0 stimuli file.STIM tran VEC filename=newstim vth=2.3 vtl=1 V(cout) v(s_1_) + indepvar=10n 20n 30n 40n 50n 60n

See Figure 43 for a graphic representation of the stimuli files. The red text highlights the stim_number in the netlist—the sequence (order) of the stimuli files. The blue text highlights the output_name—if not specified, the netlist file name (without the .sp or .spi postfix) is used:


Chapter 21: Generating New Stimuli with the .STIM StatementNanoSim-generated VEC File

Figure 43 mystim.spi netlist stimuli files

NanoSim-generated VEC File

See Example 120 for a VEC file sample. The .stim tran vec filename=tmp vth=0.9 vtl=-0.9 vol=3 v(a) v(gnd) from =

.STIM tran PWL +V(cout)V(s_0_) from=10n +to=600n

mystim.pwl0_tr0

mystim.spi Stimuli Files

.STIM tran PWL +V(n1) V(n2) from=0n to=800n +npoints=81

mystim.pwl1_tr0

.STIM tran VEC +filename=newstim vth=2.3 +vtl=1 V(cout) v(s_1_) +indepvar=10n 20n 30n 40n 50n +60n

newstim.vec0_tr0


Chapter 21: Generating New Stimuli with the .STIM StatementNanoSim-generated VEC File

10ns to = 80ns npoints = 10 statement results in the following tmp.vec0_tr0 file:

Example 120 NanoSim-generated VEC File; VEC File ; ---------------------------------------------------------------------;| |;| NanoSim Version V-2004.06 |;| SN:P20040602-SunOS_5 |;| Machine Name:omicron |;| Copyright (c) 2004 Synopsys Inc., All Rights Reserved. |;| |; --------------------------------------------------------------------;;Built by nsmgr in " 20040602_sparcOS5_ns_main " on Thu Jun 3 02:22:16 PDT 2004radix 1 1 vname va v0 tunit ns vol 3; Tabular Data Section 10.0000 x x 17.7778 x x 25.5556 x x 33.3333 1 x 41.1111 x x 48.8889 0 x 56.6667 x x 64.4444 x x 72.2222 x x 80.0000 x x


Chapter 21: Generating New Stimuli with the .STIM StatementNanoSim-generated PWL File

NanoSim-generated PWL File

See Example 121 for a PWL file sample. The stim tran pwl filename = tmp vaaa=v(a) node1=b node2=c v(a) i(r1) indepvar= 5ns 24ns 81ns statement results in the following tmp.pwl0_tr0 file:

Example 121 NanoSim-generated PWL File*PWL source* ---------------------------------------------------------------------*| |*| NanoSim Version V-2004.06 |*| SN:P20040602-SunOS_5 |*| Machine Name:omicron |*| Copyright (c) 2004 Synopsys Inc., All Rights Reserved. |*| |* ---------------------------------------------------------------------**Built by nsmgr in " 20040602_sparcOS5_ns_main " on Thu Jun 3 02:22:16 PDT 2004vaaa b c PWL+ 5n 9.500000e-01+ 24n 0.000000e+00+ 81n 5.900000e-01va a 0 PWL+ 5n 9.500000e-01+ 24n 0.000000e+00+ 81n 5.900000e-01ir1 r1 0 PWL+ 5n 9.549000e-03+ 24n 1.260000e-04+ 81n 5.776000e-03

Options

The stimuli generator can be used within NanoSim, and as a stand-alone utility. The stand-alone utility requires (1) .STIM statement(s), and (2) the waveform file(s).

The command-line for the stand-alone stimuli generator is:

stim -n <netlist_1> <netlist_2> ... -s <waveform_file_1> <waveform_file_2> ..



The number of waveform files may be larger than 1, if the simulation output is saved in the split files. Note that the split file sequence (order) must be followed.

For example,

stim -nspice net.sp -s nanosim.out nanosim1.out




2222Using Diverse NanoSim-Supported HSPICE Features

There are several HSPICE-compatible features that do not fall under the main features documented in this part of the User Guide. This chapter describes these features.

Overview

This chapter contains the following topics:■ Using the PAR() Function■ Using X() or ISUB () Functions to Probe Subcircuit Currents

Using the PAR() Function

NanoSim supports output variable definitions using algebraic expressions (compatible with HSPICE.probe and .measure statements) . See the HSPICE Command Reference Manual for detailed syntax and examples.

For PAR( ) function support—when a hierarchy name is assigned to PAR( )—NanoSim reports the entire hierarchy while HSPICE aliases the hierarchy in the *.st0 file.

Using X() or ISUB () Functions to Probe Subcircuit Currents

NanoSim supports subcircuit current probing capability using X() or ISUB() functions. Function X() or ISUB() returns the total current flowing into a subcircuit branch, including all lower-level subcircuit hierarchies. This function can be used in the following HSPICE-supported analysis statements .PRINT, .PROBE, and .MEASURE. The syntax of the function follows:


Chapter 22: Using Diverse NanoSim-Supported HSPICE FeaturesUsing X() or ISUB () Functions to Probe Subcircuit Currents

X(subcircuit_path.subcircuit_pin_name) ORISUB(subcircuit_path.subcircuit_pin_name)

For this syntax, subcircuit_path specifies the full hierarchical path to the subcircuit, and subcircuit_pin_name specifies the pin name in the subcircuit. The pin must be an external pin in a subcircuit definition or a global pin specified with the .GLOBAL statement. See Example 122 for a clear description.

Example 122 Subcircuit current probe.subckt sb1 node1 node2 clrr1 node1 node2 1kc1 clr node2 1u.ends

x1 i1 i2 0 sb1

.print x(x1.node1) combine=PAR('x(x1.clr)+i(x1.r)')


Part: 4 Appendices

Part 4 of this guide contains the appendices.


:


AAOutput File Descriptions and Samples

This appendix provides you with various types of output file samples.

The .rcxt File

The simulation tool reports active nodes whose voltage changes exceed the user-defined threshold to the .rcxt file. The .rcxt file uses the StarRCXT netlist format so that it can be read directly by StarRCXT.

The .rcxt file is divided into two main sections: ■ Header

This section displays the output format, and rcxt_hierid data. ■ Active node information

This section displays the total number of active nodes reported in the file.

Sample .rcxt File

Example 123 lists active nodes as reported by the report_node_active configuration command.

Example 123 Active nodes in StarRCXT format* Report active nodes in StarRCXT format.* rcxt_hierid = /NETS:xi0/intNETS:in* number of pre-layout active nodes reported in the file:2* number of pre-layout nodes checked for activeness:28


Appendix A: Output File Descriptions and SamplesSample .log File

Sample .log File

When you run a NanoSim simulation, you will see many simulation messages scroll by. These messages contain information on circuit partitioning, DC initialization, reported errors, and much more.



The nanosim .log file contains a record of the simulation messages, as shown in Example 124:

Example 124 NanoSim .log file sample--------------------------------------------------------| || NanoSim Version 2002.03_Release || SN: P20000805-SunOS_5 || Copyright (c) 2001 Synopsys Inc., All Rights Reserved. || | -------------------------------------------------------- Command line options: -n dcpath.spi adder.cmd -c cfg_dcpath -o dcpath Initializing system messages took 0.040 s Installing interactive/configuration commands ...Installing commands took 0.130 s Start netlist compilation at Thu Aug 10 11:11:36 2000 Compiling "dcpath.spi"Compiling "cmos35.mod"Compiling "adder.cmd" Parsing netlist finished in 0 secondsBuilding instance tree finished in 0 seconds Finish netlist compilation at Thu Aug 10 11:11:36 2000 Netlist compilation took 0.010 sBuilding node/element arrays took 0.880 s Reading configuration files ...Reading configuration files took 0.000000 s



# of CMOS elements : 166# of dc voltage sources : 1# of stimulus elements : 1# of elements : 168# of used elements : 167# of nodes : 83# of subckt : 8# of top-level instances : 8# of Verilog signals (including aliases) : 0 Circuit partitioning ... Among 37 stages, there are: 37 pwl stages 0 pwl and grouped stages 0 analog stages 0 analog and grouped stages 0 rc stages 0 ud stages0 ADFMI functional model stages 4 nodes in the largest pwl stage 0 nodes in the largest digital stage 37 stages (37 pwl/analog stages) with 0-9 nodes Among 83 nodes, there are: 83 pwl nodes 0 analog (accurate) nodes 0 rc nodes 0 ud nodes 0 cut nodes 0 mem_cut nodes 0 no_clamp nodes 72 nodes in stages 11 voltage source nodes 2 constant nodes Among 168 elements, there are: 166 elements in stages 166 pwl elements 0 synchronous elements 0 SMS elements



0 analog (accurate) elements 0 rc elements 0 ud elements 0 ADFMI functional model elements 0 mna elements 0 mos transistors identified as keepers 164 mos transistors need Subthreshold current 0 keepers removed 0 keepers reduced Circuit partitioning took 0.000 sConstructing matrix ...Matrix ordering and construction took 0.000 s After reading configuration file(s), 172 signals are identified to be printed: 83 logic signals 83 voltage signals 6 node current signals, including: 2 node inst. current signals 2 node RMS current signals 2 node AVG current signals Statistics of memory used for signal printing:229248 bytes allocated in total, including:48008 bytes allocated for node current/voltage/logic signals248 bytes allocated additionally for current printing88008 bytes allocated additionally for node current signals92984 bytes allocated additionally for element branch current signals

Levelizing stages ...Levelizing stages took 0.000 sDC initialization ... Finishing initialization (level 0 -- 6)0 dynamic stages assigned in DC Initialization Number of residual dc events scheduled : 0Number of ic nodes scheduled : 0DC initialization took 0.010 s Simulation begins in pwl mode ...



Simulation time resolution (transistor) : 1.000e-02 nsSimulation ends at 800.000 ns Simulation took 1.040 s Current information calculated over the intervals: 0.00000e+00 - 8.00100e+02 ns Node: gnd Average current : 4.11595e+02 uA RMS current : 1.39364e+03 uA Current peak #1 : 3.68430e+04 uA at 6.50000e+02 ns Current peak #2 : 3.17960e+04 uA at 3.30000e+02 ns Current peak #3 : 2.61720e+04 uA at 4.90000e+02 ns Current peak #4 : 2.57030e+04 uA at 1.70000e+02 ns Current peak #5 : 2.15570e+04 uA at 2.50000e+02 ns Node: vdd Average current : -4.21698e+02 uA RMS current : 1.41583e+03 uA Current peak #1 : -3.68430e+04 uA at 6.50000e+02 ns Current peak #2 : -3.17960e+04 uA at 3.30000e+02 ns Current peak #3 : -2.61720e+04 uA at 4.90000e+02 ns Current peak #4 : -2.57870e+04 uA at 1.70000e+02 ns Current peak #5 : -2.15570e+04 uA at 2.50000e+02 ns Simulation time resolution (transistor) : 1.000e-02 nsNumber of PWL matrix solutions : 11781Number of PWL MOS model lookups : 52828Number of time steps : 11781Number of iterations : 0Number of rejected time steps : 3 Global simulation parameters used: SPD 0.5V ASPD 0.1VSIM_DESV 0.33V SIM_AESV 0.165VVDS_MIN 7.27228e-05V AVDS_MIN 1e-08VSSC (steady state current) 0.1uASUBI (subthreshold current) 1uADC CURRENT 1uA



8.0 real 2.0 user 0.0 sys No errors reported in the .err file (dcpath.err)

The following descriptions provides further explanation of some sections of the sample .log file; it does not include the formal syntax.

Warning Messages and the .log File

Table 118 defines terms you might find in the .log file or in a warning message.

Dangling Nodes Detected

When the simulator detects dangling nodes, it prints a warning message in the

.log file. In Example 125, the following line reports 12 dangling nodes:

Example 125 Dangling nodes messagenanosim: WARNING: There are 12 dangling nodes. Please view the file nanosim.dng for the node names.

The nanosim.dng file contains a list of these dangling nodes. (For a description of dangling nodes, see the nanosim.dng section.)

Table 118 Warning messages

Term Definition

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.

There are ten nodes that are set to U by the simulator before DC initialization. See the nanosim.dcu file for the node names. NOTE: All unconnected nodes are removed by the simulator.

dangling There are eight dangling nodes that are displayed in the nanosim.dng file and the .dcu file.

floating A node is defined as floating if there is no conducting path from a voltage source to the node.



Netlist Compilation Statistics

This section provides several netlist compilation statistics, as shown in Example 126.

Example 126 Netlist compilation stats# of CMOS elements : 166# of dc voltage sources : 1# of stimulus elements : 1# of elements : 168# of used elements : 167# of nodes : 83# of subckt : 8# of top-level instances : 8# of Verilog signals (including aliases) : 0

Some of these statistics are described here (not all are present in Example 126):■ # of elements

This is a summation of all the elements listed above the current position in the log file (in the example above, CMOS, dc voltage sources, and stimulus).

■ # of capacitors from netlist

This is the total number of capacitors from the netlist, which is then divided into the following categories:

■ # of Ground CAPS from netlist

This number is not added to the total number of elements shown in the # of elements in Example 126.

■ # of Coupling CAPS from netlist

This is the number of capacitors not connected to ground. They are included in the total number of elements shown in the # of elements in Example 126.

■ # of Coupling CAPS from netlist and converted diodes

This section lists the following details about the coupling capacitors:■ # of Coupling CAPS kept■ This is the number of coupling capacitors and converted diodes that are

actually simulated as floating capacitors (see the .fcap file).



■ # of Coupling CAPS put into SMS mode

This is the number of coupling capacitors simulated in the SMS mode. Using the SMS mode simulates these capacitors faster than if they had been simulated as true floating capacitors.

■ # of Coupling CAPS split to ground

This is the number of coupling capacitors that are split to ground and simulated as ground capacitors.



Circuit Partitioning and Autodetection Results

Example 127 lists circuit partitioning and auto-detection results as shown in the following sample:

Example 127 Circuit partitioning exampleCircuit partitioning ...

Among 37 stages, there are: 37 pwl stages 0 stages are grouped 0 rc stages 0 ud stages 0 ADFMI functional model stages 4 nodes in the largest pwl stage 0 nodes in the largest digital stage 37 stages (37 PWL stages) with 0-9 nodes Among 83 nodes, there are: 83 pwl nodes 0 analog (accurate) nodes 0 rc nodes 0 ud nodes 0 cut nodes 0 mem_cut nodes 0 no_clamp nodes 72 nodes in stages 11 voltage source nodes 2 constant nodes Among 168 elements, there are: 166 elements in stages 166 pwl elements 0 synchronous elements 0 SMS elements 0 analog (accurate) elements 0 rc elements 0 ud elements 0 ADFMI functional model elements 0 mna elements 0 mos transistors identified as keepers 0 keepers removed 0 keepers reduced



Circuit partitioning took 0.010 s

Most of the node types listed should be fairly straightforward. For information on the nodes listed in the is_cut and is_mem_cut categories, see the man page descriptions of the set_node_atcut, set_node_memcut, and set_node_vppcut configuration commands.

See the following DC Initialization results sample in Example 128:

Example 128 DC Initialization Results sampleFinishing initialization (level 0 -- 6)0 dynamic stages assigned in DC Initialization

Number of residual dc events scheduled : 0Number of ic nodes scheduled : 0DC initialization took 0.010 s

This segment provides the following information on DC initialization, as shown in :■ Number of dynamic stages

If a stage has more than 50 nodes, the simulator tries to use dynamic stages to speed up the simulation. The number of dynamic stages are reported after DC initialization. (See the set_stage_size configuration command for details.)

■ Number of residual dc events

If the simulator cannot find a stable DC state for a node after several iterations, the node is scheduled to time 0 to be solved by transient analysis. The number of these unstable nodes is reported on this line.

■ Number of ic nodes scheduled

The simulator also schedules all nodes initialized by set_node_ic (or the .IC SPICE statement) to time 0 to find the correct circuit state after the state forced by set_node_ic is released at time 0.

Simulation Times

Simulation time results (in seconds) are listed near the bottom of the .log file:


Appendix A: Output File Descriptions and SamplesThe .out File

6.0 real 0.0 user

0.0 sys

These values represent three different categories of time:■ 6.0 real = the total elapsed time■ 0.0 user = the CPU time■ 0.0 sys = the system I/O time

Reported ErrorsThe last line in the file shows the total number of errors reported to the

.err file:

No errors reported in the .err file (dcpath.err).

Errors are likely to occur when using vector comparison or some circuit diagnostic commands.

The .out File

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.

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



Sample .out File

Example 129 is a sample .out file:

Example 129 .out file sample;! output_format 2002.03; header 199477086; --------------------------------------------------------;| |;| NanoSim Version 2002.03_Release |;| SN: P061000-SunOS_5 |;| Copyright (c) 2001 Synopsys Inc., All Rights Reserved. |;| |; --------------------------------------------------------;

;;.vdd 5.time_resolution 0.1.current_resolution 1e-06.voltage_resolution 0.01; tentative simulation_time 20.high_threshold 3.5.low_threshold 1.5.nnodes 83.nelems 168.extra_nodes 0.bus_notation [ - ].hier_separator ..case S.index v(gnd) 1 v.index gnd 2 l.index i(gnd) 3 i.index I(gnd) 5 I.index I_rms(gnd) 6 I_rms.index v(vdd) 7 v.index vdd 8 l.index i(vdd) 9 i.index I(vdd) 11 I.index I_rms(vdd) 12 I_rms.index v(x2.x2.n3) 13 v.index x2.x2.n3 14 l.index v(x2.x2.n2) 15 v.index x2.x2.n2 16 l.index v(x2.x2.n4) 17 v.index x2.x2.n4 18 l



.index v(x2.x1.n3) 19 v

.index x2.x1.n3 20 l









.index v(x2.p) 29 v

.index x2.p 30 l

.index v(x2.n2) 31 v

.index x2.n2 32 l


.index x2.n1 34 l

.index v(x2.b) 35 v

.index x2.b 36 l

.index v(x2.a) 37 v

.index x2.a 38 l

.index v(x2.bn) 39 v

.index x2.bn 40 l

.index v(x2.an) 41 v

.index x2.an 42 l

.index v(x2.k) 43 v

.index x2.k 44 l

















.index v(x3.p) 61 v

.index x3.p 62 l


.index x3.n2 64 l


.index x3.n1 66 l



.index v(x3.b) 67 v

.index x3.b 68 l

.index v(x3.a) 69 v

.index x3.a 70 l


.index x3.bn 72 l


.index x3.an 74 l

.index v(x3.k) 75 v

.index x3.k 76 l

















.index v(x4.p) 93 v

.index x4.p 94 l


.index x4.n2 96 l


.index x4.n1 98 l

.index v(x4.b) 99 v

.index x4.b 100 l

.index v(x4.a) 101 v

.index x4.a 102 l


.index x4.bn 104 l


.index x4.an 106 l

.index v(x4.k) 107 v

.index x4.k 108 l



















.index v(x1.p) 125 v

.index x1.p 126 l


.index x1.n2 128 l


.index x1.n1 130 l

.index v(x1.b) 131 v

.index x1.b 132 l

.index v(x1.a) 133 v

.index x1.a 134 l


.index x1.bn 136 l


.index x1.an 138 l

.index v(x1.k) 139 v

.index x1.k 140 l

.index v(n3) 141 v

.index n3 142 l

.index v(n2) 143 v

.index n2 144 l

.index v(n1) 145 v

.index n1 146 l

.index v(cout) 147 v

.index cout 148 l

.index v(cin) 149 v

.index cin 150 l

.index v(a[3]) 151 v

.index a[3] 152 l

.index v(b[3]) 153 v

.index b[3] 154 l

.index v(s[3]) 155 v

.index s[3] 156 l


.index a[2] 158 l


.index b[2] 160 l


.index s[2] 162 l




.index a[1] 164 l


.index b[1] 166 l


.index s[1] 168 l


.index a[0] 170 l


.index b[0] 172 l


.index s[0] 174 l0173 0171 0169 0167 0165 0163 0161 0

...

7 5001 0174 0172 0170 0168 0166 0; file closed at 2.000000ns; trailer 837962407

Line Format

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



NullA blank line can appear anywhere and is ignored by the waveform display tools. It can contain spaces and tabs.

Semicolon LinesA 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 those that are 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 NanoSim is piecewise-linear. Two voltages in the same timestamp indicate a voltage transient that occurs too quickly to be resolved, given the .out file time resolution.

Period LinesLines that begin with a period (.) contain keywords followed by related values.

KeywordsAll of the keywords,except for index, can be used only in the definition section. The index lines can appear in the data section, in addition to the definition section. The keywords and associated values are defined in Table 119.

Table 119 The .out file keywords and values

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, this keyword 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 number_of_extra_nodes

Total extra power node number.

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.

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

Table 119 The .out file keywords and values (Continued)




The following syntax shows the complete format for the keyword index:

name_index_pair ::= name index;index::=integer;I (SIGNAL_name) | name::= SIGNAL_name |v (SIGNAL_name) | i (SIGNAL_name) |I# (SIGNAL_name) | di/dt# (SIGNAL_name) |I_rms (SIGNAL_name) | di/dt (SIGNAL_name) |i# (SIGNAL_name) |I_rms# (SIGNAL_name)|m (SIGNAL_name) |

SIGNAL_name::=valid element/node name defined in the circuit netlist.

#::= integer giving valid circuit element branch index (1, 2, 3, 4, or 5).

The signal attributes are defined in Table 120.

bio new_name SIGNAL_name Replaces SIGNAL_name with new_name in ndisplay or other output display program.

oct bus_name SIGNAL_name3 SIGNAL_name2 SIGNAL_name1

Specifies a bus name for a group of three signals. SIGNAL_name3 is the most significant bit, and SIGNAL_name1 is the least significant bit.

hex bus_name SIGNAL_name4 SIGNAL_name3 SIGNAL_name2 SIGNAL_name1

Specifies a bus name for a group of four signals. SIGNAL_name4 is the most significant bit, and SIGNAL_name1 is the least significant bit.

big new_group_name SIGNAL_name1 SIGNAL_name2 ...

Prints a caption with new_group_name for the group of SIGNAL_name signals (used only in ndisplay output).

Table 120 Signal attribute definitions

Signal Attribute Definition

v Analog voltage (PWL/voltage resolution)

i Instantaneous current (PWC/current resolution)

Table 119 The .out file keywords and values (Continued)




In Table 120, 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, respectively.

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.

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)

Table 120 Signal attribute definitions (Continued)

Signal Attribute Definition


Appendix A: Output File Descriptions and SamplesSample .cnt File

The logic state numbers and their corresponding characters are defined in Table 121.

Sample .cnt File

The nanosim.cnt file lists the state toggling numbers of nodes specified using the report_node_toggle configuration command.

Table 121 Definitions of logic state numbers and characters

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)



This .cnt sample file, as shown in Example 130, was generated using the following configuration file (for a small test circuit) in Example 131:

Example 130 .cnt file samplereport_node_toggle start=1ns end=2ns start=4ns g0 g1 g2 g3 g5 g6 g7report_node_hotspot g0 g1 g2 g3 g5 g6 g7print_probe_i a powerprint_probe_i r powerprint_probe_i d power

print_node_v g7

print_node_l g7print_node_i g7print_node_didt g7print_node_irms g7print_node_iavg g7

print_branch_i1 x11.xi9.xn8.mxn0print_branch_i2avg x11.xi9.xn8.mxn0print_branch_i3rms x11.xi9.xn8.mxn0print_branch_didt4 x11.xi9.xn8.mxn0print_branch_didtdc x11.xi9.xn8.mxn0



Example 131 Configuration file for a small test circuit

;! cnt_file_format 2002.03; --------------------------------------------------------;| |;| NanoSim Version 2002.03_Release |;| SN: P121798-SunOS_5 |;| Copyright (c) 2001 Synopsys Inc., All Rights Reserved. |;| |; --------------------------------------------------------;;

; The state toggling (transition) numbers for specified nodes are listed Here.;=========================================================; The counting starts at 1.000000ns and ends at 2.000000ns

g5 (52) : 0g1 (54) : 2g7 (56) : 0g0 (60) : 0g6 (62) : 0g3 (67) : 2g2 (72) : 1

; Total number of toggle counts (state transitions) in this period: 5

;=========================================================; The counting starts at 4.000000ns and ends at 5.000000ns

g5 (52) : 0g1 (54) : 1g7 (56) : 0g0 (60) : 0g6 (62) : 0g3 (67) : 0g2 (72) : 0

; Total number of toggle counts (state transitions) in this period: 1

The node toggling information listed in the sample .cnt file uses the following syntax:


Appendix A: Output File Descriptions and SamplesThe .nodealias File

node_name (node_index): toggle_count

The toggle_count is the total toggle number for the node in the specified counting window. At the end of the individual counting window, the total number of toggles that occurred within the counting window is reported for all specified nodes.

The counting windows are reported in ascending order of the window ending times. If the ending times are the same, the starting times will be used to decide the reporting order.

The .nodealias File

Synopsys 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-annotated RC network■ The RC network is reduced

The .nodealias file has a NanoSim 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 NanoSim banner gives the file format version as:

;! nodealias_format version_number

The version number is updated only when a new .nodealias file format is released with the software.

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.


Appendix A: Output File Descriptions and SamplesThe .nodealias File

Sample .nodealias File

The nanosim.nodealias file contains a list of primary and alias names for nodes that are aliased to another node (due to shorted resistors, a DC voltage source of 0 V, or net statements). A sample of this file is shown in Example 132:

Example 132 .nodealias file sample;! nodealias_format 2002.03; --------------------------------------------------------;| |;| NanoSim Version 2002.03_Release |;| SN: P111398-SunOS_5 |;| Copyright (c) 2001 Synopsys Inc., All Rights Reserved. |;| |; --------------------------------------------------------;;; A node (net) in a circuit can have alias node names because:; 1. there are hierarchical alias names from instances of subcircuits;; 2. the very small resistors are shorted;; 3. the node is replaced by the back-annotated RC network;; 4. the RC network is reduced.;; The following node names specified in the spice netlists, spf files,; or config commands are not primary names. Their primary names are; printed for cross reference in the following syntax:;; <primary node_name> <the alias node name>;; The first field of each line is the primary node name picked by the; netlist parser and the second field is the original node name used; in the spice netlists, spf files or config commands.;;out t1.OUTvdd VSSPI x1.cell1.in


Appendix A: Output File Descriptions and SamplesThe .stat File

The .stat File

This section describes the contents of the .stat file generated by every NanoSim run. This file reports memory and runtime statistics for a given simulation run, as shown in Example 133.

Example 133 .stat file example--------------------------------------------------------| || NanoSim Version 2003.03_Release || SN: P20000726-SunOS_5 || Copyright (c) 2001 Synopsys Inc., All Rights Reserved. || | --------------------------------------------------------

User(s) Alloc (mb) Core (mb)load_tech_files() 0.210 (0.210) 5.380 (5.380) 19.462 (19.462)geniEnvRun() 0.020 (0.230) 1.375 (6.754) 1.381 (20.843)build_elem/node_array() 0.990 (1.220) 1.328 (8.082) 1.322 (22.165)post_read_netlist_tasks()0.010 (1.230) -0.002 (8.080) 0.000 (22.165)read_config_files() 0.000 (1.230) 0.038 (8.118) 0.037 (22.202)ct_expand_models() 0.000 (1.230) 0.000 (8.118) 0.000 (22.202)ct_node_capacitance() 0.000 (1.230) 0.016 (8.134) 0.016 (22.218)ct_preprocess_init() 0.010 (1.240) 0.008 (8.142) 0.023 (22.241)ct_partition_circuit() 0.010 (1.250) 0.042 (8.184) 0.811 (23.052)execute_static_powr_analysis()0.000 (1.250)0.008 (8.191)0.000 (23.052)build_symbolic_mtrx_list()0.000 (1.250) 0.032 (8.223) 0.000 (23.052)init_output_lib() 0.010 (1.260) 0.311 (8.534) 0.000 (23.052)ct_correct_node_capacitance()0.010 (1.270)0.001 (8.535)0.000 (23.052)levelize_circuit() 0.000 (1.270) 0.008 (8.543) 0.000 (23.052)dc_init_slot() 0.020 (1.290) 0.003 (8.545) 0.000 (23.052)ct_pre_simulation 0.000 (1.290) 0.243 (8.788) 0.000 (23.052)----------------------------------------------------------------------Data Size (byte) Number S*N----------------------------------------------------------------------stage 120 228 27360basic node 112 473 52976node with logic 144 24 3456basic element 20 1038 20760



basic used element 20 1037 20740MOS element 112 1032 115584RLC element 20 0 0BJT element 912 0 0diode element 580 0 0----------------------------------------------------------------------Total(bytes) 220136----------------------------------------------------------------------

simulation() 379.000 (380.290) 0.105 (8.893) 0.016 (23.068)postprocess() 0.070 (380.360) -6.326 (2.567) 0.000 (23.06

The top section of the file is the header, which contains the output format version number, copyright, and the time and date the file was generated. It also specifies the platform on which this software should be running. The remainder of the file is comprised of two sections.

Data Structure Statistics

The second section in The .stat File provides an overview of memory use for different types of data structures. The various columns in this section are as follows: ■ Size (in bytes)

This is the amount of memory that is needed for one unit of a certain type of data structure.

■ Number

This is the number of units of this type of data structure that are in this simulation.

■ S*N

This gives the total memory used for this type of element.

You can use this section to get a rough estimate of the memory requirements for one simulation run. Keep in mind that for each element in the netlist, there are nodes connecting to it and there is capacitance associated with it. Also, current reporting, power consumption checking, dynamic stages and other analyses in the simulation all require memory. Therefore, the actual memory use could be quite different.



Simulation Statistics

The first section of the contents displayed in Example 133 lists the simulation time and dynamic and core memory use for each phase during the simulation.

There are two types of memory listed: ■ Allocated memory■ Core memory

Allocated memory is the dynamic memory (malloc, calloc) used by the simulator. This memory is allocated and freed by the simulator as necessary. Allocation and freeing of memory might not happen in the same phase of simulation.

Note:

The allocated memory value in parentheses ( ) in Example 133 is the cumulative allocated memory.

Core memory is the space being used to store the netlist, technology files, all available data, allocated data, and the simulator itself. If the core memory use is very high and there are a lot of other processes running, swapping increases.

Note:

The core memory value in parentheses ( ) in Example 133 is the cumulative core memory.

Basically, the operating system does swapping to create the illusion of a huge RAM. The actual RAM might be much smaller. It is not necessary for many of programs to be running to cause swapping. Even if the process by itself exceeds the physical memory size (RAM), swapping will occur. Swapping slows down the run because it involves reading and writing to the disk.

The worst case is that the core memory usage goes above the maximum addressable memory location (about 3.9 GB on Solaris 32-bit, or 3.5 GB on Linux 32-bit). The simulator cannot allocate any more memory at that point and will issue an error.

There are four columns in The .stat File. Column one is the phase name, while the rest of the columns are simulation time, dynamic memory use, and core memory use.



See Table 122 as a reference.

This line describes the phase in which the simulator loads the technology file. This phase took 0.21 seconds to finish. To accomplish this process, the simulator allocated 5.380 MB of dynamic memory and 19.462 MB of core memory. As the table shows, each column contains two numbers. For simulation time and allocated memory, the number outside of the parentheses is the value used in this process, while the data inside the parentheses is the accumulative value up to the current process.

For some processes such as post_read_netlist_tasks, you might see a negative number for the allocated memory. The minus sign signals the release of some dynamic memory. Negative numbers on the core memory usage are not common because the usage is just a water-mark level. But, sometimes the OS reduces the code and data size for a process; in this case, you might see a negative number. The value in parentheses on the core memory column is the up-to-date maximum memory used.

Each phase in the simulation performs one or more functions, as described in Table 123.

Table 122 . stat file sample row

Phase Name Simulation Time Dynamic Memory Use

Core Memory Use

load_tech_files()

0.210 (0.210)

5.380 (5.380)

19.462 (19.462)

Table 123 Simulation phase functions

Simulation Phase Functions

load_tech_files Loads up technology files itself into memory.

geniEnvRun The generic netlist compiler interprets, compiles, and parses the netlist.

build_elem/node_array The simulator parses the netlist and builds the internal data structures for the circuit elements and nodes.



post_read_netlist_tasks Adjusts node capacitance (similar to all SPICE-like simulators) and scales parameters.

read_config_files Reads in configuration commands.

ct_expand_models Expands models in technology files to match the real netlist and gears them toward configuration command requirements. This includes scaling and interpolating element sizes.

ct_node_capacitance Finalizes node capacitance for each node according to configuration commands.

ct_preprocess_init Applies a vector stimulus.

ct_partition_circuit Partitions the whole circuit into stages and solves each stage when there is an event at the boundary of the stage.

execute_static_powr_analysis() Time spent doing the static checking requested by the report_ckt_leak and report_node_maxrf commands.

build_symbolic_mtrx_lis Builds the matrices for each and every stage in the circuit.

init_output_lib Builds and initializes data structures for simulation output.

ct_correct_node_capacitance This is the second capacitance correction step before the simulation starts. After this process, cross-coupling effects are included in the simulation.

levelize_circuit Levelize stages according to causality. This “levelization” is used in DC initialization.

Table 123 Simulation phase functions (Continued)




dc_init_slot The DC initialization phase. Unlike SPICE-like simulators, NanoSim does not stop when DC initiation cannot be achieved. NanoSim schedules an event at time zero for all nodes that do not converge.

simulation This is where the transient simulation happens.

postprocess Cleans up the simulation, writes output files, deletes temporary files, and releases memory.

Table 123 Simulation phase functions (Continued)



Appendix A: Output File Descriptions and SamplesSample .sum File

Sample .sum File

This summary file (hot spot report) was generated using the report_node_hotspot configuration command, as shown in Example 134:

Example 134 .sum file sample; --------------------------------------------------------;| |;| NanoSim Version 2002.03_Release |;| SN: P121798-SunOS_5 |;| Copyright (c) 2001 Synopsys Inc., All Rights Reserved. |;| |; --------------------------------------------------------;;

*************************** *** Hot Spot Statistics *** ***************************

Node Name Cap(fF) Toggle Icin(uA) Icout(uA)______________________________________________________________________g7 87.88 1 0.45 67.69g5 87.88 1 0.53 60.21g6 62.95 1 0.01 41.55

Total non-input nodes : 3Total node toggles : 3Total charging current : 0.99 uATotal discharging current : 169.45 uASample .stat File


Appendix A: Output File Descriptions and SamplesSample Block Power Report in the .log File

Sample Block Power Report in the .log File

When the report_block_powr configuration command is specified in a configuration file, NanoSim produces a block power report (shown in Example 135), which is part of the .log file.

Example 135 Block power report sampleBlock: total Number of nodes in block:3953 Number of elements in block: 9752 Number of block supply nodes:11 Number of block ground nodes:5 Number of block biput nodes:17 Number of block input nodes:3 Number of block output nodes:0 Number of block stages:1597 Number of block partial stages:0

Average supply current:-45144.660642 uA RMS supply current:64875.016572 uA

Average ground current:45127.965926 uA RMS ground current: 64878.957946 uA

Average input current:0.004319 uA RMS input current:46.694417 uA

Average output current:0.000000 uA RMS output current:0.000000 uA

Average biput current:16.694782 uA RMS biput current:293.473489 uA

Average capacitive current:-39057.934468 uA RMS capacitive current:56567.265346 uA

Average wasted current:-6115.921641 uA RMS wasted current:9764.697468 uA

Wasted current percentage:13.538631%

Average block power:179937.712787 uW RMS block power:259344.959596 uW

Supply node currents: Node: vdq Average current:-1292.744780 uA



RMS current:2689.379684 uA Node: vext Average current:-13.113817 uA RMS current:60.555783 uA Node: vr2k Average current:-1.306000 uA RMS current:1.306000 uA Node: vbprst Average current:0.000000 uA RMS current:0.000000 uA Node: vrad Average current:-0.096472 uA RMS current:125.248341 uA Node: vref Average current:0.000000 uA RMS current:0.000000 uA Node: vccex Average current:-3254.654260 uA RMS current: 6735.633010 uA Node: vbbex Average current: -46.280923 uA RMS current: 65.944698 uA Node: vplex Average current: -48.694494 uA RMS current: 65.990722 uA Node: vblex Average current: -22.313620 uA RMS current: 35.782504 uA Node: vdd Average current: -40465.456275 uA RMS current: 62012.343945 uA

Ground node currents: Node: vwpb Average current: 0.000000 uA RMS current: 0.000000 uA Node: vbfe Average current: 0.000000 uA RMS current: 0.000000 uA Node: vnbl Average current: 0.000000 uA RMS current: 0.000000 uA Node: vsc Average current: 0.000000 uA RMS current: 0.000000 uA Node: gnd Average current: 45127.965926 uA RMS current: 64878.957946 uA



Input node currents: Node: vbwe Average current: 0.001269 uA RMS current: 0.014343 uA Node: vbcas Average current: 0.001368 uA RMS current: 23.447023 uA Node: vbras Average current: 0.001682 uA RMS current: 30.281411 uA

Biput node currents: Node: vdin Average current: 0.000000 uA RMS current: 0.000000 uA Node: vdq0 Average current: 0.000000 uA RMS current: 0.000000 uA Node: vdq1 Average current: 0.000000 uA RMS current: 0.000000 uA Node: vdq2 Average current: 0.000000 uA RMS current: 0.000000 uA Node: vdq3 Average current: 0.000000 uA RMS current: 0.000000 uA Node: vain1 Average current: 0.095737 uA RMS current: 44.265948 uA Node: vain0 Average current: 3.260720 uA RMS current: 38.813769 uA Node: vain2 Average current: 3.260651 uA RMS current: 38.813809 uA Node: vain3 Average current: 0.095980 uA RMS current: 44.266041 uA Node: vain4 Average current: 3.260651 uA RMS current: 38.813809 uA Node: vain5 Average current: 3.260651 uA RMS current: 38.813809 uA Node: vain6 Average current: 0.095980 uA



RMS current: 44.266041 uA Node: vain7 Average current: 0.095979 uA RMS current: 44.266041 uA Node: vain8 Average current: 0.001632 uA RMS current: 1.129229 uA Node: vain9 Average current: 3.263539 uA RMS current: 39.380620 uA Node: vain10 Average current: 0.001632 uA RMS current: 1.129229 uA Node: vain11 Average current: 0.001632 uA RMS current: 1.129229 uA


Appendix A: Output File Descriptions and SamplesSample .power File

Sample .power File

See a sample .power file in Example 136.

Example 136 .power file;! power_file_format 2002.03; --------------------------------------------------------;| |;| NanoSim Version 2002.03_Release |;| SN: P081899-SunOS_5 |;| Copyright (c) 2001 Synopsys Inc., All Rights Reserved. |;| |; --------------------------------------------------------;;

********************************************************************** RUN TIME POWER BUDGET VIOLATIONS**********************************************************************

BLOCK top: DRAWS EXCESSIVE POWER FROM 10.8 TO 10.9 ns.BLOCK top: DRAWS EXCESSIVE SUPPLY CURRENT FROM 20.9 TO 21 ns.BLOCK top: DRAWS EXCESSIVE POWER FROM 20.8 TO 21.1 ns.BLOCK top: DRAWS EXCESSIVE SUPPLY CURRENT FROM 21.4 TO 21.5 ns.BLOCK top: DRAWS EXCESSIVE POWER FROM 21.4 TO 21.5 ns.BLOCK top: DRAWS EXCESSIVE SUPPLY CURRENT FROM 21.6 TO 21.8 ns.BLOCK top: DRAWS EXCESSIVE POWER FROM 21.6 TO 21.9 ns.BLOCK top: DRAWS EXCESSIVE SUPPLY CURRENT FROM 22.2 TO 22.5 ns.BLOCK top: DRAWS EXCESSIVE POWER FROM 22.2 TO 22.5 ns.BLOCK top: DRAWS EXCESSIVE SUPPLY CURRENT FROM 50.4 TO 50.5 ns.BLOCK top: DRAWS EXCESSIVE POWER FROM 50.4 TO 50.5 ns.BLOCK top: DRAWS EXCESSIVE SUPPLY CURRENT FROM 61.4 TO 61.5 ns.BLOCK top: DRAWS EXCESSIVE POWER FROM 61.4 TO 61.5 ns.BLOCK top: DRAWS EXCESSIVE SUPPLY CURRENT FROM 61.6 TO 62.4 ns.BLOCK top: DRAWS EXCESSIVE POWER FROM 61.6 TO 62.4 ns.BLOCK top: DRAWS EXCESSIVE SUPPLY CURRENT FROM 101.6 TO 101.8 ns.BLOCK top: DRAWS EXCESSIVE POWER FROM 101.6 TO 101.8 ns.BLOCK top: DRAWS EXCESSIVE SUPPLY CURRENT FROM 102.2 TO 102.3 ns.BLOCK top: DRAWS EXCESSIVE POWER FROM 102.2 TO 102.3 ns.BLOCK top: DRAWS EXCESSIVE SUPPLY CURRENT FROM 141.6 TO 141.8 ns.BLOCK top: DRAWS EXCESSIVE POWER FROM 141.6 TO 141.8 ns.BLOCK top: DRAWS EXCESSIVE SUPPLY CURRENT FROM 142.2 TO 142.4 ns.BLOCK top: DRAWS EXCESSIVE POWER FROM 142.2 TO 142.4 ns.



BLOCK top: DRAWS EXCESSIVE POWER FROM 170.8 TO 170.9 ns.BLOCK top: DRAWS EXCESSIVE SUPPLY CURRENT FROM 181.4 TO 181.5 ns.BLOCK top: DRAWS EXCESSIVE POWER FROM 181.4 TO 181.5 ns.BLOCK top: DRAWS EXCESSIVE SUPPLY CURRENT FROM 181.6 TO 181.8 ns.BLOCK top: DRAWS EXCESSIVE POWER FROM 181.6 TO 181.8 ns.BLOCK top: DRAWS EXCESSIVE SUPPLY CURRENT FROM 182.2 TO 182.4 ns.BLOCK top: DRAWS EXCESSIVE POWER FROM 182.2 TO 182.4 ns.BLOCK top: DRAWS EXCESSIVE SUPPLY CURRENT FROM 221.6 TO 221.8 ns.BLOCK top: DRAWS EXCESSIVE POWER FROM 221.6 TO 221.8 ns.BLOCK top: DRAWS EXCESSIVE SUPPLY CURRENT FROM 222.2 TO 222.3 ns.BLOCK top: DRAWS EXCESSIVE POWER FROM 222.2 TO 222.3 ns.BLOCK top: DRAWS EXCESSIVE SUPPLY CURRENT FROM 261.6 TO 261.7 ns.BLOCK top: DRAWS EXCESSIVE POWER FROM 261.6 TO 261.8 ns.BLOCK top: DRAWS EXCESSIVE SUPPLY CURRENT FROM 262.2 TO 262.4 ns.BLOCK top: DRAWS EXCESSIVE POWER FROM 262.2 TO 262.4 ns.BLOCK top: DRAWS EXCESSIVE SUPPLY CURRENT FROM 301.6 TO 301.8 ns.BLOCK top: DRAWS EXCESSIVE POWER FROM 301.6 TO 301.8 ns.BLOCK top: DRAWS EXCESSIVE SUPPLY CURRENT FROM 302.2 TO 302.3 ns.BLOCK top: DRAWS EXCESSIVE POWER FROM 302.2 TO 302.3 ns.BLOCK top: DRAWS EXCESSIVE SUPPLY CURRENT FROM 341.6 TO 341.8 ns.BLOCK top: DRAWS EXCESSIVE POWER FROM 341.6 TO 341.8 ns.BLOCK top: DRAWS EXCESSIVE SUPPLY CURRENT FROM 342.2 TO 342.4 ns.BLOCK top: DRAWS EXCESSIVE POWER FROM 342.2 TO 342.4 ns.BLOCK top: DRAWS EXCESSIVE SUPPLY CURRENT FROM 381.6 TO 381.7 ns.BLOCK top: DRAWS EXCESSIVE POWER FROM 381.6 TO 381.7 ns.

********************************************************************** POWER BUDGET VIOLATION SUMMARY**********************************************************************

BLOCK top: MAXIMUM INSTANTANEOUS SUPPLY CURRENT OF -157249 uA EXCEEDS BUDGET OF 30000 uA.BLOCK top: AVERAGE SUPPLY CURRENT OF -1537.84 uA EXCEEDS BUDGET OF 1000 uA.BLOCK top: MAXIMUM INSTANTANEOUS POWER OF 566098 uW EXCEEDS BUDGET OF 100000 uW.BLOCK top: AVERAGE POWER OF 5536.21 uW EXCEEDS BUDGET OF 3000 uW.

********************************************************************** BLOCK HIERARCHICAL POWER ANALYSIS**********************************************************************

BLOCK top: AVERAGE SUPPLY CURRENT.



LEVEL CURRENT PERCENT OF PERCENT OF CHILD BLOCK NAME (uA) PARENT TOP ----------------------------------------------------------------------*--------- 0 -1537.8 100.00 100.00 top-*-------- 1 -1537.8 100.00 100.00 top_xsr34x22--*------- 2 -359.83 23.40 23.40 top_xsr34x22.x1161--*------- 2 -322.71 20.98 20.98 top_xsr34x22.x1164--*------- 2 -214.54 13.95 13.95 top_xsr34x22.x1166--*------- 2 -207.33 13.48 13.48 top_xsr34x22.x1158--*------- 2 -192.92 12.55 12.55 top_xsr34x22.x1162--*------- 2 -81.777 5.32 5.32 top_xsr34x22.x1163--*------- 2 -57.569 3.74 3.74 top_xsr34x22.x1157--*------- 2 -52.966 3.44 3.44 top_xsr34x22.x1160--*------- 2 -42.359 2.75 2.75 top_xsr34x22.x1169--*------- 2 -5.8502 0.38 0.38 top_xsr34x22.x1167--*------- 2 0.0086932 -0.00 -0.00 top_xsr34x22.x1170--*------- 2 0 -0.00 -0.00 top_xsr34x22.x1165--*------- 2 0 -0.00 -0.00 top_xsr34x22.x1168--*------- 2 0 -0.00 -0.00 top_xsr34x22.x1159

BLOCK top: RMS SUPPLY CURRENT.

LEVEL CURRENT PERCENT OF PERCENT OF CHILD BLOCK NAME (uA) PARENT TOP ----------------------------------------------------------------------*--------- 0 6959.2 100.00 100.00 top-*-------- 1 6959.2 100.00 100.00 top_xsr34x22--*------- 2 3717.1 53.41 53.41 top_xsr34x22.x1161--*------- 2 2966.7 42.63 42.63 top_xsr34x22.x1164--*------- 2 1785.1 25.65 25.65 top_xsr34x22.x1166--*------- 2 1584.1 22.76 22.76 top_xsr34x22.x1162--*------- 2 1332.5 19.15 19.15 top_xsr34x22.x1158--*------- 2 1202.1 17.27 17.27 top_xsr34x22.x1163--*------- 2 647.76 9.31 9.31 top_xsr34x22.x1157--*------- 2 408.87 5.88 5.88 top_xsr34x22.x1160--*------- 2 316.96 4.55 4.55 top_xsr34x22.x1169--*------- 2 115.03 1.65 1.65 top_xsr34x22.x1167--*------- 2 2.588 0.04 0.04 top_xsr34x22.x1170--*------- 2 0 0.00 0.00 top_xsr34x22.x1165--*------- 2 0 0.00 0.00 top_xsr34x22.x1168--*------- 2 0 0.00 0.00 top_xsr34x22.x1159



BLOCK top: AVERAGE POWER.

LEVEL POWER PERCENT OF PERCENT OF CHILD BLOCK NAME (uΩ) PARENT TOP ----------------------------------------------------------------------*--------- 0 5536.2 100.00 100.00 top-*-------- 1 5536.2 100.00 100.00 top_xsr34x22--*------- 2 1467.9 26.51 26.51 top_xsr34x22.x1161--*------- 2 746.39 13.48 13.48 top_xsr34x22.x1158--*------- 2 722.92 13.06 13.06 top_xsr34x22.x1166--*------- 2 694.52 12.55 12.55 top_xsr34x22.x1162--*------- 2 639.25 11.55 11.55 top_xsr34x22.x1164--*------- 2 430.29 7.77 7.77 top_xsr34x22.x1163--*------- 2 258.27 4.67 4.67 top_xsr34x22.x1167--*------- 2 207.25 3.74 3.74 top_xsr34x22.x1157--*------- 2 190.68 3.44 3.44 top_xsr34x22.x1160--*------- 2 152.49 2.75 2.75 top_xsr34x22.x1169--*------- 2 49.414 0.89 0.89 top_xsr34x22.x1165--*------- 2 -0.031295 -0.00 -0.00 top_xsr34x22.x1170--*------- 2 0 0.00 0.00 top_xsr34x22.x1168--*------- 2 0 0.00 0.00 top_xsr34x22.x1159

BLOCK top: RMS POWER.

LEVEL POWER PERCENT OF PERCENT OF CHILD BLOCK NAME (uΩ) PARENT TOP ----------------------------------------------------------------------*--------- 0 25053 100.00 100.00 top-*-------- 1 25053 100.00 100.00 top_xsr34x22--*------- 2 14856 59.30 59.30 top_xsr34x22.x1161--*------- 2 8329.2 33.25 33.25 top_xsr34x22.x1164--*------- 2 6077 24.26 24.26 top_xsr34x22.x1166--*------- 2 5702.9 22.76 22.76 top_xsr34x22.x1162--*------- 2 4995.3 19.94 19.94 top_xsr34x22.x1163--*------- 2 4796.9 19.15 19.15 top_xsr34x22.x1158--*------- 2 2787.9 11.13 11.13 top_xsr34x22.x1167--*------- 2 2331.9 9.31 9.31 top_xsr34x22.x1157--*------- 2 1471.9 5.88 5.88 top_xsr34x22.x1160--*------- 2 1141.1 4.55 4.55 top_xsr34x22.x1169--*------- 2 602.31 2.40 2.40 top_xsr34x22.x1165--*------- 2 9.3168 0.04 0.04 top_xsr34x22.x1170


Appendix A: Output File Descriptions and SamplesSample .dcpath File

--*------- 2 0 0.00 0.00 top_xsr34x22.x1168--*------- 2 0 0.00 0.00 top_xsr34x22.x1159

Sample .dcpath File

This file lists the output of the report_ckt_dcpath configuration command.


Appendix A: Output File Descriptions and SamplesSample .dcpath File

;! dcpath_file_format 2002.03; --------------------------------------------------------;| |;|NanoSim Version 2002.03_Release |;| SN: P020299-SunOS_5 |;| Copyright (c) 2001 Synopsys Inc., All Rights Reserved. |;| |; --------------------------------------------------------;;Nonzero dc path(s) found at time 200 ns Path # 1--------------------------------------------------------------- resistor IOBUFF0.R1 current = -0.02 uA from XGND voltage = 0.00 V to DATAOUT0 voltage = 0.00 V resistor IOBUFF0.R2 current = 79.98 uA from IOBUFF0.VR voltage = 4.00 V to DATAOUT0 voltage = 0.00 V--------------------------------------------------------------- Path # 2--------------------------------------------------------------- resistor IOBUFF0.R1 current = -99.97 uA from XGND voltage = 0.00 V to DATAOUT0 voltage = 5.00 V inductor IOBUFF0.OUTBOND current = -119.93 uA from DATAOUT0 voltage = 5.00 V to IOBUFF0.OUT1 voltage = 5.00 V transistor IOBUFF0.P1 (type PMOS) current = -119.91 uA gate IOBUFF0.INGATE voltage = 0.00 V drain IOBUFF0.OUT1 voltage = 5.00 V source IOBUFF0.DP1 voltage = 5.00 V transistor IOBUFF0.P2 (type PMOS) current = -119.93 uA gate IOBUFF0.PGATE voltage = 0.00 V drain IOBUFF0.DP1 voltage = 5.00 V source EVDD voltage = 5.00 V inductor IOBUFF0.L1 current = -119.93 uA from EVDD voltage = 5.00 V to VDD voltage = 5.00 V---------------------------------------------------------------


Appendix A: Output File Descriptions and SamplesSample .hist File

Sample .hist File

Example 137 contains current information used for the creation of graphical histograms.

Example 137 .hist file sampleNode: gnd

Start (ns) Stop (ns) Avg (uA) RMS (uA) Peak (uA) Time (ns) 0.0000e+00 1.0000e+02 1.0154e+03 3.2430e+03 2.8715e+04 5.0100e+01 1.0000e+02 2.0000e+02 1.1140e+03 3.1151e+03 2.1588e+04 1.6010e+02 2.0000e+02 3.0000e+02 1.2632e+03 3.2377e+03 2.6071e+04 2.5020e+02 3.0000e+02 4.0000e+02 9.2633e+02 2.7052e+03 2.6349e+04 3.7010e+02 4.0000e+02 5.0000e+02 1.1303e+03 3.2997e+03 2.8571e+04 4.9010e+02 5.0000e+02 6.0000e+02 1.4595e+03 4.0364e+03 2.8571e+04 5.3010e+02 6.0000e+02 7.0000e+02 1.0462e+03 3.3605e+03 2.9873e+04 6.9010e+02 7.0000e+02 8.0000e+02 7.4903e+02 2.8783e+03 2.6349e+04 7.1010e+02

Node: vdd

Start (ns) Stop (ns) Avg (uA) RMS (uA) Peak (uA) Time (ns) 0.0000e+00 1.0000e+02 -1.0172e+03 3.2458e+03 -2.8715e+04 5.0100e+01 1.0000e+02 2.0000e+02 -1.1349e+03 3.1344e+03 -2.1588e+04 1.6010e+02 2.0000e+02 3.0000e+02 -1.3084e+03 3.2743e+03 -2.6071e+04 2.5020e+02 3.0000e+02 4.0000e+02 -9.5453e+02 2.7270e+03 -2.6349e+04 3.7010e+02 4.0000e+02 5.0000e+02 -1.1601e+03 3.3144e+03 -2.8571e+04 4.9010e+02 5.0000e+02 6.0000e+02 -1.4618e+03 4.0404e+03 -2.8571e+04 5.3010e+02 6.0000e+02 7.0000e+02 -1.0831e+03 3.3849e+03 -2.9873e+04 6.9010e+02 7.0000e+02 8.0000e+02 -7.5635e+02 2.8863e+03 -2.6349e+04 7.1010e+02


BBDetailed Configuration Command Information

This appendix provides detailed information about certain configuration commands, beyond what is included in the reference descriptions in the man pages. Use this information in conjunction with the man page descriptions.

Effects of set_node_thresh Command

Figure 44 illustrates how the set_node_thresh command changes the digital waveform display and the digital event generation.


Appendix B: Detailed Configuration Command InformationEffects of set_node_thresh Command

Figure 44 Illustration of set_node_thresh command

Segment A in Figure 44 shows the voltage waveform of a signal when it starts to rise from 0.0 V at 1.2 ns and when it reaches the high voltage, 5.0V, at 2.0 ns. Then, the signal starts to fall at 2.9 ns until reaching 0.0 V at 3.9 ns.

Segment B in Figure 44 shows the signal’s corresponding logic waveform by using the following default threshold setting:

5.04.54.03.53.02.52.01.51.00.50.0

1.2 1.4 1.5 1.7 2.0 3.0 3.2 3.5 3.7 3.9

Time (nanoseconds)

1.4 1.55 1.7 3.2 3.45 3.7T0U TM01 TU1 T1U TM10 TU0

1.5 1.6 1.7 3.2 3.35 3.5T0UTM01TU1 T1U TM10TU0

Time (ns)

Time (ns)

U

U U

U

T0U - time 0 UTU1 - time U 1T1U - time 1 UTU0 - time U 0TM01 - time Middle 0 1TM10 - time Middle 1 0

Case #170% 1 = 3.5V50% Middle = 2.5V30% 0 = 1.5V

Case #270% 1 = 3.5V40% Middle = 2V10% 0 = 0.5V

Vol

tsV

olts

Vol

ts

If evt 0, digital event generation occurs at TM10 and TM01

If evt 1, digital event generation occurs at TU1 and TU0

A)

B)

C)



low threshold = low voltage + 30% * (high voltage - low voltage)= 0V + 0.3 * (5V - 0V)= 1.5V

high threshold = low voltage + 70% * (high voltage - low voltage) = 0V + 0.7 * (5V - 0V)= 3.5V

middle voltage = 50% * (high threshold + low threshold)= 0.5 * (3.5V + 1.5V)= 2.5V

where:

T0U is the time the logic state changes from 0 to U

TU1 is the time the logic state changes from U to 1

T1U is the time the logic state changes from 1 to U

TU0 is the time the logic state changes from U to 0

TM01 is the time the voltage reaches the middle voltage when the state changes from 0 to 1, TM10 is the time the voltage reaches the middle voltage when the state changes from 1 to 0.

The time values for the preceding state change points can be derived from segments A and B in Figure 44:■ T0U = 1.5 ns■ TU1 = 1.7 ns■ T1U = 3.2 ns■ TU0 = 3.5 ns■ TM01 = 1.6 ns■ TM10 = 3.35 ns

The digital event generation is controlled by the evt=0|1 argument. By default, evt=0. A digital event is generated when a signal goes over or below the middle voltage, which happens at either TM01 or TM10. If evt=1, a digital event is generated when a signal rises over the high threshold or falls below the low threshold, which happens at either the TU1 or TU0 digital event.



Segment C, in Figure 44, shows the signal’s corresponding logic waveform by using 10% as the low threshold ratio and 70% as the high threshold ratio. In this case, the threshold voltages take on the following values:

low threshold= low voltage + 10% * (high voltage - low voltage)= 0V + 0.1 * (5V - 0V)= 0.5V

high threshold = low voltage + 70% * (high voltage - low voltage)= 0V + 0.7 * (5V - 0V)= 3.5V

middle voltage = 50% * (high threshold + low threshold)= 0.5 * (3.5V + 0.5V)= 2.0V

The time values for the preceding state change points can be derived from segment A and B in Figure 44:

T0U = 1.4 nsTU1 = 1.7 nsT1U = 3.2 nsTU0 = 3.7 nsTM01 = 1.55 nsTM10 = 3.45 ns

When you compare segments B and C in Figure 44, you can see that the different threshold voltages produce different logic waveforms and change when the digital event is generated.

Effects of the tv_node_edge Command

Figure 45 illustrates effects of the tv_node_edge command:



Figure 45 Effects of tv_node_edge command

The min_time and max_time of tv_node_edge can be:■ both positive■ both negative■ min_time is negative and max_time is positive

Both positive and negative values are used in the following examples:

The trigger=option is used to specify whether the signal edge (by trigger=input), the reference edge (by trigger=ref), or both signal and reference edges (by trigger=both) will trigger the edge timing check. Whatever does trigger the edge timing check needs to satisfy the timing constraints specified by min_time and max_time:

tv_node_edge SIG - REF rise trigger=input

Tref1 Tref2REF

Edge

SIG

TS2TS1

A)

B)

C)

TE1 = Tref1 + Tmax TE2 =

(positive)withmin_timemax_time

Edge(negative)withmin_timemax_time

TS1 = Tref1 + Tmin

TE1 = Tref1 + Tmax

Tref2 + Tmax

TS2 = Tref2 + Tmin

TE2 = Tref2 + Tmax

tv_node_edge SIG - REF rise Tmin Tmax trigger= ref

tv_node_edge SIG - REF rise Tmin Tmax trigger= input

TS2 = Tref2 + TminTS1 = Tref1 + Tmin

TS3

Tmin Tmax



Assuming min_time and max_time are positive, this example checks if the state transition of SIG happens in the periods from TS1 to TE1 or from TS2 to TE2 as illustrated in segment A of Figure 45.

TS1, TE1, TS2, and TE2 are defined in Example 138:

Example 138 Definition of TS1, TE1, TS2 and TE2TS1 = Tref1 + TminTE1 = Tref1 + TmaxTS2 = Tref2 + TminTE2 = Tref2 + Tmax

This command reports errors if the state transition of SIG happens outside of these periods. Since trigger=input is specified, the edge timing is checked only when the state of SIG changes:

tv_node_edge SIG - REF rise T{min} T{max}trigger=ref

Assuming min_time and max_time are negative, this example checks if the state transition of SIG happens in the periods from TS1 to TE1 or from TS2 to TE2. TS1, TE1, TS2, and TE2 are defined as follows:

TS1, TE1, TS2 and TE2 are defined in Example 139:

Example 139 TS1, TE1, TS2 and TE2 definitionsTS1 = Tref1 + TminTE1 = Tref1 + TmaxTS2 = Tref2 + TminTE2 = Tref2 + Tmax

This example reports errors if the state transition of SIG happens outside of these periods. Since trigger=ref is specified, the edge timing is checked only when REF changes to 1. Notice that the formulas for calculating the edge timing constraints are the same for both positive and negative min_time and max_time. This is illustrated in Figure 45, segment B.

Segment C in Figure 45 shows the waveform of SIG. Here, SIG is used to explain how tv_node_edge works and how trigger= changes the error report.

Based on segments A and B in Figure 45, the falling transition of SIG at TS2 causes an edge timing error since it happens outside of the acceptable periods. In this case, trigger=input reports two errors at TS2 and Tref2 because of the following conditions:


Appendix B: Detailed Configuration Command InformationEffects of tv_node_setup Command

TS2 - Tref1 > Tmax, error reported at

TS2 - Tref2 < Tmin, error reported at

The first error is checked against REF at Tref1 which happens far away from SIG at TS2. For some applications, this error is not a concern. To filter out this kind of “remote” error, use the window= argument. This argument suppresses any errors with an edge time difference larger than the window size.

If trigger=ref is specified, the simulator will not report any edge timing error because the rising REF at Tref1 satisfies the timing constraints by the rising SIG at TS1 and the rising REF at Tref2 satisfies the timing constraints by the rising SIG at TS3.

If trigger=both is used, the reported errors are the union of the errors reported by both trigger=input and trigger=ref. For this case, it is the same as using trigger=input. To catch all potential edge timing violations, trigger=both should be used (it is the default setting if trigger= is not specified).

Effects of tv_node_setup Command

For an illustration of the tv_node_setup command, see Figure 46.

Figure 46 Illustration of tv_node_setup

Ts2

Tref2

Tref1 Tref2REF

SetupTime

<setup_time>Tref1 =T1 + <setup_time>

Tref1 Tref2

Tref2

T1

T1 T2

T2TW1<setup_time>

<win_size>

(positive)

SetupTime(negative)with<win_size>

B)

A)


Appendix B: Detailed Configuration Command InformationEffects of tv_node_hold Command

Positive Setup Time

See the following positive setup time in Example 140:

Example 140 Positive setup time exampletv_node_setup SIG edge REF rise setup_time

Assuming the setup_time is positive, this example checks if SIG stays steady in the periods from T1 to Tref1 and from T2 to Tref2, where the following conditions are true:

T1 = Tref1 - setup_timeT2 = Tref2 - setup_time

This is illustrated in segment A of Figure 46.

Negative Setup Time

See the following negative setup time example in Example 141:

Example 141 Negative setup time exampletv_node_setup SIG edge REF rise setup_time window=win_size

If setup_time is a negative number, a window=win_size argument is needed to limit when the checking ends.

Example 142 checks if SIG stays steady in the periods from T1 to TW1 and from T2 to TW2 where the following conditions are true:

Example 142 SIG status exampleT1 = Tref1 - setup_timeTW1 = Tref1 + win_sizeT2 = Tref2 - setup_timeTW2 = Tref2 + win_size

This is illustrated in segment B of Figure 46.

Effects of tv_node_hold Command

For an illustration of the tv_node_hold command, see Figure 47:


Appendix B: Detailed Configuration Command InformationEffects of tv_node_hold Command

Figure 47 Illustration of tv_node_hold Command

Positive Hold Time

See Example 143 for a positive hold time example:

Example 143 Positive hold time exampletv_node_hold SIG edge REF rise hold_time

Assuming the hold_time is a positive number, this example checks if SIG stays steady in the periods from Tref1 to T1 and from Tref2 to T2, where the following conditions are true:

T1 = Tref1 + hold_timeT2 = Tref2 + hold_time

This is illustrated in segment A of Figure 47.

Tref1 Tref2

REF

<hold time>

<hold time>

<hold time>

Tref1

Tref1

Tref1

Tref2

Tref2

Tref2

A)

B)

C)

HoldTime(positive)

HoldTime(negative)

HoldTime(negative)

with<win_size>

T2

TW2

T2

T2

<win_size>

T1 = Tref1 + <hold_time>


TW1 = Tref1 + <win_size>T1

T1



Appendix B: Detailed Configuration Command InformationApplying Commands to Portions of a Circuit

Negative Hold Time without a Specified Window Size

See Example 144 for a negative hold time example (without a specified window size) :

Example 144 Negative hold time exampletv_node_hold SIG edge REF rise hold_time

Assuming hold_time is a negative number and the no window=win_size argument is used, this example checks if SIG stays steady in the periods from T1 to Tref1 and from T2 to Tref2 where the following conditions are true:

T1 = Tref1 + hold_timeT2 = Tref2 + hold_time

This is illustrated in segment B in Figure 47.

Negative Hold Time with Specified Window Size

See Example 145 for a negative hold time example (with a specified window size):

Example 145 Negative hold time (with specified window size)tv_node_hold SIG edge REF rise hold_time window=win_size

Assuming hold_time is a negative number and the window=win_size argument is specified, this example checks if SIG stays steady in the periods from T1 to TW1 and from T2 to TW2, where the following conditions are true:

T1 = Tref1 + hold_timeTW1 = Tref1 + win_sizeT2 = Tref2 + hold_timeTW2 = Tref2 + win_size

This is illustrated in segment C in Figure 47.

Applying Commands to Portions of a Circuit

There are several ways to apply configuration commands to specified parts of a circuit. For example, if your circuit contains several kinds of charge pumps and



you want to make sure that the acc simulation mode is used on certain nodes in the charge pump, you can use any of the following methods:■ Directly apply the configuration command, for example, set_node_acc, to

all the charge-pump nodes in the circuit.■ Apply the set_inst_cmd to all instances of charge-pump in the design.

Apply the set_ckt_cmd to all charge-pump subcircuits.■ Apply the set_pattern_cmd to one charge-pump pattern.

Applying Configuration Commands Directly

There are advantages and disadvantages to directly applying configuration commands, as shown in Table 124:

Applying Configuration Commands that Apply other Configuration Commands

The set_inst_cmd, set_ckt_cmd, and set_pattern_cmd commands apply given configuration to instances, subcircuits, or patterns, respectively. Each command has particular advantages and disadvantages depending on the design to which they are being applied.

Table 124 Advantages/disadvantages to directly apply config cmds

Advantage You have to list the charge-pump nodes to which you want to apply the regular configuration command.

Disadvantage You need to make sure the location of all charge pump circuits is known and up to date. If you add a new charge pump you would need to add a new command.

When to Use Use this method when the number of nodes or elements to which you want to apply the configuration command is small.



Using the set_inst_cmd Configuration CommandThere are advantages and disadvantages to directly applying the set_inst_cmd config command, as shown in Table 125:

Using the set_ckt_cmd Configuration CommandThere are advantages and disadvantages to directly applying the set_ckt_cmd config command, as shown in Table 126:

Using the set_pattern_cmd Configuration CommandThere are advantages and disadvantages to applying the set_pattern_cmd config command directly, as shown in Table 127:

Table 125 Advantages/disadvantages of applying set_inst_cmd

Advantage Straightforward.

Disadvantage You need to know the location of all charge pump circuits in the design. If you add a new charge-pump instance or instantiate a new charge pump, you need to add another iteration of this command.

When to Use Use this command when the number of instances to which you want to apply it is small.

Table 126 Advantages/disadvantages of applying set_ckt_cmd

Advantage Straightforward.

Disadvantage You need to know the names of all charge-pump subcircuits. If you add a new charge-pump circuit, you need to add another iteration of this command.

When to Use Use this command when the nodes or elements to which you want to apply it exist on a small number of subcircuits.


Appendix B: Detailed Configuration Command InformationSample Circuits Detected with report_ckt_leak

Sample Circuits Detected with report_ckt_leak

Figure 48 through Figure 54 illustrate circuits detected with the various arguments to report_ckt_leak. This command runs before the dynamic simulation. Use the report_ckt_dcpath configuration command to search for DC leakage paths during the dynamic simulation.

Figure 48 Sample circuits detected by the p_path and n_path arguments

Table 127 Advantages/disadvantages of set_pattern_cmd

Advantage Once you create a pattern, the pattern command automatically finds all occurrences of the pattern, even if they exist in different subcircuits or span subcircuit boundaries.

Disadvantage The method can be slow under some circumstances. The pattern command can only find subcircuit patterns when the ports are not shorted together or connected to a global node, like power or ground. For example, if your pattern is a two-input NAND gate and you either short the inputs together or connect one of the inputs to power or ground, the set_pattern_cmd will not find the NAND gate.

When to Use Use this method when the elements or nodes to which you want to apply a given command do not always occur in a particular subcircuit.

n_pathp_path



Figure 49 Sample circuits detected by the nc_vdd and nc_gnd arguments

Figure 50 Sample circuits detected by the to_vdd and to_gnd arguments

nc_vdd nc_gnd

to_vdd to_gnd



Figure 51 Sample circuit detected by the static_leak argument

Figure 52 Sample circuits detected by the stuck_at_1 and stuck_at_0 arguments

static_leak

stuck_at_1 stuck_at_0


Appendix B: Detailed Configuration Command InformationUsing report_node_exv

Figure 53 Sample circuits detected by the partial_off_p and partial_off_n arguments

Figure 54 Sample circuits detected by the forward_bias_p and forward_bias_n arguments

Using report_node_exv

Example 146 checks whether the voltages of the nodes matching in1 fall below -2.v for a time period longer than 0.5ns.

Example 146 Voltage node checkreport_node_exv start=0ns end=11nsreport_node_exv t_thresh=0.5ns high_thresh= 1v

low_thresh=-2v in1

The checking starts at 0ns and ends at 11ns (see Figure 55).

partial_off_p partial_off_n

VDDHVDDL

GNDLGNDH

forward_bias_p forward_bias_n

VDDH

VDDL

GNDL

GNDH


Appendix B: Detailed Configuration Command InformationCounting Pulses within a Reference Pulse

Figure 55 Sample output from the report_node_exv command

Using this sample graph, the report_node_exv command in this example would report errors at the following times: ■ Between 1 ns and 2 ns (the node voltage was too high at node in1)■ Between 4 ns and 9 ns (the node voltage was too low at node in1)

Counting Pulses within a Reference Pulse

The report_node_pulse command reports any specified nodes whose pulse counts are consistent with the specified number of pulses within the pulse of the reference node or within the specified time period to the .err file.

Figure 56 illustrates the concept of counting pulses within a reference pulse.

1.5 V

1 V

0

-2 V-1 V

-3 V

-4 V

1 2 3 4 5 6 7 8 9 10

V (in1)


Appendix B: Detailed Configuration Command InformationCounting Pulses within a Reference Pulse

Figure 56 Node pulses checked against the high pulse of a reference node

■

ref_clk

(1)

(2)

(3)

(4)(5)

(6)

(7)

■ Signals 1-5 have zero high pulses inside the high pulse of

Analysis:

reference pulse

checkednodes

referencenode

the ref_clk reference signal.

■ Signal 7 has multiple high pulses inside the high pulse of

Signal 6 has 1 high pulse inside the high pulse of ref_clk.

ref_clk.


Appendix B: Detailed Configuration Command InformationUnderstanding Keepers (search_mos_keeper)

Understanding Keepers (search_mos_keeper)

A keeper is a weak feedback device needed for keeping the storage charge at a node that might float.

For example, inv_w in Figure 57 and Figure 58 is considered to be a keeper, which retains the storage charge at node X.

Figure 57 Example of an inverter as a keeper

Figure 58 Example of a transistor as a keeper

Using set_err_window

The set_err_window command controls the printing of error messages to the .err file. It has three syntactic forms:

X Yinv_s

inv_w

X Y

inv_w

Vdd

inv_s


Appendix B: Detailed Configuration Command InformationUsing set_err_window

Syntax 1


set_err_window [command]

If you specify this command without arguments in the configuration file, the simulator prints the syntax for the command to the .log file. If you specify set_err_window with the command keyword, the simulator prints a list of available values for cmd_name.

Syntax 2


set_err_window cmd= cmd_name1[cmd=cmd_name2 ...]] start=start_time1 [end=end_time1 start=start_time2 [end=end_time2 ...]]]

Use this form to open an error window during the specified start_time and end_time pairs. If you do not specify an end_time, the error window will remain open until the end of the simulation. See Figure 59.

Figure 59 Illustration of the example given in Syntax 2

Time

TS1

TS = Time StartTE = Time End

TE1 TS2 TE2 TS3 TE3


Appendix B: Detailed Configuration Command InformationSimulating Floating Capacitors

Syntax 3


set_err_window cmd=cmd_name1 [cmd=cmd_name2 ...]] start=start_time [end=end_time] period=period_time on_time=on_time

Use this syntactic form to open an error window from start_time to end_time. The default for this window is off. Other subwindows are open from start_time(n) to start_time(n) + on_time, and between these windows, error messages are allowed to print to the .err file. See Figure 60.

The start_time(n) values are as follows:

start_time(0) = start_timestart_time(n) = start_time(n-1) + period_time

Figure 60 Illustration of the example given in Syntax 3

Simulating Floating Capacitors

The set_fcap_param and set_relfcap_param commands define the threshold capacitances and capacitance ratios, respectively, for floating capacitors. They can be applied separately or combined. Using set_fcap_param (first syntax) in combination with set_relfcap_param, defines one of the following models for simulating floating capacitors:

TimeTS


TE

on_time

period

on_time

period

on_time

period



Model 1

The precise floating-cap model with capacitor terminals being partitioned into the same stage.

Conditions for use: when capacitance C is greater than max_cap and cap_ratio is greater than max_ratio as defined by set_relfcap_param, where cap_ratio is defined as Max (C/C1, C/C2), C1 and C2 are the total lumped capacitances (including C) at terminals 1 and 2 of the floating capacitor, respectively.

Model 2

The simplified capacitance model simulated by SMS.

Conditions for use: If neither the conditions for Model 1 nor the conditions for Model 3 exist, Model 2 is selected.

Model 3

The simplified model ignoring the crosstalk coupling effect of the capacitor. This model splits the coupling capacitor to ground on each node.

Conditions for use: Capacitance is less than min_cap or cap_ratio is less than min_ratio as defined by set_relfcap_param.

Figure 61 graphically represents the conditions that need to exist before a particular model is used.



Figure 61 Illustration of model selection with sample command settings and floating capacitor

min_ratio

max_ratio

min_cap max_cap

Model 3

Model 3

Model 3

Model 3 Model 3

Model 2

Model 2

Model 2

Model 1

C500 fF

Cn1 Cn2 = 700 fF

10 f 100 f

0.05

0.3

In this example, C (500 fF) is greater than max_cap (100 fF) and cap_ratio (0.5) is greater than max_ratio (0.3); therefore, Model 1 is selected.

cap_ratio = 0.42cap_ratio = 0.5

sample settings

Sample Floating Capacitor

(set_relfcap_param)

sample settings(set_fcap_param)

Sample Values and Model Table

= 500 fF

C1 = C + Cn1 = 1 pFC2 = C + Cn2 = 1.2 pF


Appendix B: Detailed Configuration Command InformationDefining a Steady-state Strobe Window with vchk_node_window

Defining a Steady-state Strobe Window with vchk_node_window

If you specify a positive value for the period_time, parameter, the vchk_node_window command defines a steady-state strobe window within each period. The first period begins at time 0.0 ns if first_time is not given. Otherwise, the first period begins at the specified first_time.

The given start_time defines the offset time from the beginning of the period, when the node state should be steady, until the specified end-time. Both start_time and end_time are positive.

For the steady-state window in each period, the expected state is determined by the vector arriving before the steady-state window. As illustrated in Figure 66, the expected state for the window from 90 ns to 100 ns is determined by the vector arriving before 90 ns.

The expected state for the window from 190 ns to 200 ns is determined by the vector arriving between 100 ns and 190 ns, and so on. If any vector arrives during the steady-state window (for example, it arrives at 95 ns as shown in Figure 67) the simulator produces a warning message and ignores the new vector.

If a node changes states or has a mismatched state during a steady-strobe window, a comparison error is flagged.

vchk_node_window start=1.5ns end=2.0ns OUT_PIN

This example defines a vector comparison window that starts 1.5ns before and ends 2.0ns after the vector strobe arrives. The OUT_PIN node will pass the vector check if its state reaches the expected state within the defined window (as shown in Figure 62).



Figure 62 Vector comparison window

vchk_node_window strobe_delay=3.6ns OUT_PIN

This command checks if the OUT_PIN node matches the expected state given in the vector file 3.6ns after the specified vector strobe time (as shown in Figure 63).

TS = TVS - 1.5 ns

Time

TE = TVS + 2 nsTVS

TVS = Time at Vector StrobingTS = Time StartTE = Time End



Figure 63 Illustration for vchk_node_window

vchk_node_window start=1.8ns end=6.0ns steady=1 OUT_PIN

This example defines a stimulus-triggered steady strobe window starting 1.8ns before the vector strobe and ending 6.0ns after the vector strobe. The OUT_PIN node will pass the vector check if its state stays at the expected state within the strobe window (as shown in Figure 64).

TC1 = TVS1 + 3.6 ns

Time

TVS1

TVS = Time at Vector StrobingTC = Time to Check the state

TC2 = TVS2 + 3.6 nsTVS2




vchk_node_window start=-1.8ns end=6.0ns steady=1 OUT_PIN

This example defines a stimulus-triggered steady strobe window that starts 1.8ns after the vector strobe arrives and ends 6.0ns after the vector strobe arrives. Node OUT_PIN will pass the vector check if its state stays at the expected state within the defined strobe window (as shown in Figure 65).

TS = TVS - 1.8 ns

Time

TE = TVS + 6 nsTVS

TVS = Time at Vector StrobingTS = Time StartTE = Time End




vchk_node_window start=90ns end=100ns period=100ns OUT_PIN

This example opens a steady-state strobe window every 100ns for the OUT_PIN node. In each period, the window starts 90ns after the period begins and stays open until the end of the period (as shown in Figure 66).


vchk_node_window start=90ns end=100ns period=100nsfirst=5ns OUT1

TS = TVS + 1.8 ns

Time

TE = TVS + 6 ns

TVS = Time at Vector Strobing

TVS


0.0 ns 100 200 300 400

90 190 290 390

Time


Appendix B: Detailed Configuration Command InformationDefining Causality Relationships between Nodes with define_n2n_cause (BDC)

This example opens a steady-state strobe window every 100ns for the OUT1 node. The first period begins at 5ns. In each period, the window starts at 90ns after the period begins and remains open until the end of the period (see Figure 67).


vchk_node_window start=90ns end=100ns period=100nsfirst=5ns * except=foo*,bar*

This example has the same effect as displayed in Figure 67 for all nodes except those starting with foo and bar.

The state comparison starts after the first period or the first comparison vector specified in the vector file, whichever happens later.

If you use Syntax 1 or Syntax 3, the simulator only checks state levels (ZERO, ONE, UNDEF) and ignores state attributes. See “Logic States” in the Circuit Simulation and Analysis Tools Reference Guide for the definition of state levels and state attributes.

Defining Causality Relationships between Nodes with define_n2n_cause (BDC)

NanoSim does not report delays if it cannot trace the causality path between the source and sink. This can happen when the circuit is very large and complex. You can use the NanoSim BDC option to define the causality between intermediate nodes to help NanoSim track the causality. However, the NanoSim BDC option can only trace digital causality. In most cases, the input voltage swings to a sense amplifier in an SRAM are not rail-to-rail; therefore, you need to use the define_n2n_cause command to define the causality between the sense amp’s input node and output node. Once you define this causality, BDC

0.0 ns

105

200 300 400

95 195 295 395

Time

100

205 305 405


Appendix B: Detailed Configuration Command InformationMeasuring Delay between Source and Sink Nodes (BDC)

can trace the causality from the primary input to the primary output. The bold line in Figure 68 is the causality traced by BDC while the dotted line is the causality you defined with this command.

In the following example, the define_n2n_cause command is used in conjunction with the set_ckt_cmd command:

set_ckt_cmd senseamp define_n2n_cause blb - do -

This command tells BDC that every change (either rising or falling) of node do in subcircuit senseamp is caused by the change of node blb in subcircuit senseamp. With this command setting, BDC does not search for the cause of the transition on do, because you defined it as having been caused by blb.

Figure 68 SRAM read operation causality path

Measuring Delay between Source and Sink Nodes (BDC)

The meas_n2n_delay command measures the delay from source nodes to the sink nodes on the specified edges of the signal:

meas_n2n_delay b rise OUT -

row

dec

ode

r

causality pathRAM array

column selector

sense amp

output buffer

the dotted line is definedby define_n2n cause

blb

do


Appendix B: Detailed Configuration Command InformationUsing print_meas_path (BDC)

This example measures the delay from the rising edge of node b to either the rising or falling edge of node OUT (as shown in Figure 69).

Figure 69 Schematic and waveforms

In Figure 69, the falling edge of OUT is caused by the rising edge of b; therefore, you will see the following line in the nanosim .sdf output file:

(IOPATH (posedge b) out (0:0:0) (6.000:6.000:6.000))

Using print_meas_path (BDC)

The print_meas_path command prints the source-node-to-sink-node paths found by BDC to the .path file. BDC finds the causality paths to all the sink nodes in all meas_n2n_delay commands specified in the configuration file; this command will print nothing if you did not specify meas_n2n_delay in the configuration file:

meas_n2n_delay b - out - print_meas_path

This example prints, to the .path file, the delay time from the b rising edge to the out falling edge. See Figure 70.

ab

c

d

e OUT

5 10 15

a

b

c

d

e

out


Appendix B: Detailed Configuration Command InformationUsing print_node_path (BDC)


Example 147 shows the paths reported given the waveforms in Figure 70.

Example 147 Resulting nanosim.path file Path from b to out:

Node b is rising at time 7.5nsNode d is falling at time 9.5nsNode e is rising at time 11.5nsNode out is falling at time 13.5ns

Using print_node_path (BDC)

The print_node_path command prints every path that causes the specified nodes to transition even if the source node that causes the transition is not specified. The output of this command is reported in the .node_path file:

meas_n2n_delay b - out -print_node_path OUT*

This example prints every path that causes the OUT* node to transition. See Figure 71.

ab

c

d

e out

5 10 15

a

b

c

d

e

out


Appendix B: Detailed Configuration Command InformationSetting Slope Threshholds (BDC)


Example 148 shows the paths print_node_path reports given the waveforms in Figure 71.

Example 148 Sample nanosim.node_path filePath from b to out:

Node b is rising at time 7.5Node d is falling at time 9.5Node e is rising at time 11.5Node out is falling at time 13.5

Path from c to out: Node c is rising at time 16Node e is falling at time 18.5Node out is rising at time 20.5

Setting Slope Threshholds (BDC)

The set_meas_thresh command sets low and high thresholds of the slope measurement. The slope thresholds are specified as factors of VDD. The default measurement of a signal slope is from 0.3*VDD to 0.7*VDD:

ab

c

d

e out

5 10 15

a

b

c

d

e

out


Appendix B: Detailed Configuration Command InformationSetting Slope Threshholds (BDC)

set_meas_thresh 0.1 0.9

This example sets the slope measurement low threshold to 0.1*VDD and the high threshold to 0.9*VDD (see Figure 72).

Figure 72 Sample slope measurement

To print slope information in the SDF file, you need to use the set_meas_thresh command along with the print_meas_cmt command.

Example 149 displays a nanosim.sdf file generated by the print_meas_cmt command:

Example 149 nanosim.sdf file sample (CELL (INSTANCE *) //(TRANS CLK (0.080:0.080:0.080) (0.080:0.080:0.080)) 1 (DELAY (ABSOLUTE (IOPATH (posedge CLK) DO[0] (0.798:0.835:0.835) (0.838:0.855:0.855)) //(TRANS DO[0] (0.008:0.008:0.008) (0.008:0.007:0.007)) //(AT_TIME DO[0] (110.898:30.935:30.935) (20.938:120.955:120.955)) (IOPATH (posedge CLK) DO[1] (0.798:0.835:0.835) (0.838:0.855:0.855)) //(TRANS DO[1] (0.008:0.008:0.008) (0.008:0.007:0.007))

//(AT_TIME DO[1] (110.898:30.935:30.935) (20.938:120.955:120.955))

slope


CCTcl Command Support

This appendix describes Tcl command support. NanoSim is supported by a large set of built-in commands that can satisfy the requirements of most simulation projects. However, in some cases, the built-in commands are not enough to run efficient simulations.

Overview

To give you more flexibility, the Circuit Simulation Tools’ interactive mode is built to support Tcl (Tool Command Language) commands. You can enhance the simulation tools with Tcl commands to create short cuts, automate processes, or address any other needs that are not supported or insufficiently supported by the built-in commands.

Setting Up Tcl Mode

Some Tcl commands are already supported by the simulator before Tcl mode is enabled. To make sure that the parser can understand the Tcl commands correctly, you must enable the Tcl mode using the set_cmd_mode configuration command.

See the following command:

set_cmd_mode tcl_on

This command enables the Tcl mode.

See the following command:

set_cmd_mode tcl_off


Appendix C: Tcl Command SupportLimitations of Tcl Mode

This command disables the Tcl mode.

Limitations of Tcl Mode

The brackets ([ ]) and dollar sign ($) are special characters in Tcl. Names that have these characters need to have a backslash (\) preceding each special character to avoid misinterpretation. When Tcl mode is enabled, you cannot use a semicolon (;) as a comment in a configuration file because Tcl interprets it as a command separator. The simulator automatically sets the comment character to the pound sign (#) when it switches to Tcl mode.

Tcl Commands

The following Tcl commands are the most commonly used.

With these and other commands, you can create custom subroutines or load Tcl scripts into the interactive mode.

Tcl Command Examples

The following examples show some of the uses of Tcl commands:

This built-in Tcl command in Example 150 re-executes the command in the second event of the history list.

Example 150 Second event re-execution!2orhistory redo 2

Example 151 executes the UNIX ls command.

Example 151 UNIX ls commandexec ls

set node “sum* except=sum1*,sum2*,sum3*”eval “print_node_logic $node”eval “print_node_v $node”


Appendix C: Tcl Command SupportConfiguration Commands that Work with Tcl

These Tcl commands in Example 152 execute the following simulator commands:

Example 152 Simulator commandsprint_node_logic sum* except=sum1*,sum2*,sum3*print_node_v sum* except=sum1*,sum2*,sum3*

Example 153 shows you how to access an environment variable, store it in a variable, and then use the variable containing the environment variable.

Example 153 Environment variablesputs “My home directory is $env(HOME)”set myhome $env(HOME)puts “My home directory is still $myhome”

Example 154 registers a subroutine called PNS_100ns with an input parameter of node. A call to this subroutine in the interactive mode (for example, PNS_100ns out, will cause the the simulator to execute the commands cont 10ns; pns out ten times.

Example 154 Subroutine exampleproc PNS_100ns {node} { \for {set i 0} {$i < 10} {incr i 1} \{puts [cont 10ns];puts [pns $node]}}

In Example 155, the capacitance of node in is stored in $b.

Example 155 Node capacitanceregexp {Cap[a-zA-Z][ :]+([0-9\.]+)fF} \[get_node_info in] a b

Configuration Commands that Work with Tcl

The configuration command outputs that work with Tcl commands are shown in Table 128:

Table 128 Configuration commands compatible with Tcl commands

get_cmd_help iget_elem_info

get_elem_iavg iget_node_i


Appendix C: Tcl Command SupportConfiguration Commands that Work with Tcl

get_elem_ipeak iget_node_iavg

get_elem_irms iget_node_info

get_elem_info iget_node_ipeak

get_inst_param iget_node_irms

get_mos_info iprint_node_cap

get_node_conn itrace_node_aconn

get_node_i itrace_node_conn

get_node_iavg itrace_node_trig

get_node_ipeak itrace_stage_conn

get_node_irms list_elem_index

get_node_info list_elem_name

get_probe_i list_node_index

get_probe_iavg list_node_name

get_probe_ipeak report_stage_large

get_probe_irms trace_node_aconn

get_sim_phase trace_node_conn

get_sim_time trace_node_trig

get_stage_info trace_stage_conn

iget_elem_i

Table 128 Configuration commands compatible with Tcl commands


DDError Output File

This appendix describes the .err file and the Viewerror utility that you can use to read the error file. All NanoSim timing, power, and logic errors are written to an error file.

Reporting Warnings and Errors to the .err File

Synopsys 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 a Synopsys file banner that contains the name of the program generating the error file and the time the file is generated.

Description of Error Messages and Warnings

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.

The first three fields are common to all error messages and are described in Table 129.

Table 129 Fields common to all error messages

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)


Appendix D: Error Output FileReporting Warnings and Errors to the .err File

There are 10 different types of error/warning codes (T_codes), each of which has an associated 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 Table 130.

A description code (D_Codes) describes a T-Code 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. The additional fields for specific D-codes are shown directly after those codes.

Comparison Errors

See the following descriptions for comparison errors:

Table 130 Error/warning T-Code descriptions

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

T-Code 9 Multiple toggle error

T-Code 10 Multiple pulse error

T-Code 11 Excessive voltage error

Table 131 Type 1 T-Code: Comparison Error

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

Table 132 Additional Fields for Comparison Error D-code 9


4 int Simulated value (state number)

5 char Expected value

6 string Node name

Table 133 Type 1 T-Code: Comparison Error (Continued)

D_code 10 The simulated result differs from the expected results during the strobe window.

The simulated result differs from the expected results during the stimulus-triggered strobe window.

D_code 11 The simulated result differs from the expected results during the stimulus-triggered strobe window.

Table 134 Additional Fields for Comparison Error D-Code 11


Table 131 Type 1 T-Code: Comparison Error



Timing Errors

See the following descriptions for timing errors:

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

8 string Node name

Table 135 Type 2 T-Code: Timing Errors

D_Code 1 Setup time violation/tolerance

D_Code 2 Hold time violation/tolerance

D_Code 3 Edge-to-edge violation/tolerance

Table 136 Additional Fields for Timing Errors D-Code 3


4 string Node1 name

5 int Direction (0: rising |1: falling | 2: changing)

6 float Occurred time of node1

7 string Node2 name



10 float Time diff (abs (field 9 - field 6))

Table 134 Additional Fields for Comparison Error D-Code 11



11 string “Min/Max”

12 float Time required

13 string Hierarchical name of the timing checking element or “-cfg”, if the timing check element is specified in a configuration file

Table 137 Type 2 T-Code: Timing Errors (Continued)

D_Code 4 Pulse width violation/tolerance



4 string Node name


6 float Occurred time



9 float Pulse width


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



D_Code 6 SetupHold time violation/tolerance







6 float Reference edge occurred time



9 float Checked edge occured time

10 float Time difference between reference and checked edges

11 string "Min"

12 float Setup time requirement

13 float Hold time requirement

14 string Hierarchical name of the timing checking element or "-cfg", if the timing is specified in config file


D_Code 7 Period time violation/tolerance



4 string Node name








9 float Period

10 string "Min/Max"

11 float Period required



D_Code 8 Skew time violation/tolerance










11 string "Min"




12 float Skew time requirement



D_Code 9 Recovery time violation/tolerance




u int Direction (0: rising |1: falling | 2: changing)






11 string "Min"

12 float Recovery time requirement





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 by a timing violation check in the configuration file. The extension -cfg is appended to the message in the .err output file.


D_Code 10 Width time violation/tolerance



4 string Node name





9 float Width

10 float Minimum width required (" -" if default value)

11 float Maximum width required (" -" if default value)




Bus Contention Errors

See the following descriptions for bus contention errors:

High Impedance Condition

See the following descriptions for high impedance conditions:

Table 151 Type 3 T-Code: Bus Contention Error

D_Code 1 Bus contention error

Table 152 Additional Fields for Bus Contention Error D-Code 1


4 string Node name

Table 153 Type 4 T-Code: High Impedance Condition Generated by “report_node_z”

T-Code

D_Code 1 High impedance condition

Table 154 Additional Fields for High Impedance D-Code 1


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



Uncertain State Conditions

See the following descriptions for uncertain state conditions:

Table 155 Type 5 T-Code: Unknown State

D_Code 1 U-state (transition state) duration is too long.

Table 156 Additional Fields for Unknown State D-Code 1


4 string Node name

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

Table 157 Type 5 T-Code: Unknown State (Continued)

D_Code 2 U-state (transition state) duration is too short.

Table 158 Additional Fields for Unknown State D-Code 2


4 string Node name

5 float U-state end time

6 int Internal state number for unknown state (U/Z/Y)



Timing Error with Timing Tolerance Margin

See the following descriptions for timing errors with timing tolerance margins:

Table 159 Type 6 T-Code: 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

Table 160 Additional Fields for Timing Errors Tolerance Margin D-Code 3


4 string Node1 name



7 string Node2 name



10 float Time diff (abs (field 9 - field 6))


12 float Time required

13 float Tolerance margin

14 string Hierarchical name of the timing checking element or configuration file name, if the timing check element is specified in a configuration file



Table 161 Type 6 T-Code: Timing Errors With Tolerance Margin Specified (Continued)

D_Code 4 Pulse width violation/tolerance

Table 162 Additional Fields for Timing Errors Tolerance Margin D-Code 4


4 string Node name





9 float Pulse width.


11 float Width required



Table 163 Type 6 T-Code: Timing Errors WIth Tolerance Margin Specified (Continued)

D_Code 5 Edge-to-edge window violation/tolerance



Block Delay Characterization Error

See the following descriptions for block delay characterization errors:

Table 164 Additional Fields for Timing Errors Tolerance Margins D-Code 5




6 float Reference edge occurred time.



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


Table 165 Type 7 T-Code: Block Delay Characterization Error

D_code 1 No delay path

Table 166 Additional Fields for Block Delay D-Code 1




Power Diagnosis

See the following descriptions for power diagnosis:

4 string Node name

Table 167 Type 7 T-Code: Block Delay Characterization Error

D_code 2 No delay path

Table 168 Additional Fields for D-Code 2


4 int 0|1|2 for rising|falling|changing

5 int 0|1|2 for rising|falling|changing

6 string Node name

7 string Node name

Table 169 Type 8 T-Code: Power Diagnosis

D_Code 1 Static Partial-Swing Detection (NMOS)

Syntax: 0 8 1 <node_name>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)

Syntax: 0 8 2 <node_name>Definition: Node is driven by NMOS transistors only, and it drives at least one PMOS fanout transistor.

D_Code 3 Static VDD Path Problem

Table 166 Additional Fields for Block Delay D-Code 1



Syntax: 0 8 3 <node_name>Definition: No possible conducting path to VDD.

D_Code 4 Static GND Path Problem

Syntax: 0 8 4 <node_name>Definition: No possible conducting path to GND.

D_Code 5 Static DC Path to VDD

Syntax: 0 8 5 <node_name> (<t_0>) <n_1> (<t_1>) <n_2> ... <n_k> (<t_k>) <vdd>Definition: A static DC conducting path from <node_name> to VDD is detected. The path consists of elements <t_0> ... <t_k> and nodes <node_name>, <n_1>, ..., <n_k>, and Vdd.

D_Code 6 Static DC Path to GND

Syntax: 0 8 6 <node_name> (<t_0>) <n_1> (<t_1>) <n_2> ... <n_k> (<t_k>) <gnd>Definition: A static DC conducting path from <node_name> to GND is detected. The path consists of elements <t_0> ... <t_k> and nodes <node_name>, <n_1>, ..., <n_k>, and Gnd.

D_Code 7 Static DC Leakage Path between two power supply nodes

Syntax: 0 8 7 <vsrc_1> (<t_1>) <n_1> (<t_2>) <n_2> ... <t_k>) <n_k> (<t_k+1>) <vsrc_2> Definition: A static conducting path exists between supply nodes <vsrc_1> and <vsrc_2> of different voltages. The path consists of nodes <n_1> through <n_k>, and branches <t_1> through <t_k+1>.

D_Code 8 Node Stuck at Logic 1 at All Times

Syntax: 0 8 8 <node_name> (<t_0>) <n_1> (<t_1>) <n_2> ... <n_k> (<t_k>) <vdd>Definition: A static DC conducting path from <node_name> to Vdd and no possible conducting path to GND.

D_Code 9 Node Stuck at Logic 0 at All Times

Syntax: 0 8 9 <node_name> (<t_0>) <n_1> (<t_1>) <n_2> ... <n_k> (<t_k>) <gnd> Definition: A static DC conducting path from <node_name> to GND and no possible conducting path to VDD.




D_Code 10 Static Excessive-Rise/Fall Time Problem

Syntax: 0 8 10 <node_name> <est_rf_time> Definition: Node with an excessive rise/fall time "est_rf_time" by static estimation.

D_Code 11 Static Excessive-Rise/Fall Time Problem

Syntax: <time_start> 8 11 <node_name> <time_end> 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: <time_start> 8 12 <node_name> <time_end> <state_num> 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 <state_num> is an internal state number for state (L, H, Z).

D_Code 13 Excessive Branch Current

Syntax: <time_start> 8 13 <branch_name> <time_end> <current_ave> Definition: Excessive branch current detected for <branch_name> from <time_start> to <time_end>. The average current between <time_start> and <time_end> is <current_ave>.

D_Code 14 Partial off PMOS

Syntax: <time_start> 8 14 <branch_name> <ns> (<t_1>) <n_1> ... (<t_n>) <vddh> ||| <nd> (<t_k>) <n_k> ... (<t_m>) <vsrc> ||| <ng> (<t_j>) <n_j> ... (<t_q>) <vddl> Definition: A PMOS transistor <branch_name> has a possible channel-connect path to power supply <vddh>, and its gate terminal has a possible path to another power supply node <vddl>, where the voltage of vddl is less than vddh. It is possible that <branch_name> will not turn off when its gate terminal <ng> is driven to logic 1, resulting in a dc leakage path between <vddh> and the voltage source <vsrc>.

D_Code 15 Partial off NMOS




Syntax: <time_start> 8 15 <branch_name> <ns> (<t_1>) <n_1> ... (<t_n>) <gndl> ||| <nd> (<t_k>) <n_k> ... (<t_m>) <vsrc> ||| <ng> (<t_j>) <n_j> ... (<t_q>) <gndh> Definition: An NMOS transistor <branch_name> has a possible channel-connect path to power supply <gndl>, and its gate terminal has a possible path to another power supply node <gndh>, where the voltage of gndl is less than gndh. It is possible that <branch_name> will not turn off when its gate terminal <ng> is driven to logic 0, resulting in a dc leakage path between <gndl> and the voltage source <vsrc>.

D_Code 16 Forward bias PMOS

Syntax: <time_start> 8 16 <branch_name> <ns> (<t_1>) <n_1> ... (<t_n>) <vddh> ||| <vddl> Definition: A PMOS transistor <branch_name> has a possible channel-connect path to power supply <vddh>, and its bulk terminal is connected to another power supply node <vddl>, 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 <vddh> and <vddl>.

D_Code 17 Forward bias NMOS

Syntax: <time_start> 8 17 <branch_name> <ns> (<t_1>) <n_1> ... (<t_n>) <gndl> ||| <gndh> Definition: An NMOS transistor <branch_name> has a possible channel-connect path to power supply <gndl>, and its bulk terminal is connected to another power supply node <gndh>, 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 <gndh> and <gndl>.

D_Code 18 Instantaneous Current/Power Exceeds Budget

Syntax: <time_start> 8 18 <probe_name>Definition: The instantaneous current/power for the report_block_powr created probe <probe_name> has exceeded its current/power budget at <time_start>.

D_Code 19 Instantaneous Current/Power Exceeds Budget at Least Once

Syntax: <time_start> 8 19 <probe_name> <current_val> <current_thresh>Definition: The instantaneous current/power for the report_block_powr created probe <probe_name> has exceeded its current/power budget of <current_thresh> at least once during the dynamic simulation. The peak current observed was <current_val>.




The set of D-codes used for power diagnosis error messages uses field names that are defined in Table 170.

D_Code 20 Average Current/Power Exceeds Budget

Syntax: <time_start> 8 20 <probe_name> <current_val> <current_thresh>Definition: The average current/power <current_val> for the report_block_powr created probe <probe_name> exceeds its current/power budget of <current_thresh>.

D_Code 21 RMS Current/Power Exceeds Budget

Syntax: <time_start> 8 21 <probe_name> <current_val> <current_thresh>Definition: The RMS current/power <current_val> for the report_block_powr created probe <probe_name> exceeds its current/power budget of <current_thresh>.

D_Code 22 Wasted Current Percentage Exceeds Budget

Syntax: <time_start> 8 21 <probe_name> <current_val> <current_thresh>Definition: The wasted current percentage <current_val> for the report_block_powr created probe <probe_name> exceeds its budget of <current_thresh>.

Table 170 D-Code field names and their data types

Field Name Data Type

<branch_name> string

<current_ave> float

est_rf_time float

<node_name> string

<n_i> string

<state_num> Integer number as .out to represent L|H|X state

<time_end> float

<time_start> float




Multiple-Toggle Error

See the following descriptions for multiple-toggle errors:

Multiple-Pulse Error

See the following descriptions for multiple-pulse errors:

<t_i> string

Table 171 Type 9 T-Code: Multiple-Toggle Error

D_Code 1 Node toggled more than once in a user-specified period of time

Table 172 Additional Fields for Multiple-Toggle Error D-Code 1


4 string Node name

5 float Last time node changed state

Table 173 Type 10: Multiple-Pulse Error

D_Code 1 Node has more than one pulse in a user-specified period of time.

Table 174 Additional Fields for Multiple-Pulse D-Code 1


4 string Node name

5 float Time the last pulse started

Table 170 D-Code field names and their data types (Continued)

Field Name Data Type



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.



4 string Node name

5 float Time the last pulse started



8 float Time the reference pulse started

9 int Reference pulse state 0: low; 1: high)






D_Code 3 Node has a single pulse inside the pulse of the reference node.



4 string Node name

5 float Time the single pulse started




9 int Reference pulse state (0: low; 1: high)



D_Code 4 Node does not have a pulse inside the pulse of the reference node.





4 string Node name

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

4 string Node name




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







Excessive Voltage Error

See the following descriptions for excessive voltage errors:


D_Code 7 Node has no pulse in a user-specified period of time.



1 float Time when the no-pulse error is detected



3 int Error description code (6)

4 string Node name




Table 187 Type 11 T-Code: Excessive Voltage Error

D_Code 1 Node voltage higher than specified high_thresh



Syntax: <time_start> 11 1 <node_name> <time_end> <low_thresh> <high_thresh> <t_thresh>Definition: From <time_start> to <time_end>, a node’s voltage stays higher than <high_thresh>.

D_Code 2 Node voltage lower than user specified low_thresh

Syntax: <time_start> 11 2 <node_name> <time_end> <low_thresh> <high_thresh> <t_thresh>Definition: From <time_start> to <time_end>, a node’s voltage stays lower than <low_thresh>.

D_Code 3 Node voltage falls between specified low_thresh and high_thresh

Syntax: <time_start> 11 3 <node_name> <time_end> <low_thresh> <high_thresh> <t_thresh>Definition: From <time_start> to <time_end>, a node’s voltage stays lower than <low_thresh>.

D_Code 5 Excessive MOS Vds

Syntax: <time_start> 11 5 <elem_name> <time_end> <v1> <t_thresh>Definition: The Vds <elem_name> continues to be excessive from <time_start> to <time_end> when <v1> is larger than 0, which causes the drain source to stay higher than <v1>. If <v1> is smaller than 0, then the Vds stays lower than <v1>.

D_Code 6 Excessive MOS Vgs

Syntax: <time_start> 11 6 <elem_name> <time_end> <v2> <t_thresh>Definition: The Vgs <elem_name> continues to be excessive from <time_start> to <time_end> when <v2> is larger than 0, which causes the Vgs to stay higher than <v2>. If <v2> is smaller than 0, then the Vgs stays lower than <v2>.

D_Code 7 Excessive MOS Vgd

Syntax: <time_start> 11 7 <elem_name> <time_end> <v3> <t_thresh>Definition: The Vgd <elem_name> continues to be excessive from <time_start> to <time_end> when <v3> is larger than 0, which causes the Vgd to stay higher than <v3>. If <v3> is smaller than 0, then the Vgd stays lower than <v3>.

D_Code 8 Excessive MOS Vgb




Syntax: <time_start> 11 8 <elem_name> <time_end> <v4> <t_thresh>Definition: The Vgb <elem_name> continues to be excessive from <time_start> to <time_end> when <v4> is larger than 0, which causes the Vgb to stay higher than <v4>. If <v4> is smaller than 0, then the Vgb stays lower than <v4>.

D_Code 9 Excessive MOS Vdb

Syntax: <time_start> 11 9 <elem_name> <time_end> <v5> <t_thresh>Definition: The Vdb <elem_name> continues to be excessive from <time_start> to <time_end> when <v5> is larger than 0, which causes the Vdb to stay higher than <v5>. If <v5> is smaller than 0, then the Vdb stays lower than <v5>.

D_Code 10 Excessive MOS Vsb

Syntax: <time_start> 11 10 <elem_name> <time_end> <v6> <t_thresh>Definition: The Vsb <elem_name> continues to be excessive from <time_start> to <time_end> when <v6> is larger than 0, which causes the Vsb to stay higher than <v6>. If <v6> is smaller than 0, then the Vsb stays lower than <v6>.

D_Code 11 Excessive BJT Vce

Syntax: <time_start> 11 11 <elem_name> <time_end> <v1> <t_thresh>Definition: The Vce <elem_name> continues to be excessive from <time_start> to <time_end> when <v1> is larger than 0, which causes the Vce to stay higher than <v1>. If <v1> is smaller than 0, then the Vce stays lower than <v1>.

D_Code 12 Excessive BJT Vbe

Syntax: <time_start> 11 12 <elem_name> <time_end> <v2> <t_thresh>Definition: The Vbe <elem_name> continues to be excessive from <time_start> to <time_end> when <v2> is larger than 0, which causes the Vbe to stay higher than <v2>. If <v2> is smaller than 0, then the Vbe stays lower than <v2>.

D_Code 13 Excessive BJT Vbc

Syntax: <time_start> 11 13 <elem_name> <time_end> <v3> <t_thresh>Definition: The Vbc <elem_name> continues to be excessive from <time_start> to <time_end> when <v3> is larger than 0, which causes the Vbc to stay higher than <v3>. If <v3> is smaller than 0, then the Vbc stays lower than <v3>.

D_Code 14 Excessive DIODE Vca




Syntax: <time_start> 11 14 <elem_name> <time_end> <v1> <t_thresh>Definition: The Vca <elem_name> continues to be excessive from <time_start> to <time_end> when <v1> is larger than 0, which causes the Vca to stay higher than <v1>. If <v1> is smaller than 0, then the Vca stays lower than <v1>.

D_Code 15 Excessive DIODE Vac

Syntax: <time_start> 11 15 <elem_name> <time_end> <v2> <t_thresh>Definition: The Vac <elem_name> continues to be excessive from <time_start> to <time_end> when <v2> is larger than 0, which causes the Vac to stay higher than <v2>. If <v2> is smaller than 0, then the Vac stays lower than <v2>.



Appendix D: Error Output FileViewing the Error File with the Viewerror Utility

The .err File Sample

See Example 156 for an .err file sample.

Example 156 Sample .err file output

;! error_format 5.2; --------------------------------------------------------;| |;| NanoSim Version 2001.06;| SN: P042498-SunOS_5 |;| Copyright (c) 2001 Synopsys Inc., All Rights Reserved. |;| |; --------------------------------------------------------;;Built by hmchen in " sun50504 " on Mon May 4 20:51:51 PDT 2001; Wed May 6 17:36:46 2001; ;This is a comment11.00 1 1 1 0 n1 ;comparison error12.00 1 2 1 H n3 ;comparison error12.00 1 4 1 T n5 ;comparison error13.00 1 5 7 1 n19 ;comparison error14.00 1 6 9 0 n6 ;comparison error14.00 1 7 3 ? n6 ;comparison error30.00 2 1 n1 1 30.7 n2 0 30.8 0.1 Min 10-cfg;setup violation30.00 6 1 n1 1 30.7 n2 0 30.8 0.1 Min 10 0.1;setup violation warning45.00 2 2 n3 0 40.7 n4 1 60.8 20.1 Max 10-cfg;hold violation100.00 2 3 n2 0 40.7 n4 1 60.8 20.1 Max 10-cfg;edge to edge145.00 2 4 n3 0 40.7 1 45.7 5.0 min 10;pulse violation150.00 3 1 n1 ;bus contention200.00 4 1 n2 202.00 4 ;high impedance condition200.00 5 1 n2 200.2 2 ;Unknown state;end; Total number of errors in this file: 14

Viewing the Error File with the Viewerror Utility

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.



Command Syntax


viewerror

[-i file_name] [-m number_of_messages][-n nodenames][-o file_name] [-p type] [-s][-t t1 t2 ... tx,ty]

Command-line Options

The viewerror command-line options are

-i file_name

This specifies the input file, for example,

nanosim.err

. If you do not specify the file name, the program searches for nanosim.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 file_name

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, the -p option prints out all the error messages of the given type for the nodes specified in -n. Table 188 shows the 10 different types of error messages:

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

Table 188 Timing 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



-t time1 time2 timex,timey

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.




EESupporting SPICE Models

This appendix describes SPICE model support within NanoSim.

SPICE Models Supported in NanoSim

NanoSim supports direct SPICE models as shown in Table 189:

Table 189 Direct SPICE model support

Direct model Supported SPICE Level

BJT Gummel-Poon ■ HSPICE level 1■ Eldo level 1, 2

BJT (HiCUM level 0) ■ HSPICE level 13■ Eldo level 24■ Spectre model BHT0

BJT (HiCUM level 2) ■ HSPICE level 8 (version 2.1, 2.2)■ Eldo level 9 (version 2.1, 2.2)■ Spectre model BHT (version 2.1, 2.2 Beta)

DIODE ■ Eldo level 1, 2, 3, 8■ HSPICE level 1, 2, 3

DIODE JUNCAP2 ■ HSPICE level 6 (version 200.0, 200.1)■ Eldo level 8 (diolev=11)■ Spectre model JUNCAP200 (level=200)

JFET HSPICE level 1, 2

MESFET HSPICE level 3


Appendix E: Supporting SPICE ModelsSPICE Models Supported in NanoSim

MEXTRAM ■ HSPICE level 6 (vers 503, 504)■ Eldo level 4 (503), 22 (504)■ Spectre model bjt503, bjt504

MOSFET (BSIM1) ■ HSPICE level 13■ Eldo level 8■ Spectre

MOSFET (BSIM2) ■ HSPICE level 39■ Spectre

MOSFET (BSIM3v3) ■ ELDO level 53 (version 3.2.4)■ HSPICE level 49, 53 (version 3.3.0)■ Spectre model BSIM3v3 (version 3.3.0)

MOSFET (BSIM4) ■ Eldo level 60 (version 4.3, 4.4, 4.5 Beta)■ HSPICE level 54 (version 4.3, 4.4, 4.5, 4.6)■ Spectre model BSIM4 (version 4.3, 4.4, 4.5 Beta)

MOSFET (BSIM4SOI) HSPICE level 70

MOSFET (BSIM4.4+JUNCAP2)

■ Eldo level 60 (version 4.4, diolev 11, jcver 1 for 200.0 version, jcver 2 for 200.1 version)

■ HSPICE level 54 (version 4.4, juncap 2, jcap2version 200 for 200.0 version, jcap2version 200.1 for 200.1 version)

MOSFET (BSIMSOI) HSPICE level 57

MOSFET (EKV) ■ HSPICE level 55■ Eldo level 44■ Spectre

MOSFET (HVMOS) HSPICE level 66

MOSFET (HVMOS) Spectre HVMOS

MOSFET (MOS9.03) ■ Eldo level 59■ HSPICE level 50■ Spectre

Table 189 Direct SPICE model support (Continued)




NanoSim supports Gentech SPICE models as shown in Table 190:

NanoSim also supports some proprietary variations of SPICE. See your Synopsys representative for more information.

MOSFET (MOS11) ■ HSPICE level 63 (version 1100, 1102.0, 1102.1)■ Spectre model MOS1100 (level 1100), MOS11020

(level 11000), MOS11021 (level 11000) ■ Eldo level 69 (scalelev 11020, 11021)

MOSFET PSP ■ HSPICE level 69 (version 100, 100.1, 102)■ Spectre model PSP100 (version 100)■ Eldo level 70 (version 100)

NOR Flash Proprietary NOR Flash

VBIC ■ HSPICE level 4, 9■ Spectre

Table 190 Gentech SPICE models supported

Format Supported Models

Old format MOS models

New format Any general SPICE bulk MOS model for all supported SPICE types. Special internal calculations are done for the models:■ HSPICE level 28, 33 ■ Eldo level 1, 3, 4

Table 189 Direct SPICE model support (Continued)





Index

Symbols!append 284$EPIC_HOME 70*.err file 463

A-A command-line option 128ADFMI Model

replacing transistor level block 45ADFMI model

debugging (-DFM) 56using the -FM (-fm) command-line options 56

ADFMI models 44alias commands 78aliases

creating 78ALTER statement 363analog circuit simulation 109–130analog simulations 42autodetection selection 123automatic techfile generation 69

Bback-annotation post-layout flow 197batch mode 53batchfile 254

batchrun command 291DATA command 294FILE command 293format 293RUN command 294

batchrun program 254BDC

error reporting 256features 241list of commands 244measurement report 256set_sim_spd 241

bipolar junction transistors, simulating 129

bisection optimization 329block power analysis 170, 173branch, See elementbreakpoints (interactive) 104BSIM1 models 69BSIM2 models 69BSIM3 v3 models 69BTA HVMOS models 69build_model_bdc 102, 244

CCadence SPF netlist format 60capacitance

measuring 246measuring in BDC 246

causality path, defining 245chip-level power analysis 167command arguments

argument tag 83argument unit 79changing units 82specifying arguments 79

command-line options-A 128

comment line, in .epicrc file 72configuration commands 22

assign_branch_i 181, 195assign_node_i 181, 195define_n2n_cause (BDC) 245limit_dcpath_search 188meas_n2n_delay (BDC) 245meas_node_cap (BDC) 246print_branch_i 195print_meas_cmt (BDC) 246, 259print_node_i 169, 194, 195print_probe_i 182, 194report_block_leakage 171report_block_powr 170, 194report_ckt_dcpath 188report_ckt_leak 190

501

IndexD

report_ckt_phist 182report_elem_exi 185, 195report_elem_i 182report_node_hotspot 185report_node_i 169, 182, 195report_node_maxrf 191report_node_powr 169, 182report_node_quick 184report_node_u 184report_node_z 185report_probe_i 182, 194search_ckt_analog 123search_ckt_cpump 123search_ckt_logic 124search_ckt_mem 123search_ckt_msx 123, 124search_ckt_rc 124search_ckt_ud 124set_dcpath_thresh 188set_elem_acc 127set_elem_pwl 127set_elem_sms 127set_elem_sync 128set_har_post_layout 94set_hotspot_factor 187set_meas_pulsew (BDC) 245set_meas_thresh (BDC) 246set_node_spd 126set_node_thresh 184, 192set_print_ires 127set_print_iwindow 183set_print_tres 127set_print_vres 127set_sim_spd 241set_sim_subgroup 125set_sim_tres 125use_sim_case 53

configuration commands, list of basic commands 66

configuration commands, listing 75configuration file, editing from the Workbench 35configuration files 65CosmosScope, waveform viewer 266, 286current printing and reporting

block 170element 179histogram 182node 181

probes 181current resolution, controlling 128

DD_codes description codes 464dangling node 387DC initialization 93DC paths

static 190debugging 46define_n2n_cause 102, 244delay measurement

in BDC 245diagnosing power problems

dynamic 184static 189

digital vector format 347digital vector format, checking 348direct 497double-precision mode 128dynamic power analysis 184

EEdisplay utility 277

control file 283syntax 278

edisplay utility 273element

current printing 179printing branch currents 179

environment parameters 51.epicrc file

description 54sample 72

epicrc fileSee .epicrc file 72

event generation, changing 425event resolution voltage (esv), setting 125event sensitivity, applying 126

Ffile samples

.epicrc file 72nanosim.cnt file 402nanosim.dcpath file 264, 422nanosim.hist file 267, 424

502

IndexG

nanosim.log file 383nanosim.log file (block power report) 414nanosim.nodealias file 406nanosim.out file 393nanosim.power file 418nanosim.rcxt file 381nanosim.stat file 418nanosim.sum file 272, 413

filesoutput 261–272SDF 255See .epicrc filesSee input filesSee output files

floating nodes 387functional model

See also ADFMI Manual

GGentech 499Gentech utility 69

HHAR 40, 155

reduction 159sample .log file data 160setup phase 157simulation phase 158terminology 156

abstraction 156array 156controlling node 156core cell 156reduction 156

helpSee also online help 77

Help window 11Hierarchical Array Reduction 40hierarchical array reduction

sample .log file data 160setup phase 157terminology

abstraction 156array 156controlling node 156core cell 156reduction 156

Hierarchy Browser 9

histogram, current 182HSPICE digital vector format 347HSPICE/SPICE netlists 65

Ii (index) command prefix 78ICON Definitions 12index numbers, listing 78input files

configuration 65netlist 60, 65stimulus 69technology 62, 69

input netlist 60interactive commands, alias 79interactive commands, listing 75interactive mode

accessing 78command-line option (-i) 59interactive log file, opening 261tracing signal events 104

interactive mode simulation 46internal power supplies 230IOPATH 256

JJFET models 69

KKirchhoff’s Current Law 181

Lleakage current

detecting DC paths 187measuring 170

LNS reduction, mode 5 239.log file 387LSF 43

MMeas utility 275meas_n2n_delay 102, 244meas_n2n_hold 103, 244meas_n2n_setup 103, 244

503

IndexN

meas_node_cap 103, 244meas_pulse_width 244MESFET models 69message 387mixed-signal simulation 123mode 5, power net simulations 229mode=5 232models (directly supported)

BSIM1 69BSIM2 69BSIM3 v3 69BTA HVMOS 69JFET 69MESFET 69MOS9 69

multirate simulations (ACE) 125

Nnanosim command 52NanoSim environment (graphic) 52NanoSim GUI-Preference default settings 14NanoSim-VCS 39net option, set_sim_eou 112netlist file

formats 65specifying format 60types of stimulus 69

netlist, editing from the Workbench 35NMOS 191node

capacitance, measuring 246current printing 181hotspot checking 185measuring transition time 246U-state checking 184Z-state checking 184

node sensitivity control 125.nodealias file 405nodes

dangling 387floating 387

nWave 36, 273, 286

O.out file 392OUT netlist format 60

output fileactive nodes 381current 392logic states 392node alias names 405simulation statistics 407, 418voltage 392warning messages 387

output file (.err)multiple-toggle errors 483unknown state 474

output file (.log) 387output file (.nodealias) 405

format 405output file (.out)

format 392keywords 398line format 397logic state numbers 402period lines 397, 398signal attributes 400

output file (.rcxt) 381format 381

output file (.stat)format 407, 418

output filescontents of 261–272prefix specification 61

PPAR() function support 377pattern matching 434PMOS 191post-layout flow 198post-layout flow, parasitics 198power

assigning power budgets 175getting power information interactively 176in hierarchical netlists 173measuring true power (in watts) 173

power analysisfull-chip 167printing branch currents 179RC/UD mode 192

power diagnosisdynamic 184static 189

power network (power net) simulations 229

504

IndexR

print resolution, of waveforms 127print_meas_cmt 103, 244print_meas_path 103, 244probes

creating 170, 173, 181printing current 181

Rramped power supplies 230RC (full-delay) simulation mode 192.rcxt file 381Remote Simulation Control (LSF) 43return codes 73RLC reduction technique 232

Sscripts, creating 72SDF file 255sdfcombine command 255selective extraction flow 211selective net back-annotation flow 211set_meas_designname 102, 103, 244set_meas_instname 102, 103, 244set_meas_load 102, 103, 244set_node_esv 126set_node_spd 126set_powernet_default command, mode 5 232set_sim_aesv 126set_sim_aspd 126set_sim_eou

model option 110net option 112sim option 110

set_sim_eou, ease of use 109set_sim_esv 126set_sim_spd 126signal information file, VCD 137simulation

basic 23flow 26memory 409run time 409statistics 409

simulation control 98simulation mode 192

simulation modes 127simulation types 25simulation, interactive mode 46simulations, analog 42speed control, applying 126SPF/SPEF back-annotation flow, mode 5 240Spice models 497, 499SPICE netlist format 60.stat file 407, 418static power analysis 189stimulus descriptions, See netlist filestimulus files 69subcircuit current probing 377

TT_Code description codes 464–491technology files

automatic generation 63, 69specifying 62

time step algorithm, mode 5 233timing constraints

tv_node_edge (illustration) 428tracking intervals, setting 182true power (in watts), measuring 173

UUD (unit-delay) simulation mode 192units

argument units 79changing units 82

utilitiesedisplay 273

utility, vfast 287

VVCD file, signal information 137VCD, direct-read 131VCD, value change dump 131vcd_file option, VCD 132vector files 69Verilog netlist format 60vfast, conversion utility 287Viewerror utility 492

command-line options 493syntax 493

505

IndexW

viewerror utility 256voltage resolution

controlling 128limits 128

Wwarning messages 387wasted power 170

See also, leakage currentwattage report, creating 173

waveform display utilities 286waveform display, changing 425waveform viewers

nWave 273waveform, viewing from the Workbench 36waveforms, print resolution 127

W-element, HSPICE 311

506

Documents

picture.iczhiku.com · 2019. 11. 28. · iii Contents Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi Related