Encounter Library Characterizer User Guide: Product Version 12.0 December 2012

Encounter Library Characterizer User
Guide
Product Version 12.0
December 2012
20112012 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.
Encounter Library Characterizer User Guide
Contents
About This Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
How This Manual Is Organized . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Conventions Used in This Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Related Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1
Basics of Cell Library Characterization . . . . . . . . . . . . . . . . . . . . . . . .
13
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
14
15
15
15
16
17
19
19
20
20
21
26
27
28
29
30
30
30
30
30
31
December 2012
2
Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
34
35
36
36
41
43
45
46
46
48
48
3
Preparing for Library Characterization . . . . . . . . . . . . . . . . . . . . . . . . .
49
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
51
51
51
53
54
57
58
59
59
4
Performing Cell Library Characterization . . . . . . . . . . . . . . . . . . . . . .
61
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Performing Library Characterization for Standard Cells . . . . . . . . . . . . . . . . . . . . . . . . .
Performing Library Characterization using a Pre-driver Cell . . . . . . . . . . . . . . . . . . . . . .
Performing ECSM-Based Power Characterization for Level-Shifter Cells . . . . . . . . . . . .
62
63
65
67
December 2012
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 . . . . . . . . . . . . . . . . . . . . . .
Performing Library Characterization of Standard Cells Using Multiple PVT and Multiple
Corners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
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 . . . . . . . . . . . . . . . . . .
Performing AOCV Table Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
71
73
75
77
80
81
83
85
87
91
93
94
94
95
96
97
99
5
Performing Cell Library Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
101
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ecsmChecker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
libdiff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
LibVsSpice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
EtsvsSpice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
102
103
104
109
110
6
Troubleshooting Library Characterization Issues . . . . . . . . . . . .
113
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Characterizing Failed Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Handling Failures During Various db_spice Stages . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Adjusting Transient Time to Prevent Simulation Failure . . . . . . . . . . . . . . . . . . . . . . . . .
114
115
116
118
December 2012
A
Simulation Setup File Format
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Case-Sensitivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Wildcards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Define Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
GROUP Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
AOCV 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
122
122
122
122
123
125
128
130
132
135
136
138
139
139
140
142
143
144
144
148
148
153
155
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Property File Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
C
Gate File Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Gate File
169
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
December 2012
Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Gates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Making Gate File Corrections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating a Gate File to Aid Cell Recognition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.................................................................
171
171
177
179
180
184
D
Bool File Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
185
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Boolean Operator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Pin Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Logical Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tri-state Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sequential Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using a BOOL File to Aid Cell Recognition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
186
187
187
188
188
189
191
193
E
Specification File Format
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
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 2012
195
197
197
199
199
201
201
201
201
202
202
205
205
207
December 2012
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 5, Performing Cell Library Validation,

Describes how to perform validation of a cell library.
Chapter 6, Troubleshooting Library Characterization Issues,
December 2012

About This Manual
Describes the steps to troubleshoot various library characterization issues.
Conventions Used in This Manual

This section describes the typographic and syntax conventions used in this manual.
text
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]
December 2012
10

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 2012
11

About This Manual
For a complete list of documents provided with this release, see the Cadence Help System
library.
10/26/12
December 2012
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 2012
13

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 2012
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 2012
15

Figure 1-2 Tristate Logic Cells
Tristate buffer
Nch open drain
To measure tpLZ
Pch open drain

To measure tpHZ
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 2012
16

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 2012
17

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 2012
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 2012
19

Figure 1-7 Interface Cells
Sense amplifiers
Level shifters
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 2012
20

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 2012
21

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 2012
22

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 2012
23

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 2012
24

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).
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 2012
25

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 2012
26

Table 1-1 on page 27 shows the measurement levels used by Encounter library characterizer.
Table 1-1 Characterization Measurement Levels
Level
Symbol
Default*
Impact on
Input signal threshold voltage
Vthi
50%
Delay
Output signal threshold voltage
Vtho
50%
Delay
Input signal high voltage
Vih
100%
Slew
Input signal low voltage
Vil
0%
Slew
Output signal high voltage
Voh
100%
Slew
Output signal low voltage
Vol
0%
Slew
Input signal high slew voltage
Vish
90%
Slew
Input signal low slew voltage
Visl
10%
Slew
Output signal high slew voltage
Vosh
90%
Slew
Output signal low slew voltage
Vosl
10%
Slew
* Percentage of VDD
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 2012
27

Figure 1-18 Pin-to-Pin Delay
Vthi
INPUT
Vtho
OUTPUT
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 2012
28

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 2012
29

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 2012
30

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 2012
31

December 2012
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 2012
33

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 2012
34

Getting Started
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
Features
ETS L or ELC XL
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 2012
35

Getting Started
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 2012
36

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 2012
37

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 2012
38

Getting Started
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
December 2012
39

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
worst
D0001
dstorm17
16393
BUFX20
worst
D0000
dstorm18
16399
----------+----------+--------+---------+-------+---------BUFX20
worst
D0001
dstorm17
16393
BUFX20
worst
D0000
dstorm18
16399
----------+----------+--------+---------+-------+---------INVXL
worst
D0000
dstorm17
16402
BUFX20
worst
D0000
dstorm18
16399
----------+----------+--------+---------+-------+---------INVXL
worst
D0000
dstorm17
16402
INVXL
worst
D0001
dstorm18
16450
----------+----------+--------+---------+-------+---------INVXL
worst
D0001
dstorm18
16450
----------+----------+--------+---------+-------+----------
December 2012
40

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 a single job.

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:
set_var EC_SIM_USE_LSF 1
December 2012
41

Getting Started
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 2012
42

Getting Started
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 2012
43

Getting Started
Parameters
-al
Appends the log information to an existing log file.
-C 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:
-Q
December 2012
ELC GXL
ELC XL
ETS XL
ETS L
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.
44

Getting Started
-r rechar_file

recharacterization command file.
-S cmd_file

command file to use. This command file contains the
commands that are supported in the native mode.
-slc cmd_file
Enables the SignalStorm library characterizer plug-in mode

and specifies the name of the SignalStorm library
characterizer command file to load.
-version
Prints the Encounter library characterizer version name.
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 2012
45

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 2012
46

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
All applications are run as 64-bit.
NONE
All applications are run as 32-bit.
list
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 2012
47

Getting Started
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 2012
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 2012
49

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
ECSM Noise
Voltage in Voltage out (ViVo) waveform on an input or output pin of a cell
Statistical ECSM
Current waveform at power-grid pins for different combinations of slew and load
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 2012
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 2012
51

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 2012
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 2012
53

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
Description
SUBCKT
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
using the db_prepare -create_setup command.
December 2012
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.
NON_RECHAR_DESIGNS
Specifies the name of the cells to work on. If this directive is

used, the software extracts the function of the specified cells
from the subcircuit file instead of the input .lib.
SETUP
Specifies the simulation setup file.

Important
using the recharacterization or incremental flow.
AOCV_SETUP
Specifies the AOCV simulation setup file.

This is an optional directive that can be specified if you do not
want to modify the original setup file.
PROCESS
Specifies the process corner of the setup file.

Important
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.
December 2012
55

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.
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.
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.
December 2012
56

SUBCKT="subckt_file";
MODEL="model_file";
DESIGNS="INVD1 DFFD1";
SETUP="setup_file";
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}
December 2012
57

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)
# 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
December 2012
58

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.
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 2012
59

December 2012
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
Performing Library Characterization of Standard Cells Using Multiple PVT and Multiple
Corners on page 91
Creating a Binary Dotlib on page 93
Performing Additional Library Characterization Tasks on page 94
December 2012
61

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 2012
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 2012
63

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_SPICE_SIMPLIFY=1;
EC_CHAR=ECSM-TIMING ECSM-POWER;
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 2012
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;
// DRIVER CELL NAME
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 2012
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.
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 2012
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:
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.
following commands:
a. Open a database named basic_char:
db_open basic_char
db_prepare



db_close

exit
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 2012
67

(VSS) respectively.
EC_SIM_USE_LSF=1;
EC_SIM_LSF_CMD=" ";
EC_CHAR=ECSM-POWER;
EC_SIM_SUPPLY1_NAMES=VDD VDDIO;
EC_SIM_SUPPLY0_NAMES=VSS;
SUBCKT="subckt";
MODEL="model";
DESIGNS="LVLLHD1";
SETUP="setup";
PROCESS=typical;

December 2012
68

Performing CCS-Based Noise Characterization for

Standard Cells
The following procedure describes how to perform CCS-based noise characterization for
standard cells.
Tip
following commands:
a. Open a database named ccs_noise_char:
db_open ccs_noise_char
db_prepare -f


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

db_close

exit
variables:
Note: The EC_CHAR environment variable uses the CCS-NOISE value, which indicates
that CCS-based noise characterization will be performed.
EC_SIM_USE_LSF=1;
December 2012
69

EC_SIM_LSF_CMD=" ";
EC_CHAR=CCS-NOISE;
SUBCKT="subckt";
MODEL="model";
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 2012
70

Performing CCS-Based Power Characterization for

Standard Cells
The following procedure describes how to perform CCS-based power characterization for
standard cells.
Tip
following commands:
a. Open a database named ccs_power_char:
db_open ccs_power_char
db_prepare -f


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

db_close

exit
variables:
Note: The EC_CHAR environment variable uses the CCS-POWER value, which indicates
that CCS-based power characterization will be performed.
EC_SIM_USE_LSF=1;
December 2012
71

EC_SIM_LSF_CMD=" ";
EC_CHAR=CCS-POWER;
SUBCKT="subckt";
MODEL="model";
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 2012
72

Performing SOI Characterization for Standard Cells

The following procedure describes how to perform SOI characterization for standard cells.
Tip
following commands:
a. Open a database named soi_char:
db_open soi_char
db_prepare -f


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

db_close

exit
variables:
Note: The EC_SOI_CHAR environment variable should be set to 1, which indicates that
SOI characterization will be performed.
EC_SIM_USE_LSF=1;
EC_SIM_LSF_CMD=" ";
December 2012
73

EC_CHAR=ECSM-POWER;
EC_SOI_CHAR=1;
SUBCKT="subckt";
MODEL="model";
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 2012
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.
Tip
following commands:
a. Open a database named aae:
db_open aae
db_prepare -f

db_spice

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

db_close

exit
variables:
Note: The EC_CHAR environment variable uses the AAE value, which indicates that
December 2012
75

AAE-based timing characterization will be performed.
EC_SIM_USE_LSF=1;
EC_SIM_LSF_CMD=" ";
EC_CHAR=AAE;
SUBCKT="subckt";
MODEL="model";
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 2012
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:
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
AUTO_BSLEW_POINTS = 3 #the number of points for Bslew
Rslew =
7e-12 2e-09 ; #slew range
Fslew =
7e-12 2e-09 ;
Bslew = 7e-12 4e-010 ;

};
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 =
1e-15 5.2891e-12;
};
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;
December 2012
77

};
Tip
following commands:
a. Open a database named index_cell:
db_open index_cell
db_prepare -f

db_spice

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

db_close

exit
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.
EC_SIM_USE_LSF=1;
EC_SIM_LSF_CMD=" ";
EC_GEN_AUTO_SETUP=auto.st;
December 2012
78


SUBCKT="subckt";
MODEL="model";
SETUP="setup";
PROCESS=typical;

December 2012
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
Note: When you create a setup file from an existing .lib, the temperature and voltage values
in the .lib are used for setup file creation. 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 2012
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.
following commands:
a. Open a database named incr_char:
db_open incr_char
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
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.
EC_SPICE_SUPPLY1_NAMES=VDD;
December 2012
81

EC_SPICE_SUPPLY0_NAMES=VSS;
EC_INCREMENT_CHAR=ECSM-POWER;
SUBCKT="subckt";
MODEL="model";
DESIGNS="CMPE22D1 DFD1";
XDESIGNS=INVD1;
SYNLIB=incr.lib;

elc -L incremental.log -C incremental_cmd.log -S cmd_file
December 2012
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.
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
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.
EC_SPICE_SUPPLY1_NAMES=VDD;
EC_SPICE_SUPPLY0_NAMES=VSS;
EC_INCREMENT_CHAR=NATIVE-ECSM-POWER;
December 2012
83

SUBCKT="subckt";
MODEL="model";
XDESIGNS=INVD1;
SYNLIB=incr.lib;

December 2012
84

Performing Statistical Characterization

The following steps describe how to perform statistical timing and leakage characterization:
3. Create the statistical configuration file, statistical_config, as shown:
version = 1.1
# Global parameter variation specification
# Random parameter variation specification
parameter=parl1 values_random = 1
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 2012
85

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.
EC_SIM_USE_LSF=1;
EC_SIM_LSF_CMD="";
EC_CHAR=S-ECSM S-LEAKAGE;
SUBCKT="SUBCKT";
MODEL="MODEL";
SETUP="SETUP";
PROCESS=typical;
LIB=library_file;
CORNER=ss;
XDESIGNS=INVD1;
STAT_CONFIG=statistical_config;

December 2012
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.
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.
db_open rechar
db_prepare
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.
variables and ensure that the following settings are done for the recharacterization flow:
December 2012
87

EC_SIM_USE_LSF=1;
EC_SIM_LSF_CMD="";
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 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;
Note: When you create a setup file from an existing .lib, the temperature and voltage
values in the .lib are used for setup file creation. 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. However, these variables do not impact the temperature and voltage values of
a user-specified setup file.
PROCESS="rechar_process"
SUBCKT="SUBCKT";
MODEL="MODEL";
LIB=spice_library_file;
December 2012
88

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.
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 NON_RECHAR_DESIGNS directive in the elccfg configuration file to

specify a list of cells whose function should be extracted from the subcircuit file
instead of an existing input .lib.
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 2012
89

December 2012
90

Performing Library Characterization of Standard Cells

Using Multiple PVT and Multiple Corners
Encounter library characterizer allows you to perform library characterization using multiple
corners and different process, voltage, and temperature (PVT) simultaneously. You can run
parallel simulation jobs to create simulation vectors for each corner at the same time.
2. Create a simulation setup file with multiple processes. In the following example, the
PROCESS statement defines three process corners in the setup file elc_multi.st:
Process ff_10v_25c {
voltage = 1.0 ;
temp = -40 ;
model = model_ff.sp
} ;
Process ss_08v_0c {
voltage = 0.8 ;
temp = 0 ;
model = model_ss.sp
} ;
Process tt_10v_25c {
voltage = 0.72 ;
temp = 125 ;
model = model_tt.sp
} ;
The model parameter is optional. However, if you need to modify it, you need to specify
it in the setup file. When a process is used for simulation, the corresponding model file is
used by ELC for simulation.
variables. Specify the PROCESS directive in the configuration file if ELC should run for all
the processes specified with the directive. Alternatively, if you need to run all the
processes specified in the setup file elc_multi.st, you should not specify the
PROCESS directive in the configuration file.
Ensure that the following settings are done for the library characterization flow:
EC_SIM_USE_LSF=1;
EC_SIM_LSF_CMD="";
December 2012
91

EC_CHAR=ECSM-TIMING;
EC_SPICE_SIMPLIFY="true";
EC_SPICE_SUPPY0_NAMES=gnd;
EC_SPICE_SUPPLY1_NAMES=vdd vss;
SUBCKT="SUBCKT";
MODEL="MODEL";
#The simulation setup file elc_multi.st has the PROCESS statement defining each
process corner
SETUP="elc_multi.st";
a. Open a database named multi_corner_PVT:
db_open multi_corner_PVT
db_prepare -force

db_spice -keep_work -keep_log
db_spice runs simulations for all processes simultaneously.

d. Include the characterization results in the .lib file. For each process, you need to
specify the db_output command separately to create the corresponding .lib file:
db_output -lib fast.lib -process ff_10v_25c
db_output -lib slow.lib -process ss_10v_0c
db_output -lib typical.lib -process tt_10v_25c

db_close

exit

December 2012
92

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 2012
93

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 AOCV Table Generation
Performing Library Characterization Using Gate File

The following steps describe how to perform library characterization using a gate file:
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
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 2012
94

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
variables:
EC_SIM_USE_LSF=1;
EC_SIM_LSF_CMD="";
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.
December 2012
95

The following example shows an elccfg file that performs ECSM-power characterization for
the cellP5 hierarchical cell:
EC_SIM_USE_LSF=1;
EC_SIM_LSF_CMD="";
EC_CHAR=ECSM-POWER;
SUBCKT="subckt.cdl";
MODEL="model_file";
SETUP="setup_file";
EXPAND=cellP5;
DESIGNS=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:
set_var EC_INPUT_NONLINEAR 1
December 2012
96

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.
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
December 2012
sampledata
97

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 2012
98

Performing AOCV Table Generation

The following steps describe how to generate an AOCV table in the library characterization
flow:
1. Ensure that the required SPICE inputs, along with the Monte Carlo simulation parameter,
are available in the current working directory.
2. Ensure that the simulation setup file is available in the current working directory. You can
include an AOCV specific setup file by specifying the setup directive AOCV_SETUP.The
AOCV specific setup file is useful if you do not want to modify the original setup file.
Note: To reduce ELC runtime, you can create an AOCV group using the aocv_group
statement. In the statement, you need to specify a group of cells and a representative
AOCV cell. The representative AOCV cell will be simulated and the derate values will be
used for the whole group. If you do not create an AOCV group, then all cells will be
simulated.
In the following example, the aocv_group statement defines the parameters applied to
cells with the pattern INV*:
aocv_group INV {
CELL = INV*;
AOCV_CELL = INVD0BWP;
STAGES = 1 5 8 10 20;
SIMULATION_THRESHOLD = 5;
DEF_SLEW = 0.5n;
DEF_LOAD = 1.0p;
};
You can specify the AOCV group statement in the original setup file or in the AOCV
specific setup file.
following commands:
a. Open a database named aocv_table:
db_open aocv_table
db_prepare

db_spice -p elc_process -keep_log
d. Include the AOCV table in the aocv_table.aocv file:

December 2012
99

db_output -p elc_process -aocv aocv_table.aocv

db_close

exit
variables:
EC_SPICE_SIMPLIFY="1";
EC_SIM_TYPE="SPECTRE";
EC_SIM_LSF_TIMEOUT="-1";
EC_AOCV_FLOW="1";
EC_AOCV_SAMPLES="500";
EC_AOCV_STAGES="1 2 3 5 8 10 20 50"
SUBCKT="subckt";
MODEL="model";
#Model should include the monte carlo simulatio variation parameter
XDESIGNS=INVD1;

December 2012
100
5
Performing Cell Library Validation
Overview on page 102
ecsmChecker on page 103
libdiff on page 104
LibVsSpice on page 109
EtsvsSpice on page 110
December 2012
101

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 2012
102

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 information on parameters of the ecsmChecker command, see the
Executables chapter of the Encounter Library Characterizer Text Command
Reference.
December 2012
103

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 information on parameters of 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 2012
104

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.
December 2012
105

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
* Copyright (c) Cadence Design Systems, Inc. 1996 - 2008. *

* All rights reserved.
***********************************************************
Libraries "test" and "test" were diffed, with "test" taken as the reference
1 cells changed
Timing deviation
Min:-0.01%
Max:-3.86%
Avg:-0.94%
Power deviation
Min:0.00%
Max:-7.22%
Avg:-0.34%
0 cells added
0 cells deleted
+--------------------+--------------------------------+-------------------------+
|
|
|
Cell
Timing Deviation
Power Deviation
+--------------------------------+----------------------------+
|
Min
Max
Avg
Min
Max
Avg
+--------------------+--------------------------------+-------------------------+
|HD_NAND2X1
-0.01
-3.86 |
-0.94
0.00
-7.22
-0.34
+--------------------+--------------------------------+-------------------------+
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:
December 2012
106

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) {
|library (test) {
| date : "today" ;
date : "today" ;
| revision : "4.4" ;
revision : "4.4" ;
| bus_naming_style : "%s[%d]" ;
bus_naming_style : "%s[%d]" ;
|capacitive_load_unit : (1.000000,pf) ; |
capacitive_load_unit : (1.000000,pf) ;
|comment : "Cadence TLF Version 4.4" ; |
comment : "Cadence TLF Version 4.4" ;
|current_unit : "1mA" ;
current_unit : "1mA" ;
...
...
| cell(HD_NAND2X1) {
C|
cell_leakage_power : 3.712790 ;
3.682860 ;
|
value :4.229660
|
|
value :4.263510
value :3.941390
when : "((i0) & (i1))";
C|
|
leakage_power () {
when : "((!(i0)) & (i1))";
leakage_power () {
leakage_power () {
value :4.578230
when : "((!(i0)) & (i1))";
C|
cell_leakage_power :
when : "((i0) & (!(i1)))";
leakage_power () {
when : "((i0) & (!(i1)))";
C|
|
leakage_power () {
cell(HD_NAND2X1) {
leakage_power () {
when : "((i0) & (i1))";
value :2.684030
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 2012
107

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 2012
108

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";
DESIGN="INVX1 INVX2"; #Cells for which correlation has to be done
SIMULATOR="spectre";
#Specify the appropriate environment variable settings.

EC_STATE_GEN=1; #Specify this variable to generate state dependency arcs with
regular (default) arcs.
EC_STATE_SEQ_FLAG="1"; #Specify this variable to generate state dependency arcs
with regular (default) arcs during correlation of delay and output slew data
of sequential cells.
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.
December 2012
109

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 configuration_file
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 2012
110

December 2012
111

December 2012
112
6
Troubleshooting Library Characterization
Issues
Overview on page 114
Characterizing Failed Cells on page 115
Handling Failures During Various db_spice Stages on page 116
Adjusting Transient Time to Prevent Simulation Failure on page 118
December 2012
113

Troubleshooting Library Characterization Issues
Overview
This chapter describes troubleshooting techniques that you can use if you encounter
problems while performing library characterization tasks.
December 2012
114

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 2012
115

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
Likely Cause(s) for Failure
INITIAL
GENERATE
SIMULATE
Delete the lock file
Use the db_clean lock -all

command to release the locks
A parallel simulation was

running
Simulator path not found
Ensure that the SPICE simulator

is in the search path
SPICE model/library file is

missing
Ensure that the model/library file

is available and is not corrupted
Pre-driver cell simulation

might have failed
Check that the SPICE simulation

was run successfully on the
driver cell in the pre-driver flow
SPICE simulation log

(*.lis) does not exist
even after performing
SPICE simulation
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
SPICE simulation log has

ERROR messages
core file found in SPICE

working directory
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 2012
Simulation lock (sim_lock)

file was found
TRANSLATE
Troubleshooting Tip(s)
116

db_spice Stage
Likely Cause(s) for Failure
VERIFICATE
Incomplete supply settings
Cell not recognized

correctly
December 2012
117
Troubleshooting Tip(s)
Ensure that the supply settings
are correct

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 2012
118

December 2012
119

December 2012
120
A
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 144.
This appendix presents the following topics:
Case-Sensitivity on page 122
Wildcards on page 122
Define Section on page 122
Control Section on page 139
General Syntax on page 144
Examples on page 148
December 2012
121

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 2012
122

Table A-1 GROUP Statement Syntax
Descriptor
Keyword
Type
Default
Pin
Pin
string_list
None
Cell
Cell
string_list
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
GRP_CELL_CLKBUF_I
{ PIN
= CLKBUF*.A ; };
Group
GRP_CELL_CLKBUF_O
{ PIN
= CLKBUF*.Y ; };
Group
GRP_PIN_CLK
{ PIN
= *.CK ; };
Group
GRP_CELL_XL
{ CELL = *XL
; };
Group
GRP_CELL_X1
{ CELL = *X1
; };
Group
GRP_CELL_X2
{ CELL = *X2
; };
AOCV GROUP Statement

AOCV ::=
aocv_group group_name {
Cell = CellGroup ;
AOCV_Cell = CellName ;
STAGES = value1 value2;
SIMULATION_THRESHOLD = value;
DEF_SLEW = value;
DEF_LOAD = value;
} ;
Specifies groups of cells for the AOCV flow.
December 2012
123

Table A-2 AOCV GROUP Statement Syntax
Descriptor
Keyword
Type
Default
Cell Group
CELL
string_list
None
Representative
AOCV Cell
AOCV_CELL
string_list
None
Number of depths of
the cell chain
STAGES
list_of_values
Value of the variable

EC_AOCV_STAGES
Monte Carlo
simulation threshold
SIMULATION_THRES value
HOLD
Value of the variable

EC_AOCV_THRESHOL
D
Default slew for the

group
DEF_SLEW
value
last Index slew

specified in the setup
file for the
representative AOCV
cell
Default load for the

group
DEF_LOAD
value
first Index load

specified in the setup
file for the
representative AOCV
cell
The CELL statement supports wildcards in the string_list. You can specify the AOCV
group statement in the original setup file or in the extra AOCV setup file.
Example
The following aocv_group statement defines the AOCV group of cells with the cell pattern
INV* and the representative AOCV cell INVD0BWP. All the parameters are applied to the
cells with the specified pattern. This representative aocv cell will be simulated and the derate
values will be used for the whole group.
aocv_group INV {
CELL = INV*;
AOCV_CELL = INVD0BWP;
STAGES = 1 5 8 10 20;
SIMULATION_THRESHOLD = 5;
DEF_SLEW = 0.5n;
December 2012
124

DEF_LOAD = 1.0p;
};
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 ; ]
[BRslew_pwl = list_of_pwl_names ; ]
[BFslew_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; ]
[AUTO_BSLEW_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.
BRslew_pwl and BFslew_pwl define the PWL names for rising and falling binary slew,
respectively.
December 2012
125

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.
AUTO_BSLEW_POINTS specifies the number of points for Bslew.
Table A-3 INDEX Statement Syntax
Descriptor
Keyword
Type
Default
Input slew rates
Slew
list_of_values
None
Rising input slew

rates
Rslew
list_of_values
SLEW
Falling input slew

rates
Fslew
list_of_values
SLEW
Binary search slew
Bslew
list_of_values
SLEW
Output load
capacitance
Load
list_of_values
None
Rising output load

capacitance
Rload
list_of_values
LOAD
Falling output load

capacitance
Fload
list_of_values
LOAD
PWL names for

rising input slew
Rslew_pwl
list_of_pwl_names
None
PWL names for

falling input slew
Fslew_pwl
list_of_pwl_names
None
PWL names for

rising binary slew
BRslew_pwl
list_of_pwl_names
None
PWL names for

falling binary slew
FRslew_pwl
list_of_pwl_names
None
December 2012
126

Descriptor
Keyword
Type
Default
Internal node names internal
list_of_node_names
None
Glitch level (in

glitch
percentage) for
internal node names
glitch_levels
None
Cell name for index

selection
AUTO_INDEX_CELL
cell_name
None
Number of index
points generated
AUTO_INDEX_POINTS value
Number of points for AUTO_BSLEW_POINTS value

Bslew
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 {
slew
= 0.03N 0.10N 0.60N 1.00N 2.00N ;
load
= 0.8F 10.0F 40.0F 80.0F 280.0F ;
Rslew_pwl = rise_pwl1 rise_pwl2 ;

Fslew_pwl = fall_pwl1 fall_pwl2 ;
};
December 2012
127

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];
Release = scale offset [scale offset];
Removal = scale offset [scale offset];
Recovery = scale offset [scale offset];
December 2012
128

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-4 MARGIN Statement Syntax
Descriptor
Type
Default
Input capacitance factors Cap
scale, offset
1.0, 0.0
Wire capacitance factors Wcap
scale, offset
1.0, 0.0
Wire resistance factors
Wresist
scale, offset
1.0, 0.0
Cell delay factors
Delay
scale, offset
1.0, 0.0
Effective capacitance
factors
Ecap
scale, offset
1.0, 0.0
Power consumption
factors
Power
scale, offset
1.0, 0.0
Slew rate factors
Slew
scale, offset
1.0, 0.0
I/O path delay factors
Iopath
scale, offset
1.0, 0.0
Interconnect delay factors Interconnect
scale, offset
1.0, 0.0
Setup constraint factors
Setup
scale, offset
1.0, 0.0
Hold constraint factors
Hold
scale, offset
1.0, 0.0
Release constraint
factors
Release
scale, offset
1.0, 0.0
Removal constraint
factors
Removal
scale, offset
1.0, 0.0
Recovery constraint
factors
Recovery
scale, offset
1.0, 0.0
Pulse width constraint

factors
Width
scale, offset
1.0, 0.0
December 2012
Keyword
129

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
= 1.0 0.0 ;
hold
= 1.0 0.0 ;
release
= 1.0 0.0 ;
removal
= 1.0 0.0 ;
recovery = 1.0 0.0 ;

width
= 1.0 0.0 ;
delay
= 1.0 0.0 ;
power
= 1.0 0.0 ;
cap
= 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:
average_value = (max min) * factor + min ;
For example, Figure A-1 on page 131 and Figure A-2 on page 131 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.
December 2012
130

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 2012
131

Table A-5 NOMINAL Statement Syntax
Descriptor
Keyword
Type
Default
Gate capacitance
factor
Cap
value, value
0.5, 0.5
Constraint factor
Check
value, value
1.0, 1.0
Current source
factor
Current
value, value
0.5, 0.5
Power factor
Power
value, value
0.5, 0.5
Slew rate factor
Slew
value, value
0.5, 0.5
Delay factor
Delay
value, value
0.5, 0.5
Example
The following example shows a NOMINAL statement:
Nominal NOMINAL_SET_0 {
delay
= 0.5 0.5 ; // as rise fall
power
= 0.5 0.5 ;
cap
= 0.5 0.5 ;
} ;
PROCESS Statement
PROCESS ::= Process process_name {
Voltage
= value ;
Temp
= value ;
Corner
= string ;
section
= string ;
lib
= string ;
model
= string ;
Vtn
= value ;
Vtp
= value ;
RCcorner
= string ;
Gtcorner
= strings ;
December 2012
132

} ;
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
Important
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-6 PROCESS Statement Syntax
Descriptor
Keyword
Type
Default
Voltage
Voltage
value
None
Temperature
Temperature
value
None
Process corners for Gtcorner

loading cell models
from library database
strings
process_name
Library section
names in the library
model file for SPICE
simulation
section
string
None
Library Model file

name
lib
string
None
Model file name
model
string
None
December 2012
133

Descriptor
Keyword
Type
Default
Voltage of NMOS
gate.
Vtn
value
None
Vtp
value
None
RCcorner
string
None
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
Example
The following PROCESS statement defines three process corners:
Process typical {
voltage
= 1.2
temp
= 25
December 2012
134

Vtn
= 0.208 ;
Vtp
= 0.208 ;
} ;
Process best
voltage
= 1.32
temp
= 0
model
= model_tt.sp
Vtn
= 0.272 ;
Vtp
= 0.272 ;
} ;
Process worst
voltage
= 1.08
temp
= 125
Vtn
= 0.192 ;
Vtp
= 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 {
December 2012
135

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
= rise_fall_levels
Vl
= rise_fall_levels
Vth
= rise_fall_levels
Vsh
= rise_fall_levels
Vsl
= rise_fall_levels
Tsmax
= value ;
incir
= string ;
slew_derate
= value ;
};
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-7 SIGNAL Statement Syntax
Descriptor
Keyword
Type
Default
Voltage level unit
Unit
REL|ABS
REL
REL is a percentage of
the voltage level unit;
ABS is the fixed value.
High-level voltage
Vh
value
1.0
Low-level voltage
Vl
value
0.0
Threshold-level
voltage
Vth
value
0.5
December 2012
136

Descriptor
Keyword
Type
Default
High-slew voltage
level
Vsh
value
0.8
Low-slew voltage
level
Vsl
value
0.2
Maximum output
slew, which is used
for max_cap
calculation
Tsmax
value
3.0 ns
Input circuit for

generating nonlinear input slew
incir
string
Scaling factor for

input slew
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 ;

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 2012
137

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
= REL
Vh
Vl
Vth
Vsh
Vsl
tsmax
=
=
=
=
=
=
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-8 SIMULATION Statement Syntax
Descriptor
Keyword
Type
Default
Transient simulation
Transient
value, value,
value
1.0 ns, 20 ns, 10 ps
Binary search
Bisec
value, value,
value
3.0 ns, 3.0 ns, 100 ps
December 2012
138

Descriptor
Keyword
Type
Default
Pulling resistance
Resistance
value, value,
value
1000000
string
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.
Simulation STANDARD_CELL {
transient
= 1.0n
30n
10p ;
bisec
= 3.0n
3.0n
10p ;
resistance
= 10MEG ;
incir
= bf1xv ;
// binary search
} ;
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 ;
December 2012
139

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-9 SET_CELL Command Syntax
Descriptor
Keyword
Type
Default
Cell name
Name
string
None
SIMULATION
statement
Simulation
string
None
INDEX statement
Index
string
None
SIGNAL statement
Signal
string
None
MARGIN statemen
Margin
string
None
NOMINAL statement
Nominal
string
None
Example
set cell (typical) {
name= PCI33DGZ
signal
= VDDPST
index
= 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;
December 2012
140

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-10 SET_DEFINES Command Syntax
Descriptor
Keyword
Type
Default
Group name
Group
string
None
Cell name
Cell
string
None
Pin name
Pin
string.string
None
Example
set index
(best,typical,worst) {
Group(XL)
= XL
Group(X2)
= X2
Group(X3)
= X3
Group(X4)
= X4
Group(X6)
= X6
Group(X8)
= X8
Group(X12) = X12 ;
Group(X16) = X16 ;
Group(X20) = X20 ;
Group(CK_SLW) = CK_SLW ;
} ;
set signal(typical) {
Group(VDD2.5V) = VDD2.5V ;
Group(VDDB) = VDDB ;
} ;
December 2012
141

SET_GROUP Command
SET_GROUP ::= Set Group( process_name[,process_name]) {
Name = group_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-11 SET_GROUP Command Syntax
Descriptor
Keyword
Type
Default
Group name
Name
string
None
SIMULATION
statement
Simulation
string
None
INDEX statement
Index
string
None
SIGNAL statement
Signal
string
None
MARGIN statemen
Margin
string
None
NOMINAL statement
Nominal
string
None
Example
set group (typical) {
name= 1XPAD_PINS
index= IO5x6d1
signal= VDD2.5V
;
;
;
} ;
December 2012
142

SET_PIN Command
SET_PIN::= Set Pin ( process_name[,process_name]) {
Name = cell_name.pin_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-12 SET_PIN Command Syntax
Descriptor
Keyword
Type
Default
Pin name
Name
string.string
None
SIMULATION
statement
Simulation
string
None
INDEX statement
Index
string
None
SIGNAL statement
Signal
string
None
MARGIN statement
Margin
string
None
NOMINAL statement
Nominal
string
None
Example
set pin (typical) {
name= PCI33DGZ.PAD ;
signal
= VDD2.5V
index
= 5VTIO5x6d1
} ;
December 2012
143

SET_PROCESS Command
SET_PROCESS ::=
Set process (process_name[,process_name]) {
} ;
Sets the process parameters for library characterization.

Table A-13 SET_PROCESS Command Syntax
Descriptor
Keyword
Type
Default
Simulation definition
Simulation
string
DEFAULT_
SIMULATION
Simulation index
Index
string
DEFAULT_INDEX
Signal levels
Signal
string
DEFAULT_SIGNAL
Margin factors
Margin
string
DEFAULT_MARGIN
Nominal factors
Nominal
string
DEFAULT_NOMINAL
Example
set process (best,typical,worst) {
simulation = std_cell
index
= X1
signal
= std_cell
margin
= m0
nominal
= n0
} ;
General Syntax
The complete syntax of the simulation setup file is as follows:
SETUP := DEFINE_SECTION* | SET_SECTION*
December 2012
;
144

DEFINE_SECTION :=
PROCESS* | [ SIGNAL* | SIMULATION*
| GROUP * | INDEX* | MARGIN* | NOMINAL* ]

PROCESS ::= Process process_name {
Voltage
= value ;
Temp
= value ;
Corner
= string
LIB
= string
MODEL
= string
Vtn
= value ;
Vtp
= value ;
RC_Corner
= string
GT_Corner
= string
;
;
} ;
SIGNAL ::= Signal signal_name {
Unit = {REL|ABS} ;
Vh
= rise_fall_levels
Vl
= rise_fall_levels
Vth
= rise_fall_levels
Vsh
= rise_fall_levels
Vsl
= rise_fall_levels
Tsmax = value ;
};
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 ; ]
} ;
December 2012
145

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];

Hold = scale offset [scale offset];
Release = scale offset [scale offset];
Removal = 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]) {
December 2012
146

} ;
SET_PIN::= Set Pin ( process_name[,process_name]) {
Name = cell_name.pin_name
} ;
SET_CELL ::= Set Cell ( process_name[,process_name]) {
Name = cell_name ;
};
SET_GROUP ::= Set Group( process_name[,process_name]) {
Name = group_name ;
};
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|Margin|Nominal ;
define_name ::= signal_name|simulation_name|margin_name|nominal_name ;
December 2012
147

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
December 2012
: 7X7
148

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

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

Group
XL {
CELL = *XL ;
} ;
Group
X1 {
CELL = *X1 ;
} ;
Group
X2 {
CELL = *X2 ;
} ;
Group
X3 {
CELL = *X3 ;
} ;
Group
X4 {
CELL = *X4 ;
} ;
Group
X6 {
CELL = *X6 ;
} ;
Group
X8 {
CELL = *X8 ;
} ;
Group
X12 {
CELL = *X12 ;
} ;
Group
X16 {
CELL = *X16 ;
}
} ;
Group
X20 {
CELL = *X20 ;
} ;
Margin
m0 {
setup
= 1.0 0.0 ;
hold
= 1.0 0.0 ;
release = 1.0 0.0 ;

removal = 1.0 0.0 ;
recovery = 1.0 0.0 ;
width
= 1.0 0.0 ;
delay
= 1.0 0.0 ;
power
= 1.0 0.0 ;
December 2012
151

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

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
= 1.08 ; // as voltage
temp
= 125 ; // as temperature
Vtn
= 0.444932 ;
Vtp
= 0.48939 ;
} ;
// 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
= ABS
; //absolute value
Vh
= 1.08
Vl
= 0.0
Vth
= 0.504 ;
Vsh
= 0.756 ;
Vsl
= 0.324 ;
tsmax
= 1.0936e-09 ; //maximum output slew rate
} ;
// 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
= ABS ;
Vh
= 0.864 ;
Vl
= 0.0
Vth
= 0.432 ;
Vsh
= 0.6048 ; //70%
Vsl
= 0.2592 ; //30%
tsmax
= 1.0936e-09 ;
//100%
;
//50%
} ;
// Defines the simulation control variables for cell library characterization.
December 2012
153

Simulation std_cell {
transient
= 2.1872e-10 6.5616e-06 4.3544e-11 ;
bisec
= 1.31232e-08 1.31232e-08 1.6872e-10 ;
resistance
= 10MEG ;
incir
= "" ;
} ;
// Slews are quoted in a 0-100% scale
Group LVLHLD1.I {
PIN = LVLHLD1.I ;
};
Index LVLHLD1.I {
// halved for incorporting slew derate
Rslew =
0.18e-10 0.44e-10 0.97e-10
2.01e-10 4.1e-10 8.23e-10 16.63e-10 ;
Fslew =
0.18e-10 0.44e-10 0.97e-10
2.01e-10 4.1e-10 8.23e-10 16.63e-10 ;
};
Group LVLHLD1.Z {
PIN = LVLHLD1.Z ;
};
Index LVLHLD1.Z {
Rload =
7e-16 17e-16 35e-16 72e-16 146e-16 295e-16 591e-16 ;
Fload =
7e-16 17e-16 35e-16 72e-16 146e-16 295e-16 591e-16 ;
};
// Slews are quoted in a 0-100% scale
Group LVLLHD1.I {
PIN = LVLLHD1.I ;
};
Index LVLLHD1.I {
Rslew =
0.18e-10 0.44e-10 0.97e-10
2.01e-10 4.1e-10 8.23e-10 16.63e-10 ;
Fslew =
0.18e-10 0.44e-10 0.97e-10
2.01e-10 4.1e-10 8.23e-10 16.63e-10 ;
};
Group LVLLHD1.Z {
December 2012
154

PIN = LVLLHD1.Z ;
};
Index LVLLHD1.Z {
Rload =
0.8e-15 1.8e-15 3.6e-15 7.3e-15 14.7e-15 29.5e-15 59.1e-15 ;
Fload =
0.8e-15 1.8e-15 3.6e-15 7.3e-15 14.7e-15 29.5e-15 59.1e-15 ;
};
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
= std_cell;
signal
= std_cell};
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 2012
155

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

Vsh
1.35 1.35 ;
Vsl
0.15 0.15 ;
tsmax=
2.0n ;
} ;
Simulation core {
transient
= 0.1n 80n
bisec
= 4.0n 4.0n 100p ;
10p
incir
= "" ;
resistance
= 10K;
} ;
Index
load {
BSlew
= 0.1n
0.5n
1.2n 1.5n ;
Slew
= 0.1n
0.2n
0.5n 0.8n 1.2n 1.5n ;
Load
= 0.1p
0.5p
1.2p 2.4p 3.6p 4.5p ;
} ;
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 ;
December 2012
157

} ;
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 2012
;
158

} ;
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
= load
signal
= core
margin
= m0
nominal
= n0
} ;
set signal(typical) {
Group(VDDB)
= VDDB
} ;
name= 1XPAD_PINS
index= IO5x6d1
signal= VDD2.5V
} ;
name= 2XPAD_PINS
index= IO5x6d2
signal= VDD2.5V
} ;
name= 3XPAD_PINS
index= IO5x6d3
December 2012
;
;
159

signal= VDD2.5V
} ;
name= PCIPAD_PINS ;
index= IO5x6d3
signal= VDD2.5V
} ;
name= X_PINS
index= Core5x6d0
} ;
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 2012
160
B
This appendix describes the Property file format that Encounter library characterizer uses
in its processing.
December 2012
161

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 ; ]*
}; }*
{ 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" ; ]*
[ rail_connection connection_name power_supply_name ; ]*
December 2012
162

[ 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.
cell cell_name
Specifies the cell name. You can use the * and ? wildcards
when specifying a 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.
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.
December 2012
163

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
Outputs test_scan_in.
out
Outputs test_scan_out.
enable
Outputs test_scan_enable.
in_inverted
Outputs test_scan_in_inverted.
out_inverted
Outputs test_scan_out_inverted.
enable_inverted
Outputs test_scan_enable_inverted.
scan_clock
Outputs test_scan_clock.
scan_clock_a
Outputs test_scan_clock_a.
scan_clock_b
Outputs test_scan_clock_b.
clock
Outputs test_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.
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
December 2012
164

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.
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.
December 2012
165

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;
December 2012
166

...
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)";
preset : "(!SN)";
clear_preset_var1 : H;
clear_preset_var2 : L;
}
}
foo: var;
}
December 2012
167

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 -
SE1 SE2 SI
CDN\", \"Q QN SO\"

H
: - -
- : N N
) {\
- , \\\
H L/H L
: - -
- : L/H H/L - , \\\
L -
L/H
: - -
- : L/H H/L - , \\\
H L
: - -
- : L H
H H
: - -
- : H L - , \\\
H -
: - -
- : X X - , \\\
- -
: - -
- : L H - , \\\
- -
: - -
- : - -
- -
: L/H H/L - : - - L/H\";\
- , \\\
N , \\\
}";
};
Note: All special characters should have an escape sequence (\) as used in a string.
December 2012
168
C
Gate File Format
This appendix describes the Gate file format that Encounter library characterizer uses in its
processing.
December 2012
169

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.
port_name
Specifies the name of the port.
net_name
Specifies the name of the net associated with the port or gate.
port_property
Specifies a property for the specified ports. Ports can have the
following properties:
COMPLEMENTARY The input ports are complementary.
gate_type
December 2012
PULL_UP
The port has a pull-up resistance.
PULL_DOWN
The port has a pull-down resistance.
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.
170

Gate File Format
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 171 illustrates the different port types.
Figure C-1 Port Types
A
a
INPUT A (a);
SUPPLY1 VDD (a);
SUPPLY0 VSS (a);
OUTPUT A (a);
VSS
Tristate
p
VDD
OUTPUT A (a, n, p);

a
A
A
B
INOUT A (a, n, p);
p
a
n
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 2012
171

Gate File Format
Primitive Gates
The following table describes primitive gate types:
Number of
Inputs
Primitive Gates
BUF
Y=A
NOT
Y=~A
OR
Y=A | B | C
NOR
Y=~(A | B | C...)
AND
Y=A&B&C
NAND
Y=~(A&B&C...)
XOR
Y=A^B^C
XNOR
Y=~(A^B^C...)
MAJ
Y=A&B | B&C | C&A
IMAJ
Y=~(A&B | B&C | C&A) 3
MUX
Y=A?B:C
IMUX
Y=~(A?B:C)
AMP
Y=A>B? 1:A<B? 0:X
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 173 illustrates the MAJ and IMAJ gate descriptions:
December 2012
172

Gate File Format
Figure C-2 MAJ and IMAJ Gates
MAJ(Y, A, B, C);
IMAJ(Y, A, B, C);
A
A
B
MAJ
IMAJ
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 174 illustrates the MUX and IMUX gate descriptions:
December 2012
173

Gate File Format
Figure C-3 MUX and IMUX Gates
IMUX(Y, A, B, C);
MUX(Y, A, B, C);
A
B
MUX
IMUX
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:
Number of
Inputs
Tristate Gates
BUFIF1 (NMOS)
Y= if (B=1) then A else HiZ
BUFIF0 (PMOS)
Y= if (B=0) then A else HiZ
NOTIF1
Y= if (B=1) then ~A else HiZ
NOTIF0
Y= if (B=0) then ~A else HiZ
CMOS
Y= if (B=1 | C=0) then A else HiZ
PUSHPULL
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)
December 2012
174

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 175 illustrates tristate gates:

Figure C-4 Tristate Gates
BUFIF1 (Y, A, B);
CMOS (Y, A, B, C);
BUFIF0 (Y, A, B);
C
A
Y
A
B
B
NOTIF1 (Y, A, B);
PUSHPULL (Y, A, B);
NOTIF1 (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 2012
175

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 179.
Bidirectional Switches
Number of Nodes
NMOSX
NMOSX (D, S, G)
PMOSX
PMOSX (D, S, G)
CMOSX
CMOSX (D, S, NG, PG)
Figure C-5 on page 176 illustrates bidirectional switches:

Figure C-5 Bidirectional Switches
NMOSX
PMOSX
D
G
D
G
December 2012
CMOSX
D
NG
176
PG
S

Gate File Format
Examples
The following example describes and illustrates a NAND gate:
DESIGN (NAND2);
//PORT SECTION;
NAND2
VDD
INPUT A (A);
INPUT B (B);
OUTPUT Y (Y);
SUPPLY1 VDD (VDD);
SUPPLY0 VSS (VSS);
A
B
A
Y
//GATE SECTION
NAND (Y, A, B);
VSS
END_OF_DESIGN;
The following example describes and illustrates a tristate buffer:

DESIGN (TBUF);
//PORT SECTION;
Tristate buffer (TBUF)

EN
INPUT A (A);
INPUT EN(EN);
OUTPUT Y (Y, N, P);
SUPPLY1 VDD (VDD);

SUPPLY0 VSS (VSS);
(To measure tpHZ)
//GATE SECTION
BUFIF1 (Y, A, EN);

NOT ($1, EN);
NAND (P, A, EN);
NOR (N, A, $1);
EN
END_OF_DESIGN;
Y
A
N
(To measure tpLZ)
December 2012
177

Gate File Format
The following example describes and illustrates a bidirectional buffer:
DESIGN (BIO);
Bidirectional buffer (BIO)
//PORT SECTION;
INPUT A (A);
INPUT EN(EN);
OUTPUT Y (Y);
EN
INOUT PAD (PAD, N, P);

PULL_UP;
PAD
SUPPLY1 VDD (VDD);

SUPPLY0 VSS (VSS);
//GATE SECTION
BUFIF1 (PAD, A, EN);
NOT ($1, EN);
NAND (P, A, EN);
NOR (N, A, $1);

BUF (Y, PAD);
EN
END_OF_DESIGN;
PAD
A
The following example describes and illustrates a differential input circuit:

DESIGN (DIN);
Differential input (DIN)
//PORT SECTION;
INPUT P (P);
VDD
INPUT N(N);
OUTPUT Y (Y);
SUPPLY1 VDD (VDD);
SUPPLY0 VSS (VSS);
COMPLEMENTARY P, N;
//GATE SECTION
P
N
AMP (Y, P, N);

END_OF_DESIGN;
December 2012
P
Y
N
VSS
178

Gate File Format
The following example describes and illustrates a tristate IO cell to aid cell recognition:
DESIGN (BIO);
Bidirectional IO
//PORT SECTION;
OUTPUT DIN (DIN);
INOUT EXT (EXT, NET634\#10,
NET635\#13);
D$1
POR_L
EN_OUT
DOUT
INPUT EN_IN (EN_IN);
EXT
INPUT EN_OUT (EN_OUT);

INPUT POR_L (POR_L);
DIN
INPUT DOUT (DOUT);
EN_IN
//GATE SECTION
NAND ($1, POR_L, EN_OUT);
NOT ($2, $1);
BUFIF0 (EXT, DOUT, $1);
NET635\#13
D$1
NOR (NET634\#10, DOUT, $1);

NAND (NET635\#13, DOUT, $2);
NAND (DIN, EXT, EN_IN);
END_OF_DESIGN;
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 175). 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/
December 2012
179

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 2012
===========
180

Gate File Format
//
INSTANCES
//
===========
NOT ( NET0197, NET86 );
NOT ( NET130, NET78 );
NOT ( NET154, T );
NOT ( NQ, Q );
NOT ( Q, NET86 );
NAND ( NET82, NCLR, NET134 );
MUX ( NET74, NET154, NET0197, 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 CLK ( CLK );
OUTPUT OUT_L ( OUT_L );
OUTPUT OUT ( OUT );
//
===========
//
INSTANCES
//
===========
NOT ( NET0197, NET86 );
NOT ( NET154,CLK );
NOT ( OUT_L, OUT );
NOT ( OUT, NET86 );
December 2012
181

Gate File Format
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 2012
=================
182

Gate File Format
//
PORT DEFINITION
//
=================
INPUT CLK ( CLK );
OUTPUT OUT ( OUT );
//
===========
//
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 2012
183

Gate File Format
INPUT CLK ( CLK );
OUTPUT OUT ( OUT );
//
===========
//
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
December 2012
//generate simulation vectors
184
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.
Syntax on page 186
Boolean Operator on page 187
Pin Attribute on page 187
Functions on page 188
Logical Function on page 188
Tri-state Function on page 189
Sequential Function on page 191
Using a BOOL File to Aid Cell Recognition on page 193
December 2012
185

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 2012
186

Bool File Format
Boolean Operator
The following operators are available for BOOL:
Operator
Symbol
Operator Name
Syntax
~ and !
invert
Y = ~A
& and *
and
Y = A * B * C
| and +
or
Y = A + B + C
exclusive or
Y = A ^ B ^ C
complement
Y/YB = A
=>
multiplex function
Y = S?A:B
=> Y = S&A|(~S)&B
Y = A,
YB = ~A
Pin Attribute
The following pin attributes are available in BOOL:
Attribute
Description
[pin_name]
pin_name is an internal pin or a

virtual pin
#pin_name#
pin_name is an external inout pin
STATE(pin_name1,
pin_name2,...pin_namen)
pin_name is a state pin
December 2012
187

Bool File Format
Functions
The following functions are available in BOOL:
Function Type
Keywords
Logical Function
NOT(), INV(), AND(), NAND(), OR(), NOR(),

XOR(), XNOR(), MUX()
Tri-state Function
TBUF(), NOD(), POD()
Sequential Function
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)
December 2012
=> Y = S? A: B
188

Bool File Format
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 2012
189

Bool File Format
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 2012
190

Bool File Format
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 2012
191

Bool File Format
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 2012
192

Bool File Format
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
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 2012
193

Bool File Format
5. Include the characterization results in the out.lib file:
6. Exit Encounter library characterizer:

exit
December 2012
194
E
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.
Syntax on page 195
Statements on page 197
Examples on page 207
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> ) ;
December 2012
195

]*
[ 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 2012
196

Statements
The specification file includes the following statements. They are listed in alphabetical order.
ARC Statement on page 197
BUNDLE Statement on page 199
CHECK Statement on page 199
COMPLEMENTARY Statement on page 201
DESIGN Statement on page 201
END_OF_DESIGN Statement on page 201
INHIBIT Statement on page 201
NODE Statement on page 202
PORT Statement on page 202
REGISTER Statement on page 205
VECTOR Statement on page 205
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
December 2012
197

+ 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
input_port
Specifies the name of the input port.
output_port
Specifies the name of the output port.
POSITIVE_UNATE
Indicates that the input and output ports change in the same
direction.
NEGATIVE_UNATE
Indicates that the input and output ports do not change in the
same direction.
NON_UNATE
Indicates that the input and output ports can be rising or falling
as the inputs rise.
RISE_EDGE
Specifies that the inputs change only on the rising edge of the
clock.
FALL_EDGE
Specifies that the inputs change only on the falling edge of the
clock.
PRESET
Specifies that the outputs change only on the rising edge of the
clock.
CLEAR
Specifies that the outputs change only on the falling edge of the
clock.
TRISTATE_L
Specifies that the tristate is low-level active.
TRISTATE_H
Specifies that the tristate is high-level active.
NCH_OPEN_DRAIN_L
Specifies that the threshold voltage at the NMOS gate is lowlevel active.
NCH_OPEN_DRAIN_H
Specifies that the threshold voltage at the NMOS gate is highlevel active.
PCH_OPEN_DRAIN_L
Specifies that the threshold voltage at the PMOS gate is lowlevel active.
December 2012
198

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.
bundle_element
Specifies the number of the port or register in the bus.
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 2012
199

+ SETUP
+ HOLD
+ RELEASE
+ REMOVABLE
+ RECOVER
+ WIDTH_H
+ WIDTH_L
+ WHEN( condition_boolean_expression ) ]
+ USE( vector_name_1 [ , vector_name_n ]* )
;
Specifies the input constraints.

constraint_port
Specifies the name of the boundary port to which the

constraints are applied.
constraint_edge
Specifies whether the constraints are applied on the rising or

falling edge of the clock.
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
Specifies the setup time.
HOLD
Specifies the hold time.
RELEASE
Specifies the release time.
REMOVABLE
Specifies the remove time.
RECOVER
Specifies the recover time.
WIDTH_H
Specifies the positive minimum pulse.
WIDTH_L
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 2012
200

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.

true_port_name
Specifies the name of the true port.
complementary_port_name
Specifies the name of the complementary port.
DESIGN Statement
DESIGN( design_name );
Indicates the beginning of the design section.

design_name
Specifies the name of the design.
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 2012
201

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.
node_name
Specifies the name of the internal node.
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
December 2012
202

+ 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.
port_name
Specifies the name of the port.
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} )
December 2012
Specifies the status of the clock pin.

R
Specifies the rising edge in an edgetriggered clock pin.
Specifies the falling edge in an edgetriggered clock pin.
203

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
Specifies that the pin is high active.
Specifies that the pin is low active.
DATA
Specifies that the pin is a data signal.
ENABLE( {H|L|X} )
Specifies the state of the tristate enable input pin.

H
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
Specifies that the pin will be used for a single stage in the
design.
TWO_STAGE
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
Specifies that the voltage supply pin is power (high).
SUPPLY0
Specifies that the voltage supply pin is ground (low).
FEEDTHRU
Specifies that the pin is a feedthrough.
BUS_KEEPER
Specifies that the pin is a bus keeper.
December 2012
204

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.
true_reg_name
Specifies the name of the true pin in the register.
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 )
December 2012
205

+ RACE( first_change_input_ports ,
next_change_input_ports )
+ TARGET( port_names ) ;
Specifies the simulation vectors to use in the SPICE simulation.

simulation_vector
Specifies the name of the simulation vector. The simulation

vectors are shown in Table E-1.
ID( vector_name )
Specifies the name of each vector.
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
Vector Type
Function
Input
Force high level
Input
Force low level
Input
Force rising edge
Input
Force falling edge
December 2012
206

Symbol
Vector Type
Function
Input
Input search of rising edge
Input
Input search of falling edge
Output
Expect high level
Output
Expect low level
Output
Expect high Z
Output
Expect rising edge
Output
Expect falling edge
Output
Expect tpLZ
Output
Expect tpZH
Output
Expect tpHZ
Output
Expect tpZL
Output
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 2012
207

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);
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 2012
208
Index
Numerics
0 logic state 15
1 logic state 15
absolute margin factor 129

ALF file
formats to convert to 14
database
accessing 51
closing 51
opening 51
db_close command 51
db_open command 51
Define section 122
DESIGN statement 201
distributed processing 31
batch mode 46
bidirectional cells 15, 16
binary search 21, 125
BUNDLE statement 199
ECSM
description of 30
END_OF_DESIGN statement
environment variables 52
exclusive logic 20
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 200
combinatorial logic cells 14, 15
command file 46, 51
command log file 45
command-line help and man pages 48
COMPLEMENTARY statement 201
complex gates 20
Control section 139
CPPL cell 20
CVSL cell 20
December 2012
201
GROUP statement 122, 123

Gtcorner parameter 133
H
help, command-line 48
high-impedance states 15, 16
high-to-Z propagation delays 16
hold time
binary searches 139
characterization for sequential logic
characterizing 130
HTML 14
17
I
INDEX statement 125
INHIBIT statement 201
interactive mode 45
interface (pad) circuits 19
209
interface circuitry 15
ipsc command 37
ipsmon> command 39
ipsstat command 39
power consumption 28
process corners
in simulation setup file 133
specified by cell library
characterization 14
PROCESS statement 133
pulldowns 19, 139
pullups 19, 139
K
K-factor model 30
race conditions 18
recovery time
REGISTER statement 205
relative margin factor 129
release time
removal time
level shifters 19
Library Compiler
converting ALF file 14
log file 45, 46
low-to-Z propagation delay 16
M
man pages, command-line 48
margin factors 129
MARGIN statement 129
measurement levels 27
minimum pulse width 17, 29
multi-bit logic 15
Schmitt triggers 19
sense amplifiers 19
sequential logic cells 14, 15, 17, 29
SET_CELL statement 140
SET_DEFINES statement 141
SET_GROUP statement 142
SET_PIN statement 143
SET_PROCESS statement 144
setup time
binary searches 139
short-circuit power 28
SIGNAL statement 136
simulation
monitoring 39
running SPICE 19
vectors 206
simulation setup file
case sensitivity 122
Control section 139
Define section 122
example for I/O cell library
characterization 155
example for standard cell library
characterization 148
general syntax 144
network resource control daemon 39

NODE statement 202
nominal factors 130
NOMINAL statement 130
non-linear table model 30
O
30
P
parallel processing 31
pass transistor logic cells 20
path logic cells 15
pin-to-pin delay 14, 27, 28
PORT statement 203
December 2012
17
17
output driving models
17
210
17
purpose 121
wildcards 122
SIMULATION statement 138
slc.log file 45, 46
.slcrc file 52
slew rate
in simulation setup file 125
input 28
output 28
specification file
format 195
statements in 197
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 130
V
VECTOR statement 206
Verilog
converting ALF file to 14
VHDL
converting ALF file to 14
W
wildcards
122
December 2012
211
December 2012
212

Encounter Library Characterizer User Guide: Product Version 12.0 December 2012

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Encounter Library Characterizer User Guide: Product Version 12.0 December 2012

Uploaded by

Copyright:

Available Formats

Encounter Library Characterizer User

20112012 Cadence Design Systems, Inc. All rights reserved.

Encounter Library Characterizer User Guide

What Is Cell Library Characterization? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Product Version 12.0

Encounter Library Characterizer User Guide

Product and Installation Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Product Version 12.0

Encounter Library Characterizer User Guide

Performing CCS-Based Noise Characterization for Standard Cells . . . . . . . . . . . . . . . .

Product Version 12.0

Encounter Library Characterizer User Guide

Property File Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

Product Version 12.0

Encounter Library Characterizer User Guide

Product Version 12.0

Encounter Library Characterizer User Guide

Product Version 12.0

Encounter Library Characterizer User Guide

About This Manual

How This Manual Is Organized

Chapter 1, Basics of Cell Library Characterization,

Chapter 2, Getting Started

Chapter 3, Preparing for Library Characterization,

Chapter 4, Performing Cell Library Characterization,

Chapter 5, Performing Cell Library Validation,

Chapter 6, Troubleshooting Library Characterization Issues,

Product Version 12.0

Encounter Library Characterizer User Guide

Conventions Used in This Manual

Indicates text that you must type exactly as shown. For

Indicates information for which you must substitute the name

Indicates the minimum number of characters you must type for

File and directory names are specified in Courier font.

Indicates optional arguments.

Indicates an optional choice from a mutually exclusive list.

Product Version 12.0

Encounter Library Characterizer User Guide

Indicates a required choice from a mutually exclusive list.

Indicates a required choice of one or more items in a list.

Indicates that you can repeat the previous argument.

Indicates an omission in an example of computer output or

Encounter Library Characterizer Known Problems and Solutions

Encounter Library Characterizer Text Command Reference

Whats New in Encounter Library Characterizer

Product Version 12.0

Encounter Library Characterizer User Guide

Product Version 12.0

Encounter Library Characterizer User Guide

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

Product Version 12.0

Encounter Library Characterizer User Guide