elcuserguide

Encounter® Library Characterizer User Guide

Product Version 12.0

December 2012

© 2011–2012 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 Cadence’s 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; and4. 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 Cadence’s 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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9How This Manual Is Organized . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Conventions Used in This Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10Related Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

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

What Is Cell Library Characterization? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Automatic Cell Library Characterization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Multiple Cell Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Combinatorial Logic Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Tristate Logic Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Bidirectional Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Sequential Logic Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Multi-Bit Logic Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Interface (Pad) Circuits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Pass Transistor Logic Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

State Dependency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Binary Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Characterization Measurement Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Pin-to-Pin Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Power Consumption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Input Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Input Loading Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Output Driving Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Non-Linear Table Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30K-Factor Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Effective Current Source Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Distributed Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

December 2012 3 Product Version 12.0


2Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Product and Installation Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34Setting the Run-Time Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34Product Licenses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Configuring the Environment for Parallel Simulations . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Using IPSD/IPSC for Parallel Simulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36Using LSF for Parallel Simulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Starting Encounter Library Characterizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43Starting Encounter Library Characterizer in Interactive Mode . . . . . . . . . . . . . . . . . . 45Starting Encounter Library Characterizer in Batch Mode . . . . . . . . . . . . . . . . . . . . . . 46Starting Encounter Library Characterizer in 64-bit Mode . . . . . . . . . . . . . . . . . . . . . . 46

Online Documentation and Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Using Text Command Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

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

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50Inputs to Encounter Library Characterizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

SPICE Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51Encounter Library Characterizer Command File . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51Simulation Setup File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53Configuration File (elccfg) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54Statistical Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57Property File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58Liberty (.lib) File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Outputs of Encounter Library Characterizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

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

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62Performing Library Characterization for Standard Cells . . . . . . . . . . . . . . . . . . . . . . . . . 63Performing Library Characterization using a Pre-driver Cell . . . . . . . . . . . . . . . . . . . . . . 65Performing ECSM-Based Power Characterization for Level-Shifter Cells . . . . . . . . . . . . 67



Performing CCS-Based Noise Characterization for Standard Cells . . . . . . . . . . . . . . . . 69Performing CCS-Based Power Characterization for Standard Cells . . . . . . . . . . . . . . . . 71Performing SOI Characterization for Standard Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73Performing AAE Characterization for Standard Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . 75Performing Automatic Index Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77Creating a Simulation Setup File Automatically from an Existing Dotlib . . . . . . . . . . . . . 80Performing Incremental Characterization using Internal Simulator . . . . . . . . . . . . . . . . . 81Performing Incremental Characterization using External Simulator . . . . . . . . . . . . . . . . 83Performing Statistical Characterization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85Performing Library Recharacterization Using Different PVT . . . . . . . . . . . . . . . . . . . . . . 87Performing Library Characterization of Standard Cells Using Multiple PVT and Multiple Corners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91Creating a Binary Dotlib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93Performing Additional Library Characterization Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

Performing Library Characterization Using Gate File . . . . . . . . . . . . . . . . . . . . . . . . . 94Characterizing Hierarchical Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95Generating a Non-Linear Input Slew . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96Using a Characterized Database to Generate Multiple Views . . . . . . . . . . . . . . . . . . 97Performing AOCV Table Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

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

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102ecsmChecker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103libdiff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104LibVsSpice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109EtsvsSpice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

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

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114Characterizing Failed Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115Handling Failures During Various db_spice Stages . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116Adjusting Transient Time to Prevent Simulation Failure . . . . . . . . . . . . . . . . . . . . . . . . . 118



ASimulation Setup File Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

Case-Sensitivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122Wildcards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122Define Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

GROUP Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122AOCV GROUP Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123INDEX Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125MARGIN Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128NOMINAL Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130PROCESS Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132PWL Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135SIGNAL Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136SIMULATION Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

Control Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139SET_CELL Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139SET_DEFINES Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140SET_GROUP Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142SET_PIN Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143SET_PROCESS Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

General Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

Standard Cell Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148Level Shifter Cell Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153I/O Cell Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

BProperty File Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

Property File Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

CGate File Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

Gate File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170



Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171Gates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177Making Gate File Corrections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179Creating a Gate File to Aid Cell Recognition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184

DBool File Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186Boolean Operator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187Pin Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

Logical Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188Tri-state Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189Sequential Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

Using a BOOL File to Aid Cell Recognition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

ESpecification File Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195

Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

ARC Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197BUNDLE Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199CHECK Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199COMPLEMENTARY Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201DESIGN Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201END_OF_DESIGN Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201INHIBIT Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201NODE Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202PORT Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202REGISTER Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205VECTOR Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205

Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207



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,”


Encounter Library Characterizer User GuideAbout 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]



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.

■ What’s 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.

{ | } 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.


http://downloads.cadence.com


For a complete list of documents provided with this release, see the Cadence Help System library.

10/26/12



1Basics 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


Encounter Library Characterizer User GuideBasics of Cell Library Characterization

What Is Cell Library Characterization?

One of the main goals in a gate-level design flow is to prove that a design will perform to its required timing specification. Once a design has been completed through placement and routing, the next step is to understand the inherent delays associated with the completed routing. Cell library characterization generates timing characteristics (timing models) of library cells on the basis of their physical implementation (layout).

The main input to library characterization is a SPICE-format netlist that contains the detailed transistor devices, resistance, and capacitance for each library cell.

The main output of library characterization is a library database that contains timing, power, and noise models for each of the cells. These models are used in electrical analysis.

Automatic Cell Library Characterization

Encounter library characterizer performs the following steps for automatic cell library characterization:

1. Analyzes transistor circuits in SPICE format and recognizes their function, logic structure, and type.

2. Generates the logic model, or function model, for sequential circuits, combinatorial circuits, and tristate circuits.

3. Generates the specification definitions in the circuit, such as the pin-to-pin delay, input pin timing constraints, and pin direction and properties.

4. Defines the characterization environment by specifying parameters such as the supply voltage, temperature, input slew rate, output load, and process corners.

5. Invokes and executes SPICE and summarizes the results, including the pin-to-pin delay and the input timing constraints.

6. Generates the ALF file, which you can then convert to library formats such as Verilog, Liberty Library, VHDL, and HTML.

Encounter library characterizer systematically integrates all these steps, providing fully automated library characterization.



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

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 high-impedance 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.

Inverter 2-input NAND Full adder

4-input NAND

2-input NOR



Figure 1-2 Tristate Logic Cells

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.

Tristate buffer

Nch open drain

Pch open drain

To measure tpLZTo measure tpLZ

To measure tpHZ



Figure 1-3 Bidirectional Cell

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.

To measure tpLZ

To measure tpHZ



Figure 1-4 Sequential Logic Cell

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

DS flip-flop with XS, XR

to initialize latches

Register bit(dynamic)

D flip-flop(pseudo-dynamic)



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 4-bit flip-flop, shown in Figure 1-6 on page 19.

Figure 1-6 Multi-Bit Logic Cells

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.

4-bit NAND24-bit D flip-flop with XR



Figure 1-7 Interface Cells

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

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

Level shifters Sense amplifiers Schmitt trigger

CVSL CPPL



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



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.



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

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.

d0 x EC_BI_DRATIO

d0


../elctxtcmdref/variablesT.html#EC_BI_DRATIO


Figure 1-12 Initial Binary Search Step

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

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.

CK

D

Q

6.0n d0

CK

D

6.0n

Q

Latest Pass (-6.0ns)

Latest Fail (6.0ns)




Figure 1-15 on page 25 illustrates the next simulation point:

(-6 ns + 0 ns)/2 = -3 ns

This simulation passes because Q is the same as the estimated waveform, and the delay (d) is less than the d0 value multiplied by the delay tolerance check factor (SG_BI_DRATIO).


Figure 1-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.

CK

D

Q


Latest Fail (0.0ns) Previous Fail (6.0ns)

CK

D

Q

3.0n d


Previous Fail (0ns)

Previous Pass (-6.0ns)




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

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.

CK

D

Q

1.5n d

Previous Fail (0ns)


Latest Fail (-1.5ns)

CK

D

Q

2.25n d


Latest Fail (-2.0625ns)

(Latest Pass - Latest Fail) < 10ps

Setup = -Latest Pass Point = 2.25ns



Table 1-1 on page 27 shows the measurement levels used by Encounter library characterizer.

Table 1-1 Characterization Measurement Levels

* 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.

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



Figure 1-18 Pin-to-Pin 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 two-dimensional 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-to-pin 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.

delay delay

Vthi

Vtho

INPUT

OUTPUT



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 cell’s 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



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(Cload) = D0 + (K-Factor x Cload)

■ Cload 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



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 computer’s 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.



2Getting 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


Encounter Library Characterizer User GuideGetting 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


http://downloads.cadence.com


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:

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.

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

ETS XL or ELC GXL

■ All the features supported by ETS L or ELC XL

■ Statistical timing and leakage characterization



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 user’s 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



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.



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 simulator’s 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:



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



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


----------+----------+--------+---------+-------+----------



----------+----------+--------+---------+-------+----------

INVXL worst D0000 dstorm17 16402


----------+----------+--------+---------+-------+----------



----------+----------+--------+---------+-------+----------


----------+----------+--------+---------+-------+----------



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



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.



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]



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:

■ ELC GXL

■ ELC XL

■ ETS XL

■ ETS L

-Q Starts the Encounter library characterizer in silent mode. When the silent mode is enabled, the software does not report any messages related to the run.



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.

-r rechar_file Specifies the name of the Encounter library characterizer recharacterization command file.

-S cmd_file Specifies the name of the Encounter library characterizer command file to use. This command file contains the commands that are supported in the native mode.

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



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.



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



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



3Preparing for Library Characterization

■ Overview on page 50

■ Inputs to Encounter Library Characterizer on page 51

■ Outputs of Encounter Library Characterizer on page 59


Encounter Library Characterizer User GuidePreparing for Library Characterization

Overview

Encounter library characterizer is a unified characterization engine that enables you to generate timing and power models in Liberty library format. In addition, it enables you to generate ECSM-based timing, noise, and power models in a compact library. Finally, it provides you the ability to consider the effects of process variations on timing or leakage during characterization.

You can use Encounter library characterizer to generate the views necessary to support your design flow even if the required library views are not available. In addition, you can perform re-characterization on existing libraries to suit different design requirements.

Encounter library characterizer provides characterization capabilities for the following:

■ Pin-to-pin delay with state dependency

■ Input timing constraint (setup/hold/pulse width)

■ Power consumption (internal/leakage)

■ Input and output pin capacitance

■ Output pin transition time

■ ECSM Timing

❑ Voltage waveform at output pin

❑ Multi-piece ECSM capacitance

■ ECSM Power

❑ Current waveform at power-grid pins for different combinations of slew and load

■ ECSM Noise

❑ Voltage in Voltage out (ViVo) waveform on an input or output pin of a cell

■ Statistical ECSM

❑ Sensitivities to device parameters at the arc level for all load, slew, delay, waveform, and timing check tables

■ CCS Timing

❑ Current waveform at output pin

❑ Two piece receiver capacitance



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



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 parameter’s 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



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



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

This is a mandatory directive except when you are using the db_prepare -create_setup command.



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

This is a mandatory directive except when you are 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

This is a mandatory directive except when you are using the recharacterization or incremental flow.

In the recharacterization flow, this directive specifies the process name to use. If the process name is not specified, the default process name elc_process is used.

LIB Specifies the name of the SPICE library file.

Important

This directive must be specified when the CORNER directive is used.

CORNER Specifies the library corner of the SPICE library.

Important

This directive must be specified when the LIB directive is used.



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.

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.




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}



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 subcircuit-scoped.

■ The type option specifies that the param2 parameter affects only NMOS type transistors, and the param3 parameter affects only PMOS type transistors. Using the type option improves the run time.

Property File

A property file contains property information that is not defined in the ALF library, such as area, footprints, scan attributes, and pad attributes. You can use a property file to add extra



information when using the alf2lib command to generate a Liberty library file. The alf2lib command reads a property file if you specify the -def option.

Note: For more information on creating a Property file , see Appendix B, “Property File Format”.

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.



4Performing Cell Library Characterization


■ 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


Encounter Library Characterizer User GuidePerforming Cell Library Characterization

Overview

This chapter describes the steps required to perform basic, incremental, and statistical cell library characterization. In addition, it describes other library characterization tasks, such as characterization of level shifter cells, hierarchical cells, and generation of non-linear input slew.



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


../elctxtcmdref/commandsT.html#db_open

../elctxtcmdref/commandsT.html#db_prepare

../elctxtcmdref/commandsT.html#db_spice

../elctxtcmdref/commandsT.html#db_output

../elctxtcmdref/commandsT.html#db_close

../elctxtcmdref/commandsT.html#exit


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


../elctxtcmdref/variablesT.html#EC_CHAR


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 real-world 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.


../elctxtcmdref/variablesT.html#EC_PWL_FROM_DRIVER

../elctxtcmdref/variablesT.html#EC_RECHAR_DRIVER


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


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.


../elctxtcmdref/variablesT.html#EC_PWL_FROM_DRIVER

../elctxtcmdref/variablesT.html#EC_RECHAR_DRIVER





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.


a. Open a database named basic_char:

db_open basic_char


db_prepare






db_close


exit


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










(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";






Performing CCS-Based Noise Characterization for Standard Cells

The following procedure describes how to perform CCS-based noise characterization for standard cells.



Tip



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


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;










EC_SIM_LSF_CMD=" ";





EC_CHAR=“CCS-NOISE”;


SUBCKT="subckt";

MODEL="model";


SETUP="setup";





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



Performing CCS-Based Power Characterization for Standard Cells

The following procedure describes how to perform CCS-based power characterization for standard cells.



Tip



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


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;










EC_SIM_LSF_CMD=" ";





EC_CHAR=“CCS-POWER”;


SUBCKT="subckt";

MODEL="model";


SETUP="setup";





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



Performing SOI Characterization for Standard Cells

The following procedure describes how to perform SOI characterization for standard cells.



Tip



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


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=" ";



../elctxtcmdref/variablesT.html#EC_SOI_CHAR












EC_SOI_CHAR=1;


SUBCKT="subckt";

MODEL="model";


SETUP="setup";





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



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



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


Note: The EC_CHAR environment variable uses the AAE value, which indicates that










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




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



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;



};

Tip



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


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








../elctxtcmdref/variablesT.html#EC_GEN_AUTO_SETUP



SUBCKT="subckt";

MODEL="model";


SETUP="setup";






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.


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.




../elctxtcmdref/variablesT.html#EC_RECHAR_TEMPERATURE

../elctxtcmdref/variablesT.html#EC_RECHAR_VOLTAGE


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.


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


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






../elctxtcmdref/variablesT.html#EC_INCREMENT_CHAR



EC_SPICE_SUPPLY0_NAMES=”VSS”;

EC_INCREMENT_CHAR=ECSM-POWER;



SUBCKT="subckt";

MODEL="model";

DESIGNS="CMPE22D1 DFD1";

XDESIGNS=”INVD1”;



elc -L incremental.log -C incremental_cmd.log -S cmd_file



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.



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


Note: The EC_INCREMENT_CHAR environment variable uses the NATIVE-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.


EC_SPICE_SUPPLY1_NAMES=”VDD”;

EC_SPICE_SUPPLY0_NAMES=”VSS”;

EC_INCREMENT_CHAR=NATIVE-ECSM-POWER;













SUBCKT="subckt";

MODEL="model";








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




4. Create the Encounter library characterizer command file named cmd_file with the following series of commands:

Note: The command file does not contain any input for statistical characterization.

a. Open a database named stat_char:

db_open stat_char


db_prepare




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


db_close


exit










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



CORNER=”ss”;


STAT_CONFIG=”statistical_config”;






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.

5. Create the elccfg configuration file with the appropriate directives and environment variables and ensure that the following settings are done for the recharacterization flow:











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



CORNER=”ss”;


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.


../elctxtcmdref/variablesT.html#EC_SPECS_FROM_LIB

../elctxtcmdref/variablesT.html#EC_SPICE_SUPPLY1_NAMES

../elctxtcmdref/variablesT.html#EC_SPICE_SUPPLY0_NAMES

../elctxtcmdref/variablesT.html#EC_SPECS_DIR_PATH

../elctxtcmdref/variablesT.html#EC_SPEC_WORK

../elctxtcmdref/variablesT.html#EC_RECHAR_TEMPERATURE

../elctxtcmdref/variablesT.html#EC_RECHAR_VOLTAGE

../elctxtcmdref/variablesT.html#EC_SYNLIB_ATTR

../elctxtcmdref/variablesT.html#EC_SYNLIB_PASS_ATTR


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.

3. Create the elccfg configuration file with the appropriate directives and environment 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="";






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











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_filenameexit

2. Convert ELC generated dotlib file to a binary dotlib file:

ets -nowin -init binlib.ets



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 following series of commands:

a. Open a database named test.ipdb:

db_open test.ipdb


db_prepare

c. Copy the gate file for the design SAMPLEDESIGN to the specified location:

cp gate/SAMPLEDESIGN.gate test.ipdb/SAMPLEDESIGN.design/boundary/gate

Important

The gate file must be copied at the specified location before performing library characterization.

d. Overwrite the existing simulation vectors in the database and generate new simulation vectors:

db_gsim -force




../elctxtcmdref/commandsT.html#db_gsim


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



EC_SIM_USE_LSF=1;

EC_SIM_LSF_CMD="";





SUBCKT="SUBCKT";

MODEL="MODEL";

DESIGNS="SAMPLEGATE";

SETUP="SETUP";



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.







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="";






SUBCKT="subckt.cdl";

MODEL="model_file";

SETUP="setup_file";

EXPAND=”cellP5”;

DESIGNS=”cellP5”;


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



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 sampledata




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.









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.


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:






db_output -p elc_process -aocv aocv_table.aocv


db_close


exit



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










5Performing Cell Library Validation


■ ecsmChecker on page 103

■ libdiff on page 104

■ LibVsSpice on page 109

■ EtsvsSpice on page 110


Encounter Library Characterizer User GuidePerforming Cell Library Validation

Overview

This chapter describes the steps required to perform validation of a cell library. In addition, it describes the steps to validate the accuracy of the characterized data (timing data).

The following executables are used for semantic checking of cell librararies:

■ ecsmChecker

■ libdiff

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

■ LibvsSpice

■ ETSvsSpice



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.



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 library-level 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



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.



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

+--------------------+--------------------------------+-------------------------+

| | Timing Deviation | Power Deviation |

| Cell +--------------------------------+----------------------------+

| | 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:



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) { | cell(HD_NAND2X1) {

C| cell_leakage_power : 3.712790 ; | cell_leakage_power : 3.682860 ;

| leakage_power () { | leakage_power () {

| when : "((i0) & (!(i1)))"; | when : "((i0) & (!(i1)))";

C| value :4.578230 | value :4.229660

| } | }


| when : "((!(i0)) & (i1))"; | when : "((!(i0)) & (i1))";

C| value :4.263510 | value :3.941390

| } | }


| when : "((i0) & (i1))"; | when : "((i0) & (i1))";

C| 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.




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:



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.



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.



6Troubleshooting Library Characterization Issues


■ 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


Encounter Library Characterizer User GuideTroubleshooting Library Characterization Issues

Overview

This chapter describes troubleshooting techniques that you can use if you encounter problems while performing library characterization tasks.



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.









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 Troubleshooting Tip(s)

INITIAL ■ Simulation lock (sim_lock) file was found

■ A parallel simulation was running

■ Delete the lock file

■ Use the db_clean lock -all command to release the locks

GENERATE ■ Simulator path not found

■ SPICE model/library file is missing

■ Pre-driver cell simulation might have failed

■ Ensure that the SPICE simulator is in the search path

■ Ensure that the model/library file is available and is not corrupted

■ Check that the SPICE simulation was run successfully on the driver cell in the pre-driver flow

SIMULATE ■ SPICE simulation log (*.lis) does not exist even after performing SPICE simulation

■ SPICE simulation log has ERROR messages

■ core file found in SPICE working directory

■ 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

TRANSLATE ■ SPICE result translation failed to read SPICE result

■ dstran program failed to translate SPICE result to IPDB

Check your installation to confirm that the dstran_* executables exist. These executables are used to translate simulator specifc output files (.raw) to simulator independent format.




VERIFICATE ■ Incomplete supply settings

■ Cell not recognized correctly

■ Ensure that the supply settings are correct

db_spice Stage Likely Cause(s) for Failure Troubleshooting Tip(s)



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:




ASimulation Setup File Format

This appendix describes the format of the ASCII simulation setup file, which defines simulation conditions such as voltage, temperature, process corner parameters, waveform measurement levels, loading capacitance, and input slew.

The setup file is used as an input for library characterization.

For the complete syntax of the simulation setup file, see “General Syntax” on page 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


Encounter Library Characterizer User GuideSimulation Setup File Format

Case-Sensitivity

Statements and commands used in the setup file are case-insensitive.

Wildcards

You can use a question mark (?) or an asterisk (*) as wildcards in some simulation setup file statements.

Here are some examples of wildcard usage:

■ mem* matches strings that start with “mem,” such as mem1 and memory.

■ bus? matches four-character strings that start with “bus,” such as busA and bus1.

■ bus?? matches five-character strings that start with “bus,” such as bus32 and bus64.

When defining wildcards, you can use combinations of ? and *, For example, *bus? matches strings that contain “bus” but only have a single character following “bus,” such as bus1 and databusA.

The following descriptions identify statements that support wildcards.

Define Section

The Define section defines parameters, groups, variables, and margins to be used in the Control section. It includes the following statements, which are listed in alphabetical order.

GROUP Statement

GROUP ::= GROUP group_name {

Pin = CellName.PinName [,CellName.PinName]* ;

Cell = CellName [,CellName] * ;

} ;

Specifies groups of cells or pins for cell library characterization.



Table A-1 GROUP Statement Syntax

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.

Descriptor Keyword Type Default

Pin Pin string_list None

Cell Cell string_list None



Table A-2 AOCV GROUP Statement Syntax

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;


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_THRESHOLD

value Value of the variable EC_AOCV_THRESHOLD

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



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.



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


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



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 ;

};

Internal node names internal list_of_node_names None

Glitch level (in percentage) for internal node names

glitch glitch_levels None

Cell name for index selection

AUTO_INDEX_CELL cell_name None

Number of index points generated

AUTO_INDEX_POINTS value 7

Number of points for Bslew

AUTO_BSLEW_POINTS value 3




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



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


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



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 0—that 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 scales—one for rising waveforms and one for falling waveforms—that 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.



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.



Table A-5 NOMINAL Statement Syntax

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 ;


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



} ;

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


Voltage Voltage value None

Temperature Temperature value None

Process corners for loading cell models from library database

Gtcorner 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



Example

The following PROCESS statement defines three process corners:

Process typical {

voltage = 1.2 ;

temp = 25 ;

Voltage of NMOS gate.

Translates to the ecsm_vtn attribute, which is used for delay calculation.

Used as threhsold for tristate cells so that 1->Z and 0->Z arcs can be characterized.

Used for non-tristate cells if the value is lesser than the vh value.

Vtn value None

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.

Vtp value None

RC process corner RCcorner string None




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 {



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


Voltage level unit Unit REL|ABS

REL is a percentage of the voltage level unit; ABS is the fixed value.

REL

High-level voltage Vh value 1.0

Low-level voltage Vl value 0.0

Threshold-level voltage

Vth value 0.5



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 ;

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 non-linear input slew

incir “string” “”

Scaling factor for input slew

slew_derate value 0.0





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 ;// following values are specified as relative

// vs voltageVh = 1.0 1.0 ;Vl = 0.0 0.0 ;Vth = 0.5 0.5 ;Vsh = 0.8 0.8 ; Vsl = 0.2 0.2 ;tsmax = 1.0n ;// 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


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



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 ; // binary search

resistance = 10MEG ;

incir = “bf1xv” ;

} ;

Control Section

The Control section assigns the statements defined in the Define section to different processes. The db_prepare or db_gsim command reads the Control section, installs the processes appearing in the Control section, and installs all the parameters defined in the statements in the database. The Control section includes the following commands. listed in alphabetical order.

SET_CELL Command

SET_CELL ::= Set Cell ( process_name[,process_name]) {

Name = cell_name ;

Simulation = simulation_name ;

Index = index_name ;

Pulling resistance Resistance value, value, value

1000000

Default input circuit for generating non-linear input slew

incir “string” “”




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

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


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



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

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

} ;


Group name Group string None

Cell name Cell string None

Pin name Pin string.string None



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

Exampleset group (typical) {

name= 1XPAD_PINS ;

index= IO5x6d1 ;

signal= VDD2.5V ;

} ;


Group name Name string None





MARGIN statemen Margin string None




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

Exampleset pin (typical) {

name= PCI33DGZ.PAD ;

signal = VDD2.5V ;

index = 5VTIO5x6d1 ;

} ;


Pin name Name string.string None





MARGIN statement Margin string None




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

Exampleset 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* ;


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



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

} ;



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_PROCESS* | [SET_PIN] | [SET_CELL] | [SET_GROUP] | [SET_DEFINES]

SET_PROCESS ::= Set process (process_name[,process_name]) {








} ;

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 ;



rise_fall_levels::= input rise [[input fall] output rise [output fall]]

input rise::= value

input fall::= value

output rise::= value

output fall::= value

scale ::= value[:value:value]

offset ::= value[:value:value]

n_value ::= value[:value:value]

start ::= value

end ::= value

step ::= value

cell_name::=string

pin_name::=string

group_name::=string

process_name::= string

slew_name::= string

signal_name::= string

simulation_name::= string

index_name::= string

margin_name ::= string

nominal_name::= string

pin_name_list::= string [,string]*

net_name_list::= string [,string]*

instance_name_list::= string [,string]*

value::= real

Examples

Following are three examples of simulation setup files. The first one is used to generate a standard cell library, the second is used to create an I/O cell library, and the last one is used for level-shifter cells.

Standard Cell Library

Following is a sample simulation setup file used in generating a standard cell library:

// Sample stdcell simulation setup file

// For process : typical, best, worst

// table size : 7X7



// Define Section

Process typical {

voltage = 1.2 ; // as voltage

temp = 25 ; /* as temperature */

Vtn = 0.208 ;

Vtp = 0.208 ;

} ;

Process best {



Vtn = 0.272 ;

Vtp = 0.272 ;

} ;

Process worst {



Vtn = 0.192 ;

Vtp = 0.192 ;

} ;

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 ; // 50% rise/fall

Vsh = 0.8 0.8 ;

Vsl = 0.2 0.2 ;

tsmax = 1.0n ; // maximum output slew rate

} ;

Simulation std_cell {


bisec = 6.0n 6.0n 10ps ; // binary search

resistance = 10MEG;

} ;

Index X1 {

BSlew = 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 ;



} ;

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 ;

} ;

Index X12 {

load = 0.00990P 0.03960P 0.10098P 0.22176P 0.46332P 0.94446P 2.27700P ;

} ;

Index X16 {

load = 0.01320P 0.05280P 0.13464P 0.29568P 0.61776P 1.25928P 3.03600P ;

} ;

Index X20 {

load = 0.01650P 0.06600P 0.16830P 0.36960P 0.77220P 1.57410P 3.79500P ;

} ;

Index CK_SLW {

bslew = 0.0385N 0.5360N 1.0360N ;

} ;

Group CK_SLW {

PIN = *.CK ;

} ;



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 ;



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 ;

} ;



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 {


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 ; //100%

Vl = 0.0 ;

Vth = 0.432 ; //50%

Vsh = 0.6048 ; //70%

Vsl = 0.2592 ; //30%

tsmax = 1.0936e-09 ;

} ;

// Defines the simulation control variables for cell library characterization.



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 {



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 {





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 = 0.25 0.25 ;

tsmax= 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 ;



Vsh = 1.35 1.35 ;

Vsl = 0.15 0.15 ;

tsmax= 2.0n ;

} ;

Simulation core {


bisec = 4.0n 4.0n 100p ;

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 ;



} ;

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 ;



} ;

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 ;

} ;

set group (typical) {

name= 1XPAD_PINS ;

index= IO5x6d1 ;

signal= VDD2.5V ;

} ;


name= 2XPAD_PINS ;

index= IO5x6d2 ;

signal= VDD2.5V ;

} ;


name= 3XPAD_PINS ;

index= IO5x6d3 ;



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 ;

//} ;



BProperty File Format

This appendix describes the Property file format that Encounter® library characterizer uses in its processing.


Encounter Library Characterizer User GuideProperty File Format

Property File Syntax

Use the following syntax to create a property file:

{library library_name ’{’

[ tree_type tree_type_name ; ]

[ default_power_rail power_supply_name ; ]

[ power_rail power_supply_name voltage_value ; ]*

’}’; }*

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



[ 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.



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



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.



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;

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.



...

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;

}



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

table : \"L - L - - H : - - - : N N - , \\\

H L/H L - - H : - - - : L/H H/L - , \\\

L - H - L/H H : - - - : L/H H/L - , \\\

H L H - L H : - - - : L H - , \\\

H H H - H H : - - - : H L - , \\\

H - H - - H : - - - : X X - , \\\

- - - - - L : - - - : L H - , \\\

- - - L - - : - - - : - - N , \\\

- - - H - - : L/H H/L - : - - L/H\";\

}";

};

Note: All special characters should have an escape sequence (\) as used in a string.



CGate File Format

This appendix describes the Gate file format that Encounter® library characterizer uses in its processing.


Encounter Library Characterizer User GuideGate 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.

PULL_UP The port has a pull-up resistance.

PULL_DOWN The port has a pull-down resistance.

gate_type 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.


../elctxtcmdref/commandsT.html#db_gate


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

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.

INPUT A (a);

OUTPUT A (a);

a

a SUPPLY1 VDD (a);

SUPPLY0 VSS (a);

a

p

n

p

n

a

INOUT A (a, n, p); INPUT A (a); FEEDTHRU B (a);

A

A

OUTPUT A (a, n, p);

Tristate

A

B

a

A

A

a

a

VSS

VDD



Primitive Gates

The following table describes primitive gate types:

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:

Primitive Gates Number of Inputs

BUF Y=A NOT Y=~A 1

OR Y=A | B | C NOR Y=~(A | B | C...) n

AND Y=A&B&C NAND Y=~(A&B&C...) n

XOR Y=A^B^C XNOR Y=~(A^B^C...) n

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) 3

AMP Y=A>B? 1:A<B? 0:X 2



Figure C-2 MAJ and IMAJ Gates

Figure C-3 on page 174 illustrates the MUX and IMUX gate descriptions:

MAJ(Y, A, B, C);

A

B

C

MAJY

A B C Y 1 1 X 11 X 1 1 X 1 1 1 0 0 X 0 0 X 0 0 X 0 0 0

IMAJ(Y, A, B, C);

A

B

C

IMAJY

A B C Y 1 1 X 01 X 1 0 X 1 1 0 0 0 X 1 0 X 0 1 X 0 0 1



Figure C-3 MUX and IMUX Gates

Tristate Gates

The following table describes tristate gate types:

Tristate Gates Number of Inputs

BUFIF1 (NMOS) Y= if (B=1) then A else HiZ 2

BUFIF0 (PMOS) Y= if (B=0) then A else HiZ 2

NOTIF1 Y= if (B=1) then ~A else HiZ 2

NOTIF0 Y= if (B=0) then ~A else HiZ 2

CMOS Y= if (B=1 | C=0) then A else HiZ 3

PUSHPULL Y= if (A=1 & B=1) then 0 elseif (A=0 & B=0) then 1 elseif (A=0 & B=1) then HiZ elseif (A=1 & B=0) then X (inhibit)

2

MUX(Y, A, B, C); IMUX(Y, A, B, C);

A

B

C

MUXY

A

B

C

IMUXY

A B C Y 1 1 X 11 0 X 0 0 X 1 1 0 X 0 0 X 1 1 1 X 0 0 0

A B C Y 1 1 X 01 0 X 1 0 X 1 0 0 X 0 1 X 1 1 0 X 0 0 1



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

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

A

B

Y

BUFIF1 (Y, A, B);

A

B

Y

BUFIF0 (Y, A, B);

A

B

Y

NOTIF1 (Y, A, B);

A

B

Y

NOTIF1 (Y, A, B);

A

B

Y

PUSHPULL (Y, A, B);

B

A Y

C

CMOS (Y, A, B, C);



information modifying the gate file, see “The following example describes and illustrates a tristate IO cell to aid cell recognition:” on page 179.

Figure C-5 on page 176 illustrates bidirectional switches:

Figure C-5 Bidirectional Switches

Bidirectional Switches Number of Nodes

NMOSX NMOSX (D, S, G) 3

PMOSX PMOSX (D, S, G) 3

CMOSX CMOSX (D, S, NG, PG) 4

D

G

S

NG

D

S

PG

CMOSX

D

G

S

PMOSXNMOSX



Examples

The following example describes and illustrates a NAND gate:

The following example describes and illustrates a tristate buffer:

DESIGN (NAND2);

//PORT SECTION;

INPUT A (A);

INPUT B (B);

OUTPUT Y (Y);

SUPPLY1 VDD (VDD);

SUPPLY0 VSS (VSS);

//GATE SECTION

NAND (Y, A, B);

END_OF_DESIGN;

A

BY

VDD

VSS

NAND2

YB

A

EN

A Y

EN

A

P

Y

N

(To measure tpHZ)

(To measure tpLZ)

Tristate buffer (TBUF) DESIGN (TBUF);

//PORT SECTION;

INPUT A (A);

INPUT EN(EN);

OUTPUT Y (Y, N, P);

SUPPLY1 VDD (VDD);

SUPPLY0 VSS (VSS);

//GATE SECTION

BUFIF1 (Y, A, EN);

NOT ($1, EN);

NAND (P, A, EN);

NOR (N, A, $1);

END_OF_DESIGN;



The following example describes and illustrates a bidirectional buffer:

The following example describes and illustrates a differential input circuit:

EN

A

Y

EN

A

P

N

Bidirectional buffer (BIO)

PAD

Y

PAD

DESIGN (BIO);

//PORT SECTION;

INPUT A (A);

INPUT EN(EN);

OUTPUT Y (Y);

INOUT PAD (PAD, N, P);

PULL_UP;

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

END_OF_DESIGN;

DESIGN (DIN);

//PORT SECTION;

INPUT P (P);

INPUT N(N);

OUTPUT Y (Y);

SUPPLY1 VDD (VDD);

SUPPLY0 VSS (VSS);

COMPLEMENTARY P, N;

//GATE SECTION

AMP (Y, P, N); END_OF_DESIGN;

P

N

VDD

VSS

YP

NY

Differential input (DIN)



The following example describes and illustrates a tristate IO cell to aid cell recognition:

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/

POR_L

EN_OUT

D_OUT

Bidirectional IO

EXT

DESIGN (BIO);

//PORT SECTION;

OUTPUT DIN (DIN);

INOUT EXT (EXT, NET634\#10, NET635\#13);

INPUT EN_IN (EN_IN);

INPUT EN_OUT (EN_OUT);

INPUT POR_L (POR_L);

INPUT DOUT (DOUT);

//GATE SECTION

NAND ($1, POR_L, EN_OUT);

NOT ($2, $1);

BUFIF0 (EXT, DOUT, $1);

NOR (NET634\#10, DOUT, $1);

NAND (NET635\#13, DOUT, $2);

NAND (DIN, EXT, EN_IN);

END_OF_DESIGN;

DOUT

YDIN EN_IN

EXT

D$1

NET635\#13

NET634\#10

D$1


../elctxtcmdref/commandsT.html#db_gate



*.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 );

// ===========




// 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 );







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

// =================



// 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

// =================




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 //generate simulation vectors



DBool 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


Encounter Library Characterizer User GuideBool 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# ;



Boolean Operator

The following operators are available for BOOL:

Pin Attribute

The following pin attributes are available in 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 => Y = A, YB = ~A

? multiplex function Y = S?A:B => Y = S&A|(~S)&B

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



Functions

The following functions are available in BOOL:

Logical Function

■ NOT(), INV() inverter

<output> = NOT(<input>)

<output> = INV(<input>)

Example: Y = NOT(A) => Y = ~A

■ AND(), NAND() AND / NAND gate

<output> = AND(<input(1)>, <input(2)>, … , <input(n)>)

<output> = NAND(<input(1)>, <input(2)>, … , <input(n)>)

Example: Y = AND(A, B, C) => Y = A * B * C

■ OR(), NOR() OR / NOR gate

<output> = OR(<input(1)>, <input(2)>, … , <input(n)>)

<output> = NOR(<input(1)>, <input(2)>, … , <input(n)>)

Example: Y = OR(A, B, C) => Y = A + B + C

■ XOR(), XNOR() exclusive OR / NOR gate

<output> = OR(<input(1)>, <input(2)>, … , <input(n)>)

<output> = NOR(<input(1)>, <input(2)>, … , <input(n)>)

Example: Y = XOR(A, B, C) => Y = A ^ B ^ C

■ MUX() multiplexer

<output> = MUX(<input(1)>, <input(2)>, <input(3)>)

Example: Y = MUX(S, A, B) => Y = S? A: B

Function Type Keywords

Logical Function NOT(), INV(), AND(), NAND(), OR(), NOR(), XOR(), XNOR(), MUX()

Tri-state Function TBUF(), NOD(), POD()

Sequential Function DLSR(), DFSR()



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)

■ NOD( ) Nch open drain

(<output>, <ngate>) = NOD(<input_logic>)

Example: (Y, [N]) = NOD(A)

TBUF, “Tri-state Buffer” (#PAD#,[P],[N]) = TBUF(A,EN)

(Y,[N]) = NOD(A)



■ POD( ) Pch open drain

(<output>, <pgate>) = POD(i<input_logic>)

Example: (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.

(Y, [P]) = POD(A)



Sequential Function

■ DLSR( ) Level-Sensitive Latch

(<true_reg>, <comp_reg>) = DLSR(<data>, <clock>, <preset>, <clear>)

Example: (IQ, XIQ) = DLSR(D, C, 0, 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]);

(X, XQ) = DLSR(D, C, S, R)



■ 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)

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.

(Q ,XQ, [P], XP) = DFSR(D, C, S, R)



DFF,“Flip-Flop with set and reset”,

([N7],[N1],[N4],[N6])=DFSR(D,CP,!SD,!CD),

(Q, QN) = ([N1],[N7]) ;

Using a BOOL File to Aid Cell Recognition

The following procedure describes how to use a BOOL file:

1. Open a database named test.ipdb:

db_open test.ipdb

2. Load the design and SPICE model data, perform circuit recognition, create the simulation vectors, and load the characterization conditions:

db_prepare -f

3. Specify a bool file (test.bool) for performing circuit recognition. The following command overwrites the existing simulation vectors in the database and generates new simulation vectors:

db_gsim -bool test.bool -force

Note: Circuit recognition using a bool file is complete.

4. Perform circuit simulation:

db_spice







5. Include the characterization results in the out.lib file:


6. Exit Encounter library characterizer:

exit





ESpecification File Format

This appendix describes the format of the specification file, which the db_gsim command generates from information in the database. The file is in ASCII format. Do not edit the specification file.


■ 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> ) ;


Encounter Library Characterizer User GuideSpecification File Format

]*

[ REGISTER( <TrueRegName> [ , <ComplementRegName> ] )

+LOGIC( <TrueRegBooleanExpression> [ , <ComplementRegBooleanExpression> ] ) ;

]*

[ INHIBIT( <InhibitStateBooleanExpression> ) ; ]

[ COMPLEMENTARY( <TruePortName> , <ComplementPortName> ) ; ]*

[ BUNDLE( <BundleElement(1)> [ , <BundleElement(n)> ]* ) ; ]*

[ ARC( <InputPort>, <OutputPort> )

{ + POSITIVE_UNATE | + NEGATIVE_UNATE | + NON_UNATE }

[ + RISE_EDGE | + FALL_EDGE ] [ + PRESET | + CLEAR ]

[ + TRISTATE_L | + NCH_OPEN_DRAIN_L | + PCH_OPEN_DRAIN_L

| + TRISTATE_H | + NCH_OPEN_DRAIN_H | + PCH_OPEN_DRAIN_H ]

{ + TRAN( <InputEdge> : <OutputEdge> )

[ + MEASURE( <PseudoOutputNode> : <PseudoOutputEdge> ) ]

[ + CLAMP( <ClampPort> : <ClampLevel> ) ]

}*

[ + USE( <VectorName_1> [ , <VectorName_n> ]* ) ] ;

]*

[ CHECK( <ConstraintPort> [ : <ConstraintEdge> ] )

[ + RELATED( <RelatedPort> [ : <RelatedEdge> ] ) ]

[ + SETUP ] [ + HOLD ] [ + RELAESE ] [ + REMOVABLE ] [ + RECOVER ]

[ + WIDTH_H ] [ + WIDTH_L ]

[ + WHEN( <ConditionBooleanExpression> ) ]

[ + USE( <VectorName_1> [ , <VectorName_n> ]* ) ] ;

]*

[ VECTOR( <SimulationVector> )

[ + ID( <VectorName> ) ]

[ + DELAY( <ChangePorts> )

| + I_DELAY( <ChangePorts> )

| + NO_DELAY( <ChangePorts> )

| + RACE( <FirstChangeInputPorts> , <NextChangeInputPorts> ) ]

[ TARGET( port_names );

]*

END_OF_DESIGN ; }*



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



+ 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 low-level active.

NCH_OPEN_DRAIN_H Specifies that the threshold voltage at the NMOS gate is high-level active.

PCH_OPEN_DRAIN_L Specifies that the threshold voltage at the PMOS gate is low-level active.



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.


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

PCH_OPEN_DRAIN_H Specifies that the threshold voltage at the PMOS gate is high-level 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_element Specifies the number of the port or register in the bus.


../elctxtcmdref/variablesT.html#EC_DISABLE_BUNDLING


+ 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.



COMPLEMENTARY Statement

COMPLEMENTARY( true_port_name , complementary_port_name ) ;

Specifies the ports composing the differential input pair.


DESIGN Statement

DESIGN( design_name );

Indicates the beginning of the design section.


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.

USE vector_name Specifies the names of the simulation vectors.

true_port_name Specifies the name of the true port.

complementary_port_name

Specifies the name of the complementary port.

design_name Specifies the name of the design.




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.


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

inhibit_state_boolean_expression

Specifies the logic that the input pins should have to avoid a short. This is a Boolean expression.

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.



+ 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} ) Specifies the status of the clock pin.

R Specifies the rising edge in an edge-triggered clock pin.

F Specifies the falling edge in an edge-triggered clock pin.



H Specifies a high enable in a level-triggered clock pin.

L Specifies low enable in a level-triggered clock pin.

FORCE( {H|L} ) Specifies the state of the asynchronous force pin.

H Specifies that the pin is high active.

L 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.

L Specifies that the tristate pin is a low-enable pin.

X 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.



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.


VECTOR Statement

VECTOR( simulation_vector )

+ ID( vector_name )

+ DELAY( change_ports )

+ POWER( change_ports )

+ NO_DELAY( change_ports )

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.

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.



+ RACE( first_change_input_ports , next_change_input_ports )

+ TARGET( port_names ) ;

Specifies the simulation vectors to use in the SPICE simulation.


Table E-1 Simulation Vectors

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.

Symbol Vector Type Function

1 Input Force high level

0 Input Force low level

R Input Force rising edge

F Input Force falling edge



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

J Input Input search of rising edge

K Input Input search of falling edge

H Output Expect high level

L Output Expect low level

Z Output Expect high Z

U Output Expect rising edge

D Output Expect falling edge

A Output Expect tpLZ

M Output Expect tpZH

V Output Expect tpHZ

W Output Expect tpZL

- Output Don’t care

Symbol Vector Type Function



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;



Index

Numerics0 logic state 151 logic state 15

Aabsolute margin factor 129ALF file

formats to convert to 14

Bbatch mode 46bidirectional cells 15, 16binary search 21, 125BUNDLE statement 199

Ccell library characterization

bidirectional cells 15, 16binary search 21combinatorial logic cells 14, 15interface (pad) circuits 19measurement levels 27methodology used 14output driving models 30pass transistor logic cells 20pin-to-pin delay 14, 27, 28sequential logic cells 14, 15, 17, 29state-dependent models 20tristate logic cells 16

CHECK statement 200combinatorial logic cells 14, 15command file 46, 51command log file 45command-line help and man pages 48COMPLEMENTARY statement 201complex gates 20Control section 139CPPL cell 20CVSL cell 20

Ddatabase

accessing 51closing 51opening 51

db_close command 51db_open command 51Define section 122DESIGN statement 201distributed processing 31

EECSM

description of 30END_OF_DESIGN statement 201environment variables 52exclusive logic 20

GGROUP statement 122, 123Gtcorner parameter 133

Hhelp, command-line 48high-impedance states 15, 16high-to-Z propagation delays 16hold time

binary searches 139characterization for sequential logic 17characterizing 130

HTML 14

IINDEX statement 125INHIBIT statement 201interactive mode 45interface (pad) circuits 19



interface circuitry 15ipsc command 37ipsmon> command 39ipsstat command 39

KK-factor model 30

Llevel shifters 19Library Compiler

converting ALF file 14log file 45, 46low-to-Z propagation delay 16

Mman pages, command-line 48margin factors 129MARGIN statement 129measurement levels 27minimum pulse width 17, 29multi-bit logic 15

Nnetwork resource control daemon 39NODE statement 202nominal factors 130NOMINAL statement 130non-linear table model 30

Ooutput driving models 30

Pparallel processing 31pass transistor logic cells 20path logic cells 15pin-to-pin delay 14, 27, 28PORT statement 203

power consumption 28process corners

in simulation setup file 133specified by cell library

characterization 14PROCESS statement 133pulldowns 19, 139pullups 19, 139

Rrace conditions 18recovery time

characterization for sequential logic 17REGISTER statement 205relative margin factor 129release time

characterization for sequential logic 17removal time

characterization for sequential logic 17

SSchmitt triggers 19sense amplifiers 19sequential logic cells 14, 15, 17, 29SET_CELL statement 140SET_DEFINES statement 141SET_GROUP statement 142SET_PIN statement 143SET_PROCESS statement 144setup time

binary searches 139characterization for sequential logic 17

short-circuit power 28SIGNAL statement 136simulation

monitoring 39running SPICE 19vectors 206

simulation setup filecase sensitivity 122Control section 139Define section 122example for I/O cell library

characterization 155example for standard cell library

characterization 148general syntax 144



purpose 121wildcards 122

SIMULATION statement 138slc.log file 45, 46.slcrc file 52slew rate

in simulation setup file 125input 28output 28

specification fileformat 195statements in 197

SPICE format 14SPICE simulation 19state dependency 20static leakage power 28switching power 28

Ttiming constraints 14tristate logic cells 14, 15, 16typical delay 130

VVECTOR statement 206Verilog

converting ALF file to 14VHDL

converting ALF file to 14

Wwildcards 122
