Elc UG

Encounter Library Characterizer User Guide
Product Version 10.1 December 2010
20092010 Cadence Design Systems, Inc. All rights reserved. Printed in the United States of America. Cadence Design Systems, Inc. (Cadence), 2655 Seely Ave., San Jose, CA 95134, USA. Trademarks: Trademarks and service marks of Cadence Design Systems, Inc. (Cadence) contained in this document are attributed to Cadence with the appropriate symbol. For queries regarding Cadences trademarks, contact the corporate legal department at the address shown above or call 1-800-862-4522. All other trademarks are the property of their respective holders. Restricted Print Permission: This publication is protected by copyright and any unauthorized use of this publication may violate copyright, trademark, and other laws. Except as specified in this permission statement, this publication may not be copied, reproduced, modified, published, uploaded, posted, transmitted, or distributed in any way, without prior written permission from Cadence. This statement grants you permission to print one (1) hard copy of this publication subject to the following conditions: 1. The publication may be used solely for personal, informational, and noncommercial purposes; 2. The publication may not be modified in any way; 3. Any copy of the publication or portion thereof must include all original copyright, trademark, and other proprietary notices and this permission statement; and 4. Cadence reserves the right to revoke this authorization at any time, and any such use shall be discontinued immediately upon written notice from Cadence. Disclaimer: Information in this publication is subject to change without notice and does not represent a commitment on the part of Cadence. The information contained herein is the proprietary and confidential information of Cadence or its licensors, and is supplied subject to, and may be used only by Cadences customer in accordance with, a written agreement between Cadence and its customer. Except as may be explicitly set forth in such agreement, Cadence does not make, and expressly disclaims, any representations or warranties as to the completeness, accuracy or usefulness of the information contained in this document. Cadence does not warrant that use of such information will not infringe any third party rights, nor does Cadence assume any liability for damages or costs of any kind that may result from use of such information. Restricted Rights: Use, duplication, or disclosure by the Government is subject to restrictions as set forth in FAR52.227-14 and DFAR252.227-7013 et seq. or its successor.
Contents
About This Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9 Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 How This Manual Is Organized . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Conventions Used in This Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Related Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1 Basics of Cell Library Characterization . . . . . . . . . . . . . . . . . . . . . . . .

What Is Cell Library Characterization? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Automatic Cell Library Characterization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Multiple Cell Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Combinatorial Logic Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tristate Logic Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bidirectional Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sequential Logic Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Multi-Bit Logic Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Interface (Pad) Circuits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pass Transistor Logic Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . State Dependency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Binary Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Characterization Measurement Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pin-to-Pin Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Power Consumption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Input Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Input Loading Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Output Driving Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Non-Linear Table Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . K-Factor Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Effective Current Source Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Distributed Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13 14 14 15 15 15 16 17 19 19 20 20 21 26 27 28 29 30 30 30 30 30 31
December 2010
Product Version 10.1
2 Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Product and Installation Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Setting the Run-Time Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Product Licenses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring the Environment for Parallel Simulations . . . . . . . . . . . . . . . . . . . . . . . . . . . Using IPSD/IPSC for Parallel Simulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using LSF for Parallel Simulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Starting Encounter Library Characterizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Starting Encounter Library Characterizer in Interactive Mode . . . . . . . . . . . . . . . . . . Starting Encounter Library Characterizer in Batch Mode . . . . . . . . . . . . . . . . . . . . . . Starting Encounter Library Characterizer in 64-bit Mode . . . . . . . . . . . . . . . . . . . . . . Online Documentation and Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Text Command Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33 34 34 35 36 36 41 43 45 46 46 48 48
3 Preparing for Library Characterization . . . . . . . . . . . . . . . . . . . . . . . . .

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Inputs to Encounter Library Characterizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPICE Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Encounter Library Characterizer Command File . . . . . . . . . . . . . . . . . . . . . . . . . . . . Simulation Setup File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuration File (elccfg) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Statistical Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Property File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Liberty (.lib) File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Outputs of Encounter Library Characterizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49 50 51 51 51 53 54 57 58 59 59
4 Performing Cell Library Characterization . . . . . . . . . . . . . . . . . . . . . .

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Performing Library Characterization for Standard Cells . . . . . . . . . . . . . . . . . . . . . . . . . Performing Library Characterization using a Pre-driver Cell . . . . . . . . . . . . . . . . . . . . . . Performing ECSM-Based Power Characterization for Level-Shifter Cells . . . . . . . . . . . .
61 62 63 65 67
December 2010
Performing CCS-Based Noise Characterization for Standard Cells . . . . . . . . . . . . . . . . Performing CCS-Based Power Characterization for Standard Cells . . . . . . . . . . . . . . . . Performing SOI Characterization for Standard Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . Performing AAE Characterization for Standard Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . Performing Automatic Index Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating a Simulation Setup File Automatically from an Existing Dotlib . . . . . . . . . . . . . Performing Incremental Characterization using Internal Simulator . . . . . . . . . . . . . . . . . Performing Incremental Characterization using External Simulator . . . . . . . . . . . . . . . . Performing Statistical Characterization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Performing Library Recharacterization Using Different PVT . . . . . . . . . . . . . . . . . . . . . . Creating a Binary Dotlib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Performing Additional Library Characterization Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . Performing Library Characterization Using Gate File . . . . . . . . . . . . . . . . . . . . . . . . . Characterizing Hierarchical Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Generating a Non-Linear Input Slew . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using a Characterized Database to Generate Multiple Views . . . . . . . . . . . . . . . . . .
69 71 73 75 77 80 81 83 85 87 90 91 91 92 93 94
5 Performing Cell Library Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
97
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 ecsmChecker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 libdiff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 LibVsSpice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 EtsvsSpice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
6 Troubleshooting Library Characterization Issues . . . . . . . . . . . .

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Characterizing Failed Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Handling Failures During Various db_spice Stages . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adjusting Transient Time to Prevent Simulation Failure . . . . . . . . . . . . . . . . . . . . . . . . .
109 110 111 112 114
December 2010
A Simulation Setup File Format
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 118 118 118 118 119 122 124 126 129 130 132 133 133 134 136 137 138 138 142 142 147 149
Case-Sensitivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Wildcards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Define Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GROUP Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . INDEX Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MARGIN Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . NOMINAL Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PROCESS Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PWL Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SIGNAL Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SIMULATION Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Control Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SET_CELL Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SET_DEFINES Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SET_GROUP Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SET_PIN Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SET_PROCESS Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . General Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Standard Cell Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Level Shifter Cell Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I/O Cell Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B Property File Format
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Property File Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
C Gate File Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
163
Gate File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
December 2010
Gates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Making Gate File Corrections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating a Gate File to Aid Cell Recognition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .................................................................
165 171 173 174 178
D Bool File Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Boolean Operator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pin Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Logical Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tri-state Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sequential Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using a BOOL File to Aid Cell Recognition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
179 180 181 181 182 182 183 185 187
E Specification File Format
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 189 191 191 193 193 195 195 195 195 196 196 199 199 201
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ARC Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BUNDLE Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CHECK Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . COMPLEMENTARY Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DESIGN Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . END_OF_DESIGN Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . INHIBIT Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . NODE Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PORT Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . REGISTER Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VECTOR Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
December 2010
December 2010
About This Manual

This manual describes how to install, configure, and use the Cadence Encounter library characterizer to perform different types of library characterization tasks.
Audience
This manual is written for library developers who work with standard cell libraries. Such library developers must also have a good understanding of UNIX and Tcl/Tk programming and concepts of cell layout, SPICE modeling, and circuit simulation.
How This Manual Is Organized

The chapters in this manual focus on the concepts and tasks related to a particular type of characterization or topic being discussed. In addition, the following chapters provide prerequisite information for using the Encounter library characterizer software:
Chapter 1, Basics of Cell Library Characterization, Describes the basic concepts related to cell library characterization.
Chapter 2, Getting Started Describes how to install, set up, and run the Encounter library characterizer software, and use the online Help system.
Chapter 3, Preparing for Library Characterization, Describes the inputs for different types of library characterization tasks and the outputs.
Chapter 4, Performing Cell Library Characterization, Describes how to perform basic, incremental, and statistical cell library characterization.
Chapter 6, Troubleshooting Library Characterization Issues, Describes the steps to troubleshoot various library characterization issues.
December 2010
Encounter Library Characterizer User Guide About This Manual
Conventions Used in This Manual

This section describes the typographic and syntax conventions used in this manual. Indicates text that you must type exactly as shown. For example: db_copy -reset text Indicates information for which you must substitute the name or value. In the following example, you must substitute the name of a specific design for design_name: db_copy -design design_name * (asterisk) Indicates the minimum number of characters you must type for it to be a valid shortcut for the command. Only letters to the left of the asterisk are required. If there is no asterisk, you must type the entire word. Do not type the asterisk. In the following example, you only need to type -d in order to specify the -design argument: db_degrade -d*esign list_of_designs library.lib [ ] File and directory names are specified in Courier font. Indicates optional arguments. In the following example, you can specify none, one, or both of the bracketed arguments: command [-arg1] [-arg2 value] [ | ] Indicates an optional choice from a mutually exclusive list. In the following example, you can specify any of the arguments or none of the arguments, but you cannot specify more than one: command [-arg1 | -arg2 | -arg3 | -arg4]
text
December 2010
10
Encounter Library Characterizer User Guide About This Manual
{ | }
Indicates a required choice from a mutually exclusive list. In the following example, you must specify one, and only one, of the following arguments: command {-arg1 | -arg2 | -arg3}
{ [ ] [ ] }
Indicates a required choice of one or more items in a list. In the following example, you must choose one argument from the list, but you can choose more than one: command {[-arg1] [-arg2] [-arg3]}
... . . .
Indicates that you can repeat the previous argument. Indicates an omission in an example of computer output or input.
Use white space (tabs or spaces) to separate a command and its arguments.
Related Documents
For more information about Encounter library characterizer, see the following documents. You can access these and other Cadence documents with the Cadence Help System online documentation system.
Encounter Library Characterizer Known Problems and Solutions Describes important Cadence Change Requests (CCRs) for Encounter library characterizer, including solutions for working around known problems.
Encounter Library Characterizer Text Command Reference Describes the Encounter library characterizer text commands, environment variables, and executables, including syntax and examples.
Whats New in Encounter Library Characterizer Provides information about new and changed features in this release of Encounter library characterizer.
README file Contains installation, compatibility, and other prerequisite information, including a list of Cadence Change Requests (CCRs) that were resolved in this release. You can read this file online at downloads.cadence.com.
December 2010
11
Encounter Library Characterizer User Guide About This Manual For a complete list of documents provided with this release, see the Cadence Help System library. 11/12/10
December 2010
12
1
Basics of Cell Library Characterization
This chapter describes Encounter library characterizer automatic cell library characterization in more detail, including the potential problems in cell library characterization and how Encounter library characterizer solves them. This chapter presents the following topics:

What Is Cell Library Characterization? on page 14 Automatic Cell Library Characterization on page 14 Multiple Cell Types on page 15 State Dependency on page 20 Binary Search on page 21 Characterization Measurement Levels on page 26 Pin-to-Pin Delay on page 27 Power Consumption on page 28 Input Constraints on page 29 Input Loading Model on page 30 Output Driving Model on page 30 Distributed Processing on page 31
December 2010
13
Encounter Library Characterizer User Guide Basics of Cell Library Characterization
What Is Cell Library Characterization?

One of the main goals in a gate-level design flow is to prove that a design will perform to its required timing specification. Once a design has been completed through placement and routing, the next step is to understand the inherent delays associated with the completed routing. Cell library characterization generates timing characteristics (timing models) of library cells on the basis of their physical implementation (layout). The main input to library characterization is a SPICE-format netlist that contains the detailed transistor devices, resistance, and capacitance for each library cell. The main output of library characterization is a library database that contains timing, power, and noise models for each of the cells. These models are used in electrical analysis.
Automatic Cell Library Characterization

Encounter library characterizer performs the following steps for automatic cell library characterization: 1. Analyzes transistor circuits in SPICE format and recognizes their function, logic structure, and type. 2. Generates the logic model, or function model, for sequential circuits, combinatorial circuits, and tristate circuits. 3. Generates the specification definitions in the circuit, such as the pin-to-pin delay, input pin timing constraints, and pin direction and properties. 4. Defines the characterization environment by specifying parameters such as the supply voltage, temperature, input slew rate, output load, and process corners. 5. Invokes and executes SPICE and summarizes the results, including the pin-to-pin delay and the input timing constraints. 6. Generates the ALF file, which you can then convert to library formats such as Verilog, Liberty Library, VHDL, and HTML. Encounter library characterizer systematically integrates all these steps, providing fully automated library characterization.
December 2010
14
Multiple Cell Types

Encounter library characterizer can handle several types of cells, including combinatorial logic, tristate logic, bidirectional, sequential logic, multi-bit loigic, interface circuitry, and pass transistor logic cells.
Combinatorial Logic Cells

Combinatorial logic refers to cells in which the outputs change according to the combination of inputs switching. This type of cell is the main component of standard logic circuits. Examples of combinatorial logic cells are INV, NAND, NOR, AND, and ADDER cells, as shown in Figure 1-1 on page 15. Library characterization output for the combinatorial cells includes the calculation of all propagation delays from every input port to every output port, and the generation of input load and output source models. Figure 1-1 Combinatorial Logic Cells
Inverter
2-input NAND
Full adder
4-input NAND 2-input NOR
Tristate Logic Cells

Tristate logic cells are circuits that have three logic states at the output: logic 0, logic 1, and high impedance (Z). This type of cell is typically used to drive bus structures, where the highimpedance state is required to prevent bus conflicts. Tristate logic cells include n-channel and p-channel open drain circuits. Examples of tristate logic cells are shown in Figure 1-2.
December 2010
15
Encounter Library Characterizer User Guide Basics of Cell Library Characterization Figure 1-2 Tristate Logic Cells
Tristate buffer Nch open drain Pch open drain To measure tpHZ
To measure tpLZ
To measure tpLZ
Library characterization output for tristate logic cells includes standard propagation delays and propagation delays for the high-impedance states (low to Z, high to Z, Z to low, and Z to high). Encounter library characterizer generates input load models and output source models, as well as the capacitance of the high-impedance ports, which is needed when multiple outputs are connected together. Since it is not possible to measure the off-state delays (tpLZ and tpHZ) directly, Encounter library characterizer uses internal nodes to characterize these delays. It automatically recognizes tristate logic and identifies the internal nodes to use for the off-state characterization. Note: N-channel open drain circuits have only low-to-Z propagation delays, and p-channel open drain circuits have only high-to-Z propagation delays.
Bidirectional Cells
Bidirectional cells, which contain ports that are both inputs and outputs, are composed of tristate logic outputs and combinatorial inputs. Encounter library characterizer automatically recognizes this type of circuitry and identifies the internal nodes necessary for off-state delay characterization. Figure 1-3 on page 17 shows an example of a bidirectional cell.
December 2010
16
Encounter Library Characterizer User Guide Basics of Cell Library Characterization Figure 1-3 Bidirectional Cell
To measure tpHZ
To measure tpLZ
Sequential Logic Cells

Sequential logic refers to cells that contain circuitry to sustain logic levels. Examples of sequential logic cells are flip-flops, latches, and register cells. For sequential logic, in addition to the standard propagation delays and input/output models, input timing must be characterized for setup time, hold time, release time, removal time, recovery time, and minimum input pulse widths. In sequential CMOS logic, registers typically contain latches composed of two high-gain inverters for static logic or tristate circuitry for dynamic logic. Encounter library characterizer automatically recognizes both the static and dynamic types of registers and assigns internal nodes for delay characterization and circuit initialization, as shown in Figure 1-4 on page 18 and Figure 1-5 on page 18.
December 2010
17
Encounter Library Characterizer User Guide Basics of Cell Library Characterization Figure 1-4 Sequential Logic Cell
DS flip-flop with XS, XR
to initialize latches
Specifically for sequential logic cells, Encounter library characterizer automatically generates a comprehensive suite of vectors to validate race conditions. These vectors switch all combinations of the inputs to calculate input timing constraints. In addition, for dynamic sequential logic cells, Encounter library characterizer automatically adds internal nodes to enable drive strength checking, as shown in Figure 1-5 on page 18. Figure 1-5 Dynamic Sequential Logic Cells
D flip-flop (pseudo-dynamic) Register bit (dynamic)
December 2010
18
Multi-Bit Logic Cells

Encounter library characterizer automatically recognizes multi-bit logic cells, which accelerate the SPICE simulation. Examples of multi-bit logic cells are a 4-bit NAND and a 4bit flip-flop, shown in Figure 1-6 on page 19. Figure 1-6 Multi-Bit Logic Cells
4-bit D flip-flop with XR 4-bit NAND2
Interface (Pad) Circuits

Interface (pad) circuits often contain special analog circuits like Schmitt triggers, sense amplifiers, level shifters, pullups, and pulldowns. Encounter library characterizer includes internal templates to assist in the recognition of these circuits and supports manual definition if the automatic recognition fails. Examples of interface circuits are shown in Figure 1-7 on page 20.
December 2010
19
Encounter Library Characterizer User Guide Basics of Cell Library Characterization Figure 1-7 Interface Cells
Level shifters Sense amplifiers Schmitt trigger
Pass Transistor Logic Cells

Pass transistor logic cells are often used in a design to improve circuit performance. Examples of pass transistor logic cells are the CVSL and CPPL cells shown in Figure 1-8 on page 20. Encounter library characterizer can recognize these type of cells and supports manual definition if the automatic recognition fails. Figure 1-8 Pass Transistor Logic Cells
CPPL
CVSL
State Dependency
The propagation delay between some input ports and output ports depends on the status of other input ports. Two types of logic are state-dependent:

Complex gates, such as AOI and OAI Exclusive logic, such as XOR and XNOR
December 2010
20
Encounter Library Characterizer User Guide Basics of Cell Library Characterization Encounter library characterizer automatically detects state-dependent logic and generates vectors to comprehensively exercise the logic, as shown in Figure 1-9 on page 21. Figure 1-9 State Dependency
Binary Search
In sequential logic, the register state is determined by the timing between two input ports. Examples are the setup and hold time between the data port and the clock port, the release and removal time between the clock and the asynchronous port, and the recovery time between asynchronous ports (see Figure 1-10 on page 22).
December 2010
21
Encounter Library Characterizer User Guide Basics of Cell Library Characterization Figure 1-10 Input Timing Constraints
Encounter library characterizer characterizes these input timing constraints by automatically searching for the smallest difference in propagation delay between the two ports while performing detailed simulations. This method is called a binary search. A binary search uses the following parameters specified in the SIMULATION statement in the setup file to set the initial search range (CK - start, CK + end) and the minimum size of the range for search (step).
Bisec = start end step
The start value specifies a value that is known to pass for setup time simulation and to fail for hold time simulation. The end value specifies a value that is known to fail for setup time simulation and to pass for hold time simulation. The binary search stops when the size of the search range shrinks to less than the step value. By default, binary search uses the following values: Bisec = 3.0ns 3.0ns 10ps Binary search then uses the following equation to determine the next simulation point: D - CK = (Latest Pass Point + Latest Fail Point)/ 2 In a binary search for setup time, the initial Latest Pass Point equals -start, and the initial Latest Fail Point equals end. In a binary search for hold time, the initial Latest Pass Point equals end, and the initial Latest Fail Point equals -start. If the simulation result for the output Q is the same as the expected waveform (rise or fall), and the CK to Q delay satisfies the delay tolerance check, the simulation passes. Otherwise, the simulation fails.
December 2010
22
Encounter Library Characterizer User Guide Basics of Cell Library Characterization Because the setup time for sequential logic can also affect propagation delay, Encounter library characterizer measures the propagation delays during these simulations, as shown in Figure 1-11 on page 23. To ensure that the setup time chosen is not so close to the switching point that the simulation fails, it performs a delay tolerance check by multiplying the delay from the clock (CK) to the output Q by a factor specified with the EC_BI_DRATIO variable. Figure 1-11 Setup Versus Propagation Delay
d0 x EC_BI_DRATIO
d0
Example 1-1 Characterizing Setup Time Assume the following binary search information in the SIMULATION statement in the setup file:
Bisec = 6.0ns 6.0ns 10ps
Figure 1-12 on page 24 illustrates the initial binary search simulation. This step passes because it uses the start value (6ns) set in the SIMULATION statement in the setup file. This step also measures the delay (d0) from the clock (CK) to the output Q. This delay is used for the delay tolerance check, to ensure that the setup time chosen is not so close to the switching point that the simulation fails.
December 2010
23
Encounter Library Characterizer User Guide Basics of Cell Library Characterization Figure 1-12 Initial Binary Search Step
D CK
6.0n
d0
Figure 1-13 on page 24 illustrates the first simulation. In this step, the simulation fails because it uses the end value (6ns) set in the SIMULATION statement in the setup file. Figure 1-13 Binary Search Step 1
Latest Pass (-6.0ns)
D CK
6.0n
Latest Fail (6.0ns)
The following simulations use the following equation to measure the next simulation point: D - CK = (Latest Pass Point + Latest Fail Point)/ 2 Figure 1-14 on page 25 illustrates the next simulation. Using this equation, the simulation point is: (-6.0 ns + 6.0 ns)/2 = 0 ns This simulation fails because Q is different than the estimated waveform.
December 2010
24
Encounter Library Characterizer User Guide Basics of Cell Library Characterization Figure 1-14 Binary Search Step 2
CK
Latest Fail (0.0ns)
Previous Fail (6.0ns)
Figure 1-15 on page 25 illustrates the next simulation point: (-6 ns + 0 ns)/2 = -3 ns This simulation passes because Q is the same as the estimated waveform, and the delay (d) is less than the d0 value multiplied by the delay tolerance check factor (SG_BI_DRATIO). Figure 1-15 Binary Search Step 3
Previous Pass (-6.0ns)
D CK
3.0n
Previous Fail (0ns)
Figure 1-16 on page 26 illustrates the next simulation point: (-3 ns + 0 ns)/2 = -1.5 ns This simulation fails because, even though Q is the same as the estimated switching point, d is greater than the d0 value multiplied by the delay tolerance check factor.
December 2010
25
Encounter Library Characterizer User Guide Basics of Cell Library Characterization Figure 1-16 Binary Search Step 4
D CK
1.5n
Previous Fail (0ns)
Latest Fail (-1.5ns)
Binary search continues until the size of the search range shrinks to less than the 10ps value set in the SIMULATION statement in the setup file. When this occurs, the latest simulation pass value becomes the setup time value (see Figure 1-17 on page 26). Figure 1-17 Final Binary Search Step
D
CK
2.25n
(Latest Pass - Latest Fail) < 10ps

Latest Fail (-2.0625ns)
Setup = -Latest Pass Point = 2.25ns
Characterization Measurement Levels

Encounter library characterizer uses circuit simulation to extract cell characteristics. It automatically measures the waveforms generated by circuit simulation at specific voltages and times to generate the characterization data, which it saves in the Encounter library characterizer database.
December 2010
26
Encounter Library Characterizer User Guide Basics of Cell Library Characterization Table 1-1 on page 27 shows the measurement levels used by Encounter library characterizer. Table 1-1 Characterization Measurement Levels
Level Input signal threshold voltage Output signal threshold voltage Input signal high voltage Input signal low voltage Output signal high voltage Output signal low voltage Input signal high slew voltage Input signal low slew voltage Output signal high slew voltage Output signal low slew voltage
* Percentage of VDD
Symbol Vthi Vtho Vih Vil Voh Vol Vish Visl Vosh Vosl
Default* 50% 50% 100% 0% 100% 0% 90% 10% 90% 10%
Impact on Delay Delay Slew Slew Slew Slew Slew Slew Slew Slew
Pin-to-Pin Delay
Pin-to-pin delay is the time that it takes a change at an input pin to effect a change at an output pin. The time is measured from the point when an input signal switches through an input threshold voltage (Vthi) to the point when an output signal switches through an output threshold voltage (Vtho), as shown in Figure 1-18 on page 28.
December 2010
27
Encounter Library Characterizer User Guide Basics of Cell Library Characterization Figure 1-18 Pin-to-Pin Delay
Vthi
INPUT
OUTPUT
Vtho
delay
delay
Because the amount of delay depends on the input slew rate and the output pin capacitance, library characterization executes simulations by using different input slew rates and output loading capacitance combinations.
The input slew rate, output loading, and calculated pin-to-pin delay is saved as a twodimensional delay table (delay model). The output slew rate, which is also calculated during these simulations, is saved in a second table (output slew model).
Using the characterization data contained in these two tables, the Encounter library characterizer cell library characterization provides the delay/driver model for specific pin-topin delays.
Power Consumption
Power consumption refers to three types of power:

Switching power, which is due to the charging and discharging of the loading capacitance Short-circuit power, which is due to the current draw from supply to ground when the output switches. Short-circuit power depends on both the input slew rate and the output loading capacitance. Static leakage power, which is due to the static current drawn from supply to ground when the circuit is stable
Encounter library characterizer characterizes all three types of power consumption and saves the results in tabular format in the database.
December 2010
28
Encounter Library Characterizer User Guide Basics of Cell Library Characterization Encounter library characterizer measures internal power consumption by using the following methodology: 1. First it measures the current drawn from the circuit under quiescent conditions (static leakage power). 2. It measures the current drawn from supply to ground when output switches and during charging and discharging of loading capacitance. If the outputs switch from low to high (that is, the current flow from the supply charges the output capacitance), or if the outputs switch from high to low (that is, the current flows from the output capacitance to ground), Encounter library characterizer uses the following formula to compute the power:
power = (Qsupply-Qleakage)*VDD - (1/2*Cload*VDD*VDD)
OR
power = Integ(I(VDD)-I(LEAKAGE))*VDD - (1/2*Cload*VDD*VDD)
where, Cload is the load capacitance 3. Encounter library characterizer saves the power consumption data based on the input slew rate and the output capacitance as a two-dimensional table. Note: To ensure comprehensive coverage, Encounter library characterizer generates tables for each input-to-output combination for both rising and falling output conditions.
Input Constraints
For sequential logic cells, Encounter library characterizer characterizes the input signal constraints, including setup time, hold time, release time, removal time, recovery time, and minimum pulse width. It characterizes the constraints by using a delay-tolerance-based binary search method. The results are saved as a table of input slew rates. From a cells sequential logic, Encounter library characterizer determines the properties of the clock signal, data signal, preset signal, and clear signal and generates the constraint definition, as follows: Setup, hold: data to clock Release, removal: clear/preset to clock Recovery: clear/preset to preset/clear Minimum pulse width: clock/clear/preset
December 2010
29
Encounter Library Characterizer User Guide Basics of Cell Library Characterization Encounter library characterizer also automatically generates the binary search vectors, which are named Rxxxx.
Input Loading Model

Encounter library characterizer characterizes input gate capacitance using both rising and falling input signals. For delay or power simulation, it measures the average current on the switched input pins. The average input gate capacitance generated is calculated as follows: gate_cap = average_current * simulation_time/(Vh Vl)
Output Driving Model

Encounter library characterizer generates output driving models for different applications.
Non-Linear Table Model

Encounter library characterizer can generate non-linear tables for each pair of input-output pins. The tables include delay tables and output transition tables, and their values depend on both the input slew rate and the output loading capacitance. These tables can be used by many EDA timing tools that use the Synopsys .lib format.
K-Factor Model
Encounter library characterizer generates a simplified output driving model called a K-factor model. It calculates this model as follows: delay(C load) = D0 + (K-Factor x C load )

C load is the load capacitance on the output. D0 is the initial delay when loading is zero. K-Factor is the dependency of the loading.
Effective Current Source Model

Encounter library characterizer generates a detailed output driving model called the effective current source model (ECSM) and saves it in the database. The ECSM model contains the
December 2010
30
Encounter Library Characterizer User Guide Basics of Cell Library Characterization effective current for different combinations of input slew rates and output loading capacitances. The table contains several effective currents measured at different output voltage levels.
Distributed Processing
Since Encounter library characterizer executes many simulation jobs to obtain accurate results, it contains a distributed (parallel) processing system to minimize throughput time. The distributed processing system is based on the server-client model and can therefore use multiple CPUs across a network. Encounter library characterizer contains load-sharing software that monitors each computers workload and invokes jobs on machines with less loading. The Encounter library characterizer distributed processing system differs from a typical batch system by monitoring the number of free simulator licenses, so simulations will not fail because there are no licenses available. The distributed processing system supports multiple users. The order in which jobs are submitted can be controlled by user-defined priorities.
December 2010
31
December 2010
32
2
Getting Started
This chapter describes the configuration requirements for Encounter library characterizer.

Product and Installation Information on page 34 Setting the Run-Time Environment on page 34 Product Licenses on page 35 Configuring the Environment for Parallel Simulations on page 36 Starting Encounter Library Characterizer on page 43 Online Documentation and Help on page 48
December 2010
33
Encounter Library Characterizer User Guide Getting Started
Product and Installation Information

For product, release, and installation information, see the Encounter Timing System README file at any of the following locations:
downloads.cadence.com, where you can review the README before you download the Encounter library characterizer software. In the software installation, where it is also available when you are using or running the Encounter library characterizer software. At the top level of your installation hierarchy.
Setting the Run-Time Environment

After installation, the following directory structure contains the Encounter library characterizer tool:
install_dir/tools/bin
where: install_dir is the actual installation directory.
Add the appropriate directory to your PATH. For example:

install_dir/tools/bin
December 2010
34
Product Licenses
Encounter library characterizer offers a wide range of features and functionality. The features to which you have access are determined by your product license. The following table shows a list of Encounter library characterizer features that are supported through different licenses: License ETS L or ELC XL Features
Non-Linear Delay Model (NLDM)-based timing and power characterization ECSM-timing, ECSM-power, and noise characterization CCS-timing, CCS-power, and noise characterization Parallel processing support All the features supported by ETS L or ELC XL Statistical timing and leakage characterization
ETS XL or ELC GXL
Important The first ELC XL/GXL and ETS L/XL license enables simulations to run on a single processor. Every additional ELC XL/GXL and ETS L/XL license allows you to run parallel simulations on three additional CPUs. Therefore, if you have 4 licenses, it will allow 10 parallel simulations.
December 2010
35
Configuring the Environment for Parallel Simulations

Using IPSD/IPSC for Parallel Simulations on page 36 Using LSF for Parallel Simulations on page 41
Using IPSD/IPSC for Parallel Simulations

Library characterization requires several machines running circuit simulation on the network. To run the parallel simulation, you must first start the IPSD and IPSC network resource control daemons. Configuring the IPSD Daemon The IPSD daemon is a process that determines whether a machine is enabled to execute the parallel jobs required during library characterization. When an IPSD daemon is actively running, it provides CPU and loading information to the IPSC daemon that controls the parallel queues. You can configure the IPSD daemon as root or as the user. When you configure IPSD as root (the recommended way), it runs as the root users process to execute simulation jobs for any user who uses Encounter library characterizer. When you configure IPSD as the user, all of the simulation jobs run as though requested by a normal user who invokes IPSD. A user who wants to use Encounter library characterizer must use the user ID that was used to launch IPSD. Attempt to run a simulation job using a user ID other than the one used to launch IPSD will fail. Caution If you ignore this restriction, Encounter library characterizer reports an unexpected status in the messages output by the db_spice command. Configuring as Root 1. Add the following line to the /etc/xinetd.conf file.
ipsd/1 tli rpc/* wait root ipsd
This modification is needed for all the machines on which you will run the simulation. 2. Add the following line to the /etc/rpc file:
ipsd 574786868 ipsd
December 2010
36
Encounter Library Characterizer User Guide Getting Started 3. Send the SIGHUP signal to the xinetd process as follows:
kill -HUP `ps -eff |grep xinetd|grep -v grep| awk '{ print $2 }'`
The xinetd process rereads /etc/xinetd.conf and starts to support IPSD. Configuring as the User
Type ipsd. Tip For more information on the ipsd command, see the Executables chapter of the Encounter Library Characterizer Text Command Reference.
Configuring the IPSC Daemons Next, you must configure at least two IPSC daemons, which are the network resource control daemons. The IPSC daemons assign simulation jobs from Encounter library characterizer to the machines running IPSD, and control the queues for the parallel jobs required during library characterization. One daemon is for non-simulation jobs, and the other daemons are for simulation jobs. IPSC does not have to be started by the root user. 1. Set the following environment variable to specify the license file for the simulator:
setenv LM_LICENSE_FILE /full_sim_licensefile_path:full_elc_licensefile_path
You can specify multiple simulator license files by specifying this variable for each simulator. 2. Specify the ipsc command to configure an IPSC daemon:
ipsc [-c number_of_jobs] [-f] [-i] [-l license_file[:license_file...]] [-n feature_name] [-w machine_load_threshold] [-s ipsd_server]
Tip For more information on the ipsc command, see the Executables chapter of the Encounter Library Characterizer Text Command Reference. a. To configure an IPSC daemon that manages the other IPSC daemons, and does not assign simulation jobs, specify the ipsc command without a simulator license feature name.
December 2010
37
Encounter Library Characterizer User Guide Getting Started For example,

ipsc
This IPSC daemon runs as ipsc[0]. b. To configure an IPSC daemon to assign simulation jobs, specify the ipsc command with a simulator license feature name. For example,
ipsc -n SPECTRE
This IPSC daemon assigns simulation jobs for the Spectre simulator. Note: You can configure multiple IPSC daemons to assign ELDO, hSpice, and Spectre simulations at the same time.
Specify the ipsc command for each simulator that the library characterizer wants to run. For example, to configure IPSC daemons to assign ELDO and Spectre simulations, specify the ipsc command twice, once for each simulator:
ipsc -n ELDO ipsc -n SPECTRE
When you specify a simulator, IPSC checks for the simulators license. If you did not previously set the license file with the LM_LICENSE_FILE variable, or if you want to specify a different license file, you can use the -l argument to do so. Multiple users can submit jobs to different simulators at the same time. You can monitor the job status by using the ipsstat command. Running IPSD/IPSC Use the following steps to run IPSD/IPSC:
Start the IPSD daemon on the host as well as the client machine:
ipsd
Start the IPSC daemon on the host machine using the following command if all the machines are on the same network:
ipsc host client1 client2
If all the machines are on different networks, use the following command to start the IPSC daemon on the host machine:
ipsc -s host client1 client2
Use the ipsc command to specify the settings for parallel simulation:
December 2010
38

ipsc -w 4 -c 4 -i -n spectre
Where:

-w specifies that the maximum average load of the server will be 4. -c specifies that the maximum number of parallel jobs that can be submitted for simulation will be 4. -i disables the checking of the simulator license by IPSC. -n specifies that the Spectre simulator license will be used.
Verifying the Network Resource Control Daemon Setup To verify that the network resource control daemon is set up correctly, check the report generated by the ipsstat command to ensure that the IPSC daemons you configured are running as you specified. Verifying Daemon Installation
Verify that the network resource control daemon is installed on the network by typing the following UNIX command:
shell 100> ipsstat
A report on the connection to the control daemon and the availability of simulation servers on the network is output. Note: Use the ipsstat command with the -ipsc option to display the IPSC configuration for a specific host on the network. For example to display the IPSC information for host1, use the following command:
ipsstat -ipsc host1
Monitoring Simulations on the Network
To monitor all simulations on the network, specify the ipsmon command:

ipsmon [c client_name] [-u user_name] [-s server_machines]
The ipsmon command contains the following arguments:
-c client_name Specifies the name of the client machines on which Encounter library characterizer is running. To list the names of all such machines on the network, type -c all.
-u user_name
39 Product Version 10.1
December 2010
Encounter Library Characterizer User Guide Getting Started Specifies the names of users who have submitted simulation jobs. To list the names of all such users, type -u all.
-s server_machines Specifies the names of the simulation server machines to be monitored. The default is the list of machines specified by the IPSSERVER variable.
The following example shows a report generated by the ipsmon command. In this report, DESIGN lists the cell names on which the library characterizer is running simulations. For each cell name:

PROCESS is the process name of the simulation ID is the identification number of the simulation vector SITE is the machine running the simulation PID is the process identification number for the simulation job on the machine STATUS is the status of the simulation job
---Searching a host that ipsd is running...Done. IPSD server list: dstorm17 dstorm18. DESIGN PROCESS ID SITE PID STATUS
----------+----------+--------+---------+-------+-------------------+----------+--------+---------+-------+-------------------+----------+--------+---------+-------+---------BUFX20 BUFX20 BUFX20 BUFX20 INVXL BUFX20 INVXL INVXL INVXL worst worst worst worst worst worst worst worst worst D0001 D0000 D0001 D0000 D0000 D0000 D0000 D0001 D0001 dstorm17 dstorm18 dstorm17 dstorm18 dstorm17 dstorm18 dstorm17 dstorm18 dstorm18 16393 16399 16393 16399 16402 16399 16402 16450 16450
----------+----------+--------+---------+-------+----------
----------+----------+--------+---------+-------+----------
----------+----------+--------+---------+-------+----------
----------+----------+--------+---------+-------+-------------------+----------+--------+---------+-------+----------
December 2010
40
Encounter Library Characterizer User Guide Getting Started Monitoring Simulations on Specific Machines 1. To monitor simulations on specific machines, specify the following environment variable with their names:
setenv IPSSERVER name1:name2:name3
You can specify one or more names by separating them with a colon (:). 2. Specify the ipsmon command with the machine names using the -s argument. For example, the following command returns job information for the user named student, who is running jobs on machines named student1, student2, and student3.
ipsmon -c all -u student -s student1:student2:student3
Using LSF for Parallel Simulations

You can also control the running of parallel simulation jobs by using the LSF queue. 1. To enable the use of the LSF queue, specify:
set_var EC_SIM_USE_LSF 1
2. To define the LSF bsub command options to submit a batch job to the LSF queue, specify:
set_var EC_LSF_OPTIONS lsf_bsub_options
For example, to run jobs on machines in the rh_any LSF host group, specify:
set_var EC_LSF_OPTIONS -m rh_any
Note: By default, Encounter library characterizer uses the sgsimlsf run script, which includes the EC_LSF_OPTIONS variable. This script can be found in the install_dir/etc/elc/bin directory. If you want to use a user-defined run script instead, specify the EC_SIM_LSF_CMD variable. This variable can also be used to specify bsub command options. 3. To specify the number of parallel jobs to submit to the LSF queue at once, specify:
set_var EC_SIM_LSF_PARALLEL number
By default (0), Encounter library characterizer submits the maximum number of jobs at one time. Running Simulation Jobs on the Same Local Host
The following variables run three parallel simulation jobs on the same local host using the Spectre simulator:
December 2010

set_var EC_SIM_USE_LSF 1 set_var EC_SIM_LSF_CMD "" set_var EC_SIM_LSF_PARALLEL 3 set_var EC_SIM_TYPE "SPECTRE" set_var EC_SIM_NAME "spectre"
Note: The EC_SIM_LSF_CMD variable specifies the command to submit simulation jobs. If you specify this variable as null (), the library characterizer calls the specified simulator (EC_SIM_NAME) to run jobs on the local host.
December 2010
42
Starting Encounter Library Characterizer

To start an Encounter library characterizer session, type the elc command with the appropriate options at the UNIX prompt. The syntax of the elc command is as follows:
elc [-version] [-cdb makecdb_cmd_file] [-dpm makedpm_cmd_file] [-slc slc_cmd_file] [-r rechar_cmd_file] [-S cmd_file] [-Q] [-L log_file] [-lic { elcgxl | elcxl | etsxl | etsl }] [-C log_file] [-al]
December 2010
43
Encounter Library Characterizer User Guide Getting Started Parameters Appends the log information to an existing log file. Specifies the name of the Encounter library characterizer command log file. This file contains the list of commands that were executed during characterization. Default: elc_cmd.log -cdb cmd_file Enables the make_cdB plug-in mode and specifies a make_cdB command file to load. Note: make_cdB is a noise characterizer utility that generates a cdB noise library from transistor-level netlists and SPICE models. -dpm cmd_file Enables the makedpm plug-in mode and specifies the name of the makedpm command file to load. Note: makedpm is an incremental power characterizer that generates an ECSM-based power library from transistor-level netlists and SPICE models. -L log_file Specifies the name of the Encounter library characterizer log file. This file contains the log of the entire Encounter library characterizer run. Default: elc.log -lic { elcgxl | elcxl | etsxl | etsl } Checks out the specified license. If this option is not specified, the software checks for a valid license in the specified order:

-al -C log_file
ELC GXL ELC XL ETS XL ETS L
-Q
Starts the Encounter library characterizer in silent mode. When the silent mode is enabled, the software does not report any messages related to the run.
December 2010
44
-r rechar_file -S cmd_file
Specifies the name of the Encounter library characterizer recharacterization command file. Specifies the name of the Encounter library characterizer command file to use. This command file contains the commands that are supported in the native mode. Enables the SignalStorm library characterizer plug-in mode and specifies the name of the SignalStorm library characterizer command file to load. Prints the Encounter library characterizer version name.
-slc cmd_file
-version
If you do not specify any parameters, the following actions occur:

A log file named elc.log is created. A command file named elc_cmd.log is created. The first available license is checked out.
Starting Encounter Library Characterizer in Interactive Mode

To start Encounter library characterizer in interactive mode, type the following on the command line:
elc -L logfile -C command_logfile
The elc command has the following arguments:
-L logfile Specifies the name of the log file. The default name is elc.log. This parameter is optional.
-C command_logfile Specifies the name of the command log file, which contains a log of all of the commands that you used during your Encounter library characterizer session. The default name is elc_cmd.log.
The prompt now changes to the following:

elc>
Encounter library characterizer initializes the shell environment by processing the environment variables or by reading the variables in the configuration (elccfg) file.
December 2010
45
Encounter Library Characterizer User Guide Getting Started You can list all the commands issued in the Encounter library characterizer prompt by typing the following command:
elc> history
You can also execute a previous command by typing the following command:
elc> !command_name
or this command:
elc> !history_number
In the shell environment, you can also execute any UNIX command in addition to the Encounter library characterizer commands. To run a command file in interactive mode, type the following:
elc> source cmd_file
where cmd_file is the name of the command file.
Starting Encounter Library Characterizer in Batch Mode

To start Encounter library characterizer in batch mode, type the following on the command line:
elc -S cmd_file L logfile
where the parameters are as follows:
-S cmd_file Specifies the name of the command file.
L logfile Specifies the name of the log file. The default name is elc.log.
Encounter library characterizer reads the command file, executes the commands, and outputs any messages to the log file.
Starting Encounter Library Characterizer in 64-bit Mode

To run a 64-bit version of the Encounter library characterizer software: 1. Verify that your operating system supports 64-bit applications. 2. Verify that a 64-bit version of the application is installed.
December 2010
46
Encounter Library Characterizer User Guide Getting Started The 64-bit version of an application is located in the 64bit directory in the standard installation location of the application. For example: your_install_dir/tools/bin/64bit 3. Set the following environment variable:
CDS_AUTO_64BIT { ALL | NONE | list }
ALL NONE list
All applications are run as 64-bit. All applications are run as 32-bit. Only the applications specified are run as 64-bit. Specify list as a list of case-sensitive application names, separated by a colon, comma, or semicolon. If you use a semi-colon, enclose the list in single quotation marks. For the Encounter library characterizer product, the following executable name is a valid entry for list: elc
December 2010
47
Online Documentation and Help

You can access Encounter library characterizer documentation by using the Cadence Help online documentation system. From the <installation_dir>/tools/bin directory, type cdnshelp at the command prompt. After launching Cadence Help, press F1 or choose Help - Contents to display the help page for Cadence Help.
Using Text Command Help

To see syntax information about a command, type the following on the Encounter library characterizer prompt:
help command_name
To see the entire list of commands and their syntax, type the following on the Encounter library characterizer prompt:
help
The information is written to the Encounter library characterizer log file. To see the complete set of information about a command, type the following on the Encounter library characterizer prompt:
man command_name
December 2010
48
3
Preparing for Library Characterization

Overview on page 50 Inputs to Encounter Library Characterizer on page 51 Outputs of Encounter Library Characterizer on page 59
December 2010
49
Encounter Library Characterizer User Guide Preparing for Library Characterization
Overview
Encounter library characterizer is a unified characterization engine that enables you to generate timing and power models in Liberty library format. In addition, it enables you to generate ECSM-based timing, noise, and power models in a compact library. Finally, it provides you the ability to consider the effects of process variations on timing or leakage during characterization. You can use Encounter library characterizer to generate the views necessary to support your design flow even if the required library views are not available. In addition, you can perform re-characterization on existing libraries to suit different design requirements. Encounter library characterizer provides characterization capabilities for the following:

Pin-to-pin delay with state dependency Input timing constraint (setup/hold/pulse width) Power consumption (internal/leakage) Input and output pin capacitance Output pin transition time ECSM Timing

Voltage waveform at output pin Multi-piece ECSM capacitance
ECSM Power
Current waveform at power-grid pins for different combinations of slew and load
ECSM Noise
Voltage in Voltage out (ViVo) waveform on an input or output pin of a cell
Statistical ECSM
Sensitivities to device parameters at the arc level for all load, slew, delay, waveform, and timing check tables
CCS Timing

Current waveform at output pin Two piece receiver capacitance
December 2010
50
Inputs to Encounter Library Characterizer

The following are the inputs to Encounter library characterizer:
SPICE Inputs
A SPICE-format subcircuit (SUBCKT) file, which includes all the transistors and local RC component circuits defined for each standard cell A SPICE-format device model file, which specifies the device models An optional parameter library file, which defines the device parameters for different process corners
Encounter Library Characterizer Command File

Encounter library characterizer uses a combination of commands and variables in the command file to control library characterization. Use a text editor to enter these commands and variables into the file. Command File Syntax The Encounter library characterizer command file must include the db_open command, which opens the database. It should also include the db_close command, which closes the database.
db_open database_name commands . . . db_close database_name exit
Note: Encounter library characterizer accesses a central database, which stores the circuit and RC information. All commands starting with db_ are used to access the database. They either read the information in the database or read the information and write additional information to it. Depending on the type of access, all commands have a database lock function that verifies that more than one user can access the database and run multiple parallel processes on it at the same time. Encounter library characterizer checks the lock every time that you enter a command to access the database. It also creates a lock on each
December 2010
51
Encounter Library Characterizer User Guide Preparing for Library Characterization design in the database. If the design is locked by others, Encounter library characterizer issues a message and stops the execution of the command. You can include additional command files within the Encounter library characterizer command file by using the UNIX source command. Setting Commands See the Commands chapter of the Encounter Library Characterizer Text Command Reference for a list of commands that you can use in the command file. Setting Variables Environment variables in Encounter library characterizer use many different processing options. Encounter library characterizer obtains a parameters value from the environment variable table, which is initialized upon invocation.
Enter variables whose values you will change from time to time in the command file. To reset the variables in the command file, use the following command:
elc> set_var variable_name variable_value
Enter variables whose values will not change in the elccfg file. This is the default configuration file that resides in the working directory. Encounter library characterizer reads this file automatically if it finds it in the working directory. Note: See the Configuration File (elccfg) section for more information on how to change the variable settings in the configuration file. Tip See the Environment Variables chapter in the Encounter Library Characterizer Text Command Reference for a list of variables that you can use in either of the files.
Example Command File The following example shows a sample Encounter library characterizer command file for cell library characterization:
db_open demo db_prepare db_spice -p typical db_output -p typical -alf test.alf -lib test.lib
December 2010
52

db_close
The above example:

Opens a database called demo.ipdb Imports a subcircuit file and runs the automatic circuit recognition function Sets up the SPICE simulation conditions and runs the SPICE simulation on all vectors Outputs the cell library characterization results to the test.alf and test.lib files Closes the database
Simulation Setup File

The simulation setup file is an ASCII-format file that is used for cell library characterization. The setup file contains the following information:

Process corner definitions, such as temperature, voltage, and corner parameter names Simulation condition definitions for each device process corner for the SPICE simulation Signal measurement levels, such as the voltage threshold level and the high/low voltage level Loading capacitance of the boundary output pins Input slew rate conditions for the boundary input pins Characterized result margin factors Nominal factor definitions Loading for block boundaries Slew rates for block boundaries Derating factors for the calculation results, such as the delay across the I/O pads, interconnect delays, and setup and hold constraints Tip You can use the default setup file included in the Encounter library characterizer package, then modify it. You can find it in the installation directory:
$install_dir/etc/elc/misc/setup.default
December 2010
53
Encounter Library Characterizer User Guide Preparing for Library Characterization For more information on the simulation setup file format, see Appendix A, Simulation Setup File Format.
Configuration File (elccfg)

The Encounter library characterizer configuration file contains environment variables or setup directives that will be used during the run. To specify environment variables in the configuration file, use the following format: variable_name=value; Tip See the Environment Variables chapter in the Encounter Library Characterizer Text Command Reference for a complete list of supported environment variables. In addition, you need to specify the characterization inputs in the form of directives. To specify the directives in the configuration file, use the following format: DIRECTIVE_NAME=value; The following table shows a list of supported directives:
Directive SUBCKT
Description Specifies the SPICE subcircuit file. Important This is a mandatory directive except when you are using the db_prepare -create_setup command.
MODEL
Specifies the model file name. Important This is a mandatory directive except when you are using the db_prepare -create_setup command.
December 2010
54
DESIGNS
Specifies the name of the cells to work on. If this directive is not used, the software installs all the cells from the netlist in the Encounter library characterizer database. This is an optional directive.
SETUP
Specifies the simulation setup file. Important This is a mandatory directive except when you are using the recharacterization or incremental flow.
PROCESS
Specifies the process corner of the setup file. Important This is a mandatory directive except when you are using the recharacterization or incremental flow. In the recharacterization flow, this directive specifies the process name to use. If the process name is not specified, the default process name elc_process is used.
LIB
Specifies the name of the SPICE library file. Important This directive must be specified when the CORNER directive is used.
CORNER
Specifies the library corner of the SPICE library. Important This directive must be specified when the LIB directive is used.
XDESIGNS
Specifies the name of the cells that should be excluded. If this directive is not used, the software installs all the cells from the netlist in the Encounter library characterizer database. This is an optional directive.
December 2010
55
EXPAND
Specifies the name of the subcircuit that should be expanded. Important This is a mandatory directive when characterizing hierarchical cells.
STAT_CONFIG
Specifies the name of the statistical configuration file. Important This is a mandatory directive for using the statistical characterization flow.
SYNLIB
Specifies the .lib file on which incremental characterization will be performed. Important This is a mandatory directive for using the recharacterization and incremental flow.
BOOL
Specifies the bool file name. A bool file is an ASCII file, which describes macro cell logic with functions, including tristate, bidirectional, and sequential logic. This is an optional directive.
Following is an example of the configuration file:

#Specify the environment variable settings to use for characterization. EC_SIM_USE_LSF=1; EC_SIM_LSF_CMD=""; EC_SIM_LSF_PARALLEL=10; EC_SIM_TYPE="spectre"; EC_IGN_XTG=1; EC_SIM_NAME="spectre"; EC_CHAR=ECSM-TIMING ECSM-POWER; #Specify the characterization inputs. SUBCKT="subckt_file"; MODEL="model_file"; DESIGNS="INVD1 DFFD1"; SETUP="setup_file";
December 2010 56 Product Version 10.1

PROCESS=process_corner; LIB=library_file; CORNER=ss; EXPAND=cell_name; STAT_CONFIG=stat_config; SYNLIB=incr.lib; BOOL=bool_file
Statistical Configuration File

Contains the directives for parameter variation. This file is required only while performing statistical timing and leakage characterization. The statistical configuration file provides the input for generating sensitivity for both global (inter-gate) or random (intra-gate) parameter variations. Global Parameter Variation In the case of global variation, perfect correlation is considered between all devices in the chip. This means that the same variation value will be applied to all the transistors in the chip. To specify global parameter variation, use the values and AGAUSS keywords. The syntax of specifying a global parameter variation is as follows:
parameter=paramter_name values = AGAUSS(nominal_value, n*sigma_value, n)
where, The variation value is defined by n*sigma_value/n. Random Parameter Variation In the case of random variation, all transistors in the chip are considered to be noncorrelated. This means that different variation values will be applied to different transistors. To specify random parameter variation, use the values_random keyword. The syntax of specifying a random parameter variation is as follows:
parameter=parameter_name values_random = value scope={local|global} type={nmos|pmos}
Example Following is an example of the statistical configuration file:

version = 1.1 # Global parameter variation specification

parameter=a1 values = AGAUSS(0, 2.12798, 1) parameter=a2 values = AGAUSS(0, 1.45779, 1) parameter=a3 values = AGAUSS(0, 1.89527, 1) parameter=a4 values = AGAUSS(0, 1.56212, 1) # Random parameter variation specification parameter=param1 values_random = 0.5 parameter=param2 values_random = 0.8 scope=local type=nmos parameter=param3 values_random = 1 scope=local type=pmos parameter=param4 values_random = 1.2
In the above example:

The global parameter variation is specified for the a1, a2, a3, and a4 parameters. The values 0, 2.12798, and 1 for the a1 parameter signify the nominal_value, n*sigma_value, and n values, respectively. This means that the variation value for the a1 parameter is 2.12798. Similarly, the variation values for the a2, a3, and a4 parameters are 1.45779, 1.89527, and 1.56212, respectively. These values are used for sensitivity calculation for global variation of the respective parameters. The random parameter variation is specified for param1, param2, param3, and param4 parameters. The values 0.5, 0.8, 1, and 1.2 are used for sensitivity calculation for random variation of the param1, param2, param3, and param4 parameters, respectively. The scope option specifies that the param2 and param3 parameters are subcircuitscoped. The type option specifies that the param2 parameter affects only NMOS type transistors, and the param3 parameter affects only PMOS type transistors. Using the type option improves the run time.
Property File
A property file contains property information that is not defined in the ALF library, such as area, footprints, scan attributes, and pad attributes. You can use a property file to add extra information when using the alf2lib command to generate a Liberty library file. The alf2lib command reads a property file if you specify the -def option. Note: For more information on creating a Property file , see Appendix B, Property File Format.
December 2010
58
Liberty (.lib) File

Contains timing information and is used as an input for recharacterization or incremental flows.
Outputs of Encounter Library Characterizer
Library Compiler (.lib) file that can contain the following information:

Timing or ECSM-timing ECSM-noise Power or ECSM-power ECSM statistical and leakage Composite Current Source (CCS) based timing
ALF file, which contains the library characterization results in advanced library format. You can later convert this file to Library Compiler (.lib), Verilog, or VHDL libraries, or to datasheets in HTML format. Library report file, which provides all the characterization results for each cell.
December 2010
59
December 2010
60
4
Performing Cell Library Characterization

Overview on page 62 Performing Library Characterization for Standard Cells on page 63 Performing Library Characterization using a Pre-driver Cell on page 65 Performing ECSM-Based Power Characterization for Level-Shifter Cells on page 67 Performing CCS-Based Noise Characterization for Standard Cells on page 69 Performing CCS-Based Power Characterization for Standard Cells on page 71 Performing SOI Characterization for Standard Cells on page 73 Performing AAE Characterization for Standard Cells on page 75 Performing Automatic Index Selection on page 77 Creating a Simulation Setup File Automatically from an Existing Dotlib on page 80 Performing Incremental Characterization using Internal Simulator on page 81 Performing Incremental Characterization using External Simulator on page 83 Performing Statistical Characterization on page 85 Performing Library Recharacterization Using Different PVT on page 87 Creating a Binary Dotlib on page 90 Performing Additional Library Characterization Tasks on page 91
December 2010
61
Encounter Library Characterizer User Guide Performing Cell Library Characterization
Overview
This chapter describes the steps required to perform basic, incremental, and statistical cell library characterization. In addition, it describes other library characterization tasks, such as characterization of level shifter cells, hierarchical cells, and generation of non-linear input slew.
December 2010
62
Performing Library Characterization for Standard Cells

The following procedure describes how to perform ECSM-based timing and power characterization for standard cells. Important You can use this flow to perform library characterization for all standard cells except level-shifter cells, which require different settings in the simulation setup file and the elccfg configuration file. See the Performing ECSM-Based Power Characterization for Level-Shifter Cells section for more information on how to characterize level-shifter cells. 1. Ensure that the required SPICE inputs are accessible from the current working directory. 2. Ensure that the simulation setup file is available in the current working directory. Tip For more information on how to create a simulation setup file for standard cells such combinational cells, see the Standard Cell Library section in Appendix A, Simulation Setup File Format. 3. Create the Encounter library characterizer command file named cmd_file with the following commands: a. Open a database named basic_char:
db_open basic_char
b. Load the design and SPICE model data, perform circuit recognition, create the simulation vectors, and load the characterization conditions:
db_prepare -f
c. Perform circuit simulation:

db_spice -s spectre -keep_log
d. Include the characterization results in the out.lib file:

db_output -lib out.lib -process typical -state
e. Close the database:

db_close
f. Exit Encounter library characterizer:

exit
December 2010
63
Encounter Library Characterizer User Guide Performing Cell Library Characterization 4. Create the elccfg configuration file with the appropriate directives and environment variables: Note: The EC_CHAR environment variable uses the ECSM-TIMING and ECSM-POWER values, which indicate that ECSM-based timing and power characterization will be performed.
#Specify the environment variable settings. EC_SIM_USE_LSF=1; EC_SIM_LSF_CMD=" "; EC_SIM_LSF_PARALLEL=10; EC_SIM_TYPE="spectre"; EC_SIM_NAME="spectre"; EC_SPICE_SIMPLIFY=1; EC_CHAR=ECSM-TIMING ECSM-POWER; #Specify the characterization inputs. SUBCKT="subckt"; MODEL="model"; DESIGNS="INVX1 INVX2"; SETUP="setup"; PROCESS=typical; XDESIGNS=INVXL;
5. Start Encounter library characterizer in batch mode to perform library characterization:

elc -L test.log -C test_cmd.log -S cmd_file
December 2010
64
Performing Library Characterization using a Pre-driver Cell

For the input driver, the traditional use of a ramped linear waveform is not desirable because it can by itself impact the accuracy of delay calculation by 5-10 percent. To generate realworld input waveforms, you can use the following methods:

Pre-driver Method Pre-driver Generated Non-Linear Waveform Method
If you have characterized the pre-driver cell, Encounter library characterizer can use a table lookup approach to obtain the actual loading capacitance. The capacitance is changed on the output pin of the input circuit cell, so the input circuit generates a more accurate input slew rate for the characterized cell. The input circuit is connected to a voltage control voltage source to enable the transfer of the non-linear waveform to the characterized cell input. This method of connecting a pre-driver cell using voltage control voltage source (VCVS) might result in a stiffened waveform at the input. You can overcome this by using a pre-driver generated non-linear waveform. This flow is enabled by using the EC_PWL_FROM_DRIVER and EC_RECHAR_DRIVER variables. The following steps show how to use a pre-driver generated non-linear waveform: 1. Define the driver cell as the input circuit (INCIR) with the SIMULATION statement in the setup file using the following syntax: incir = string For example, to define DRIVER as the input circuit, add the following information to the test.setup setup file:
incir = DRIVER
Note: This incir statement specifies the location where the INVX1 cell was copied, in this case DRIVER. It must have one input and one output. It can be either an inverter or buffer logic. 2. Create the following Encounter library characterizer configuration file (elccfg) to use the copied cell to generate non-linear input slew rates:
EC_INPUT_NONLINEAR=1; #To enable pre-driver generated non-linear waveform instead of VCVS EC_PWL_FROM_DRIVER=1; #To improve accuracy with EC_PWL_FROM_DRIVER, set the EC_RECHAR_DRIVER environment variable to 1.
December 2010
65

EC_RECHAR_DRIVER=1; SUBCKT="mycells.subckt"; MODEL="spice_models.scs"; DESIGNS="NOR3X1 INVX1 BUFX2 CLKBUFX2 DRIVER"; # Include DRIVER cell in the DESIGNS parameter. XDESIGNS=DRIVER; SETUP="test.setup"; PROCESS=typical;
When creating the elccfg configuration file, be sure to specify the following variables:
Set the EC_PWL_FROM_DRIVER variable to 1. This will extract the piece-wise linear (PWL) information from the driver and apply it to the cell being characterized. Set the EC_RECHAR_DRIVER to 1. This setting interpolates the capacitance of the driver cell to calculate the input slew value of the cell that you want to characterize. This value is closest to the output transition obtained by characterizing the driver. Because the required input slew of the cell that you want to characterize might not be the same as the output transition obtained from characterizing the driver, it is recommended to set this variable.
3. Type the following commands to perform characterization with the pre-driver set to DRIVER:
db_open test_1 db_prepare -f db_spice -simulator SPECTRE -d INVX1 -keep_log
For more information on generating non-linear input slew rates for cell characterization, refer to Generating a Non-Linear Input Slew.
December 2010
66
Performing ECSM-Based Power Characterization for Level-Shifter Cells

The following procedure describes how to perform ECSM-based power characterization for level-shifter cells: 1. Ensure that the required SPICE inputs are accessible from the current working directory. 2. Ensure that the simulation setup file is available in the current working directory. Tip For more information on how to create a simulation setup file for level-shifter cells, see the Level Shifter Cell Library section in Appendix A, Simulation Setup File Format. 3. Create the Encounter library characterizer command file named cmd_file with the following commands: a. Open a database named basic_char:
db_open basic_char
db_prepare



db_close

exit
4. Create the elccfg configuration file with the appropriate directives and environment variables: Note: The EC_CHAR environment variable uses the ECSM-POWER value, which indicates that ECSM-based timing (default) and power characterization will be performed. In addition, the EC_SIM_SUPPLY1_NAMES and EC_SIM_SUPPLY0_NAMES variables specify the multiple power supply values (VDD and VDDIO) and ground supply value
December 2010
67
Encounter Library Characterizer User Guide Performing Cell Library Characterization (VSS) respectively.
#Specify the environment variable settings. EC_SIM_USE_LSF=1; EC_SIM_LSF_CMD=" "; EC_SIM_LSF_PARALLEL=10; EC_SIM_TYPE="spectre"; EC_SIM_NAME="spectre"; EC_SPICE_SIMPLIFY=1; EC_CHAR=ECSM-POWER; EC_SIM_SUPPLY1_NAMES=VDD VDDIO; EC_SIM_SUPPLY0_NAMES=VSS; #Specify the characterization inputs. SUBCKT="subckt"; MODEL="model"; DESIGNS="LVLLHD1"; SETUP="setup"; PROCESS=typical;

December 2010
68
Performing CCS-Based Noise Characterization for Standard Cells

The following procedure describes how to perform CCS-based noise characterization for standard cells. 1. Ensure that the required SPICE inputs are accessible from the current working directory. 2. Ensure that the simulation setup file is available in the current working directory. Tip For more information on how to create a simulation setup file for standard cells such combinational cells, see the Standard Cell Library section in Appendix A, Simulation Setup File Format. 3. Create the Encounter library characterizer command file named cmd_file with the following commands: a. Open a database named ccs_noise_char: db_open ccs_noise_char b. Load the design and SPICE model data, perform circuit recognition, create the simulation vectors, and load the characterization conditions:
db_prepare -f


db_output -lib out.lib -process typical -state -alf out.alf

db_close

exit
4. Create the elccfg configuration file with the appropriate directives and environment variables: Note: The EC_CHAR environment variable uses the CCS-NOISE value, which indicates that CCS-based noise characterization will be performed.
#Specify the environment variable settings. EC_SIM_USE_LSF=1;
December 2010
69

EC_SIM_LSF_CMD=" "; EC_SIM_LSF_PARALLEL=10; EC_SIM_TYPE="spectre"; EC_SIM_NAME="spectre"; EC_SPICE_SIMPLIFY=1; EC_CHAR=CCS-NOISE; #Specify the characterization inputs. SUBCKT="subckt"; MODEL="model"; DESIGNS="INVX1 INVX2"; SETUP="setup"; PROCESS=typical; XDESIGNS=INVXL;

Note: To create a noise library file (.lib) using the ALF file for extra customization:
alf2lib alf out.alf lib noise.lib ccs_noise -state
The newly created noise library file (noise.lib) will contain ccs_noise constructs, such as:

propagated_noise_high propagated_noise_low dc_current output_voltage_rise output_voltage_fall miller_cap_rise miller_cap_fall
December 2010
70
Performing CCS-Based Power Characterization for Standard Cells

The following procedure describes how to perform CCS-based power characterization for standard cells. 1. Ensure that the required SPICE inputs are accessible from the current working directory. 2. Ensure that the simulation setup file is available in the current working directory. Tip For more information on how to create a simulation setup file for standard cells such combinational cells, see the Standard Cell Library section in Appendix A, Simulation Setup File Format. 3. Create the Encounter library characterizer command file named cmd_file with the following commands: a. Open a database named ccs_power_char: db_open ccs_power_char b. Load the design and SPICE model data, perform circuit recognition, create the simulation vectors, and load the characterization conditions:
db_prepare -f


db_output -lib out.lib -process typical -state out.alf

db_close

exit
4. Create the elccfg configuration file with the appropriate directives and environment variables: Note: The EC_CHAR environment variable uses the CCS-POWER value, which indicates that CCS-based power characterization will be performed.
#Specify the environment variable settings. EC_SIM_USE_LSF=1;
December 2010
71

EC_SIM_LSF_CMD=" "; EC_SIM_LSF_PARALLEL=10; EC_SIM_TYPE="spectre"; EC_SIM_NAME="spectre"; EC_SPICE_SIMPLIFY=1; EC_CHAR=CCS-POWER; #Specify the characterization inputs. SUBCKT="subckt"; MODEL="model"; DESIGNS="INVX1 INVX2"; SETUP="setup"; PROCESS=typical; XDESIGNS=INVXL;

Note: To create a power library file (.lib) using the ALF file for extra customization:
alf2lib alf out.alf lib power.lib ccs_power -state
The newly created power library file (power.lib) will contain ccs_power constructs, such as:

dynamic_current leakage_current pg_current switching_group
December 2010
72
Performing SOI Characterization for Standard Cells

The following procedure describes how to perform SOI characterization for standard cells. 1. Ensure that the required SPICE inputs are accessible from the current working directory. 2. Ensure that the simulation setup file is available in the current working directory. Tip For more information on how to create a simulation setup file for standard cells such combinational cells, see the Standard Cell Library section in Appendix A, Simulation Setup File Format. 3. Create the Encounter library characterizer command file named cmd_file with the following commands: a. Open a database named soi_char: db_open soi_char b. Load the design and SPICE model data, perform circuit recognition, create the simulation vectors, and load the characterization conditions:
db_prepare -f


db_output -lib out.lib -process typical -state -alf out.alf

db_close

exit
4. Create the elccfg configuration file with the appropriate directives and environment variables: Note: The EC_SOI_CHAR environment variable should be set to 1, which indicates that SOI characterization will be performed.
#Specify the environment variable settings. EC_SIM_USE_LSF=1; EC_SIM_LSF_CMD=" "; EC_SIM_LSF_PARALLEL=10;
December 2010
73

EC_SIM_TYPE="spectre"; EC_SIM_NAME="spectre"; EC_SPICE_SIMPLIFY=1; EC_CHAR=ECSM-POWER; EC_SOI_CHAR=1; #Specify the characterization inputs. SUBCKT="subckt"; MODEL="model"; DESIGNS="INVX1 INVX2"; SETUP="setup"; PROCESS=typical; XDESIGNS=INVXL;

Note: To create a library file (.lib) in the SOI format using the ALF file for extra customization:
alf2lib alf out.alf lib soi.lib soi -state
This command generates three library files (.lib) that conform to the SOI characterization methodology. These are:

soi.lib - User-specified library containing nominal data soi-min.lib - "MIN" library containing "MIN" rise and fall delays soi-max.lib - "MAX" library containing "MAX" rise and fall delays
December 2010
74
Performing AAE Characterization for Standard Cells

Advanced Analysis Engine (AAE) timing characterization is based on the Voltage In Voltage Out (ViVo) methodology wherein characterization is done based on the input slew and output voltage. The AAE characterization methodology captures current waveforms of output pin for different combinations of input slew and output voltage. The following procedure describes how to perform AAE timing characterization for standard cells. 1. Ensure that the required SPICE inputs are accessible from the current working directory. 2. Ensure that the simulation setup file is available in the current working directory. Tip For more information on how to create a simulation setup file for standard cells such combinational cells, see the Standard Cell Library section in Appendix A, Simulation Setup File Format. 3. Create the Encounter library characterizer command file named cmd_file with the following commands: a. Open a database named aae: db_open aae b. Load the design and SPICE model data, perform circuit recognition, create the simulation vectors, and load the characterization conditions:
db_prepare -f

db_spice

db_output -lib out.lib -p typical -state -alf out.alf

db_close

exit
4. Create the elccfg configuration file with the appropriate directives and environment variables: Note: The EC_CHAR environment variable uses the AAE value, which indicates that
Encounter Library Characterizer User Guide Performing Cell Library Characterization AAE-based timing characterization will be performed.
#Specify the environment variable settings. EC_SIM_USE_LSF=1; EC_SIM_LSF_CMD=" "; EC_SIM_LSF_PARALLEL=10; EC_SIM_TYPE="spectre"; EC_SIM_NAME="spectre"; EC_SPICE_SIMPLIFY=1; EC_CHAR=AAE; #Specify the characterization inputs. SUBCKT="subckt"; MODEL="model"; DESIGNS="INVX1 INVX2"; SETUP="setup"; PROCESS=typical;

Note: To create a library file (.lib) in the AAE format using the ALF file for extra customization:
alf2lib alf out.alf lib aae.lib vivo -state
This command generates a library file (.lib) that conforms to the AAE characterization methodology. The newly created power library file (aae.lib) will contain the following constructs:
ecsm_stimulus - includes the time (time), voltage at input (vin) and voltage at output (vout) parameters ecsm_data - includes the time (time) and current at output (iout) parameters
December 2010
76
Performing Automatic Index Selection

Encounter library characterizer automatically determines the input slew and output load indices if you provide the applicable slew ranges in the simulation setup file. The following procedure describes how to perform automatic index selection: 1. Ensure that the required SPICE inputs are accessible from the current working directory. 2. Ensure that the simulation setup file is available in the current working directory. Specify the slew and load ranges for input slew and output load indices in the setup file. The following excerpt from the simulation setup file shows the format for specifying the slew and load range:
Group CQIVX20.A { PIN = CQIVX20.A ; }; Index CQIVX20.A { AUTO_INDEX_CELL = CQIVX20; #the cell to be used for index selection AUTO_INDEX_POINTS = 10; #the number of points to be generated Rslew = Fslew = }; Group CQIVX20.Z { PIN = CQIVX20.Z ; }; Index CQIVX20.Z { AUTO_INDEX_CELL = CQIVX20; AUTO_INDEX_POINTS = 10; Rload = 1e-15 5.2891e-12; #load range, this range is just for initial simulation and will be overridden by the inferred load range Fload = }; set index (typical) { Group(CQIVX20.A) = CQIVX20.A ; Group(CQIVX20.Z) = CQIVX20.Z ; } set process (typical) { simulation = std_cell; index = std_cell; signal = std_cell; }; 1e-15 5.2891e-12; 7e-12 2e-09 ; #slew range 7e-12 2e-09 ;
December 2010
77
Tip For more information on how to create a simulation setup file for standard cells such combinational cells, see the Standard Cell Library section in Appendix A, Simulation Setup File Format. 3. Create the Encounter library characterizer command file named cmd_file with the following commands: a. Open a database named index_cell: db_open index_cell b. Load the design and SPICE model data, perform circuit recognition, create the simulation vectors, and load the characterization conditions:
db_prepare -f

db_spice

db_output -lib out.lib -p typical -state -alf out.alf

db_close

exit
4. Create the elccfg configuration file with the appropriate directives and environment variables: Note: Specify the EC_GEN_AUTO_SETUP environment variable to automatically generate slew and load indices for the cells or pins based on the slew and load ranges specified in the original setup file. ELC creates the new setup file with the name specified with the EC_GEN_AUTO_SETUP variable.
#Specify the environment variable settings. EC_SIM_USE_LSF=1; EC_SIM_LSF_CMD=" "; EC_SIM_LSF_PARALLEL=10; EC_SIM_TYPE="spectre"; EC_SIM_NAME="spectre"; EC_SPICE_SIMPLIFY=1; EC_GEN_AUTO_SETUP=auto.st;
December 2010
78

#Specify the characterization inputs. SUBCKT="subckt"; MODEL="model"; DESIGNS="INVX1 INVX2"; SETUP="setup"; PROCESS=typical;

December 2010
79
Creating a Simulation Setup File Automatically from an Existing Dotlib

You can create a simulation setup file automatically from an existing dotlib using the following series of commands: 1. Specify the name of the original .lib file with the SYNLIB directive in the configuration file:
SYNLIB=lib_name;
2. Specify the name of the new setup file using the SETUP directive. The default name is elc.st.
SETUP="setup_file";
Note: If the setup file name already exists, the software does not overwrite the file. Instead, it creates a new file with the same name and appends a number (.number) to it. For example, if the file name setup_file already exists, it creates a new file setup_file.1. 3. Specify the name of the process in the setup file using the PROCESS directive. The default name is elc_process.
PROCESS=typical;
4. Open the database using the db_open command:

db_open test_db
5. Create the simulation setup file using the input Liberty library specified using the SYNLIB directive:
db_prepare -create_setup
You can use the EC_RECHAR_TEMPERATURE and EC_RECHAR_VOLTAGE variables to overwrite the temperature and voltage values in the input Liberty library specified using the SYNLIB directive.
December 2010
80
Performing Incremental Characterization using Internal Simulator

Incremental characterization is useful when you have an existing timing library (.lib) and want to add ECSM-based noise and power information to it. The following steps describe how to perform incremental characterization: 1. Ensure that the library for which you want to perform incremental characterization is accessible from the current working directory. 2. Ensure that the required SPICE inputs are available in the current working directory. 3. Create the Encounter library characterizer command file named cmd_file with the following commands: a. Open a database named incr_char:
db_open incr_char
b. Load the design and SPICE model data, perform circuit recognition, create the simulation vectors, and load the characterization conditions: Note: While performing incremental characterization, you must specify the output .lib file name with the -out option of db_prepare.
db_prepare -out incr_out.lib
c. Close the database:

db_close
d. Exit Encounter library characterizer:

exit
4. Create the elccfg configuration file with the appropriate directives and environment variables: Note: The EC_INCREMENT_CHAR environment variable uses the ECSM-POWER value, which indicates that the ECSM-based power information will be added to the output .lib. In addition, the SYNLIB directive specifies the name of the .lib file on which incremental characterization will be performed. Tip Alternatively, you can specify the ECSM-SI value for the EC_INCREMENT_CHAR variable to perform incremental noise characterization.
#Specify the environment variable settings. EC_SPICE_SUPPLY1_NAMES=VDD;

EC_SPICE_SUPPLY0_NAMES=VSS; EC_INCREMENT_CHAR=ECSM-POWER; EC_SIM_NAME="spectre"; #Specify the characterization inputs. SUBCKT="subckt"; MODEL="model"; DESIGNS="CMPE22D1 DFD1"; XDESIGNS=INVD1; SYNLIB=incr.lib;

elc -L incremental.log -C incremental_cmd.log -S cmd_file
December 2010
82
Performing Incremental Characterization using External Simulator

Incremental characterization is useful when you have an existing timing library (.lib) and want to add ECSM-based power information to it. The following steps describe how to perform incremental characterization: 1. Ensure that the library for which you want to perform incremental characterization is accessible from the current working directory. 2. Ensure that the required SPICE inputs are available in the current working directory. 3. Create the Encounter library characterizer command file named cmd_file with the following commands: a. Open a database named incr_char:
db_open incr_char
db_prepare -force

db_spice -p elc_process -keep_log

db_output -alf elc_state_power.alf -p elc_process -state -lib out.lib

db_close

exit
4. Create the elccfg configuration file with the appropriate directives and environment variables: Note: The EC_INCREMENT_CHAR environment variable uses the NATIVE-ECSMPOWER value, which indicates that the ECSM-based power information will be added to the output .lib. In addition, the SYNLIB directive specifies the name of the .lib file on which incremental characterization will be performed.
#Specify the environment variable settings. EC_SPICE_SUPPLY1_NAMES=VDD; EC_SPICE_SUPPLY0_NAMES=VSS; EC_INCREMENT_CHAR=NATIVE-ECSM-POWER;

EC_SIM_NAME="spectre"; EC_SIM_TYPE="spectre"; #Specify the characterization inputs. SUBCKT="subckt"; MODEL="model"; DESIGNS="CMPE22D1 DFD1"; XDESIGNS=INVD1; SYNLIB=incr.lib;

elc -L incremental.log -C incremental_cmd.log -S cmd_file
December 2010
84
Performing Statistical Characterization

The following steps describe how to perform statistical timing and leakage characterization: 1. Ensure that the required SPICE inputs are available in the current working directory. 2. Ensure that the simulation setup file is available in the current working directory. 3. Create the statistical configuration file, statistical_config, as shown:
version = 1.1 # Global parameter variation specification parameter=a1 values = AGAUSS(0, 2.87219, 1) parameter=a2 values = AGAUSS(0, 1.97457, 1) parameter=a3 values = AGAUSS(0, 1.72895, 1) parameter=a4 values = AGAUSS(0, 1.21652, 1) # Random parameter variation specification parameter=parl1 values_random = 1 parameter=parl2 values_random = 1 parameter=parl3 values_random = 1 parameter=parl4 values_random = 1
4. Create the Encounter library characterizer command file named cmd_file with the following series of commands: Note: The command file does not contain any input for statistical characterization. a. Open a database named stat_char:
db_open stat_char
db_prepare


db_output -lib out.lib -process typical -ecsm -state

db_close

exit
December 2010
85
Encounter Library Characterizer User Guide Performing Cell Library Characterization 5. Create the elccfg configuration file with the appropriate directives and environment variables: Note: The EC_CHAR environment variable uses the S-ECSM and S-LEAKAGE values, which indicate that ECSM-based statistical timing and leakage characterization will be performed. In addition, the STAT_CONFIG statement specifies the name of the statistical configuration file.
#Specify the environment variable settings. EC_SIM_USE_LSF=1; EC_SIM_LSF_CMD=""; EC_SIM_LSF_PARALLEL=10; EC_SIM_TYPE="spectre"; EC_SIM_NAME="spectre"; EC_CHAR=S-ECSM S-LEAKAGE; #Specify the characterization inputs. SUBCKT="SUBCKT"; MODEL="MODEL"; DESIGNS="CMPE22D1 DFD1"; SETUP="SETUP"; PROCESS=typical; LIB=library_file; CORNER=ss; XDESIGNS=INVD1; STAT_CONFIG=statistical_config;

December 2010
86
Performing Library Recharacterization Using Different PVT

You can use the recharacterization flow to regenerate a .lib file with ECSM-based timing, power, and statistical extensions. During recharacterization you can specify different process, voltage, and temperature (PVT) information. The following steps describe how to use an existing .lib file (as seed input) to drive the library recharacterization flow: 1. Ensure that the input .lib file is available in the current working directory. Note: The input .lib file can be located in any directory provided the absolute path is specified in the elccfg configuration file. 2. Ensure that the required SPICE inputs are available in the current working directory. Note: The SPICE inputs can be located in any directory provided the absolute path is specified in the elccfg configuration file. 3. Check if the simulation setup file is available in the current working directory. Note: This is an optional step. If the simulation setup file is not available, the software generates a simulation setup file named elc.st in the encounterlc.spec/ IPDB_NAME.spec location. This setup file is used during recharacterization if the SETUP directive is not specified in the elccfg file. 4. Create the Encounter library characterizer command file named cmd_file with the following series of commands:
db_open rechar db_prepare db_spice -s spectre -keep_log db_output -lib rechar.lib -process elc_process db_close exit
Important Ensure that you specify elc_process with the -process option of the db_output command. In the recharacterization flow, the software uses the default process elc_process when the SETUP directive is not specified in the elccfg configuration file. 5. Create the elccfg configuration file with the appropriate directives and environment variables and ensure that the following settings are done for the recharacterization flow:

#Specify the environment variable settings. EC_SIM_USE_LSF=1; EC_SIM_LSF_CMD=""; EC_SIM_LSF_PARALLEL=10; EC_SIM_TYPE="spectre"; EC_SIM_NAME="spectre"; EC_CHAR=ECSM-TIMING; #Set the EC_SPECS_FROM_LIB variable to 1. #This is a required input for library recharacterization. EC_SPECS_FROM_LIB=1; EC_SPICE_SUPPY0_NAMES=gnd; EC_SPICE_SUPPLY1_NAMES=vdd vss; #Specify the characterization inputs. #Specify the input .lib file with the SYNLIB directive. #This is a required input for library recharacterization. SYNLIB="input.lib"; #Specify the temperature to use during recharacterization. #This is an optional input. EC_RECHAR_TEMPERATURE=40; #Specify the voltage value to use during recharacterization. #This is an optional input. EC_RECHAR_VOLTAGE=1.15; PROCESS="rechar_process" SUBCKT="SUBCKT"; MODEL="MODEL"; DESIGNS="CMPE22D1 DFD1"; LIB=spice_library_file; CORNER=ss; XDESIGNS=INVD1;
6. Ensure that the elccfg configuration file contains the following settings:
The SYNLIB directive specifies the name of the input library file.
December 2010
88
The EC_SPECS_FROM_LIB variable is set to 1. When you set this variable to 1, the software creates a directory called encounterlc.spec in the working directory. The encounterlc.spec directory contains the specification files for the cells in the input library. The supply pin names are specified using the EC_SPICE_SUPPLY1_NAMES or EC_SPICE_SUPPLY0_NAMES variables. This step is required if the input .lib does not have power rail information.
In addition, you can use the following optional settings in the recharacterization flow:
Specify the PROCESS directive in the elccfg configuration file to define the process name. By default, the software uses the elc_process process name. Specify the EC_RECHAR_TEMPERATURE variable to specify the temperature value, in degree celsius, which will be applied during cell library recharacterization. If this variable is not specified, the software uses the temperature value from the input Liberty library specified using the SYNLIB directive. Specify the EC_RECHAR_VOLTAGE variable to specify the voltage value, in volts, which will be applied during cell library recharacterization. If this variable is not specified, the software uses the voltage value from the input Liberty library specified using the SYNLIB directive. Specify the EC_SPECS_DIR_PATH variable to use an existing specification file for the recharacterization flow. If you already have the specification file from a previous run, you can specify its location using this variable instead of using the EC_SPECS_FROM_LIB variable. Specify the EC_SPEC_WORK variable to specify an alternative location for the encounterlc.spec directory. Specify the EC_SYNLIB_ATTR variable to specify a list of attributes defined in the input .lib file (specified using the SYNLIB directive), which should be copied to the output library that is generated after recharacterization. Before using this variable, set the EC_SYNLIB_PASS_ATTR variable to 1.

December 2010
89
Creating a Binary Dotlib

The following steps describe how to convert a normal dotlib file to a binary dotlib file: 1. Create a command file for ETS: a. Create a text file in any editor and specify a filename. In this example, the filename is binlib.ets. b. Specify the following Tcl command in the file:
write_ldb library elcLibrary_filename -outfile binaryLibrary_filename exit
2. Convert ELC generated dotlib file to a binary dotlib file:

ets -nowin -init binlib.ets
December 2010
90
Performing Additional Library Characterization Tasks

Performing Library Characterization Using Gate File Characterizing Hierarchical Cells Generating a Non-Linear Input Slew Using a Characterized Database to Generate Multiple Views
Performing Library Characterization Using Gate File

The following steps describe how to perform library characterization using a gate file: 1. Ensure that the required SPICE inputs are available in the current working directory. 2. Ensure that the simulation setup file is available in the current working directory. Note: For information on how to create a simulation setup file for I/O cells, see the Level Shifter Cell Library section in Appendix A, Simulation Setup File Format. 3. Create the Encounter library characterizer command file named gate.tcl with the following series of commands: a. Open a database named test.ipdb:
db_open test.ipdb
db_prepare
c. Copy the gate file for the design SAMPLEDESIGN to the specified location:
cp gate/SAMPLEDESIGN.gate test.ipdb/SAMPLEDESIGN.design/boundary/gate
Important The gate file must be copied at the specified location before performing library characterization. d. Overwrite the existing simulation vectors in the database and generate new simulation vectors:
db_gsim -force
December 2010
91
Important When the db_gsim command is executed, the software displays a message indicating that the gate file is being read. e. Perform circuit simulation:
db_spice
f. Generate the Liberty library file:

db_output -process typical -lib tsst-state.lib -state
g. Close the database:

db_close
h. Exit Encounter library characterizer:

exit
4. Create the elccfg configuration file with the appropriate directives and environment variables:
EC_SPICE_SIMPLIFY=1; EC_SIM_USE_LSF=1; EC_SIM_LSF_CMD=""; EC_SIM_LSF_PARALLEL=20; EC_SIM_TYPE="spectre"; EC_SIM_NAME="spectre"; EC_CHAR=ECSM-POWER; SUBCKT="SUBCKT"; MODEL="MODEL"; DESIGNS="SAMPLEGATE"; SETUP="SETUP"; PROCESS=typical;

elc -L test.log -C test_cmd.log -S gate.tcl
6. Run ecsmChecker to validate the Liberty library file.
Characterizing Hierarchical Cells

To perform characterization of hierarchical cells, use the EXPAND directive in the elccfg configuration file. Note: All other steps to perform library characterization remain the same.
Encounter Library Characterizer User Guide Performing Cell Library Characterization The following example shows an elccfg file that performs ECSM-power characterization for the cellP5 hierarchical cell:
#Specify the environment variable settings. EC_SIM_USE_LSF=1; EC_SIM_LSF_CMD=""; EC_SIM_LSF_PARALLEL=20; EC_SIM_TYPE="spectre"; EC_SIM_NAME="spectre"; EC_CHAR=ECSM-POWER; #Specify the characterization inputs. SUBCKT="subckt.cdl"; MODEL="model_file"; SETUP="setup_file"; EXPAND=cellP5; DESIGN=cellP5; LIB=library_file; CORNER=ss;
In the above example, the EXPAND directive is used to specify a top-level cell called cellP5, which will be expanded to make a flat netlist for cell recognition. Important You must use the EXPAND directive if the input subcircuit file has a hierarchical structure.
Generating a Non-Linear Input Slew

There are three methods for generating non-linear input slew rates for cell characterization:

Generating slew using an RC circuit Generating slew using a K-factor
Generating Slew Using RC Circuit To generate non-linear input slew using an RC circuit: 1. Set the following environment variable:
set_var EC_INPUT_NONLINEAR 1
Encounter Library Characterizer User Guide Performing Cell Library Characterization 2. Specify the resistance with the EC_INCIR_R environment variable. Capacitance is calculated using the following equation: C = target_slew/resistance/4.6 Generating Slew Using the K-Factor To generate non-linear input slew using the K-factor: 1. Define the input circuit (INCIR) in the SIMULATION statement of the setup file using the following syntax: incir = string. The input circuit must have one input and one output. It can be either an inverter or buffer logic. 2. Set the following environment variable:
set_var EC_INPUT_NONLINEAR 1
3. Set the following environment variables to specify the rise and fall K-factor values:
set_var EC_INCIR_K value
or
set_var EC_INCIR_K_RISE value set_var EC_INCIR_K_FALL value
Capacitance is calculated using the following equation: C = target_slew/K-factor - output_capacitance Set the following environment variables to specify the output capacitance:
set_var EC_INCIR_COUT value
or
set_var EC_INCIR_COUT_RISE value set_var EC_INCIR_COUT_FALL value
Using a Characterized Database to Generate Multiple Views

Encounter library characterizer software allows you to generate a Liberty (.lib) library with both ECSM-timing and CCS-timing extensions. If you want to generate both ECSM-timing and CCS-timing extensions without running the SPICE simulation multiple times, use the following procedure: 1. Open the database using the db_open command:
db_open sampledata
December 2010
94
Encounter Library Characterizer User Guide Performing Cell Library Characterization 2. Load the design and SPICE model data, perform circuit recognition, create the simulation vectors, and load the characterization conditions
db_prepare -f
3. Set the EC_CHAR variable with both ECSM-TIMING and CCS-TIMING values:
EC_CHAR CCS-TIMING ECSM-TIMING
4. Perform circuit simulation:

db_spice -f
5. Generate the test_ccs_and_ecsm.lib library, which will contain CCS-timing as well as ECSM-timing data:
db_output -force -state -lib test_ccs_and_ecsm.lib
Important After you generate the CCS and ECSM timing data in the Liberty file, you can choose to generate the ECSM and CCS timing data in separate Liberty files without having to repeat steps 1, 2, and 4. This saves considerable run time. After you complete the above steps, you can generate separate Liberty libraries containing CCS and ECSM timing data, respectively.
To perform CCS-based timing characterization, use the following settings:

set_var EC_CHAR CCS-TIMING db_output -force -state -lib test_ccs.lib
To perform ECSM-based timing characterization, use the following settings:

set_var EC_CHAR "ECSM-TIMING db_output -force -state -lib test_ecsm.lib
Note: NLDM data in both CCS-based and ECSM-based libraries generated using the above flow will remain identical.
December 2010
95
December 2010
96
5
Performing Cell Library Validation

Overview on page 98 ecsmChecker on page 99 libdiff on page 100 LibVsSpice on page 105 EtsvsSpice on page 106
December 2010
97
Encounter Library Characterizer User Guide Performing Cell Library Validation
Overview
This chapter describes the steps required to perform validation of a cell library. In addition, it describes the steps to validate the accuracy of the characterized data (timing data). The following executables are used for semantic checking of cell librararies:

ecsmChecker libdiff
The following two validation methods are used to correlate the accuracy of characterized data against SPICE:

LibvsSpice ETSvsSpice
December 2010
98
ecsmChecker
The ecsmChecker command validates the specified Liberty library and detects potential errors. The validation results are printed in a log file. The log file contains warning messages which indicate the issues detected in the input Liberty library based on the library validation criteria specified. The following command validates the sample.lib library and generates the log in the results.txt file:
ecsmChecker sample.lib -o results.txt
Tip For more information on the ecsmChecker command, see the Executables chapter of the Encounter Library Characterizer Text Command Reference.
December 2010
99
libdiff
The libdiff command compares two library files and generates a report on the differences between them. This is a standalone utility that can be invoked from the command line. The libdiff utility is particularly useful when you want to compare a recharacterized library with the input library that was used for performing recharacterization. While comparing the libraries, the libdiff utility checks the differences in the following .lib constructs:

Library-Level Properties Thresholds Operating Conditions K-factors Cell-Level Properties Leakage Power Pin-Level Properties Timing Arcs, with ECSM data Power Arcs, with ECSM data
The libdiff utility can be used in the output file generation mode or in the view mode. Tip For more information on the libdiff command, see the Executables chapter of the Encounter Library Characterizer Text Command Reference. Using the Output File Generation Mode In this mode, the utility accepts two timing library files as input and generates a binary file (.ldf extension) containing the line-by-line differences between the input libraries, a librarylevel summary report and an html report of the differences. You can view these reports in the view mode. The timing libraries can be in one of the following formats:

Liberty format Cadence Library Database (Compiled Format) A combination of the above formats
December 2010
Encounter Library Characterizer User Guide Performing Cell Library Validation The syntax of using the libdiff utility in the output file generation mode is as follows:
libdiff library1 library2 [-diff diff_file] [-allow allowance_limit] [-no_timing_checks] [-ignore_below lower_limit]
Important The options specified in the syntax are applicable in the output file generation mode only. In other words, the options used in the output file generation mode and the options used in the view mode are mutually exclusive. Note: To view libdiff reports for library files having different units, you need to set the LIBDIFF_UNIT_SUPPORT variable, as shown:
setenv LIBDIFF_UNIT_SUPPORT 1
You must set this variable before running the libdiff utility in the output file generation mode. Using the View Modes to Report the Differences The libdiff utility provides you the capability to view the differences between the libraries in various other reporting modes. To view the reports, you need a .ldf file generated by the libdiff utility. You can choose one of the following report types:

Summary (summ): Prints a cell-level summary report on the terminal Terminal (term): Prints the line-by-line differences on the terminal HTML (html): Displays the comparison results in HTML format Note: Before viewing the HTML report, you must set the path to the browser application by using the BROWSER variable, as shown:
setenv BROWSER path_to_browser_binary
The syntax of the libdiff utility in the view mode is as follows:

libdiff [-view <diff_file>] [-format { summ | term | html }
Important The options specified in the syntax are applicable in the view mode only. In other words, the options used in the view mode and the options used in the output file generation mode are mutually exclusive.
Encounter Library Characterizer User Guide Performing Cell Library Validation Viewing the Summary Report To view a summary of the comparison results on the screen: 1. Compare sample1.lib and sample2.lib files and report the differences in the diff_file.ldf file.
libdiff sample1.lib sample2.lib -diff diff_file.ldf
2. View the summary of the differences between the input timing libraries on the screen.
libdiff -view diff_file.ldf -format summ
The following is an example of a summary report generated by the libdiff utility:

*********************************************************** * libdiff version 08.10-b004_1 * All rights reserved. * * * Copyright (c) Cadence Design Systems, Inc. 1996 - 2008. * *********************************************************** Libraries "test" and "test" were diffed, with "test" taken as the reference 1 cells changed Timing deviation Min:-0.01% Min:0.00% 0 cells added 0 cells deleted +--------------------+--------------------------------+-------------------------+ | | | |HD_NAND2X1 Cell | | | Min -0.01 Timing Deviation | | Max | Avg -0.94 | | | Min 0.00 Power Deviation | | Max -7.22 | | Avg -0.34 | | | +--------------------------------+----------------------------+ Max:-3.86% Max:-7.22% Avg:-0.94% Avg:-0.34% Power deviation
+--------------------+--------------------------------+-------------------------+ -3.86 | +--------------------+--------------------------------+-------------------------+
Viewing the Line-By-Line Comparison Results on the Screen To view a line-by-line comparison between the library files: 1. Compare sample1.lib and sample2.lib files and report the differences in the diff_file.ldf file.
2. View the line-by-line differences between the input timing libraries on the screen:

libdiff -view diff_file.ldf -format term
The following is an excerpt of the line-by-line differences reported by the libdiff utility:
|library (test) { | date : "today" ; | revision : "4.4" ; | bus_naming_style : "%s[%d]" ; | | | |library (test) { date : "today" ; revision : "4.4" ; bus_naming_style : "%s[%d]" ; capacitive_load_unit : (1.000000,pf) ; comment : "Cadence TLF Version 4.4" ; current_unit : "1mA" ;
|capacitive_load_unit : (1.000000,pf) ; | |comment : "Cadence TLF Version 4.4" ; | |current_unit : "1mA" ; ... ... | cell(HD_NAND2X1) { C| cell_leakage_power : 3.712790 ; 3.682860 ; | | C| | | | C| | | | C| | leakage_power () { when : "((i0) & (!(i1)))"; value :4.578230 } leakage_power () { when : "((!(i0)) & (i1))"; value :4.263510 } leakage_power () { when : "((i0) & (i1))"; value :2.684030 } |
| | | | | | | | | | | | | |
cell(HD_NAND2X1) { cell_leakage_power : leakage_power () { when : "((i0) & (!(i1)))"; value :4.229660 } leakage_power () { when : "((!(i0)) & (i1))"; value :3.941390 } leakage_power () { when : "((i0) & (i1))"; value :2.674240 }
... ... Viewing the Comparison Results in HTML Format To view the comparison results in HTML format: 1. Set the path to the browser that you wan to use:
setenv BROWSER path_to_browser_binary
2. Compare the sample1.lib and sample2.lib files and report the differences in the diff_file.ldf file.
December 2010
103
Encounter Library Characterizer User Guide Performing Cell Library Validation 3. View the differences between the input timing libraries in HTML format.
libdiff -view diff_file.ldf -format html
The following is an example of the HTML format generated by the libdiff utility:
December 2010
104
LibVsSpice
The LibVsSpice script correlates the delay and output slew data from the characterized library and from the SPICE simulator. LibVsSpice has the following parameters:

-cfg config_filename - Reads the ELC configuration file in LibVsSpice. -view html - Displays the validation results in the HTML format. -ignore_below lower_limit - Specifies a number below which the absolute differences in values of the .lib and SPICE numbers will not be reported. This option is useful in cases where small changes in the value translate to high percentage differences. For example, the percentage difference between 0.001ps and 0.002ps is 100 percent. However, if the library units are in ns, this difference is insignificant.
To run the script: 1. Ensure that the current working directory contains: LibVsSpice script (LibVsSpice.pl), encounterlc.work produced from the ELC run, ELC generated .lib, subcircuit file, and model file. 2. Create a configuration file by specifying the netlist and models (sample config file).
TOOL_LIB="elc.lib"; #ELC generated library for correlation SUBCKT="subckt"; MODEL="model"; DESIGNS="INVX1 INVX2"; #Cells for which correlation has to be done SIMULATOR="spectre";
3. Run the script.

LibVsSpice.pl -cfg configuration_file
4. View the HTML output by executing the following command:

LibVsSpice.pl -view html
Note: ELC should be run with the state-dependency (db_output -state) and ECSM characterization (db_output -ecsm) options to get propogation delay and ECSM differences in the report. #Specify the following environment variable to generate state dependency arcs with regular (default) arcs:
EC_STATE_GEN=1;
December 2010
105
EtsvsSpice
The EtsvsSpice script correlates the path delay from STA on a design that has been constructed from characterized library cells and from the SPICE simulator. The script compares ETS's result on a user specified netlist with SPICE's output and generates an HTML report. It runs for all combinational cells as well as a mix of combinational cells with sequential cells. EtsvsSpice has the following parameters:

-cfg config_filename - Reads the ELC configuration file in EtsvsSpice. -view html - Displays the validation results in the HTML format.
To run the script: 1. Ensure that the current working directory contains: EtsvsSpice.tcl (TCL file executed for report generation), standard cell .lib, subcircuit file, model file, and verilog netlist. Note: You can include the following optional files: ets_cmd (ETS command file) and ets_sdc (timing constraints file). If you have not specified these optional files, these files are automatically generated and used by the tool. 2. Create a configuration file by specifying the netlist and models (sample config file).
designs "INVX1 INVX2" verilog cell.v module cell_0100 spice "subckt.sp" model "model" tool_lib "elc.lib" #If you are using unconstrained timing paths, you do not need to specify the sdc timing file. read_sdc sdc_file read_cmd_file ets_cmd_file
3. Source a Spectre for running the script.

setenv SPECTRE spectre_path
4. Run the script.

/tclsh EtsvsSpice.tcl -cfg
5. View the comparison report generated by the tcl script in the HTML format:
/tclsh EtsvsSpice.tcl -view html
Note: Use tclsh 8.5 or above.
December 2010
106
December 2010
107
December 2010
108
6
Troubleshooting Library Characterization Issues

Overview on page 110 Characterizing Failed Cells on page 111 Handling Failures During Various db_spice Stages on page 112 Adjusting Transient Time to Prevent Simulation Failure on page 114
December 2010
109
Encounter Library Characterizer User Guide Troubleshooting Library Characterization Issues
Overview
This chapter describes troubleshooting techniques that you can use if you encounter problems while performing library characterization tasks.
December 2010
110
Characterizing Failed Cells

At times, there might be situations in which Encounter library characterizer fails to characterize a certain type of cell because of the following reasons:

Simulator accessibility Network connectivity Disk accessibility
Use the following steps to characterize the failed cell in such situations: 1. Identify the cells for which the simulation failed. 2. Specify the failed cell(s) with the -designs option of the db_spice command in the command file, as shown:
db_open db_spice -designs failedCell db_output
Consider the following points in this step:
Do not use the -f option with the db_prepare or db_spice command at the time of characterization. The db_prepare command is not required because the other cells are already installed in the database.
December 2010
111
Handling Failures During Various db_spice Stages

When you run the db_spice command, the software performs the simulation through a series of stages. The status of completion for each stage is marked as either PASS or FAIL. The following table provides a list of the db_spice stages and tips on how to work around problems encountered in each stage.
db_spice Stage INITIAL
Likely Cause(s) for Failure
Troubleshooting Tip(s) Delete the lock file Use the db_clean lock -all command to release the locks Ensure that the SPICE simulator is in the search path Ensure that the model/library file is available and is not corrupted Check that the SPICE simulation was run successfully on the driver cell in the pre-driver flow Check if you have permission to run the SPICE simulator Ensure that the SPICE simulator and the SPICE subckt/model files are compatible If the *.lis files exist, check them for warnings or errors generated during SPICE simulation
Simulation lock (sim_lock) file was found
A parallel simulation was running Simulator path not found
GENERATE
SPICE model/library file is missing Pre-driver cell simulation might have failed SPICE simulation log (*.lis) does not exist even after performing SPICE simulation SPICE simulation log has ERROR messages core file found in SPICE working directory
SIMULATE
TRANSLATE
SPICE result translation Check your installation to confirm that failed to read SPICE result the dstran_* executables exist. These executables are used to dstran program failed to translate simulator specifc output files translate SPICE result to (.raw) to simulator independent IPDB format.
December 2010
112
db_spice Stage VERIFICATE
Likely Cause(s) for Failure

Troubleshooting Tip(s) Ensure that the supply settings are correct
Incomplete supply settings Cell not recognized correctly
December 2010
113
Adjusting Transient Time to Prevent Simulation Failure

One of the common reasons for simulation failure in the VERIFICATE stage of the db_spice run during characterization is the measurement of delay, power, and noise values not being completed within the specified transient time. In Encounter library characterizer, transient time is specified with the transient statement of the simulation setup file. The following message appears in the encounterlc.log/<ipdb>.log/*log file when a problem related to transient time is encountered:
[WARNING(dssimchk)] Z : can not messure risefall time. => need more transient time.
To troubleshoot this issue, you can use the db_wave command to generate the waveform for the failed vector. The following figure shows the voltage and current waveform for the failed vector D0000:
Notice that the rise time of the Z output has not reached the threshold values within the specified transient time (40ns). You need to check the waveform for the output voltage reaching 5% of the desired voltage. This issue can be addressed by increasing the transient time to an appropriate value. Typically, the transient time value specified in the simulation setup file should be sufficiently larger than the slews values. The following figure shows the pass status of the D0000 vector after the transient time value was changed to 60ns in the simulation setup file:
December 2010
114
December 2010
115
December 2010
116
A
Simulation Setup File Format
This appendix describes the format of the ASCII simulation setup file, which defines simulation conditions such as voltage, temperature, process corner parameters, waveform measurement levels, loading capacitance, and input slew. The setup file is used as an input for library characterization. For the complete syntax of the simulation setup file, see General Syntax on page 138. This appendix presents the following topics:

Case-Sensitivity on page 118 Wildcards on page 118 Define Section on page 118 Control Section on page 133 General Syntax on page 138 Examples on page 142
December 2010
117
Encounter Library Characterizer User Guide Simulation Setup File Format
Case-Sensitivity
Statements and commands used in the setup file are case-insensitive.
Wildcards
You can use a question mark (?) or an asterisk (*) as wildcards in some simulation setup file statements. Here are some examples of wildcard usage:

mem* matches strings that start with mem, such as mem1 and memory. bus? matches four-character strings that start with bus, such as busA and bus1. bus?? matches five-character strings that start with bus, such as bus32 and bus64.
When defining wildcards, you can use combinations of ? and *, For example, *bus? matches strings that contain bus but only have a single character following bus, such as bus1 and databusA. The following descriptions identify statements that support wildcards.
Define Section
The Define section defines parameters, groups, variables, and margins to be used in the Control section. It includes the following statements, which are listed in alphabetical order.
GROUP Statement
GROUP ::= GROUP group_name { Pin = CellName.PinName [,CellName.PinName]* Cell = CellName [,CellName] * ; } ; ;
Specifies groups of cells or pins for cell library characterization.
December 2010
118
Encounter Library Characterizer User Guide Simulation Setup File Format Table A-1 GROUP Statement Syntax
Descriptor Pin Cell
Keyword Pin Cell
Type string_list string_list
Default None None
The GROUP statement supports wildcards in the string_list. Example The following GROUP statement defines groups named GRP_*, which contain cell or pin names with specific values. For instance, the group named GRP_CELL_XL contains all cell names that end in XL.
Group Group Group Group Group Group GRP_CELL_CLKBUF_I GRP_CELL_CLKBUF_O GRP_PIN_CLK GRP_CELL_XL GRP_CELL_X1 GRP_CELL_X2 { PIN { PIN { PIN = CLKBUF*.A ; }; = CLKBUF*.Y ; }; = *.CK ; }; ; }; ; }; ; };
{ CELL = *XL { CELL = *X1 { CELL = *X2
INDEX Statement
INDEX ::= Index index_name { Slew =
values ;
Load = values ; [Rslew = values ; ] [Rload = values ; ] [Fslew = values ; ] [Fload = values ; ] [Bslew = values ; ] [Rslew_pwl = list_of_pwl_names ; ] [Fslew_pwl = list_of_pwl_names ; ] [internal = list_of_node_names ; ] [glitch = glitch_levels_for_node_names ; ] [AUTO_INDEX_CELL = cell_name; ]

[AUTO_INDEX_POINTS = value; ] } ;
Specifies simulation input slew rates and output loading capacitance for cell library characterization. Slews defined by RSLEW or FSLEW overwrite slews defined by SLEW. Loads defined using RLOAD or FLOAD overwrite loads defined by LOAD. BSLEW defines the slew rates for the binary searches. If BSLEW is not defined, the binary search algorithm uses the slew rates defined by SLEW. Rslew_pwl and Fslew_pwl define the PWL names for rising input slew and falling input slew, respectively. Note: The minimum number of values that can be specified with the Slew, Rslew, Fslew, Load, Rload, and Fload keywords is 2 and the maximum number of values is 32. internal defines the internal node names. glitch specifies the corresponding glitch level (in percentage) for the internal nodes. AUTO_INDEX_CELL specifies the name of the cell to be used for index selection. AUTO_INDEX_POINTS specifies the number of index points to be generated. Table A-2 INDEX Statement Syntax
Descriptor Input slew rates Rising input slew rates Falling input slew rates Binary search slew Output load capacitance Rising output load capacitance
Keyword Slew Rslew Fslew Bslew Load Rload
Type list_of_values list_of_values list_of_values list_of_values list_of_values list_of_values
Default None SLEW SLEW SLEW None LOAD
December 2010
120
Descriptor Falling output load capacitance PWL names for rising input slew PWL names for falling input slew
Keyword Fload Rslew_pwl Fslew_pwl
Type list_of_values list_of_pwl_names list_of_pwl_names list_of_node_names glitch_levels
Default LOAD None None None None
Internal node names internal Glitch level (in glitch percentage) for internal node names Cell name for index selection Number of index points generated AUTO_INDEX_CELL
cell_name
None 7
AUTO_INDEX_POINTS value
Examples
In the following statement, the first index group is named MY_DEFAULT_INDEX. It contains load and slew defaults, which are used to create a lookup table that contains delay and transition time information (for simulation). The Additional index groups such as LOAD_XL are defined to create more lookup tables. These index groups only define the capacitance load, so the slew information comes from the slews defined in MY_DEFAULT_INDEX.
Index MY_DEFAULT_INDEX { slew = 0.03N 0.10N 0.60N 1.00N 2.00N; load = 0.8F 10.0F 40.0F 80.0F 280.0F; BSlew = 0.03N 0.60N 2.00N; } ; Index LOAD_XL { load = 0.4F 5.0F 20.0F 30.0F 40.0F; }; Index LOAD_X2 { load = 1.6F 20.0F 80.0F 120.0F 160.0F; }; Index SLEW_CLK { bslew = 0.03N 0.10N 1.00N ; };
In the following INDEX statement, you specify the PWL names for rising input slew and falling input slew using the Rslew_pwl and Fslew_pwl keywords, respectively:
Index MY_DEFAULT_INDEX {
December 2010
121

slew load = 0.03N 0.10N 0.60N 1.00N 2.00N ; = 0.8F 10.0F 40.0F 80.0F 280.0F ;
Rslew_pwl = rise_pwl1 rsie_pwl2 ; Fslew_pwl = fall_pwl1 fall_pwl2 ; };
Note: You must define the PWL names using the PWL statement before specifying them with the Rslew_pwl and Fslew_pwl keywords.
In the following INDEX statement, you specify the internal node names and corresponding glitch levels using the internal and glitch keywords, respectively:
Group FF.INTERNAL { cell = FF; }; Index FF.INTERNAL { internal = node1 node2; glitch = 20 10; }; Group(FF.INTERNAL) = FF.INTERNAL;
The internal statement specifies the internal node names, namely, node1 and node2. The glitch statement specifies the corresponding glitch level (in percentage) of 20 and 10 for node1 and node2, respectively.
MARGIN Statement
MARGIN ::= Margin margin_name { Cap = scale offset ; Wcap = scale offset ; Wresist = scale offset ; Delay = scale offset ; Ecap = scale offset ; Power = scale offset [scale offset]; Current = scale offset [scale offset]; Slew = scale offset [scale offset]; Iopath = scale offset [ [scale offset] [scale offset] ] ; Interconnect = scale offset [scale offset]; Setup = scale offset [scale offset]; Hold = scale offset [scale offset];
December 2010
122

Release = scale offset [scale offset]; Removal = scale offset [scale offset]; Setup = scale offset [scale offset]; Recovery = scale offset [scale offset]; Width = scale offset [scale offset]; };
Specifies the margin factors for cell library characterization. The margin factors include two factors: a relative factor (scale) and an absolute factor (offset). They are applied to the result data as follows: results = number * scale + offset ; Table A-3 MARGIN Statement Syntax
Descriptor
Keyword
Type scale, offset scale, offset scale, offset scale, offset scale, offset scale, offset scale, offset scale, offset scale, offset scale, offset scale, offset scale, offset scale, offset
Default 1.0, 0.0 1.0, 0.0 1.0, 0.0 1.0, 0.0 1.0, 0.0 1.0, 0.0 1.0, 0.0 1.0, 0.0 1.0, 0.0 1.0, 0.0 1.0, 0.0 1.0, 0.0 1.0, 0.0
Input capacitance factors Cap Wire capacitance factors Wcap Wire resistance factors Cell delay factors Effective capacitance factors Power consumption factors Slew rate factors I/O path delay factors Wresist Delay Ecap Power Slew Iopath
Interconnect delay factors Interconnect Setup constraint factors Hold constraint factors Release constraint factors Removal constraint factors Setup Hold Release Removal
December 2010
123
Descriptor Recovery constraint factors Pulse width constraint factors
Keyword Recovery Width
Type scale, offset scale, offset
Default 1.0, 0.0 1.0, 0.0
Example The following example shows a MARGIN statement. All scale values have been set to 1.0, and all offset values have been set to 0that is, the margins are disabled.
Margin MARGIN_SET_0 { setup hold release removal width delay power cap } ; = 1.0 0.0 ; = 1.0 0.0 ; = 1.0 0.0 ; = 1.0 0.0 ; = 1.0 0.0 ; = 1.0 0.0 ; = 1.0 0.0 ; = 1.0 0.0 ;
recovery = 1.0 0.0 ;
NOMINAL Statement
NOMINAL ::= Nominal nominal_name { Cap = n_value n_value ; Check = n_value n_value ; Current = n_value n_value ; Power = n_value n_value ; Slew = n_value n_value ; Delay = n_value n_value n_value; };
Specifies the nominal factors with which to calculate the typical (average) values for cell library characterization. You can define two scalesone for rising waveforms and one for falling waveformsthat are used to calculate the average value from the minimum and maximum values by using the nominal factors as follows:
December 2010
124
Encounter Library Characterizer User Guide Simulation Setup File Format average_value = (max min) * factor + min ; For example, Figure A-1 on page 125 and Figure A-2 on page 125 show the hold time characterization results for a gate. The first timing diagram shows the hold-time results for a rising waveform, and the second shows the hold-time results for a falling waveform. Figure A-1 Hold-Time Characterization Results (Rising Input)
If the setup file specified Nominal check 0.5 0.4, the average hold time for the rising waveform would be reported as follows: Average rise hold time = { (10 6) * 0.5 } + 6 = 8ns Figure A-2 Hold-Time Characterization Results (Falling Input)
Note: Nominal delay defines three values: the first two are for rising and falling waveforms, and the third is for delay-to-tristate measurements.
December 2010
125
Encounter Library Characterizer User Guide Simulation Setup File Format Table A-4 NOMINAL Statement Syntax
Descriptor Gate capacitance factor Constraint factor Current source factor Power factor Slew rate factor Delay factor
Keyword Cap Check Current Power Slew Delay
Type value, value value, value value, value value, value value, value value, value
Default 0.5, 0.5 1.0, 1.0 0.5, 0.5 0.5, 0.5 0.5, 0.5 0.5, 0.5
Example The following example shows a NOMINAL statement:

Nominal NOMINAL_SET_0 { delay power cap } ; = 0.5 0.5 ; // as rise fall = 0.5 0.5 ; = 0.5 0.5 ;
PROCESS Statement
PROCESS ::= Process process_name { Voltage Temp Corner section lib model Vtn Vtp RCcorner Gtcorner
December 2010
= value ; = value ; = string ; = string ; = string ; = string ; = value ; = value ; = string ; = strings ;

} ;
The Gtcorner parameter defines the process corner data for cells as follows:
min_name:type_name:best_name min_name:max_name name1 name2 ... name
Note: In Simplify mode, the section, lib, and model parameters specified in the simulation setup file override the ones defined in the elccfg configuration file or the command file. In non-Simplify mode, these parameters do not affect the characterization. Defines the simulation process conditions, that is, the device parameter conditions and the simulation temperature and voltage operating conditions, for cell library characterization. You must define the parameters of the PROCESS statement before defining the parameters of any other statement. Table A-5 PROCESS Statement Syntax
Descriptor Voltage Temperature
Keyword Voltage Temperature
Type value value strings
Default None None process_name
Process corners for Gtcorner loading cell models from library database Library section names in the library model file for SPICE simulation Library Model file name Model file name section
string
None
lib model
string string
None None
December 2010
127
Descriptor Voltage of NMOS gate. Translates to the ecsm_vtn attribute, which is used for delay calculation. Used as threhsold for tristate cells so that 1->Z and 0->Z arcs can be characterized. Used for non-tristate cells if the value is lesser than the vh value. Voltage of PMOS gate. Translates to the ecsm_vtp attribute, which is used for delay calculation. Used as threhsold for tristate cells so that 1->Z and 0->Z arcs can be characterized. Used for non-tristate cells if the value is lesser than the vl value. RC process corner
Keyword Vtn
Type value
Default None
Vtp
value
None
RCcorner
string
None
Example The following PROCESS statement defines three process corners:

Process typical { voltage temp
December 2010
= 1.2 = 25
; ;

Vtn Vtp } ; Process best voltage temp Vtn Vtp } ; Process worst voltage temp Vtn Vtp } ; { = 1.08 = 125 ; ; { = 1.32 = 0 ; ; = 0.208 ; = 0.208 ;
= 0.272 ; = 0.272 ;
= 0.192 ; = 0.192 ;
PWL Statement
PWL ::= PWL pwl_grp_name { pwl_name = pwl_waveform ; [pwl_name = pwl_waveform ; ]* };
Defines the piece-wise linear information that can be applied to the input waveform. You can use any name for the PWLs that you define. PWL names are case insensitive. Before you use the PWL statement in the setup file, ensure that the following conditions are met:

The voltage value must be normalized. The time value must be the offset value from the transient start time, which is defined in the SIMULATION statement. In addition, the first time value must be 0. The time value must be specified in the increasing order.
Example The following PWL statement defines a PWL group called MY_DEFAULT_PWL, which contains PWL names and their corresponding waveforms:
PWL MY_DEFAULT_PWL { rise_pwl1 = 0 0 25P 0.32 50P 0.6 100P 1 ;

rise_pwl2 = 0 0 100P 0.55 200P 1 ; fall_pwl1 = 0 1 100P 0 ; fall_pwl2 = 0 1 60P 0.5 200P 0 ; };
SIGNAL Statement
SIGNAL ::= Signal signal_name { Unit = {REL|ABS} ; Vh Vl Vth Vsh Vsl Tsmax incir = rise_fall_levels = rise_fall_levels = rise_fall_levels = rise_fall_levels = rise_fall_levels = value ; = string ; = value ; ; ; ; ; ;
slew_derate };
Sets the levels of the input or output signals for generating the simulation input waveforms, initializing the output voltage level, and measuring the simulation waveforms for delay and power in cell library characterization. Table A-6 SIGNAL Statement Syntax
Descriptor Voltage level unit
Keyword Unit
Type REL|ABS REL is a percentage of the voltage level unit; ABS is the fixed value.
Default REL
High-level voltage Low-level voltage Threshold-level voltage
Vh Vl Vth
value value value
1.0 0.0 0.5
December 2010
130
Descriptor High-slew voltage level Low-slew voltage level Maximum output slew, which is used for max_cap calculation Input circuit for generating nonlinear input slew Scaling factor for input slew
Keyword Vsh Vsl Tsmax
Type value value value
Default 0.8 0.2 3.0 ns
incir
string
slew_derate
value
0.0
You can define values in three ways:
You can specify four values to individually define the input-rise, input-fall, output-rise, and output-fall voltage thresholds, as in this example:
Vth = 0.1 0.2 0.15 0.25 ;
This example would set the values as follows: input rise Vth = 0.1 V input fall Vth = 0.2 V output rise Vth = 0.15 V output fall Vth = 0.25 V
You can specify two values to define common input rise/fall and common output rise/fall voltages, as in this example:
Vth = 0.1 0.2 ;
This example would set the values as follows: input-rise Vth = input-fall Vth = 0.1 V output-rise Vth = output-fall Vth = 0.2 V
You can specify a single value to define all rise/fall voltages:

Vth = 0.1 ;
December 2010
131
Encounter Library Characterizer User Guide Simulation Setup File Format This example would set the values as follows: input-rise Vth = input-fall Vth = 0.1 V output-rise Vth = output-fall Vth = 0.1 V Example In the following SIGNAL statement, a signal group named STANDARD_CELL is defined by relative voltage levels, so that Vth will be 0.6 V for the typical process corner (that is, 50 percent of the supply voltage, which is 1.2 V).
Signal STANDARD_CELL {
unit Vh Vl Vth Vsh Vsl tsmax = REL = = = = = = 1.0 0.0 0.5 0.8 0.2 1.0n 1.0 0.0 0.5 0.8 0.2 ;// following values are specified as relative // vs voltage ; ; ; ; ; ;// maximum output slew rate
} ;
SIMULATION Statement
SIMULATION ::= Simulation simulation_name { Transient = start end step ; Bisec = start end resolution ; Resistance = value ; Incir = string ; };
Defines the simulation control variables for cell library characterization. Table A-7 SIMULATION Statement Syntax
Descriptor Transient simulation Binary search
Keyword Transient Bisec
Type value, value, value value, value, value
Default 1.0 ns, 20 ns, 10 ps 3.0 ns, 3.0 ns, 100 ps
December 2010
132
Descriptor Pulling resistance
Keyword Resistance
Type value, value, value string
Default 1000000
Default input circuit for incir generating non-linear input slew
Example In the following example, the following conditions have been set:

SPICE simulations will run from 1.0 ns to 30 ns in steps of 10 ps. Binary searches, which are used to accurately characterize setup and hold times, will search for a maximum of 3 ns in steps of 10 ps. The pullup and pulldown resistance to be used for tristate measurements is 10 megohms.
transient bisec resistance incir = 1.0n = 3.0n 30n 3.0n 10p ; 10p ; // binary search
Simulation STANDARD_CELL {
= 10MEG ; = bf1xv ;
} ;
Control Section
The Control section assigns the statements defined in the Define section to different processes. The db_prepare or db_gsim command reads the Control section, installs the processes appearing in the Control section, and installs all the parameters defined in the statements in the database. The Control section includes the following commands. listed in alphabetical order.
SET_CELL Command
SET_CELL ::= Set Cell ( process_name[,process_name]) { Name = cell_name ; Simulation = simulation_name ; Index = index_name ;

Signal = signal_name ; Margin = margin_name; Nominal = nominal_name; };
Assigns the statements for a specific cell. It overwrites the assignment in the SET_PROCESS command and SET_GROUP command. It does not overwrite the assignment in the SET_PIN command. The SET_CELL command must include a name definition that is used in cell library characterization. Table A-8 SET_CELL Command Syntax
Descriptor Cell name SIMULATION statement INDEX statement SIGNAL statement MARGIN statemen NOMINAL statement
Keyword Name Simulation Index Signal Margin Nominal
Type string string string string string string
Default None None None None None None
Example
set cell (typical) { name= PCI33DGZ signal index } ; = VDDPST ; ;
= tpz015g_5VTIO5x6d1 ;
SET_DEFINES Command
SET_DEFINES ::= Set define_card (process_name[,process_name]) { Group (group_name) = define_name ; Cell (cell_name)= define_name ; Pin (pin_name)= define_name;

define_card ::= } ; [signal|simulation|index|margin|nominal]
Assigns new statements for pins, cells, or groups. SET_DEFINES is used as a placeholder to assign SIGNAL, SIMULATION, INDEX, MARGIN, and NOMINAL statements for pins, cells, or groups. It specifies the format for the SET_SIGNAL, SET_SIMULATION, SET_INDEX, SET_MARGIN, and SET_NOMINAL commands. SET_DEFINES overwrites the assignment made by the SET_PROCESS command. If the SET_DEFINES command assigns statements to the same group, cell, or pin with the SET_GROUP, SET_CELL, or SET_PIN command, respectively, a conflict will result. Avoid assigning statements with both SET_DEFINES and one of these commands. SET_DEFINES is used only for library characterization. Table A-9 SET_DEFINES Command Syntax
Descriptor Group name Cell name Pin name
Keyword Group Cell Pin
Type string string string.string
Default None None None
Example
set index (best,typical,worst) { = XL = X2 = X3 = X4 = X6 = X8 ; ; ; ; ; ; Group(XL) Group(X2) Group(X3) Group(X4) Group(X6) Group(X8)
Group(X12) = X12 ; Group(X16) = X16 ; Group(X20) = X20 ; Group(CK_SLW) = CK_SLW ; } ; set signal(typical) { Group(VDD2.5V) = VDD2.5V ; Group(VDD5.0V) = VDD5.0V ; Group(VDDB) = VDDB ; } ;
December 2010
135
SET_GROUP Command
SET_GROUP ::= Set Group( process_name[,process_name]) { Name = group_name ; Simulation = simulation_name ; Index = index_name ; Signal = signal_name ; Margin = margin_name; Nominal = nominal_name; };
Assigns the statements for a specific group. It overwrites the assignments made by the SET_PROCESS command. It does not overwrite the assignment made by the SET_CELL command and the SET_PIN command. The SET_GROUP command must include a group name definition that is used in cell library characterization. Table A-10 SET_GROUP Command Syntax
Descriptor Group name SIMULATION statement INDEX statement SIGNAL statement MARGIN statemen NOMINAL statement
Type string string string string string string
Example
set group (typical) { name= 1XPAD_PINS index= IO5x6d1 signal= VDD2.5V } ; ; ; ;
December 2010
136
SET_PIN Command
SET_PIN::= Set Pin ( process_name[,process_name]) { Name = cell_name.pin_name ;
Simulation = simulation_name ; Index = index_name ; Signal = signal_name ; Margin = margin_name; Nominal = nominal_name; } ;
Assigns the statements for a single pin. It overwrites the assignments in the SET_PROCESS command, SET_CELL command, and SET_GROUP command. The SET_PIN command must include a pin name definition that is used in cell library characterization. Table A-11 SET_PIN Command Syntax
Descriptor Pin name SIMULATION statement INDEX statement SIGNAL statement MARGIN statement NOMINAL statement
Type string.string string string string string string
Example
set pin (typical) { name= PCI33DGZ.PAD ; signal index } ; = VDD2.5V = 5VTIO5x6d1 ; ;
December 2010
137
SET_PROCESS Command
SET_PROCESS ::= Set process (process_name[,process_name]) { Simulation = simulation_name ; Index = index_name ; Signal = signal_name ; Margin = margin_name; Nominal = nominal_name; } ;
Sets the process parameters for library characterization. Table A-12 SET_PROCESS Command Syntax
Descriptor Simulation definition Simulation index Signal levels Margin factors Nominal factors
Keyword Simulation Index Signal Margin Nominal
Type string string string string string
Default DEFAULT_ SIMULATION DEFAULT_INDEX DEFAULT_SIGNAL DEFAULT_MARGIN DEFAULT_NOMINAL
Example
set process (best,typical,worst) { simulation = std_cell index signal margin nominal } ; = X1 = m0 = n0 ; ; ; ; = std_cell ;
General Syntax
The complete syntax of the simulation setup file is as follows:
SETUP := DEFINE_SECTION* | SET_SECTION*
December 2010 138
;
DEFINE_SECTION :=
PROCESS* | [ SIGNAL* | SIMULATION*
| GROUP * | INDEX* | MARGIN* | NOMINAL* ] PROCESS ::= Process process_name { Voltage Temp Corner LIB MODEL Vtn Vtp RC_Corner GT_Corner } ; SIGNAL ::= Signal signal_name { Unit = {REL|ABS} ; Vh Vl Vth Vsh Vsl }; SIMULATION ::= Simulation simulation_name { Transient = start end step ; Bisec = start end resolution ; Resistance = value ; }; INDEX ::= Index index_name { Slew = values ; Load = values ; [Rslew = values ; ] [Rload = values ; ] [Fslew = values ; ] [Fload = values ; ] [Bslew = values ; ] } ;
= value ; = value ; = string = string = string = value ; = value ; = string = string ; ; ; ; ;
= rise_fall_levels = rise_fall_levels = rise_fall_levels = rise_fall_levels = rise_fall_levels
; ; ; ; ;
Tsmax = value ;
GROUP ::=
GROUP group_name { ;
Pin = CellName.PinName [,CellName.PinName]* Cell = CellName [,CellName] * ; } ; MARGIN ::= Margin margin_name { Cap = scale offset ; Wcap = scale offset ; Wresist = scale offset ; Delay = scale offset ; Ecap = scale offset ; Power = scale offset [scale offset];
Current = scale offset [scale offset]; Slew = scale offset [scale offset]; Iopath = scale offset [ [scale
offset ] [scale offset] ] ;
Interconnect = scale offset [scale offset]; Setup = scale offset [scale offset]; Hold = scale offset [scale offset]; Release = scale offset [scale offset]; Removal = scale offset [scale offset]; Setup = scale offset [scale offset]; Recovery = scale offset [scale offset]; Width = scale offset [scale offset]; }; NOMINAL ::= Nominal nominal_name { Cap = n_value nvalue ; Check = n_value n_value ; Current = n_value n_value ; Power = n_value n_value ; Slew = n_value n_value ; Delay = n_value n_value n_value; }; SET_SECTIONS ::= [SET_DEFINES] SET_PROCESS ::= SET_PROCESS* | [SET_PIN] | [SET_CELL] | [SET_GROUP] |
Set process (process_name[,process_name]) {
Simulation = simulation_name ; Index = index_name ;


Signal = signal_name ; Margin = margin_name; Nominal = nominal_name; } ; SET_PIN::= Set Pin ( process_name[,process_name]) { Name = cell_name.pin_name Index = index_name ; Signal = signal_name ; Margin = margin_name; Nominal = nominal_name; } ; SET_CELL ::= Set Cell ( process_name[,process_name]) { Name = cell_name ; Simulation = simulation_name ; Index = index_name ; Signal = signal_name ; Margin = margin_name; Nominal = nominal_name; }; SET_GROUP ::= Set Group( process_name[,process_name]) { Name = group_name ; Simulation = simulation_name ; Index = index_name ; Signal = signal_name ; Margin = margin_name; Nominal = nominal_name; }; SET_DEFINES ::= Set define_card (process_name[,process_name]) { ; Simulation = simulation_name ;
Group (group_name) = define_name ; Cell (cell_name)= define_name ; Pin (pin_name)= define_name; } ; define_card ::= Signal|Simulation|Margin|Nominal ; define_name ::= signal_name|simulation_name|margin_name|nominal_name ;
December 2010
141

rise_fall_levels::= input rise [[input fall] output rise [output fall]] input rise::= value input fall::= value output rise::= value output fall::= value scale ::= value[:value:value] offset ::= value[:value:value] n_value ::= value[:value:value] start ::= value end ::= value step ::= value cell_name::=string pin_name::=string group_name::=string process_name::= string slew_name::= string signal_name::= string simulation_name::= string index_name::= string margin_name ::= string nominal_name::= string pin_name_list::= string [,string]* net_name_list::= string [,string]* instance_name_list::= string [,string]* value::= real
Examples
Following are three examples of simulation setup files. The first one is used to generate a standard cell library, the second is used to create an I/O cell library, and the last one is used for level-shifter cells.
Standard Cell Library

Following is a sample simulation setup file used in generating a standard cell library:
// Sample stdcell simulation setup file // For process : typical, best, worst // table size : 7X7
December 2010
142

// Define Section = 1.2 ; // as voltage
Process typical { voltage temp Vtn Vtp } ; Process best temp Vtn Vtp } ; Process worst voltage temp Vtn = 0.192 Vtp = 0.192 } ; Signal unit Vh Vl Vth Vsh Vsl } ; Simulation std_cell { transient bisec resistance } ; Index BSlew X1 { = 0.0385N 0.5360N 2.0000N ; // optional for binary search = 0.0385N 0.0744N 0.1440N 0.2780N 0.5360N 1.0360N 2.0000N ; = 0.00082P 0.00330P 0.00842P 0.01848P 0.03861P 0.07870P 0.18975P ;
= 25 = 0.208 ; = 0.208 ;
; /* as temperature */
{ = 1.32 ; ; ; // as voltage = 0 ; /* as temperature */
voltage = 0.272 = 0.272
{ = 1.08 ; // as voltage ; /* as temperature */
= 125 ; ;
std_cell { ; 1.0 ; 0.0 ; 0.5 ; 0.8 ; 0.2 ; ; // maximum output slew rate // 50% rise/fall // relative value // 100% rise/fall
= REL = 1.0 = 0.0 = 0.5 = 0.8 = 0.2
tsmax = 1.0n
= 1.0n 60n = 10MEG;
10p
; // binary search
= 6.0n 6.0n 10ps ;
slew load
December 2010

} ; Index } ; Index } ; Index } ; Index } ; Index } ; Index } ; Index } ; Index } ; Index } ; Index bslew } ; Group PIN } ; CK_SLW { = *.CK ; CK_SLW { = 0.0385N 0.5360N 1.0360N ; X20 { = 0.01650P 0.06600P 0.16830P 0.36960P 0.77220P 1.57410P 3.79500P ; load X16 { = 0.01320P 0.05280P 0.13464P 0.29568P 0.61776P 1.25928P 3.03600P ; load X12 { = 0.00990P 0.03960P 0.10098P 0.22176P 0.46332P 0.94446P 2.27700P ; load X8 { = 0.00660P 0.02640P 0.06732P 0.14784P 0.30888P 0.62964P 1.51800P ; load X6 { = 0.00495P 0.01980P 0.05049P 0.11088P 0.23166P 0.47223P 1.13850P ; X4 { = 0.00330P 0.01320P 0.03366P 0.07392P 0.15444P 0.31482P 0.75900P ; load X3 { = 0.00248P 0.00990P 0.02524P 0.05544P 0.11583P 0.23612P 0.56925P ; X2 { = 0.00165P 0.00660P 0.01683P 0.03696P 0.07722P 0.15741P 0.37950P ; XL { = 0.00041P 0.00165P 0.00421P 0.00924P 0.01930P 0.03935P 0.09488P ;
load
load
load
load
December 2010
144

Group } ; Group } ; Group } ; Group } ; Group } ; Group } ; Group } ; Group } ; Group } } ; Group } ; Margin setup hold m0 { = 1.0 0.0 ; = 1.0 0.0 ; X20 { CELL = *X20 ; X16 { CELL = *X16 ; X12 { CELL = *X12 ; X8 { CELL = *X8 ; X6 { CELL = *X6 ; X4 { CELL = *X4 ; X3 { CELL = *X3 ; X2 { CELL = *X2 ; X1 { CELL = *X1 ; XL {
CELL = *XL ;
release = 1.0 0.0 ; removal = 1.0 0.0 ; recovery = 1.0 0.0 ; width delay power = 1.0 0.0 ; = 1.0 0.0 ; = 1.0 0.0 ;
December 2010

cap } ; Nominal delay power cap } ; // Control Section // set process (best,typical,worst) { simulation = std_cell index signal margin nominal } ; set index // (best,typical,worst) { = XL = X1 = X2 = X3 = X4 = X6 = X8 ; ; ; ; ; ; ; = X1 = m0 = n0 ; ; ; ; = std_cell ; n0 { = 0.5 0.5 ; // as rise fall = 0.5 0.5 ; = 0.5 0.5 ; = 1.0 0.0 ;
Group(XL) Group(X1) Group(X2) Group(X3) Group(X4) Group(X6) Group(X8)
Group(X12) = X12 ; Group(X16) = X16 ; Group(X20) = X20 ; Group(CK_SLW) = CK_SLW ; } ;
December 2010
146
Level Shifter Cell Library

To characterize level shifter cells, configure the simulation setup file with multiple supply voltages. For example, the following setup file defines two signal groups with different voltages:
// Define Section // Defines the typical simulation process conditions. Process elc_process { voltage temp Vtn Vtp } ; // Defines the input and output voltage levels for a signal group called // std_cell, which denotes the nominal voltage level specification. Signal std_cell { unit Vh Vl Vth Vsh Vsl tsmax } ; // Defines the input and output voltage levels for a signal group called // default_cell, which denotes voltage level specification other than // the nominal voltage. This voltage is applied to the specified input, // output, inout, or supply pins. Signal default_cell { unit Vh Vl Vth Vsh Vsl tsmax } ; // Defines the simulation control variables for cell library characterization.
= 1.08 ; // as voltage = 125 ; // as temperature = 0.444932 ; = 0.48939 ;
= ABS = 1.08 = 0.0
; //absolute value ; ;
= 0.504 ; = 0.756 ; = 0.324 ; = 1.0936e-09 ; //maximum output slew rate
= ABS ; = 0.864 ; = 0.0 ; //50% = 0.432 ; //100%
= 0.6048 ; //70% = 0.2592 ; //30% = 1.0936e-09 ;

Simulation std_cell { transient bisec resistance incir } ; // Slews are quoted in a 0-100% scale Group LVLHLD1.I { PIN = LVLHLD1.I ; }; Index LVLHLD1.I { // halved for incorporting slew derate Rslew = Fslew = }; Group LVLHLD1.Z { PIN = LVLHLD1.Z ; }; Index LVLHLD1.Z { Rload = Fload = }; // Slews are quoted in a 0-100% scale Group LVLLHD1.I { PIN = LVLLHD1.I ; }; Index LVLLHD1.I { Rslew = Fslew = }; Group LVLLHD1.Z {
= 2.1872e-10 6.5616e-06 4.3544e-11 ; = 1.31232e-08 1.31232e-08 1.6872e-10 ; = 10MEG ; = "" ;
0.18e-10 0.44e-10 0.97e-10 0.18e-10 0.44e-10 0.97e-10
2.01e-10 4.1e-10 8.23e-10 16.63e-10 ; 2.01e-10 4.1e-10 8.23e-10 16.63e-10 ;
7e-16 17e-16 35e-16 72e-16 146e-16 295e-16 591e-16 ; 7e-16 17e-16 35e-16 72e-16 146e-16 295e-16 591e-16 ;
0.18e-10 0.44e-10 0.97e-10 0.18e-10 0.44e-10 0.97e-10
2.01e-10 4.1e-10 8.23e-10 16.63e-10 ; 2.01e-10 4.1e-10 8.23e-10 16.63e-10 ;
PIN = LVLLHD1.Z ; }; Index LVLLHD1.Z { Rload = Fload = }; Group G_EXT { PIN = LVLLHD1.VDDL LVLLHD1.Z ; }; set index (elc_process) { Group(LVLHLD1.I) = LVLHLD1.I ; Group(LVLHLD1.Z) = LVLHLD1.Z ; Group(LVLLHD1.I) = LVLLHD1.I ; // Group(LVLLHD1.Z) = LVLLHD1.Z ; Group (G_EXT) = LVLLHD1.Z ; }; set process (elc_process) { simulation = std_cell; index signal = std_cell; = std_cell}; 0.8e-15 1.8e-15 3.6e-15 7.3e-15 14.7e-15 29.5e-15 59.1e-15 ; 0.8e-15 1.8e-15 3.6e-15 7.3e-15 14.7e-15 29.5e-15 59.1e-15 ;
set signal (elc_process) { Group(G_EXT) = default_cell ; };
I/O Cell Library

Following is a sample simulation setup file used in generating an I/O cell library:
// Sample iocell simulation setup file // For process : typical // table size : 6X5 // Cadence Design Systems, Inc. (2003) // DEFINES Process typical {
December 2010
149

voltage temp Vtn Vtp } ; Signal INTERNAL { unit Vh Vl Vth Vsh Vsl } ; Signal VDD2.5V { unit = Vh Vl Vth Vsh Vsl } ; Signal VDD5.0V { unit = Vh Vl Vth Vsh Vsl } ; Signal VDDB { unit = Vh Vl Vth
December 2010
= 1.0 = 25 = 0.1 = 0.1
; // as voltage ; /* as temperature */ ; ;
= REL = 1.0 = 0.0 = 0.5 = 0.9 = 0.1
; 1.0 ; 0.0 ; 0.5 ; 0.9 ; 0.1 ; ;
tsmax = 2.0n
ABS ; 2.5 2.5 ; 0.0 0.0 ; 1.25 1.25 ; 2.25 2.25 ; 0.25 0.25 ; 2.0n ;
= = = = =
tsmax=
ABS ; 5.0 5.0 ; 0.0 0.0 ; 2.50 2.50 ; 4.50 4.50 ; 0.50 0.50 ; 2.0n ;
= = = = =
tsmax=
ABS ; 1.5 1.5 ; 0.0 0.0 ; 0.75 0.75 ;

= = =

Vsh Vsl } ; Simulation core { transient bisec incir resistance } ; Index load { = 0.1n = 0.1n = 0.1p 0.5n 0.2n 0.5p 1.2n 1.5n ; 0.5n 0.8n 1.2n 1.5n ; 1.2p 2.4p 3.6p 4.5p ; = 0.1n 80n = "" ; = 10K; 10p ; = 4.0n 4.0n 100p ; = = 1.35 1.35 ; 0.15 0.15 ; 2.0n ;
tsmax=
BSlew Slew Load } ;
Index Core5x6d0 { Load = 0.012p 0.024p 0.048p 0.072p 0.120p 0.240p ; } ; Index 5VTIO5x6d0 { Load = 0.012p 0.024p 0.048p 0.072p 0.120p 0.240p ; } ; Index 5VTIO5x6d1 { Load = 0.024p 0.048p 0.096p 0.144p 0.192p 0.240p ; } ; Index 5VTIO5x6d2 { Load = 0.024p 0.096p 0.192p 0.288p 0.480p 0.960p ; } ; Index IO5x6d0 { Slew = 0.3n 0.6n 1.2n 1.5n 3.0n ; Load = 5.000p 10.000p 15.000p 20.000p 25.000p 30.000p ; } ; Index IO5x6d1 { Slew = 0.3n 0.6n 1.2n 1.5n 3.0n ; Load = 10.000p 20.000p 30.000p 40.000p 70.000p 100.000p ; } ; Index IO5x6d2 { Slew = 0.3n 0.6n 1.2n 1.5n 3.0n ; Load = 20.000p 40.000p 60.000p 80.000p 100.000p 150.000p ;

} ; Index IO5x6d3 { Slew = 0.3n 0.6n 1.2n 1.5n 3.0n ; Load = 30.000p 50.000p 70.000p 90.000p 120.000p 175.000p ; } ; Index USBFIO12x5 { Load = 10.000p 20.000p 40.000p 50.000p 100.000p ; } ; Index USBLIO10x5 { Load = 10.000p 20.000p 40.000p 50.000p 100.000p ; } ; Index IO3x1d2 { Load = 30.000p ; } ; Index 5VTIO3x6d2 { Load = 0.024p 0.096p 0.192p 0.288p 0.480p 0.960p ; } ; Group VDD2.5V { pin = *.VDDA *.PGATE *.FLOAT *.VD33 *.P0001 *.P0000 ; } ; Group VDDB { pin = *.VDDB ; } ; Group VDD5.0V { pin = *.VDD5V ; } ; Group C_PINS { pin = *.C } ; Group 1XPAD_PINS { pin = *02*.PAD *04*.PAD } ; Group 2XPAD_PINS { pin = *08*.PAD *12*.PAD
December 2010
;

} ; Group 3XPAD_PINS { pin = *16*.PAD *24*.PAD } ; Group X_PINS { pin = *.XC *.XOUT } ; Group PCIPAD_PINS { pin = PCI*.PAD ; } ; // set functions set process (typical) { simulation = core index signal margin nominal } ; set signal(typical) { Group(VDD2.5V) = VDD2.5V ; Group(VDD5.0V) = VDD5.0V ; Group(VDDB) } ; set group (typical) { name= 1XPAD_PINS index= IO5x6d1 signal= VDD2.5V } ; set group (typical) { name= 2XPAD_PINS index= IO5x6d2 signal= VDD2.5V } ; set group (typical) { name= 3XPAD_PINS index= IO5x6d3
December 2010
; ; ; ; ;
= load = core = m0 = n0
= VDDB
; ; ;
; ; ;
; ;

signal= VDD2.5V } ; set group (typical) { name= PCIPAD_PINS ; index= IO5x6d3 signal= VDD2.5V } ; set group (typical) { name= X_PINS index= Core5x6d0 } ; set group (typical) { name= C_PINS index= 5VTIO5x6d1 } ; /* you can use following set to set specific cell/pin condition */ //set pin (typical) { //name= PCI33DGZ.PAD ; //signal= VDD2.5V //index= 5VTIO5x6d1 //} ; //set cell (typical) { //name= PCI33DGZ //signal= VDDPST //} ; ; ; ; ; ; ; ; ; ; ; ;
//index= tpz015g_5VTIO5x6d1 ;
December 2010
154
B
Property File Format
This appendix describes the Property file format that Encounter library characterizer uses in its processing.
December 2010
155
Encounter Library Characterizer User Guide Property File Format
Property File Syntax

Use the following syntax to create a property file:
{library library_name { [ tree_type tree_type_name ; ] [ default_power_rail power_supply_name ; ] [ power_rail power_supply_name voltage_value ; ]* [ voltage_map (voltage_pin_name, voltage_value); ]* }; }* { cell cell_name { [ pg_pin pg_pin_name { ; [ pin_name pg_pin_name ; ] [ voltage_name voltage_pin_name ; ] [ pg_type power_type ; ] [ pg_function power_supply_name ; ] [ switch_function value ; ] };]* [ pin pin_name { direction { input | output | inout } ; [ scan signal_type ; ] [ is_pad { true | false } ; ] [ output_voltage voltage_symbol ; ] [ input_voltage voltage_symbol ; ] [ driver_type { pull_up | pull_down } ; ] [ drive_current current ; ] [ pulling_resistance resistance ; ] [ property "property" ; ]* [ test_property "property" ; ]* [ rail_connection connection_name ; ] [ signal_level power_supply_name ; ] [ related_power_pin pg_pin_name ; ] [ related_ground_pin pg_ground_pin_name ; ] }; ]* [ function { ff construct | latch construct | statetable construct} ; ] [ footprint footprint_name ; ] [ area value ; ] [ pad_cell { true | false } ; ] [ property "property" ; ]*
December 2010
156

[ rail_connection connection_name power_supply_name ; ]* [ is_level_shifter { true | false } ; ] }; }*
Where:
library library_name Specifies the library name. You can use the * and ? wildcards when specifying a library name. tree_type tree_type_name Specifies the tree_type_name in the operating_conditions group of the output .lib. default_power_rail power_supply_name Specifies the default power_supply_name in the power_supply group of the output .lib. power_rail power_supply_name voltage_value Specifies the power_supply_name and the voltage_value in the power_supply group of the output .lib. voltage_map (voltage_pin_name, voltage_value) Specifies the voltage name and voltage value. The voltage name specified with this statement is referenced by the celllevel pg_pin groups. cell cell_name pg_pin pg_pin_name Specifies the power/ground group name. pin_name pg_pin_name Specifies the power/ground pin name. voltage_name voltage_pin_name Specifies the voltage name. The voltage name specified with this statement is the same as the voltage name specified with the voltage_map library-level statement. Specifies the cell name. You can use the * and ? wildcards when specifying a cell name.
December 2010
157
pg_type power_type Specifies the power type values, such as primary_power, ground_power, and so on. The value specified with this statement is dumped with the pg_type attribute in the output .lib file. pg_function power_supply_name Specifies the power supply name, which should be one of the power/ground pins defined using the pg_pin statement. pin pin_name Specifies the pin name. You can use the * and ? wildcards when specifying a pin name.
direction { input | output | inout } Specifies the direction of the pin. scan signal_type Specifies the signal type to output for the pin. Specify one of the following signal types: in out enable in_inverted out_inverted Outputs test_scan_in. Outputs test_scan_out. Outputs test_scan_enable. Outputs test_scan_in_inverted. Outputs test_scan_out_inverted.
enable_inverted Outputs test_scan_enable_inverted. scan_clock scan_clock_a scan_clock_b clock is_pad {true | false) Specifies whether the pin is a pad pin. output_voltage voltage_symbol Specifies the output voltage for the pin, if is_pad is set to true. input_voltage voltage_symbol Specifies the input voltage for the pin, if is_pad is set to true. Outputs test_scan_clock. Outputs test_scan_clock_a. Outputs test_scan_clock_b. Outputs test_clock.
December 2010
158
driver_type { pull_up | pull_down } Specifies the driver type, if pad_cell is set to true. drive_current current Specifies the drive for the pin, if pad_cell is set to true. pulling_resistance resistance Specifies the pulling resistance of the pin, if pad_cell is set to true. test_property property Specifies a property for a pin, which will be added to the corresponding pin definition within the test_cell group in the output .lib. rail_connection connection_name Specifies the rail connection_name for a pin. This parameter should be used if the connection_name is different from the supply pin name in the ALF power table. If the connection_name is the same as the supply name in the ALF power table, Encounter library characterizer automatically generates the power_level parameter in the internal_power group of the output .lib. signal_level power_supply_name Specifies the power_supply_name for the input_signal_level or output_signal_level statements in the pin group of the output .lib. related_power_pin pg_pin_name Associates the power/ground pin to the signal pin of the cell. In other words, relates the pg_pin attribute to the power_rail attribute. related_ground_pin pg_ground_pin_name Associates the power/ground pin to the signal pin of the cell. In other words, relates the pg_ground_pin attribute to the power_rail attribute. footprint footprint_name Specifies the footprint name for the cell.
December 2010
159
area value
Specifies the area for the cell.
pad_cell { true | false } Specifies whether the cell is a pad cell. property property Specifies a property for the cell or pin. rail_connection connection_name power_supply_name Specifies the rail connection_name and power_supply_name for a cell. Note: To generate power rail descriptions in the output .lib file, you must specify the rail_connection parameter for the cell. is_level_shifter { true | false } Specifies whether the cell is a level shifter cell. function {ff construct | latch construct | statetable construct} Specifies the function of a cell that can be a latch/ff/statetable construct. This parameter overrides any function or behavior description in the ALF file.
Example
If you specify the following property file with the alf2lib command:
cell SDF* { pin SE { direction input; scan enable; }; pin SI { direction input; scan in; }; pin Q* { direction output; scan out; }; footprint asdf ; property "foo: var;" ;

};
The alf2lib command outputs the following Liberty file:

cell (SDF12) { cell_footprint : asdf; ... test_cell() { pin(CKN) { direction : input; } pin(D) { direction : input; } pin(Q) { direction : output; signal_type : test_scan_out; } pin(QN) { direction : output; signal_type : test_scan_out; } pin(RN) { direction : input; } pin(SE) { direction : input; signal_type : test_scan_enable; } pin(SI) { direction : input; signal_type : test_scan_in; } pin(SN) { direction : input; } ff (P0000,P0003) { next_state : "D"; clocked_on : "!CKN"; clear : "(!RN)";
December 2010
161

preset : "(!SN)"; clear_preset_var1 : H; clear_preset_var2 : L; } } foo: var; }
The following is an example of a property file to illustrate the use of the cell level property function to pass latch/ff/statetable constructs:
cell DFF { function "ff$IQ,IQN$ {\ next_state : \"D\";\ clocked_on : \"C\";\ }"; }; cell LDX { function "latch$IQ,IQN$ {\ data_in : \"D\";\ enable : \"E\";\ clear : \"$!CDN$\";\ }"; }; cell LD2X { function "statetable(\"E D table : \"L H L/H L L H L H H H - - - }"; }; H H H H L L H SE1 SE2 SI L/H L H H H H H H L H CDN\", \"Q QN SO\" : - : - : - : - : - : - : - : - - : N N - , \\\ - : L/H H/L - , \\\ - : L/H H/L - , \\\ - : L H - , \\\ - : H L - , \\\ - : X X - , \\\ - : L H - , \\\ - : - N , \\\ ) {\
: L/H H/L - : - - L/H\";\
Note: All special characters should have an escape sequence (\) as used in a string.
December 2010
162
C
Gate File Format
This appendix describes the Gate file format that Encounter library characterizer uses in its processing.
December 2010
163
Encounter Library Characterizer User Guide Gate File Format
Gate File
A gate file contains primitive gates that describe a circuit. The db_gsim command uses the gate file to generate a specification file that is then used to create the simulation vectors for the design. The gate file can also be used to verify extracted circuits. You can create a gate file using the db_gate command. (For syntax information, see db_gate.) You can also create a gate file using the -g option with the db_gsim command, but only if gate recognition fails. You cannot use the db_gsim command to create a gate file if gate recognition has completed. The gate file is created using following file format:
DESIGN (design_name); // comment; {port_type port_name (net_name, ...);} [port_property;] // comment; {gate_type (net_name, ...);} END_OF_DESIGN;
Where: DESIGN design_name Specifies the name of the design. port_type Specifies the type of port. The port can be one of the following types: INPUT, OUTPUT, INOUT, SUPPLY0, SUPPLY1, or FEEDTHRU. Specifies the name of the port. Specifies the name of the net associated with the port or gate. Specifies a property for the specified ports. Ports can have the following properties: COMPLEMENTARY The input ports are complementary. PULL_UP PULL_DOWN gate_type The port has a pull-up resistance. The port has a pull-down resistance.
port_name net_name port_property
Specifies the type of gate. The gate can be one of the following types: BUF, NOT, OR, NOR, AND, NAND, XOR, NXOR, MAJ, IMAJ, MUX, IMUX, BUFIF1 (NMOS), BUFIF0 (PMOS), NOTIF1, NOTIF0, CMOS, PUSHPULL, or AMP.
December 2010
164
Ports
Port definitions in the gate file include the port type, port name and associated net names for each port. Figure C-1 on page 165 illustrates the different port types. Figure C-1 Port Types
a
A
a
INPUT A (a);
VDD a SUPPLY1 VDD (a);
OUTPUT A (a); a SUPPLY0 VSS (a);
Tristate
p OUTPUT A (a, n, p); a n
VSS
A A
a
B
p a n INOUT A (a, n, p); INPUT A (a); FEEDTHRU B (a);
Gates
Gate definitions in the gate file include the gate type and associated net names for each gate. There are two categories of gates that you can define: primitive gates; and tristate gates.
December 2010
165
Encounter Library Characterizer User Guide Gate File Format Primitive Gates The following table describes primitive gate types:
Primitive Gates BUF OR AND XOR MAJ MUX AMP Y=A Y=A | B | C Y=A&B&C Y=A^B^C Y=A&B | B&C | C&A Y=A?B:C Y=A>B? 1:A<B? 0:X NOT NOR NAND XNOR IMAJ IMUX Y=~A Y=~(A | B | C...) Y=~(A&B&C...) Y=~(A^B^C...)
Number of Inputs 1 n n n
Y=~(A&B | B&C | C&A) 3 Y=~(A?B:C) 3 2
When specifying primitive gates, the following rules apply:

Output ports cannot be connected to each other. Output ports cannot be connected to tristate output gates. Output ports cannot be connected to input or inout ports.
Figure C-2 on page 167 illustrates the MAJ and IMAJ gate descriptions:
December 2010
166
Encounter Library Characterizer User Guide Gate File Format Figure C-2 MAJ and IMAJ Gates
MAJ(Y, A, B, C); A B C MAJ Y IMAJ(Y, A, B, C); A B C IMAJ Y
A 1 1 X 0 0 X
B 1 X 1 0 X 0
C X 1 1 X 0 0
Y 1 1 1 0 0 0
A 1 1 X 0 0 X
B 1 X 1 0 X 0
C X 1 1 X 0 0
Y 0 0 0 1 1 1
Figure C-3 on page 168 illustrates the MUX and IMUX gate descriptions:
December 2010
167
Encounter Library Characterizer User Guide Gate File Format Figure C-3 MUX and IMUX Gates
MUX(Y, A, B, C); A B C MUX Y
IMUX(Y, A, B, C); A B C IMUX Y
A 1 1 0 0 X X
B 1 0 X X 1 0
C X X 1 0 1 0
Y 1 0 1 0 1 0
A 1 1 0 0 X X
B 1 0 X X 1 0
C X X 1 0 1 0
Y 0 1 0 1 0 1
Tristate Gates The following table describes tristate gate types:
Tristate Gates BUFIF1 (NMOS) BUFIF0 (PMOS) NOTIF1 NOTIF0 CMOS PUSHPULL Y= if (B=1) then A else HiZ Y= if (B=0) then A else HiZ Y= if (B=1) then ~A else HiZ Y= if (B=0) then ~A else HiZ Y= if (B=1 | C=0) then A else HiZ Y= if (A=1 & B=1) then 0 else if (A=0 & B=0) then 1 else if (A=0 & B=1) then HiZ else if (A=1 & B=0) then X (inhibit)
168
Number of Inputs 2 2 2 2 3 2
December 2010
Encounter Library Characterizer User Guide Gate File Format When specifying tristate gates, the following rules apply:

Output ports can be connected to each other. Output ports cannot be connected to a primitive gate. Output ports cannot be connected to an input port.
Figure C-4 on page 169 illustrates tristate gates: Figure C-4 Tristate Gates
BUFIF1 (Y, A, B); BUFIF0 (Y, A, B); CMOS (Y, A, B, C); C A Y A Y A B B B Y
NOTIF1 (Y, A, B);
NOTIF1 (Y, A, B); A
PUSHPULL (Y, A, B);
A Y
Bidirectional Switches The following table describes MOSFET, or bidirectional switches. Bidirectional switches are written out in the gate file if gate recognition fails. A specification file cannot be generated if these switches exist; therefore, you must replace them with primitive or tristate gates. For
December 2010
169
Encounter Library Characterizer User Guide Gate File Format information modifying the gate file, see The following example describes and illustrates a tristate IO cell to aid cell recognition: on page 173.
Bidirectional Switches NMOSX PMOSX CMOSX NMOSX (D, S, G) PMOSX (D, S, G) CMOSX (D, S, NG, PG)
Number of Nodes 3 3 4
Figure C-5 on page 170 illustrates bidirectional switches: Figure C-5 Bidirectional Switches
NMOSX PMOSX CMOSX
D G S G
D NG S
D PG S
December 2010
170
Examples
The following example describes and illustrates a NAND gate:
DESIGN (NAND2); //PORT SECTION; INPUT A (A); INPUT B (B); OUTPUT Y (Y); SUPPLY1 VDD (VDD); SUPPLY0 VSS (VSS); //GATE SECTION NAND (Y, A, B); END_OF_DESIGN; VSS A B A Y B Y NAND2
VDD
The following example describes and illustrates a tristate buffer:

DESIGN (TBUF); //PORT SECTION; INPUT A (A); INPUT EN(EN); OUTPUT Y (Y, N, P); SUPPLY1 VDD (VDD); SUPPLY0 VSS (VSS); //GATE SECTION BUFIF1 (Y, A, EN); NOT ($1, EN); NAND (P, A, EN); NOR (N, A, $1); END_OF_DESIGN; A EN Y (To measure tpHZ) P A Y EN Tristate buffer (TBUF)
N (To measure tpLZ)
December 2010
171
Encounter Library Characterizer User Guide Gate File Format The following example describes and illustrates a bidirectional buffer:
Bidirectional buffer (BIO) Y
DESIGN (BIO); //PORT SECTION; INPUT A (A); INPUT EN(EN); OUTPUT Y (Y); INOUT PAD (PAD, N, P); SUPPLY1 VDD (VDD); SUPPLY0 VSS (VSS); PULL_UP PAD //GATE SECTION BUFIF1 (PAD, A, EN); NOT ($1, EN); NAND (P, A, EN); NOR (N, A, $1); BUF (Y, PAD); END_OF_DESIGN;
EN
PAD
P Y
EN PAD A
The following example describes and illustrates a differential input circuit:

DESIGN (DIN); //PORT SECTION; INPUT P (P); INPUT N(N); OUTPUT Y (Y); SUPPLY1 VDD (VDD); SUPPLY0 VSS (VSS); COMPLEMENTARY P, N; //GATE SECTION AMP (Y, P, N); END_OF_DESIGN; Differential input (DIN)
VDD P N
P Y N VSS
December 2010
172
Encounter Library Characterizer User Guide Gate File Format The following example describes and illustrates a tristate IO cell to aid cell recognition:
DESIGN (BIO); //PORT SECTION; OUTPUT DIN (DIN); INOUT EXT (EXT, NET634\#10, NET635\#13); INPUT EN_IN (EN_IN); INPUT EN_OUT (EN_OUT); INPUT POR_L (POR_L); INPUT DOUT (DOUT); //GATE SECTION NAND ($1, POR_L, EN_OUT); NOT ($2, $1); BUFIF0 (EXT, DOUT, $1); NOR (NET634\#10, DOUT, $1); NAND (NET635\#13, DOUT, $2); NAND (DIN, EXT, EN_IN); END_OF_DESIGN;
Bidirectional IO
D$1
POR_L EN_OUT DOUT
EXT
DIN
EN_IN
NET635\#13 D$1
EXT
D_OUT
NET634\#10
Making Gate File Corrections

If a circuit description in a gate file is not correct, Encounter library characterizer does not recognize the logic, and simulation vectors are not created. Instead, bidirectional switches are written out in the gate file (see Bidirectional Switches on page 169). You must manually modify the gate file to correct the description. 1. Use the db_gate or db_gsim command to create the gate file:
db_gate -d cell_name -r cell_name.design/boundary/gate
or
db_gsim -g -d cell_name
Note: If you use the db_gsim command, the gate file is written out to the *.ipdb/
Encounter Library Characterizer User Guide Gate File Format *.design/boundary directory. 2. Manually edit the gate file to replace the logic description with the correct information:
vi ipdb_name.ipdb/cell_name.design/boundary/gate
3. Run the db_gsim command to create the simulation vectors.

db_gsim -d cell_name -force
Creating a Gate File to Aid Cell Recognition

The following procedure describes how to use an existing gate file to create a gate file for a cell that is not recognized by ELC: 1. Identify a cell already recognized by ELC, for example TFF_1, which has similar functionality and the same number of inputs/outputs as compared to the cell TFF_2, which is not automatically recognized by ELC. Note: If you have a cell, which is not exactly similar to the already recognized cell (has different number of ports with extra/less logic), modify the gate file to add or remove the required ports/log. Alternatively, you can use the BOOL file approach. See Bool File Format for more information on the BOOL file format. 2. Generate a gate file for the TFF_1 cell using the db_gate or db_gsim command. The following example shows how to generate a gate file for TFF_1:
db_open tff_1 db_prepare -f db_gsim f //vectors are succesfully generated db_gate -r gate.org The generated gate file is as follows: DESIGN ( TFF_1 ); // // // ================= PORT DEFINITION ================= INPUT NCLR ( NCLR ); INPUT T ( T ); OUTPUT NQ ( NQ ); OUTPUT Q ( Q ); SUPPLY0 VSS ( VSS ); SUPPLY1 VDD ( VDD ); //
December 2010
===========

// // INSTANCES =========== NOT ( NET0197, NET86 ); NOT ( NET130, NET78 ); NOT ( NET134, NET74 ); NOT ( NET154, T ); NOT ( NQ, Q ); NOT ( Q, NET86 ); NAND ( NET82, NCLR, NET134 ); NAND ( NET86, NCLR, NET130 ); MUX ( NET74, NET154, NET0197, NET82 ); MUX ( NET78, NET154, NET86, NET82 ); END_OF_DESIGN;
3. Modify the gate file generated using the TFF-1 cell so that the cell name and pin names are exactly the same as in the TFF_2 cell. Consider that the TFF_2 cell has a port list as follows:
subckt TFF_2 ( CLK NCLR OUT_L OUT VDD VSS )
The modified gate file will be as follows:

DESIGN ( TFF_2 ); // // // ================= PORT DEFINITION ================= INPUT NCLR ( NCLR ); INPUT CLK ( CLK ); OUTPUT OUT_L ( OUT_L ); OUTPUT OUT ( OUT ); SUPPLY0 VSS ( VSS ); SUPPLY1 VDD ( VDD ); // // // =========== INSTANCES =========== NOT ( NET0197, NET86 ); NOT ( NET130, NET78 ); NOT ( NET134, NET74 ); NOT ( NET154,CLK ); NOT ( OUT_L, OUT ); NOT ( OUT, NET86 ); NAND ( NET82, NCLR, NET134 );
December 2010
175

NAND ( NET86, NCLR, NET130 ); MUX ( NET74, NET154, NET0197, NET82 ); MUX ( NET78, NET154, NET86, NET82 ); END_OF_DESIGN;
4. If you are using a sequential design, note the register node net names. The register node net names are reported by ELC while generating the gate file. If register pair nodes exist, they are complementary to each other. Note: If the design is not sequential, proceed to the seventh step. The following example shows two pairs of register nodes that were reported during gate file generation of TFF_1. These nodes correspond to internal register pair nodes for the master and slave flop in TFF_1.
============================== DESIGN : TFF_1 ============================== - register(NET134,NET82) is recognized. - register(NET130,NET86) is recognized.
5. Identify the register nodes of the TFF_2 cell in the schematic of the netlist. The following example shows the probable register nodes for the TFF_2 cell:
============================== DESIGN : TFF_2 ============================== - loop node ( Q_L ) is found - loop node ( R_L ) is found - loop node ( Q ) is found - loop node ( S_L ) is found - register(R_L) is recognized. - register(S_L) is recognized. => no simulation
Note: ELC also reports loop nodes, which are also known as probable register nodes. 6. Map these register nodes with the register nodes of TFF_1 and replace them in the gate file, as shown:
DESIGN ( TFF_2 ); // =================
December 2010
176

// // PORT DEFINITION ================= INPUT NCLR ( NCLR ); INPUT CLK ( CLK ); OUTPUT OUT_L ( OUT_L ); OUTPUT OUT ( OUT ); SUPPLY0 VSS ( VSS ); SUPPLY1 VDD ( VDD ); // // // =========== INSTANCES =========== NOT ( NET0197, Q_L ); NOT ( Q, NET78 ); NOT ( R_L, NET74 ); NOT ( NET154,CLK ); NOT ( OUT_L, OUT ); NOT ( OUT, Q_L ); NAND ( S_L, NCLR, R_L ); NAND ( Q_L, NCLR, Q ); MUX ( NET74, NET154, NET0197, S_L ); MUX ( NET78, NET154, Q_L, S_L ); END_OF_DESIGN;
In this example, the register pair nodes, (R_L, S_L) and (Q, Q_L) correspond to (NET134, NET82) and (NET130, NET86) in the TFF_2 cell. Note: Set the EC_GATE_CHECK_UNKNOWN_NODE variable to 1 to skip checking the existence of nodes in the subcircuit file while reading a gate file. The register node names have to be the SPICE node names in the subcircuit file.
set_var EC_GATE_CHECK_UNKNOWN_NODE 0
In case of a netlist with parasitics, specify the node names using the EC_ORIGINAL_NODE_NAME variable. 7. Replace all other TFF_1 cell specific net names used in the gate file with the ELC generated net names (names starting with $). For example, replace NET0197, NET78, NET74 and NET154 with $1, $2, $3 and $4, respectively. Note: Ensure that there are no duplicate net name entries in the gate file.
DESIGN ( TFF_2); // // // ================= PORT DEFINITION =================
December 2010
177

INPUT NCLR ( NCLR ); INPUT CLK ( CLK ); OUTPUT OUT_L ( OUT_L ); OUTPUT OUT ( OUT ); SUPPLY0 VSS ( VSS ); SUPPLY1 VDD ( VDD ); // // // =========== INSTANCES =========== NOT ( $1, Q_L ); NOT ( Q, $2 ); NOT ( R_L, $3 ); NOT ( $4, CLK ); NOT ( OUT_L, OUT ); NOT ( OUT, Q_L ); NAND ( S_L, NCLR, R_L ); NAND ( Q_L, NCLR, Q ); MUX ( $3, $4, $1, S_L ); MUX ( $2, $4, Q_L, S_L ); END_OF_DESIGN;
8. Use the gate file (gate.mod) created for TFF_2 to aid automatic simulation vector generation as follows:
db_open test db_prepare -f cp gate.mod test.ipdb/TFF_2.design/boundary/gate //copy the created gate file (gate.mod) to <ipdb_name>.ipdb/<cell_name>.design/boundary/gate db_gsim f //generate simulation vectors
December 2010
178
D
Bool File Format
This appendix describes the format of a BOOL file. The BOOL file is a Synspec original file that describes macro cell functions including the tri-state, logical, and sequential functions. This appendix presents the following topics:

Syntax on page 180 Boolean Operator on page 181 Pin Attribute on page 181 Functions on page 182

Logical Function on page 182 Tri-state Function on page 183 Sequential Function on page 185
Using a BOOL File to Aid Cell Recognition on page 187
December 2010
179
Encounter Library Characterizer User Guide Bool File Format
Syntax
The syntax of BOOL is as follows:
BOOL ::= { ,
<macro_name>, <function_type> <outpin> = <boolean_expression> }* ; }*
Example 1:
IO_pad,"GENERIC IO", DATA_INP = MUX(EN_INP,#PAD#,DVDD12), (#PAD#,PG,NG) = TBUF(DATA_OUT,EN_OUT);
Example 2:
IOPAD, "IO cell", (#PAD#, I1_INANDOE33, I1_INOROEN33) = TBUF(I, !OEN), C = #PAD# ;
December 2010
180
Boolean Operator
The following operators are available for BOOL:
Operator Symbol ~ and ! & and * | and + ^ / ?
Operator Name invert and or exclusive or complement multiplex function
Syntax Y = ~A Y = A * B * C Y = A + B + C Y = A ^ B ^ C Y/YB = A Y = S?A:B => Y = A, YB = ~A
=> Y = S&A|(~S)&B
Pin Attribute
The following pin attributes are available in BOOL:
Attribute [pin_name] #pin_name# STATE(pin_name1, pin_name2,...pin_namen)
Description pin_name is an internal pin or a virtual pin pin_name is an external inout pin pin_name is a state pin
December 2010
181
Functions
The following functions are available in BOOL:
Function Type Logical Function Tri-state Function Sequential Function
Keywords NOT(), INV(), AND(), NAND(), OR(), NOR(), XOR(), XNOR(), MUX() TBUF(), NOD(), POD() DLSR(), DFSR()
Logical Function
NOT(), INV() inverter

<output> = NOT(<input>) <output> = INV(<input>)
Example: Y = NOT(A) => Y = ~A
AND(), NAND() AND / NAND gate

<output> = AND(<input(1)>, <input(2)>, , <input(n)>) <output> = NAND(<input(1)>, <input(2)>, , <input(n)>)
Example: Y = AND(A, B, C)
=>
Y = A * B * C
OR(), NOR() OR / NOR gate

<output> = OR(<input(1)>, <input(2)>, , <input(n)>) <output> = NOR(<input(1)>, <input(2)>, , <input(n)>)
Example: Y = OR(A, B, C)
=>
Y = A + B + C
XOR(), XNOR() exclusive OR / NOR gate

<output> = OR(<input(1)>, <input(2)>, , <input(n)>) <output> = NOR(<input(1)>, <input(2)>, , <input(n)>)
Example: Y = XOR(A, B, C)
=>
Y=A^B^C
MUX() multiplexer
<output> = MUX(<input(1)>, <input(2)>, <input(3)>)
Example: Y = MUX(S, A, B)
=> Y = S? A: B
December 2010
182
Tri-state Function
TBUF( ) Tri-state buffer

(<output>, <pgate>, <ngate>) = TBUF(<input_logic>, <control_logic>)
Example: (Y, [P], [N]) = TBUF(A, EN), (Y, [P], [N]) = TBUF(A&B, ~EN)
TBUF, Tri-state Buffer (#PAD#,[P],[N]) = TBUF(A,EN)
NOD( ) Nch open drain

(<output>, <ngate>) = NOD(<input_logic>)
Example: (Y, [N]) = NOD(A)
(Y,[N]) = NOD(A)
December 2010
183
POD( ) Pch open drain

(<output>, <pgate>) = POD(i<input_logic>)
Example: (Y, [P]) = POD(~A)
(Y, [P]) = POD(A)
Tri-state Internal Node <pgate> and <ngate> are virtual pins used for off-state time (tpLZ and tpHZ) measurement. These pins cannot be defined to describe the logic of other pins.
December 2010
184
Sequential Function
DLSR( ) Level-Sensitive Latch

(<true_reg>, <comp_reg>) = DLSR(<data>, <clock>, <preset>, <clear>)
Example: (IQ, XIQ) = DLSR(D, C, 0, R)
(X, XQ) = DLSR(D, C, S, R) The function DLSR() is used for the level-sensitive latch. <true_reg> and <comp_reg> on the left side of the equation are resister nodes inside the latch. The output pins should be defined by the other equation. If a latch does not have a set or reset pin, 0 is used in the function.
TLAT,low-level latch,([N4],[N1]) = DLSR(D,!GN,0,0), (Q,QN)=([N4],[N1]);
December 2010
185
DFSR( ) Edge-Triggered Register

(<treg>, <creg>, <tmst_reg>, <cmst_reg>) = DFSR(<data>, <clock>, <preset>, <clear>)
Example: (IQ, XIQ, IP, IPB) = DFSR(D, C, S, R)
(Q ,XQ, [P], XP) = DFSR(D, C, S, R) The function DFSR() is used for the edge-triggered register. <treg>, <creg>, <tmst_reg>, and <cmst_reg> on the left side of the equation are register nodes inside the register. The output pins should be defined by the other equation. <tmst_reg> and <cmst_reg> are virtual internal nodes used for setup, hold, and other timing constraint measurement. If the register does not have a set or reset pin, 0 is used in the function.
December 2010
186
DFF,Flip-Flop with set and reset, ([N7],[N1],[N4],[N6])=DFSR(D,CP,!SD,!CD), (Q, QN) = ([N1],[N7]) ;
Using a BOOL File to Aid Cell Recognition

The following procedure describes how to use a BOOL file: 1. Open a database named test.ipdb:
db_open test.ipdb
2. Load the design and SPICE model data, perform circuit recognition, create the simulation vectors, and load the characterization conditions:
db_prepare -f
3. Specify a bool file (test.bool) for performing circuit recognition. The following command overwrites the existing simulation vectors in the database and generates new simulation vectors:
db_gsim -bool test.bool -force
Note: Circuit recognition using a bool file is complete. 4. Perform circuit simulation:
db_spice
December 2010
187
Encounter Library Characterizer User Guide Bool File Format 5. Include the characterization results in the out.lib file:
6. Exit Encounter library characterizer:

exit
December 2010
188
E
Specification File Format
This appendix describes the format of the specification file, which the db_gsim command generates from information in the database. The file is in ASCII format. Do not edit the specification file. This appendix presents the following topics:

Syntax on page 189 Statements on page 191 Examples on page 201
Syntax
The syntax of the specification file is as follows:
{ DESIGN( <DesignName> ) ; { PORT( <PortName> ) + DIRECTION( { INPUT | OUTPUT | INOUT } ) [ + LOGIC( <OutputLogicBooleanExpression> ) ] [ + TRISTATE( <NgateNodeName>, <PgateNodeName> ) ] [ + COMPLEMENT( <ComplementalPortName> ) ] [ + CLOCK( {R|F|H|L} ) | + FORCE( {H|L} ) | + DATA ] [ + ENABLE( {H|L|X} ) ] [ + ONE_STAGE | + TWO_STAGE ] [ + RISE( <RiseMinValue> [, <RiseMaxValue> ] ) ] [ + FALL( <FallMinValue> [, <FallMaxValue> ] ) ] [ + EFFECTED( <EffectedOutputPortName> ) ] [ + SUPPLY1 | + SUPPLY0 | + FEEDTHRU | + BUS_KEEPER | + NAKED ] + NET_NUMBER( <NetNumber> ) [ + NAME_MAP( number )] ; }* [ NODE( <NodeName> )M + NET_NUMBER( <NetNumber> ) ;
Encounter Library Characterizer User Guide Specification File Format

]* [ REGISTER( <TrueRegName> [ , <ComplementRegName> ] ) +LOGIC( <TrueRegBooleanExpression> [ , <ComplementRegBooleanExpression> ] ) ; ]* [ INHIBIT( <InhibitStateBooleanExpression> ) ; ] [ COMPLEMENTARY( <TruePortName> , <ComplementPortName> ) ; ]* [ BUNDLE( <BundleElement(1)> [ , <BundleElement(n)> ]* ) ; ]* [ ARC( <InputPort>, <OutputPort> ) { + POSITIVE_UNATE | + NEGATIVE_UNATE | + NON_UNATE } [ + RISE_EDGE | + FALL_EDGE ] [ + PRESET | + CLEAR ] [ + TRISTATE_L | + NCH_OPEN_DRAIN_L | + PCH_OPEN_DRAIN_L | + TRISTATE_H | + NCH_OPEN_DRAIN_H | + PCH_OPEN_DRAIN_H ] { + TRAN( <InputEdge> : <OutputEdge> ) [ + MEASURE( <PseudoOutputNode> : <PseudoOutputEdge> ) ] [ + CLAMP( <ClampPort> : <ClampLevel> ) ] }* [ + USE( <VectorName_1> [ , <VectorName_n> ]* ) ] ; ]* [ CHECK( <ConstraintPort> [ : <ConstraintEdge> ] ) [ + RELATED( <RelatedPort> [ : <RelatedEdge> ] ) ] [ + SETUP ] [ + HOLD ] [ + RELAESE ] [ + REMOVABLE ] [ + RECOVER ] [ + WIDTH_H ] [ + WIDTH_L ] [ + WHEN( <ConditionBooleanExpression> ) ] [ + USE( <VectorName_1> [ , <VectorName_n> ]* ) ] ; ]* [ VECTOR( <SimulationVector> ) [ + ID( <VectorName> ) ] [ + DELAY( <ChangePorts> ) | + I_DELAY( <ChangePorts> ) | + NO_DELAY( <ChangePorts> ) | + RACE( <FirstChangeInputPorts> , <NextChangeInputPorts> ) ] [ TARGET( port_names ); ]* END_OF_DESIGN ; }*
December 2010
190
Statements
The specification file includes the following statements. They are listed in alphabetical order.

ARC Statement on page 191 BUNDLE Statement on page 193 CHECK Statement on page 193 COMPLEMENTARY Statement on page 195 DESIGN Statement on page 195 END_OF_DESIGN Statement on page 195 INHIBIT Statement on page 195 NODE Statement on page 196 PORT Statement on page 196 REGISTER Statement on page 199 VECTOR Statement on page 199
ARC Statement
ARC( input_port, output_port ) + POSITIVE_UNATE + NEGATIVE_UNAT + NON_UNATE + RISE_EDGE + FALL_EDGE + PRESET + CLEAR + TRISTATE_L + TRISTATE_H + NCH_OPEN_DRAIN_L + NCH_OPEN_DRAIN_H + PCH_OPEN_DRAIN_L + PCH_OPEN_DRAIN_H

+ TRAN( input_edge : output_edge ) + MEASURE( pseudo_output_node : pseudo_output_edge ) + CLAMP( clamp_port : clamp_level ) + USE( vector_name_1 [ , vector_name_n ]* ) ;
Specifies the propagation delay, or timing arc. Options and Arguments Specifies the name of the input port. Specifies the name of the output port. Indicates that the input and output ports change in the same direction. Indicates that the input and output ports do not change in the same direction. Indicates that the input and output ports can be rising or falling as the inputs rise. Specifies that the inputs change only on the rising edge of the clock. Specifies that the inputs change only on the falling edge of the clock. Specifies that the outputs change only on the rising edge of the clock. Specifies that the outputs change only on the falling edge of the clock. Specifies that the tristate is low-level active. Specifies that the tristate is high-level active. Specifies that the threshold voltage at the NMOS gate is lowlevel active. Specifies that the threshold voltage at the NMOS gate is highlevel active. Specifies that the threshold voltage at the PMOS gate is lowlevel active.
input_port output_port POSITIVE_UNATE NEGATIVE_UNATE NON_UNATE RISE_EDGE FALL_EDGE PRESET CLEAR TRISTATE_L TRISTATE_H NCH_OPEN_DRAIN_L NCH_OPEN_DRAIN_H PCH_OPEN_DRAIN_L
December 2010
PCH_OPEN_DRAIN_H
Specifies that the threshold voltage at the PMOS gate is highlevel active.
TRAN input_edge output_edge Specifies the direction of the signal switching. MEASURE pseudo_output_node pseudo_output_edge Specifies the name of the internal output node used to measure delay when you cannot measure the output node. CLAMP clamp_port clamp_level Specifies the name of the pullup or pulldown and whether it is low or high. USE vector_name Specifies the names of the simulation vectors.
BUNDLE Statement
BUNDLE( bundle_element_1 [ , bundle_element_n ]* ) ;
Identifies the ports and registers composing a bus or equivalent logic. Note: To disable bundling, set the EC_DISABLE_BUNDLING variable to 1. Options and Arguments Specifies the number of the port or register in the bus.
bundle_element
Example
The following statement shows the syntax for a bundle of ports:

BUNDLE(port1, port2, port3, port4, ...)
The following statement shows the syntax for a bundle of registers:

BUNDLE((treg1,creg1),(treg2,creg2),(treg3,creg3),(treg4,creg4), ...)
CHECK Statement
CHECK( constraint_port [ : constraint_edge ] ) + RELATED( related_port [ : related_edge ] )
December 2010
193

+ SETUP + HOLD + RELEASE + REMOVABLE + RECOVER + WIDTH_H + WIDTH_L + WHEN( condition_boolean_expression ) ] + USE( vector_name_1 [ , vector_name_n ]* ) ;
Specifies the input constraints. Options and Arguments Specifies the name of the boundary port to which the constraints are applied. Specifies whether the constraints are applied on the rising or falling edge of the clock.
constraint_port constraint_edge
RELATED related_port related_edge Indicates the name of the port related to the boundary port and whether it changes on the rising or falling edge of the clock. SETUP HOLD RELEASE REMOVABLE RECOVER WIDTH_H WIDTH_L Specifies the setup time. Specifies the hold time. Specifies the release time. Specifies the remove time. Specifies the recover time. Specifies the positive minimum pulse. Specifies the negative minimum pulse.
WHEN condition_boolean_expression Specifies the conditions under which the constraints should be checked. It is a Boolean expression.
December 2010
194
USE vector_name
Specifies the names of the simulation vectors.
COMPLEMENTARY Statement
COMPLEMENTARY( true_port_name , complementary_port_name ) ;
Specifies the ports composing the differential input pair. Options and Arguments Specifies the name of the true port.
true_port_name
complementary_port_name Specifies the name of the complementary port.
DESIGN Statement
DESIGN( design_name );
Indicates the beginning of the design section. Options and Arguments Specifies the name of the design.
design_name
END_OF_DESIGN Statement
END_OF_DESIGN ;
Indicates the end of the design section. All statements for the target design must reside between the DESIGN statement and END_OF_DESIGN statement.
INHIBIT Statement
INHIBIT( inhibit_state_boolean_expression ) ;
Specifies the logic that the input pins should have to avoid an electrical short in the design.
December 2010
195
Encounter Library Characterizer User Guide Specification File Format Options and Arguments
inhibit_state_boolean_expression Specifies the logic that the input pins should have to avoid a short. This is a Boolean expression.
NODE Statement
NODE( node_name ) + NET_NUMBER( net_number ) ;
Specifies the internal nodes required in characterization. These nodes are automatically extracted by the db_gsim command. Options and Arguments Specifies the name of the internal node.
node_name
NET_NUMBER net_number Specifies the number of the net to which the node is connected.
PORT Statement
PORT( port_name ) + DIRECTION( {INPUT|OUTPUT|INOUT} ) + LOGIC( output_logic_boolean_expression ) + TRISTATE( ngate_node_name, pgate_node_name ) + COMPLEMENT( complementary_port_name ) + CLOCK( {R|F|H|L} ) + FORCE( {H|L} ) + DATA + ENABLE( {H|L|X} ) + ONE_STAGE + TWO_STAGE

+ RISE( RiseMinValue [, RiseMaxValue ] ) + FALL( FallMinValue [, FallMaxValue ] ) + EFFECTED( EffectedOutputPortName ) + SUPPLY1 + SUPPLY0 + FEEDTHRU + BUS_KEEPER + NAKED + NET_NUMBER( net_number ) + NAME_MAP ;
Specifies the port information for the ports on the perimeter of the design. Options and Arguments Specifies the name of the port.
port_name
DIRECTION( {INPUT|OUTPUT|INOUT} ) Specifies the direction of the port. LOGIC( output_logic_boolean_expression ) Specifies the logic of the port. It is a Boolean expression. TRISTATE( ngate_node_name, pgate_node_name ) Specifies the internal node names of the NMOS and PMOS gates in a tristate buffer. COMPLEMENT( complementary_port_name ) Specifies the name of the complementary input pin in a differential input pair. CLOCK( {R|F|H|L} ) Specifies the status of the clock pin. R F Specifies the rising edge in an edgetriggered clock pin. Specifies the falling edge in an edgetriggered clock pin.
December 2010
197
H L FORCE( {H|L} )
Specifies a high enable in a level-triggered clock pin. Specifies low enable in a level-triggered clock pin.
Specifies the state of the asynchronous force pin. H L Specifies that the pin is high active. Specifies that the pin is low active.
DATA ENABLE( {H|L|X} )
Specifies that the pin is a data signal. Specifies the state of the tristate enable input pin. H L X Specifies that the tristate pin is a high-enable pin. Specifies that the tristate pin is a low-enable pin. Specifies that the state of the tristate pin is unknown.
ONE_STAGE TWO_STAGE
Specifies that the pin will be used for a single stage in the design. Specifies that the pin will be used for two stages in the design.
RISE( RiseMinValue [, RiseMaxValue] } Specifies the minimum and maximum voltage value for the RISE arc. FALL( FallMinValue [, FallMaxValue ] ) Specifies the minimum and maximum voltage value for the FALL arc. EFFECTED( EffectedOutputPortName ) Specifies the output pins that can be impacted by a change in signal at this pin. SUPPLY1 SUPPLY0 FEEDTHRU BUS_KEEPER Specifies that the voltage supply pin is power (high). Specifies that the voltage supply pin is ground (low). Specifies that the pin is a feedthrough. Specifies that the pin is a bus keeper.
December 2010
198
NAKED
Specifies that the pin is a naked pin, which is a pin whose state is determined by the state of other pins.
NET_NUMBER( net_number ) Specifies the number of the net to which the pin is connected in the Encounter library characterizer database. NAME_MAP Contains the name mapping for the internal node names specified with the internal statement in the Simulation Setup file.
REGISTER Statement
REGISTER( true_reg_name [ , complement_reg_name ] ) + LOGIC( true_reg_boolean_expression [ , complement_reg_boolean_expression ] ) ;
Specifies the internal register in a pair of nodes or a tristate register and its Boolean function. Options and Arguments Specifies the name of the true pin in the register.
true_reg_name
complement_reg_name Specifies the name of the complementary pin in the register. LOGIC true_reg_boolean_expression complement_reg_boolean_expression Specifies the logic of the true pin and the complementary pin. Both are Boolean expressions.
VECTOR Statement
VECTOR( simulation_vector ) + ID( vector_name ) + DELAY( change_ports ) + POWER( change_ports ) + NO_DELAY( change_ports )

+ RACE( first_change_input_ports , + TARGET( port_names ) ;
next_change_input_ports )
Specifies the simulation vectors to use in the SPICE simulation. Options and Arguments Specifies the name of the simulation vector. The simulation vectors are shown in Table E-1. Specifies the name of each vector.
simulation_vector ID( vector_name )
DELAY( change_ports ) Specifies a list of comma-separated port names between which to measure the delay. POWER( change_ports ) Specifies the ports between which to measure internal power. NO_DELAY( change_ports ) Specifies that the list of comma-separated vectors will not be used for delay calculation. RACE( first_change_input_ports, next_change_input_ports ) Specifies the input port that changes first and the input port that changes next under race conditions. TARGET( port_names ) Specifies the comma-separated names of the target ports. Table E-1 Simulation Vectors
Symbol 1 0 R F
Vector Type Input Input Input Input
Function Force high level Force low level Force rising edge Force falling edge
December 2010
200
Symbol J K H L Z U D A M V W -
Vector Type Input Input Output Output Output Output Output Output Output Output Output Output
Function Input search of rising edge Input search of falling edge Expect high level Expect low level Expect high Z Expect rising edge Expect falling edge Expect tpLZ Expect tpZH Expect tpHZ Expect tpZL Dont care
Examples
The following is an example of a specification file generated for an inverter called INVD1:
DESIGN(INVD1) + REFERENCE(N,P); PORT(I) + DIRECTION(INPUT) + NET_NUMBER(0); PORT(ZN) + DIRECTION(OUTPUT) + LOGIC(~I) + RISE(6.533333) + FALL(4.266666) + NET_NUMBER(1); PORT(VDD) + DIRECTION(INPUT) + SUPPLY1 + BULK + NET_NUMBER(2); PORT(VSS) + DIRECTION(INPUT) + SUPPLY0 + BULK + NET_NUMBER(3); ARC(I:ZN) + NEGATIVE_UNATE + ONE_STAGE + TRAN(10:01) + TRAN(01:10) + USE(D0000,D0001); VECTOR(RD10) + ID(D0000) + DELAY(I) + TARGET(ZN); VECTOR(FU10) + ID(D0001) + DELAY(I) + TARGET(ZN); END_OF_DESIGN;
The following is an example of a specification file generated for a D flip/flop called DFD1:
DESIGN(DFD1) + REFERENCE(N,P); PORT(D) + DIRECTION(INPUT) + DATA + NET_NUMBER(0);
December 2010
201

PORT(CP) + DIRECTION(INPUT) + CLOCK(R) + NET_NUMBER(1); PORT(Q) + DIRECTION(OUTPUT) + LOGIC(P0002) + RISE(6.533333) + FALL(4.266666) + NET_NUMBER(2); PORT(QN) + DIRECTION(OUTPUT) + LOGIC(~P0002) + RISE(6.533333) + FALL(4.266666) + NET_NUMBER(3); PORT(VDD) + DIRECTION(INPUT) + SUPPLY1 + BULK + NET_NUMBER(4); PORT(VSS) + DIRECTION(INPUT) + SUPPLY0 + BULK + NET_NUMBER(5); NODE(P0000) + DIRECTION(OUTPUT) + SOURCE(VDD) + NET_NUMBER(9) + NAME_MAP(7); NODE(P0001) + DIRECTION(OUTPUT) + SOURCE(VDD) + NET_NUMBER(11) + NAME_MAP(8); NODE(P0002) + DIRECTION(OUTPUT) + SOURCE(VDD) + NET_NUMBER(13) + NAME_MAP(10); NODE(P0003) + DIRECTION(OUTPUT) + SOURCE(VDD) + NET_NUMBER(14) + NAME_MAP(11); REGISTER(P0001,P0000) + LOGIC(~P0000,~(CP?P0001:D)); REGISTER(P0003,P0002) + LOGIC(~(CP?P0001:P0002),~P0003); ARC(CP:Q) + NON_UNATE + RISE_EDGE + TRAN(01:01) + TRAN(01:10) + USE(D0004,D0005); ARC(CP:QN) + NON_UNATE + RISE_EDGE + TRAN(01:01) + TRAN(01:10) + USE(D0004,D0005); CHECK(D) + RELATED(CP:01) + SETUP + HOLD + USE(R0000,R0001,R0002,R0003); CHECK(CP) + WIDTH_H + WIDTH_L + USE(D0004,D0005,D0007,D0008); VECTOR(R0HL10DUHL) + ID(D0000) + POWER(D); VECTOR(R1LH10HLLH) + ID(D0001) + POWER(D); VECTOR(F0HL10UDHL) + ID(D0002) + POWER(D); VECTOR(F1LH10HLLH) + ID(D0003) + POWER(D); VECTOR(0RDU10HLDU) + ID(D0004) + DELAY(CP) + TARGET(Q,QN); VECTOR(1RUD10LHUD) + ID(D0005) + DELAY(CP) + TARGET(Q,QN); VECTOR(0RLH10HLLH) + ID(D0006) + POWER(CP); VECTOR(0FHL10UDHL) + ID(D0007) + POWER(CP); VECTOR(1FLH10DULH) + ID(D0008) + POWER(CP); VECTOR(0FLH10HLLH) + ID(D0009) + POWER(CP); VECTOR(JRud10duud) + ID(R0000) + RACE(D,CP) + SETUP + TARGET(Q,QN); VECTOR(JRdu10hldu) + ID(R0001) + RACE(CP,D) + HOLD + TARGET(Q,QN); VECTOR(KRud10lhud) + ID(R0002) + RACE(CP,D) + HOLD + TARGET(Q,QN); VECTOR(KRdu10uddu) + ID(R0003) + RACE(D,CP) + SETUP + TARGET(Q,QN); END_OF_DESIGN;
December 2010
202
Index
Numerics
0 logic state 15 1 logic state 15
D
database accessing 51 closing 51 opening 51 db_close command 51 db_open command 51 Define section 118 DESIGN statement 195 distributed processing 31
A
absolute margin factor 123 ALF file formats to convert to 14
B
batch mode 46 bidirectional cells 15, 16 binary search 21, 120 BUNDLE statement 193
E
ECSM description of 30 END_OF_DESIGN statement environment variables 52 exclusive logic 20 195
C
cell library characterization bidirectional cells 15, 16 binary search 21 combinatorial logic cells 14, 15 interface (pad) circuits 19 measurement levels 27 methodology used 14 output driving models 30 pass transistor logic cells 20 pin-to-pin delay 14, 27, 28 sequential logic cells 14, 15, 17, 29 state-dependent models 20 tristate logic cells 16 CHECK statement 194 combinatorial logic cells 14, 15 command file 46, 51 command log file 45 command-line help and man pages 48 COMPLEMENTARY statement 195 complex gates 20 Control section 133 CPPL cell 20 CVSL cell 20
December 2010 203
G
GROUP statement 118 Gtcorner parameter 127
H
help, command-line 48 high-impedance states 15, 16 high-to-Z propagation delays 16 hold time binary searches 133 characterization for sequential logic characterizing 125 HTML 14
17
I
INDEX statement 120 INHIBIT statement 195 interactive mode 45 interface (pad) circuits 19
interface circuitry 15 ipsc command 37 ipsmon> command 39 ipsstat command 39
K
K-factor model 30
power consumption 28 process corners in simulation setup file 127 specified by cell library characterization 14 PROCESS statement 127 pulldowns 19, 133 pullups 19, 133
L
level shifters 19 Library Compiler converting ALF file 14 log file 45, 46 low-to-Z propagation delay 16
R
race conditions 18 recovery time characterization for sequential logic REGISTER statement 199 relative margin factor 123 release time characterization for sequential logic removal time characterization for sequential logic 17
17 17
M
man pages, command-line 48 margin factors 123 MARGIN statement 123 measurement levels 27 minimum pulse width 17, 29 multi-bit logic 15
S
Schmitt triggers 19 sense amplifiers 19 sequential logic cells 14, 15, 17, 29 SET_CELL statement 134 SET_DEFINES statement 135 SET_GROUP statement 136 SET_PIN statement 137 SET_PROCESS statement 138 setup time binary searches 133 characterization for sequential logic short-circuit power 28 SIGNAL statement 130 simulation monitoring 39 running SPICE 19 vectors 200 simulation setup file case sensitivity 118 Control section 133 Define section 118 example for I/O cell library characterization 149 example for standard cell library characterization 142 general syntax 138
204
N
network resource control daemon 39 NODE statement 196 nominal factors 124 NOMINAL statement 124 non-linear table model 30
17
O
output driving models 30
P
parallel processing 31 pass transistor logic cells 20 path logic cells 15 pin-to-pin delay 14, 27, 28 PORT statement 197
December 2010
purpose 117 wildcards 118 SIMULATION statement 132 slc.log file 45, 46 .slcrc file 52 slew rate in simulation setup file 120 input 28 output 28 specification file format 189 statements in 191 SPICE format 14 SPICE simulation 19 state dependency 20 static leakage power 28 switching power 28
T
timing constraints 14 tristate logic cells 14, 15, 16 typical delay 124
V
VECTOR statement 200 Verilog converting ALF file to 14 VHDL converting ALF file to 14
W
wildcards 118
December 2010
205
December 2010
206

Elc UG

Caricato da

Informazioni sul documento

Descrizione originale:

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Elc UG

Caricato da

Copyright:

Formati disponibili

Encounter Library Characterizer User Guide

Product Version 10.1 December 2010

Encounter Library Characterizer User Guide

1 Basics of Cell Library Characterization . . . . . . . . . . . . . . . . . . . . . . . .

Product Version 10.1

Encounter Library Characterizer User Guide

3 Preparing for Library Characterization . . . . . . . . . . . . . . . . . . . . . . . . .

4 Performing Cell Library Characterization . . . . . . . . . . . . . . . . . . . . . .

Product Version 10.1

Encounter Library Characterizer User Guide

5 Performing Cell Library Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6 Troubleshooting Library Characterization Issues . . . . . . . . . . . .

109 110 111 112 114

Product Version 10.1

Encounter Library Characterizer User Guide

A Simulation Setup File Format

B Property File Format

Property File Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

C Gate File Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Gate File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

Product Version 10.1

Encounter Library Characterizer User Guide

165 171 173 174 178

D Bool File Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

179 180 181 181 182 182 183 185 187

E Specification File Format

Product Version 10.1

Encounter Library Characterizer User Guide

Product Version 10.1

Encounter Library Characterizer User Guide

About This Manual

How This Manual Is Organized

Product Version 10.1

Encounter Library Characterizer User Guide About This Manual

Conventions Used in This Manual

Product Version 10.1

Encounter Library Characterizer User Guide About This Manual

Product Version 10.1

Product Version 10.1

Encounter Library Characterizer User Guide

Product Version 10.1

Encounter Library Characterizer User Guide Basics of Cell Library Characterization

What Is Cell Library Characterization?

Automatic Cell Library Characterization

Product Version 10.1

Encounter Library Characterizer User Guide Basics of Cell Library Characterization

Multiple Cell Types

Combinatorial Logic Cells

4-input NAND 2-input NOR

Tristate Logic Cells

Product Version 10.1

Product Version 10.1

Sequential Logic Cells

Product Version 10.1

DS flip-flop with XS, XR

Product Version 10.1

Encounter Library Characterizer User Guide Basics of Cell Library Characterization

Multi-Bit Logic Cells

Interface (Pad) Circuits

Product Version 10.1

Pass Transistor Logic Cells

Product Version 10.1